Category: Applications

First Steps Towards Decoding HD Radio

Programmer Phil Burr wrote in and wanted to share his newest code which is a partial implementation (no audio) of the iBiquity IBOC HD Radio standard. HD Radio is a proprietary broadcast radio protocol and is used only in North America. You may have noticed it before as the rectangular sidebands on the spectrum which surround standard analogue broadcast FM signals.

The audio codec specifications are not public and is thus not implemented here, so this code has very little use outside of being a good learning tool. But Phil does write that if anyone if able to figure out how to decode the codec, then this code may be a good starting point.

Phil writes:

I wrote this because I wanted to learn about digital broadcasts. Despite the fact that the audio codec used is iBiquity’s proprietary HDC codec, I decided that writing a receiver that could decode the air interface would be a great learning experience.

iBiquity’s HDC codec is supposedly based upon some of the same technologies as HE-AAC codec so it may be possible for some audio codec gurus, given access to the raw HDC audio packets, to write a decoder for the codec.

The receiver is somewhat limited. It only decodes FM MP1 profile transmissions (which happens to includes every IBOC FM transmitter in my area). It is also somewhat limited in the Layer2 packet demultiplexing. It likely needs a strong signal in order to decode signals reasonably well. However it is just enough to get access to the main program stream.

HD Radio Sidebands Visible on the Spectrum
HD Radio Sidebands Visible on the Spectrum

Reverse Engineering Honeywell 345 MHz Home Automation Sensors with an RTL-SDR

OpenHAB is an open source home automation software program which is designed to interface and manage all the various sensors and systems in an automated house. One problem however, is that many wireless sensors and actuators utilize a proprietary communications protocol that is not supported by OpenHAB.

In his home, Dan Englender had several Honeywell 5800 series 345 MHz wireless security door sensors, all of which interface using a proprietary protocol that is not yet implemented in OpenHAB. In order to get around this, Dan decided to reverse engineer the protocol and implement a decoder into OpenHAB himself. 

Dan’s four part write up covers the RF capture & demodulation, protocol reverse engineering and implementation into OpenHAB. First he looked up the frequency and bandwidth of the signal via the FCC filing information on fcc.io. Then he captured some packets from a door sensor using his RTL-SDR and GNU Radio, and then wrote a short Python program to decode the protocol and transmit the door open/closed information to OpenHAB. In the future he hopes to optimize the decoder so that it can comfortably run on a Raspberry Pi as the GNU Radio script uses quite a bit of computing power.

The final project is called decode345 and the code is available over on his GitHub.

Honeywell 345 MHz Door Sensor
Honeywell 345 MHz Door Sensor
Custom Door Sensor Status in OpenHAB
Custom Door Sensor Status in OpenHAB
[Also seen on Hackaday]

 

RTL-SDR Waterfall on a C.H.I.P

The C.H.I.P is a $9 USD single board computer which is similar to a Raspberry Pi. It is powerful enough to run the RTL-SDR, and in fact the Outernet project use the C.H.I.P together with our V3 dongles in their DIY kit to receive, decode and serve their free L-band satellite data service.

Over on the C.H.I.P forums a user ‘Basketball’ has also submitted a photo showing his C.H.I.P with LCD screen running a Python based waterfall display with his RTL-SDR. His C.H.I.P system has been modified to be portable with a 3D printed case, 10000 mAh battery and 4.3″ LCD screen. Others on the forum have also noted that they have had FreqShow successfully running on their Pocket C.H.I.Ps as well.

So if you’re looking for a low cost computing platform to run your RTL-SDR the C.H.I.P may be a good choice. 

Thanks to Mike Ladd for the submitting the forum post to us.

CHIP_waterfall
C.H.I.P Running a Waterfall Display

Removing that Center Frequency DC Spike in Gnuradio the Easy Way

