Category: Digital Signals

NOAA using the SDRplay RSP2 and RTL-SDR for Receiving Weather Balloon Data

NOAA RSP2 setup for Receiving Radiosonde Data
NOAA RSP2 setup for Receiving Radiosonde Data

Over on the SDRplay forums there has been a post by a NOAA engineer showing how they are using SDRplay RSP2 units in the field for tracking their radiosonde weather balloons. A radiosonde is a small sensor package and transmitter that is carried high into the atmosphere by a weather balloon. It gathers weather data whilst transmitting the data live back down to a base stations. You can get data such as temperature, pressure, humidity, altitude and GPS location.

Bobasaurus' coworker launching a weather balloon.
Bobasaurus' coworker launching a weather balloon.

The NOAA engineer on the forum (handle 'bobasaurus') wrote SkySonde, which is the software used by NOAA to decode and plot data from the radiosondes. SkySonde is freely available for public download on the NOAA website. A PDF file showing how to use the SkySonde software with an RSP2 or RTL-SDR can be found here, and the full SkySonde manual is available here. The software consists of a client and server, with the server connecting to the RSP2 or RTL-SDR, and then sending data to the client. Both server and client can run on the same PC.

The hardware setup consists of an RSP2 (can be interchanged with an RTL-SDR), an Uputronics Radiosonde Filtered preamp and a Yagi antenna. Presumably a Yagi and LNA is not completely required, although the receivable range will be less. The RSP2 bias tee is used to power the preamp, and on a V3 RTL-SDR the bias tee should also work.

NOAA appears to use the iMet brand of radiosondes which transmit a Bell 202 signal. Bobasaurus writes that they transmit in the 401-405 MHz range. This video shows an example of such a signal. If you are in the US near an area that launches these iMet weather balloons you should be able to receive them. An alternative piece of software that supports iMet radiosondes is RS. For other radiosondes we have a tutorial that uses SondeMonitor available here.

SkySonde Radiosonde Software
SkySonde Radiosonde Software

Exploring Vulnerabilities in Tire Pressure Monitoring Systems (TPMS) with a HackRF

Over on YouTube the channel "Lead Cyber Solutions" has uploaded a video presentation for the Cyber Skills Competition. In the video Christopher Flatley, James Pak and Thomas Vaccaro discuss a man-in-the-middle attack that can be performed on vehicle Tire Pressure Monitoring Systems (TPMS) with a transmit capable SDR such as a HackRF.

A TPMS system consists of small battery powered wireless sensors placed on a vehicles wheels which automatically monitor tire pressure. An LCD basestation usually exists on the dashboard of the car indicating live tire pressure. Most modern cars come with this feature, and it is simple to retrofit an older car with an aftermarket TPMS system.

The idea behind the vulnerability is that a HackRF can be used to reverse engineer the TMPS signal, and then re-transmit a new fake signal that causes the base station to read the tire pressure as low. This can set off an alarm in the car and possibly cause someone to pull over. More alarmingly, they discuss how tractors have automatic tire inflation systems which work using similar sensors. A false low pressure reading could cause the tractor tires to over inflate and be damaged.

In the past we have also posted about Jared Boon's work on TPMS where he shows how privacy could be breached by monitoring and tracking TPMS identifiers.

Testing out SDRAngel with an RTL-SDR

SDRAngel is a general purpose SDR program similar to other programs like SDR#, HDSDR and SDR-Console. It is compatible with Windows and Linux systems. However, SDRAngel has certain features that make it a good program to have in your SDR software arsenal.

One good feature is that if you have a TX capable SDR like a HackRF, PlutoSDR, BladeRF or LimeSDR then SDRAngel can also be used for TXing. Marty Wittrock has done a lot of previous work figuring out how to TX with LimeSDR and SDRAngel.

