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 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.
Over the Horizon radar is typically used at HF frequencies and is used to detect targets from hundreds to thousands of kilometers away from the radar station. On HF they are very common and can be easily heard as continuous or bursty buzzing sounds.
Over on his blog Daniel Estevez writes how he was inspired by Balint Seebers GRCon16 talk to perform his own investigations into HF OTH radar. Daniel first analyzed a recorded IQ signal of a presumed Russian radar in Audacity, and noticed that it consisted of 15 kHz wide pulses repeated at 50 Hz intervals. He then used GNU Radio and the Quadrature Demod block to FM demodulate the pulse and see how the frequency changes over time. From this he was able to determine the original transmitted radar pulse characteristics
Next he performs pulse compression, which is essentially a cross correlation of the received pulse and transmitted pulse which was determined from the characteristics found earlier. The signal being received at Daniels location is distorted, because it will arrive from multiple paths, since the signal will bounce of multiple layers of the ionosphere. With this pulse compression technique Daniel is able to determine the time of flight for the different multi-path components of the received pulse. By graphing all the results over time he was able to obtain this image illustrating relative propagation distance over time.
RTL-SDR.com reader Syed Ghazanfar Ali Shah Bukhari from the Frequency Allocation Board in Pakistan recently emailed us to let us know a trick he’s found which lets you combine the bandwidths of two HackRF software defined radios in GNU Radio. Syed’s program is based on Oliver’s flowgraph that we posted previously, which was used to combine the bandwidth of two RTL-SDR dongles.
Syed also sent us the GRC file to share which we’ve uploaded here.
I have used grc flow graph of Oliver as mentioned in the link :- http://www.rtl-sdr.com/combining-the-bandwidth-of-two-rtl-sdr-dongles-in-gnu-radio and modified it to be used with 2 HackRF Ones. I also shifted the two bandwidths inward by 1 MHz instead of 0.2 MHz to make a smooth continuation for a 38 MHz spectrum. Unfortunately one of my HackRF Ones has its RF Amp burnt up so I adjusted its IF and BB gain to have same noise floor as that of other HackRF One. It’s really awesome. I am sending you the diagram and grc file. The attached image is showing complete GSM900 downlink spectrum (38 MHz) in my area with active 2G and 3G signals.
Back in September the GNU Radio 2016 (GRCon16) conference was held. GRCon16 is an annual conference centered around the GNU Radio Project and community, and is one of the premier software defined radio industry events. GNU Radio is an open source digital signals processing (DSP) tool which is often used with SDR radios.
One of our favorite talks from the conference is Micheal Ossmanns talk on his idea to create a low cost $150 RX/TX radio. Micheal Ossmann is the creator of the HackRF which is a $299 USD RX/TX capable SDR. It was one of the first affordable general purpose wide frequency TX capable SDRs. Micheal also mentions his other projects including Neapolitan which will be an add on for the HackRF which will enable full-duplex communications and Marizpan which will essentially be a single board Linux SDR using the HackRF circuit.
Another is Balints talk on “Hacking the Wireless World” where he does an overview of various signals that can be received and analyzed or decoded with an SDR. Some applications he discusses include Aviation, RDS Traffic Management Channel, Radio Direction Finding, OP25, IoT, SATCOM and his work on rebooting the ISEE-3 space probe.
After listening to dock workers with his RTL-SDR for a few days, RTL-SDR.com reader Eoin decided that he wanted to try a more practical experiment. He decided to see if he could reverse engineering the wireless protocol on his garage door opener. Upon opening his remote he discovered a bunch of DIP switches, which are presumably used to program the remote to a particular garage door. Eoin’s next step was to determine at what frequency the garage door opener was transmitting at. He made an assumption that it would be in the 433 MHz unlicenced ISM band as this is where many handheld remotes transmit at. He was right, and found the signal.
His next step was then to record the signal audio in Audacity. From the audio waveform he could see a square wave which looked just like binary bits. By manually eyballing the waveform and translating the high/low squarewave into bits he was able to get the binary data. He then confirmed this data with the dipswitch positions and discovered that a 010 binary code matched with the UP position on the dip switch and 011 matched with the DOWN position.
Having decoded the signal manually fairly easily, Eoin decided his next challenge would be to automate the whole decoding in GNU Radio. In the end he was successful and managed to create a program that automatically determines the position of the DIP switches from the signal. His post goes into detail about his algorithm and GNU Radio program.
The GOMX-3 is a CubeSat which carries an experimental ADS-B repeater. Since it is a satellite the experimental receiver hopes to be able to receive ADS-B from orbit, then beam it back down to earth at a frequency of about 437 MHz using a GFSK at 19200 baud high data rate transmission protocol. From space the GOM3-X satellite can see many aircraft at one time and space based tracking allows for aircraft tracking over oceans.
Recently the creators of the satellite, GomSpace released a complete decoder for the ADS-B downlink, and now it has also been turned into a GNU Radio flowgraph by Daniel Estevez which can output decoded aircraft position data directly to a KML file which can then be opened in Google Earth or similar. This blog by DK3WN shows several logged decodes of the satellite and shows what the signal looks like in SDR#. Some of his posts also curiously shows what looks to be a Windows decoder, or logger, though we were unable to find a download for it.
Decoding the downlink should give you real time ADS-B data in your area, but the full log of stored stored data is apparently only downloaded when the satellite passes over the GomSpace groundstations which are mostly located in the EU.
To run GNU Radio for Windows you will need a 64-bit version of Windows 7/8/10. It appears that the installation is as easy as running the installer and waiting for it to download and install the 1.7 GB worth of files.
Also, over on his blog author designing on a juicy cup posted about how he’d been able to get the GNU Radio Windows binaries to run a ATSC HDTV decoder from a file recorded using an SDRplay RSP (ATSC is too wideband for an RTL-SDR to decode). ATSC is the digital TV standard used in North America, some parts of Central America and South Korea. He writes that one advantage to using GNU Radio on Windows is the ability to use a RAM drive for faster file processing.