Recently RTL-SDR.com reader ghostop14 wrote in to us and wanted to share his GNU Radio block and tutorial that shows how to get rid of the DC spike in GNU Radio. The DC spike is the annoying spike in the middle of the spectrum that appears no matter where you tune and shows up with almost all SDRs, such as the HackRF used by ghostop14. Software programs like SDRsharp and HDSDR have algorithms in place to filter and remove the DC spike, but until now there was no block that existed for GNU Radio.

If you’re looking for the quick solution, the CorrectIQ GNU Radio block by ghostop14 is available at https://github.com/ghostop14/gr-correctiq.git. But if you want an interesting read on how ghostop14 figured out how to create the block, then he’s done a nice writeup which is available here (pdf). Some excerpts:

It’s your first time with gnuradio and you love your hackrf. You’ve played with receiver software like SDRSharp and audio piping to decode your favorite signal of choice, and now you’re ready to dig deeper and learn more about SDR. Everyone’s talked about gnuradio, so you install it and fire up your first flowgraph. You drop in an osmocom source block and set the device to hackrf, set your sample rate, frequency, and gain then connect it to a frequency sink and hit the button to generate your flowgraph. The ease with which you just built a receiver and the excitement about the possibilities is overwhelming… you can’t wait to hit play.

Then it happens. Right in the middle of your first flowgraph is this huge signal spike that you know is not the signal you want to receive, and as you change the frequency it follows you. What?!? So your first thought is you did something wrong. After all you’re new to gnuradio and you’re sure you’re making a newbie mistake. First you make sure there really isn’t a signal there. You go back to SDRSharp and there’s no spike. Then you swap out your hackrf for your airspy and rtl-sdr dongle, feed that into gnuradio, and there’s still no spike. What’s going on? Why is my favorite SDR that I want to use doing this? What you’ve stumbled on is an artifact of the way SDR radios do IQ sampling. Your first attempts at searching on the problem reveal that it’s called a DC spike and it’s going to appear in the raw IQ data and there’s nothing you can do to stop it. So you go back to your favorite search engine because you can’t be the first person to want to get rid of it and you find that folks say that you have 3 options: 1.) ignore it (yeah not happening. It’s huge and right in the middle of my spectrum!) 2.) Offset tune away from it on your center frequency (which means every flowgraph I make or download I’m going to have to custom change to actually get a clean center frequency signal to make them work. There has to be a better way!), or 3.) filter it out.

(cntd…)

I finally had a few hours to look into the problem further and spent the time to search and understand what was happening, and the math behind fixing it. Then researched how others were doing the same thing in their code. Turns out the solution is simple. Since the data represents an alternating RF signal, over time the signal average in a clean signal should be zero (I know I’m oversimplifying it). When there’s the IQ DC spike, that average isn’t zero. So the solution is to calculate a weighted average over ongoing samples and simply subtract it from each future sample. It doesn’t affect the overall quality of the filtered signal, but as long as the spike is on the center frequency, this approach very efficiently gets rid of it. And that was what I was hoping to accomplish.

The CorrectIQ block which gets rid of the DC spike in GNU Radio.
The CorrectIQ block which gets rid of the DC spike in GNU Radio.

Camp++ YouTube Talk: GSM Signal Sniffing for Everyone with GR-GSM and Multi-RTL

Over on YouTube the channel Budapest Hackerspace has recently uploaded a talk by Piotr Krysik which was given during the August 2016 Camp++ 0x7e0 information security conference. The talk is titled: “GSM signal sniffing for everyone with gr-gsm and Multi-RTL by Piotr Krysik” and talks about using the gr-gsm software and RTL-SDR dongles to sniff the GSM mobile phone network. Also, a tool developed by Piotr called multi-rtl which allows the proper synchronization of multiple RTL-SDR dongles in order to cover the large gap between the GSM uplink and downlink frequencies is discussed.

The talk explains a bit about how GSM works, and then goes on to talk about the gr-gsm and multi-rtl software. The talk blurb reads:

Gr-gsm is a set of tools for receiving GSM transmissions, which works with any software radio hardware capable of receiving GSM signal. Together with widely available RTL2832 based TV dongles, that are popularly used as low cost software radio receivers (known as RTL-SDR), it enables everyone to receive and study protocols used in GSM’s mobile radio interface.