If you're only interested in RXing then SDRAngel also has some convenient features such as a built in DSD decoder which can be used to easily decode DMR/MOTOTRBO, dPMR, D-STAR and Yaesu System Fusion (YSF). The decoder is based on the DSDcc library which is a complete rewrite of the original open source DSD software.  It is not quite as developed and feature rich as DSD+, but still does the job decently. SDRAngel also has LoRa and analogue TV (ATV) decoders built in as well, although the ATV decoder kept crashing the software for us.

SDRAngel also supports multiple VFO's on the same bandwidth, has built in decimation, a nice phosphor effect RF spectrum display and a frequency manager. There is also the ability to run multiple SDRs in the same software instance at the same time.

We gave SDRAngel a try on Windows and were able to easily get it up and running with an RTL-SDR. Regular WFM, FM, AM, SSB etc modes all work fine and so does the DSD decoder which we tested on a DMR signal. Getting it to decode was extremely simple, just add a DSD Demodulator channel, then click on the signal and you should be instantly decoding. It is probably the easiest way to get started on decoding a non-trunking digital voice channel, but for trunking channels and P25 signals you should probably still use Unitrunker and DSD+ or SDRTrunk.

SDRAngel Screenshot
SDRAngel Screenshot

Below is a brief tutorial on getting up an running with SDRAngel on Windows with an RTL-SDR:

  1. Download the latest version of SDRAngel from the releases section of the GitHub. Only a build for Windows x64 is available and this has the filename sdrangel64_v3.8.4.7z (version number may change in the future). Linux .deb files are also available for various Ubuntu versions.
     
  2. Using 7zip, extract the 7z file to a folder on your PC.
     
  3. Plug in your RTL-SDR dongle, and run sdrangel.exe. We assume zadig has already been previously run to install the RTL-SDR drivers.
     
  4. On the left under 'sampling devices control' click on the small hand icon. A drop down box will pop up, and from here you should be able to select the RTL-SDR. Press ok.
     
  5. Now you can click the green play button on the top left to start the SDR.
     
  6. By default the display bandwidth is zoomed in very closely with x16 decimation and a sample rate of 1 MSPS. So in the top left box change "Dec" to 1, and increase the sample rate to 2 or 2.4 MSPS if you like.
     
  7. We suggest also clicking on the 'DC' button in the top left to remove the DC spike.
     
  8. Now you can tune around just like in other software by using the frequency numbers in the top left.
  9. If you want a spectrum analyzer display, go to the bottom left box, and click on the blue spectrum icon.
     
  10. Unlike most other software you need to add a demodulator first before you can click on a signal and listen to it. The list of available demodulators can be found in the second box on the left, just below the hand icon which you used to add the RTL-SDR.
     
  11. Select the correct demodulator for your signal of interest (e.g. WFM, NFM, AM, DSD, LoRa etc...), and then click the "+" icon. This will add the demodulator to the right of the SDRAngel window. You may want to drag the right window a little large if you cannot see all of the demodulator option as well.
     
  12. Now you can click on the signal in the spectrum window to move the VFO and begin demodulating the signal. You can explore the demodulator options on the right.
     
  13. Multiple demodulators can be added if desired, just repeat steps 8 - 10. If you add more than one demodulator, the VFO's will need to be dragged.
     
  14. If you're having trouble getting a digital voice signal with DSD to be recognized, try zooming in with the decimation feature or reducing the sample rate. It doesn't seem to work too well with higher bandwidths.

Spectral Fusion with Sparrow-WiFi: SDR meets WiFi, Bluetooth, and drones in one new tool

Thanks to Mike (ghostop14) for submitting another interesting article this time about his work with spectral fusion on the WiFi and Bluetooth bands. In the article Mike describes his new Sparrow-WiFi tool, which is a tool that allows you to visualize the WiFi and Bluetooth signal spaces all in one spectral display. The hardware consists of a WiFi and Bluetooth dongle as well as optionally an SDR like the HackRF. The software displays all data simultaneously on the same display, so you can easily tell if there is some channel clashes occurring, or if there is some other source of interference. In Addition Sparrow-WiFi also works remotely and even with a Raspberry Pi mounted on a drone.

From the article he writes:

