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.
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.
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.
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 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.
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.
Shmoocon 2017: Sniffing IR Signals and More! - Hak5 2120
RTL-SDR experimenter Hayati Ayguen (hayguen on GitHub) has released a version of rtl_tcp and an ExtIO module that allows access to normally hidden tuner settings. The ExtIO allows you to manually set the tuner bandwidth of the R820T/2 chip. It can be set almost anywhere between 350 kHz and 8000 kHz. In the standard drivers the tuner bandwidth is normally set at a size appropriate for the sample rate, but in this driver using a smaller bandwidth allows you to filter out unwanted signals whilst taking advantage of the decimation a higher sample rate gives you.
In addition to the tuner bandwidth settings, the ExtIO module also implements decimation controls. This allows you to reduce the displayed bandwidth without sacrificing the sample rate. At the same time the R820T/2 tuner bandwidth is reduced to the visible sample rate, improving filtering.
Hayati writes in the Readme file:
Tuner bandwidth is supported with E4000 and R820T tuners. Changing bandwidth with R820T looks good and shows immediate differences in spectrum. E4000 is not so nice, i can’t see any difference, for the bandwidths below 3400 kHz. I also put in the wider bandwidths, even wider than the samplerate, which will produce aliasing! These might be interesting for wide amplitude modulated signals, e.g. ADS-B.
Decimation of Samplerate is an option for very old and slow computers: Before decimation, a very simple and fast low-quality filter (sum) is applied: y(k) = sum over x( k * (1..decimation) ) ; x() = input samples from rtl_tcp ; y() = output samples to SDR app (HDSDR) The sum produces values requiring more than 8 bit. In addition to this soft-filter, minimize the tuner-bandwidth! You will still receive aliases!!!, but a bit damped compared to directly sampling at the slower speed. The reception’s center frequency (LO) is the most alias-free region.
The ExtIO interface. Enables tuner bandwidth and decimation controls.
A precompiled release of the ExtIO dll can be downloaded at github.com/hayguen/extio_rtl_tcp/releases. As the ExtIO connects via an rtl_tcp server, you will also need to download Hayati’s modified rtl_tcp server from github.com/librtlsdr/librtlsdr/releases/tag/win32_with_biasTee. To use the driver, first run rtl_tcp locally simply by double clicking on it, then open HDSDR and select the new ExtIO_RTL_TCP.dll file.
We tested out the tuner bandwidth functions and it appears to work well. For instance in the following image there is a strong pager signal near 157.9 MHz. At first the RTL-SDR is overloaded by the strong signal causing multiple images to appear on the spectrum. But after reducing the tuner bandwidth to 350 kHz the left side of the spectrum is attenuated, and the interfering pager signal is no longer too strong.
The modified rtl_tcp software (and rtl_(adsb|fm|power|tcp)) also support access to the software activated bias tee on our V3 dongles via the -T flag.
Tuner Bandwidth Selection Example.
Hayati has also uploaded some slides which show some of the effects of using various different tuner bandwidths.
Over on the SDRplay blog and forums OH2BUA has been sharing how he has set up ‘propagation triggered recording’ by continuously monitoring JT65/JT9 signals with his SDRplay. The idea is that you leave the radio on receiving all night, and set it to automatically start recording IQ files if good propagation conditions occur as determined by the locations received from the JT65/JT9 signal. This may yield some interesting far off stations that can be listened to in the morning, whilst weeding out hours where nothing but commonplace local stations are heard. The software is a simple Windows batch file that works together to coordinate HDSDR and JTDX. It should work with any HF capable SDR.
JT65/JT9 are weak signal propagation HF modes (also known as WSJT modes) that can be decoded all around the world, even with very weak reception thanks to strong digital error correction. They can often be used to determine propagation conditions by determining where successfully decoded messages are being sent from.
OH2BUA writes:
I have made a set of scripts and other files which can be used to build a system which monitors JT65/JT9 (digital modes) amateur radio traffic on 160m/1.8MHz band, and if nice propagation to area you are interested in exists, a MW-BC-band recording is started. When the conditions fall off, the recording is stopped.
There is an attached zip-file containing all the necessary stuff. Sorry this is a windows thing – but easily portable also for linux. Create C:\bat\ and drop all there. Have a look, starting from README.
The default example is to start a MW-band I/Q-recording, if North American ham signals are heard – but it is fully modifiable according to your target when in comes to areas, bands, schedules etc.
The files are available as an attachment to the forum post.
Where WSJT Modes are located (slideplayer.com/slide/4310450)
