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.
Akos the author of the radioforeveryone.com blog has recently added two new articles to his blog. The first post is a comprehensive guide to setting up your own ADS-B station. The guide focuses on creating a system that is easy to use, has good performance and is value for money. In the post he shows what type of computing hardware is required, what software can be used and what RTL-SDR dongles work best. He also shows what choices are available when it comes to amplification and filtering to improve signal reception and goes on to talk a bit about adapters and the antennas that work best for him.
EDIT: It’s been pointed out in the comments by antenna experts/enthusiasts that the 1/2 wave ground plane antenna described by Akos in his tutorial may not be technically correct. A 1/2 wave antenna has a huge impedance which requires some sort of matching. Without matching there is going to be about 10 dB of loss due to the mismatch, and so the antenna will perform poorly. We recommend sticking with a 1/4 wave design, which is essentially the same as Akos’ 1/2 wave ground plane antenna, just with the element lengths halved.
The existing thermostat wireless receiver is a Danfoss RX2. In order to reverse engineer the protocol Andy opened up an older that one he had and saw that it used an Infineon TDA5210 RF receiver chip. Armed with this part number he was able to look up the datasheet and determine the operating frequency. Then by using an RTL-SDR he captured some packets while pressing buttons on the thermostat transmitter and piped the audio file into audacity, where he was able to clearly see the digital waveform.
Andy then wrote a Python program using the ‘wave’ library, which allowed him to easily read binary values for a .wav file. With his code he was able to extract the data from the signal and determine the preamble, sync word, thermostat ID and the instruction code (on/off/learn).
In a future post Andy hopes to show us how he’ll use an RF69 module with an Arduino to actually control the thermostat using the reverse engineered packet knowledge.