Thinking about the 2.4 and 5 GHz bands, my biggest issues with traditional wifi tools were always that apps such as inSSIDer which are great on the Windows side didn’t have a nice polished Linux GUI equivalent so I’d have to run a Windows system or virtual machine to visualize the signal space. On the flip side, some of the great Linux-only capabilities didn’t have a nice polished integrated UI and I’d have a lot of textual data, some of which the Windows tools didn’t provide, but it was harder to visualize. Then there’s the fact that wifi tools can’t “see” Bluetooth (and vice versa), and SDR historically didn’t have enough instantaneous bandwidth to show the whole 2.4 GHz or 5 GHz spectrum at one time. And, did I mention the tools don’t integrate or talk to each other so I can’t get a “single pane of glass” perspective of all the different ways to look at the same RF space simultaneously? It would be great if I could get one single view of the most common protocols and see the actual spectrum all in one place at the same time.

Now enter the era of the Internet-of-Things, new SDR receivers, and even drones and my old wifi tools seem to have been left a bit behind. Why do I say that? I can’t “see” all of the chatter from wireless networks, Bluetooth, ZigBee, NEST devices, remotes, etc. scattered all over my wireless bands in one view. Sure, I can run 3 or 4 tools independently to find the signals and try to see what they are, but it becomes tough to get a single integrated perspective. Especially when I can’t see my RF spectrum overlaid on top of the wifi SSID’s and Bluetooth advertisements to sort out what may be related to a a signal I know about and what may be something else. Ultimately, it means that I can’t clearly explain why I have poor wifi connections in one area versus another even though I may not have overlapping channels (I know, use 5 GHz and sparrow-wifi supports that too). The reason for this is simple; current tools don’t have true spectral awareness based on the most common possibilities in one integrated solution.

