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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.