Tagged: rtl-sdr

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.

Receiving GOES 16 Weather Satellite Images with the Open Satellite Project

Back in October/November of last year Lucas Teske showed us how to receive weather satellite images from the GOES line of geostationary satellites with an Airspy SDR (and possibly an RTL-SDR too), dish antenna and the decoding software that he created. 

On November 19, 2016 the next generation GOES 16 (aka GOES-R) satellite was launched by NASA. GOES 16 is a little different to the older GOES satellites as it has better sensors and is capable of capturing and transmitting a new image every 15 minutes which is quite fast. Thus a different and higher bandwidth RF transmission protocol called HRIT (High Rate Information Transfer) is used, compared to the LRIT (Low Rate Information Transfer) signal used on the older satellites.

Once the satellite started transmitting in January 2017, Lucas got to work on trying to create a decoder for the new satellite. After noticing some discrepancies between the published HRIT specs and the actual signal, Lucas sent off an email to NOAA and actually received an email back with the full specifications. With this information he was able to update his Open Satellite Project code and start decoding images from GOES 16.

The images being sent right now seem to just be relays of other similar satellites like Himawari-8 and Meteosat, as it seems that they are still testing the satellite. The relayed images received via GOES 16 received by Lucas can be seen on the Open Satellite Project twitter feed and on Lucas’ personal twitter feed.

Full disk image received via GOES 16, relayed from the Himawari-8 satellite.
Full disk image received via GOES 16, relayed from the Himawari-8 satellite.
Weather data received via GOES 16.
Weather data received via GOES 16.

HDSDR Updated to Version 2.76

The popular HDSDR software has recently been updated to version 2.76. After a three year hiatus the HDSDR developers are back in action starting with the 2.75 update which was released in early January. The 2.76 stable version released February 02, 2017 is a minor update with several bugfixes and a few new features. The 2.76 changelog is posted below:

Version 2.76 (February 02, 2017)

– switchable display mode: S-units / dBm
– switchable mode for S-meter: RMS / Peak
– enhanced accuracy of level indicators. New calibration required!
– periodic and explicit level logging into .CSV file
– switching AGC to off, sets manual gain value
– oversteering/clipping audio does now reduce gain value – not volume
– fixed OmniRig handling: “MuteOnTX”
– deactivate AFC after frequency/mode changes for a small duration
– Fast WAV file demodulation & recording
– some new keyboard shortcuts
– some other small improvements and fixes

Of interested are the new keyboard shortcuts which should improve efficiency with the program.

The 2.76 HDSDR Control Panel
The 2.76 HDSDR Control Panel

Decoding DAB with an RTL-SDR and SDR-J On an Odroid C2

The Odroid C2 is a $40 USD single board computer with a 1.5 GHz ARM-A53 quad core CPU and 2 GB of RAM. Compared to a Raspberry Pi 3 it is more powerful and costs almost the same. YouTube uploader radio innovation recently wrote into us and wanted to share his video showing SDR-J decoding DAB+ smoothly on his Odroid C2. It seems that SDR-J works perfectly and only uses a small amount of CPU.

DAB stands for Digital Audio Broadcast and is a replacement/alternative to standard broadcast FM stations. SDR-J is a software suite that includes a DAB decoder for the RTL-SDR. It is compatible with Windows, Linux and the Raspberry Pi (and evidently also the Odroid C2). Over on their website they also provide a ready to go Raspberry Pi 2 image, and they write that it should perform well on the Rpi2 platform as well.

We’ve also seen that there is a new variant of SDR-J for the Raspberry Pi (and potentially other similar devices) available on GitHub. This one has a nice touch screen friendly GUI, which should be useful for creating a cheap portable DAB device.

Alternative SDR-J Raspberry Pi GUI
New SDR-J Variant for the Raspberry Pi with nice GUI

Radioforeveryone New Posts: PiAware Step-By-Step Guide and a Guide to Feeding Other ADS-B Aggregrators

Akos from the radioforeveryone.com blog has recently uploaded some new posts. The first post is a tutorial on setting up a PiAware server with an RTL-SDR. PiAware is the official ADS-B feeder software from FlightAware.com, which is a web service that provides real time tracking of aircraft. Most of the flight data comes from volunteers around the world running a PiAware server with an RTL-SDR, ADS-B antenna and Raspberry Pi. The installation is fairly simple, involves burning an SDcard with the PiAware image, setting up the WiFi and then seeing your receiver online on the PiAware website. From there you can then configure the device further.

In the second post Akos describes how to feed other tracking websites, e.g. not just FlightAware, but also similar sites like Planefinder.net and flightradar24.com. Akos has also mentioned that a single Raspberry Pi can be used to feed all three aggregators simultaneously.

FlightAware vs FlightRadar24 vs Planefinder Plots
FlightAware vs FlightRadar24 vs Planefinder Plots

A Multichannel FM Demodulator

A few days ago programmer Phil V wrote in and wanted to let us know about his tsl-sdr MultiFM software for the RTL-SDR. This is a Python based command line program which is somewhat similar to rtl_fm, but the difference is that MultiFM allows for multiple FM audio streams to be demodulated simultaneously. Phil writes:

This is supposed to be of interest to people who might want to demodulate multiple channels to feed different parts of a monitoring workflow. This is fed by an rtlsdr in my “production” configuration, so I figure it’s relevant to your blog.

While this is something that can be done with GNUradio, there are a few things that make this unique:

1) All the calculations are done using fixed point arithmetic. This means the application runs efficiently even in low-resource systems. The intensive calculations are optimized using NEON for ARM, since my target platform is ARM-based.

2) The external dependencies are very minimal. libjansson (a JSON parser) is the only run-time dependency. ConcurrencyKit and Python are all you need to build it. This makes it fit nicely into embedded systems.

3) The behavior of the application can be set and modified based on configuration parameters only. Filter kernels, sampling requirements, and channels are all set using this configuration file, which is easy-to-understand JSON.

I’m using this as a part of a larger project that monitors multiple frequencies in a narrow 1 MHz then feeds the data into an analysis system in the cloud.

The code is also intended to be easy to understand and follow, so anyone who is trying to learn DSP and how to build these things should be able to pick it up.

The software looks quite useful especially as we have not seen many lightweight command line multichannel decoders for the RTL-SDR yet. The closest thing we’d seen previously was RTL-Airband which is designed for monitoring up to eight AM airband channels and streaming them to the internet as an MP3, but can also be used for NFM.

Phil has indicated that he may write more tutorials on MultiFM’s use in the future, for example showing how to monitor multiple 4FSK channels.

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.

Camp++ 0x7e0 // GSM signal sniffing for everyone with gr-gsm and Multi-RTL by Piotr Krysik

A Tutorial on Receiving WSPR with an RTL-SDR V3

Over on YouTube user Veryokay has uploaded a video that shows how he uses the HF direct sampling mode on one of our V3 RTL-SDR’s to receive WSPR signals. WSPR (pronounced “Whisper”) is short for Weak Signal Propagation Reporting, and is a HF ham mode typically run on very low power levels such as 1W. The data from WSPR reception can be used to determine how good or bad HF propagation is currently around the world as each WSPR message contains the callsign, 6-digit locator and the transmit power level used.

For the antenna Veryokay uses a simple random wire antenna directly connected to the SMA port of the V3 up on top of the roof of his apartment building. This gets him reception good enough to receive many WSPR signals. Then together with SDR#, VB Cable and the WSPR-X decoder software, signals can be received and decoded.

He has also uploaded a document detailing the instructions in text and image form at bit.ly/wspr-rtlsdr.

Easy WSPR reception using $19 RTL-SDR dongle