Now, let’s ask even harder questions. What if I want to step up my wifi “wardriving” and start “warflying”? Or, what if I need a mobile platform that can be sent into an area on a rover? Can I bring the same spectral awareness in a small enough platform to fly for example as an under-350-gram payload complete with power, wifi, spectral scans, and even pull GPS for anything we see? And, can I interact with it remotely for real-time visibility or have it work autonomously? Okay, now you’re just asking a lot. These were all goals of a new tool I just released called “Sparrow-wifi” which is now available on GitHub (https://github.com/ghostop14/sparrow-wifi.git). Sparrow-wifi has been purpose-built from the ground up to be the next generation 2.4 GHz and 5 GHz spectral awareness and visualization tool. At its most basic, it provides a more comprehensive GUI-based replacement for tools like inSSIDer and linssid and runs specifically on Linux. In its most comprehensive use cases, Sparrow-wifi integrates wifi, software- defined radio (HackRF), advanced Bluetooth tools (traditional and Ubertooth), GPS via gpsd, and drone/rover operations using a lightweight remote agent and GPS using the Mavlink protocol in one solution.

Sparrow-Wifi Spectral Fusion. Wifi & Bluetooth dongle data + Live spectrum from a HackRF.
Sparrow-Wifi Spectral Fusion. Wifi & Bluetooth dongle data + Live spectrum from a HackRF.

A full list of the possible scenarios that Sparrow-WiFi was designed for is pasted bleow.

  • Basic wifi SSID identification.
  • Wifi source hunt - Switch from normal to hunt mode to get multiple samples per second and use the telemetry windows to track a wifi source.
  • 2.4 GHz and 5 GHz spectrum view - Overlay spectrums from Ubertooth (2.4 GHz) or HackRF (2.4 GHz and 5 GHz) in real time on top of the wifi spectrum (invaluable in poor connectivity troubleshooting when overlapping wifi doesn't seem to be the cause).
  • Bluetooth identification - LE advertisement listening with standard Bluetooth, full promiscuous mode in LE and classic Bluetooth with Ubertooth.
  • Bluetooth source hunt - Track LE advertisement sources or iBeacons with the telemetry window.
  • iBeacon advertisement - Advertise your own iBeacons.
  • Remote operations - An agent is included that provides all of the GUI functionality via a remote agent the GUI can talk to.
  • Drone/Rover operations - The agent can be run on systems such as a Raspberry Pi and flown on a drone (it’s made several flights on a Solo 3DR), or attached to a rover in either GUI-controlled or autonomous scan/record modes. And yes, the spectrum output works over this connection as well.
  • The remote agent is HTTP JSON-based so it can be integrated with other applications
  • Import/Export - Ability to import and export to/from CSV and JSON for easy integration and revisualization. You can also just run 'iw dev <interface> scan' and save it to a file and import that as well.
  • Produce Google maps when GPS coordinates are available for both discovered SSID's / Bluetooth devices or to plot the wifi telemetry over time.
Sparrow WiFi running on a Raspberry Pi on a drone
Sparrow WiFi running on a Raspberry Pi on a drone

Tracking RS41-SGP weather balloons and reporting them to the APRS Network

Over on his blog Daniel Estevez has created a post showing how an RTL-SDR can be used to receive, plot and forward RS41-SGP radiosonde data to the APRS-IS network. Radiosondes are the small payloads used on weather balloons. They transmit weather and positional telemetry data back to a base station at the meteorological agency. But depending on the frequency used in your country it can be fairly easy to receive this data yourself with an RTL-SDR dongle and some decoding software. We have an introductory tutorial for radiosonde decoding available here.

In his area of Barajas, Spain the meteorological agency recently switched to the newer RS41-SGP radiosondes. To decode these Daniel uses the open source "RS" software which is capable of decoding various radiosondes including RS41. He notes that for now it is better to use his fork of "RS" as the base version contains a bug. He also shows how the received data can be plotted in Viking, which is a program used for plotting things like GPS tracks on a map.

Finally he shows how to feed the radiosonde data to the APRS-IS network. APRS is a packet radio system used by hams which works via radio and the internet, allowing for worldwide communication by radio. Feeding the data into APRS-IS allows anyone to see the flightpath on a site like aprs.fi.

Radiosonde Flight Path
RS41 Radiosonde Flight Path recorded by Daniel Estevez

A Tutorial on Receiving HRPT Weather Satellite Images with an SDRplay RSP2

RSP2user's HRPT equipment

Over on the SDRplay forums user 'RSP2user' has put up a quality post describing how he receives HRPT weather satellite images with his SDRplay RSP2. HRPT stands for 'High Resolution Picture Transmission' and provides a much higher resolution image compared to the APT weather satellite images typically downloaded from NOAA satellites. Somewhat confusingly the picture quality of HRPT is similar to LRPT (low rate picture transmission) which is used on the Russian Meteor M series weather satellite. HRPT provides 1.1 km resolution, whilst LRPT provides 1 km resolution.

Currently there are multiple satellites broadcasting HRPT signals including NOAA 19, NOAA 18, NOAA 15, Meteor M2, Fengyun 3B, Fengyun 3C, Metop A and Metop B.

The difference in difficulty of receiving APT and LRPT versus HRPT transmissions typically occur in the L-band at about 1.7 GHz, and requires a directive high gain antenna with tracking motor to track the satellite as it passes over. This makes these images many times more difficult to receive compared to APT and LRPT which only require a fixed position antenna for reception at the more forgiving 137 MHz.

Over on his post RSP2user shows how he uses a repurposed Meade Instruments telescope tracking mount and controller to drive the tracking of a 26 element loop Yagi antenna. A 0.36dB noise figure LNA modified with bias tee input is used to boost the signal and reduce the noise figure. The signal is received by a SDRplay RSP2 and processed on a PC with USA-satcoms HRPT decoder software, which is available for purchase by directly contacting him. The HRPT signal bandwidth appears to be about 2.4 MHz so possibly an RTL-SDR could also be used, but it might be pushing it to the limit.

If you are interested, RSP2user also uploaded an APT weather satellite image reception tutorial on another post. This tutorial shows how to build a quality quadrifilar helix antenna as well.

Receiving the HRPT signal on USA-Satcoms' HRPT decoder.
Receiving the HRPT signal on USA-Satcoms' HRPT decoder.

QRadioLink Development Webpage Now Up

Back in September we posted [1, 2] about the QRadioLink software which is an RTL-SDR compatible digital amateur radio voice decoder and encoder program for Linux and Android (with chroot). It supports modern digital voice codecs like Codec2 and Opus. It is capable of being used with multiple SDRs, and can be used for transmitting digital voice too if you have a transmit capable SDR.

Andrian the developer recently wrote in to let us know that QRadioLink now has a website at qradiolink.org that you can follow for updates about its development. The website also explains some of the features of the software, and lists possible performance values of digital voice. The features include:

  • Receives and transmits analog voice, digital voice, low resolution video, text, IP protocol.
  • Narrow band modem with Codec2 or wideband modem and Opus.
  • Digital Modems: BPSKQPSK2FSK4FSK
  • Modes: narrow FM, SSB, digital voice, digital video, digital data
  • Formats: Codec2 700B, Codec2 1400, Opus 10 kbit/s
  • Video formats: JPEG
  • Supported hardware: Ettus USRPRTL-SDR, HackRF, BladeRF and in general all devices supported by gr-osmosdr

Typical Receiver performance is given in the following table, with all values being measured on an R820T RTL-SDR.

Mode Condition Sensitivity (dBm)
Codec2 700B 20 db SINAD -115
Codec2 1400 20 db SINAD -112
Opus 20 db SINAD -102
Narrow FM 12 db SINAD -118

In the future Adrian hopes to expand the software to include features like VOIP integration, SSB transceiver, DTMF & CTCSS encoder/decoders, multi-channel RX, HD video, remote control and a GUI improvement.

QRadioLink Main Page

Using an RTL-SDR and RPiTX to Defeat the Rolling Code Scheme used on Some Subaru Cars

Over on GitHub Tom Wimmenhove has been experimenting with the car keyfob on his Subaru car, and has discovered that the rolling code scheme used is very weak and so can be easily exploited.

Most modern vehicles use some form of rolling code security on their wireless keyfobs to prevent unauthorized replay attacks. When the car owner presses a button on the keyfob, a unique rolling code is sent to the car. If it matches one of the codes currently stored in the car, the car will unlock and then invalidate that code so it can never be used again, thus preventing a replay attack. On the next press the keyfob sends a new code. In most designs when a code is used up, a new code is added to the list of valid codes via a random number generator based on a secure algorithm only known (presumably) to the engineers.

Essentially Tom found that instead of producing a randomly generated rolling code, the Subaru keyfob simply increments the rolling code number each time. This allows an attacker to perform a second key press simply recording an initial real key press, decoding the packet, increasing the decoded rolling code by one, then re-transmitting. It also means that the attacker could continually raise the rolling code value on the car himself, which would eventually make the real keyfob useless as the codes on the keyfob would be outdated and no longer match the same number range as the car.

The entire exploit was found on a super low budget. Tom used only an RTL-SDR and Raspberry Pi. The receive is obviously handled by the RTL-SDR, but the transmit side is handled by RPiTX which is software that allows the Raspberry Pi to transmit RF signals directly from a GPIO pin without the need for any additional transmitting hardware. Tom writes that the exploit probably affects the 2006 Subaru Baja, 2005 - 2010 Subaru Forester, 2004 - 2011 Subaru Impreza, 2005 - 2010 Subaru Legacy and the 2005 - 2010 Subaru Outback. Tom also writes that various dealers and spokes people have contacted him stating that the exploit probably only affects US models. If you have one of the affected models and are worried the only way to stay safe is to simply not use wireless entry on the keyfob, at least until/if Subaru fixes the issue with a recall. Although so far no statement from Subaru has been released.

Tom has also uploaded a demonstration video to YouTube which is shown below.

[Also seen on Hackaday, Bleeping Computer and The Register]