Ability to receive signals spread over wide frequency range exceeding single RTL-SDR receiver’s bandwidth (~2.4MHz) was available exclusively for the owners of more capable and more expensive SDR devices. With introduction of Multi-RTL project by the author of the talk, this limit was overcome through synchronization of multiple RTL-SDR receivers in time domain, that doesn’t require complicated hardware modifications. With Muli-RTL it is possible to receive for example uplink and downlink of GSM900 transmissions, that are separated by 45MHz.

Speaker will present origins of both of the projects, together with description of their inner workings, examples of applications and plans for the future.

The talk slides can be downloaded here.

https://www.youtube.com/watch?v=xnXMKRIqkZ4

Hak5 at Shmoocon 2017: Shock Collar Radio Roulette, GNU Radio, Sniffing IR (Terrahertz) Signals and More!

Over on YouTube the popular Hak5 channel has uploaded a video with several SDR related topics mentioned during Shmoocon 2017 conference.

One fun event talked about in the video was the Shmoocon wireless village SDR contest by Russell Handorf which involved wireless dog shock collars. These are collars usually placed on dogs, that emit a mild electric shock when a button on a wireless remote is pressed. This can help train the dog into better behaviors. Contestants were able to first make recordings of the wireless signals made by the shock collars. Then each contestant strapped a wireless shock collar to their leg and the goal was then to reverse engineer and understand the protocol as quickly as possible, then use that knowledge and a HackRF to shock the other contestants.

Another part of the video discuss GNU Radio reverse engineering with representatives from bastille.net who are wireless IoT security researchers. The video then goes on to interview Micheal Ossmann (creator if the HackRF) who talks a bit about his work in building an infrared (IR) software defined radio. Micheal explains how infrared is essentially just radio at terrahertz frequencies and that many SDR concepts can be applied by using a photodiode sensor. He mentions that there are several IR systems used these days, such as the common remote control, toys, and high bandwidth wireless IR headphones used in car entertainment systems and conferences. The hardware Micheal has created is called “Gladiolus” and is still in development.

https://www.youtube.com/watch?v=yMf1DKsJKns

rtlmic: Wireless Microphone Receiver for RTL-SDR

Over on GitHub a new program called rtlmic has recently been uploaded. The program descriptions reads: 

rtlmic is a multichannel FM microphone receiver/demodulator for RTL-SDR cards. It outputs realtime audio to JACK.

Basic usage is simply:

$ rtlmic [channel 1 frequency] [channel 2 frequency]…

This program may be able to be used as a replacement for wireless microphone base stations at events. The software allows you to capture as many channels as your CPU can handle, within the active bandwidth of the RTL-SDR. There are also settings for tweaking the companding ratio and tau, deemphasis tau and FM deviation all of which affect the output audio and can be used to optimize the frequency response of the microphone.

The audio outputs directly to Jack audio which is an audio piping API, which simply routes the audio out to wherever you choose it to go.

A typical wireless microphone base station and microphones.
A typical wireless microphone base station and microphones.

CNxROOT Two Posts: How to Build an RTL-SDR Server with OpenWRT, Creating a GSM BaseStation with OpenBTS and a USRP

Recently security researcher cnxroot wrote in to let us know about two of his posts that may be of interest to readers. The posts are written in Chinese, so please use Google Translate to read them in English – it translates okay to some extent.

The first post shows us how to run the RTL-SDR on an OpenWRT capable router server. OpenWRT is a Linux firmware/OS that can be installed on several compatible router devices which extends the usefulness and features of the router. Since it is running Linux the RTL-SDR drivers can be installed onto it, and then rtl_tcp can be run, providing a remote RTL-SDR.

The second post is a bit more advanced. It is about creating a pseudo GSM base station with a USRP SDR and intercepting IoT devices which connect over GSM/GPRS. The post shows how to set up OpenBTS which can be used to create a base station.

RTL-SDR running on an internet router with OpenWRT.
RTL-SDR running on an internet router with OpenWRT.