Category: Applications

—–Hz: A New STD-C Inmarsat Decoder

UPDATE: Unfortunately we have been informed that the code base of this software was illegally decompiled and reused in an almost unchanged way from an already available closed source decoder. This means the program itself is illegal and totally unethical.

Please respect the original developers hard work and do not download this software.

A new STD-C Inmarsat decoder called —-Hz has recently been released. The decoder is Windows based and simply listens to the demodulated Inmarsat STD-C audio from a program such as SDR#. This means that it is compatible with the RTL-SDR, and any other SDR that can receive Inmarsat. 

We gave the software a brief test and it ran very well, and managed to decode several SafeteNET messages without issue, maintaining a good lock most of the time. The author writes that he plans to improve on the software in the future by creating a web service based version of the software.

Currently there are two other Inmarsat decoders available. One is called InmarsatDecoder and the other is the Tekmanoid decoder. The InmarsatDecoder is generally regarded as the best, but the Tekmanoid decoder was recently updated for improved performance. The new software appears to be about the same as the Tekmanoid decoder.

Inmarsat STD-C messages are broadcast from geostationary satellites in the L-band at around 1.5 Ghz. They send mostly marine based messages such as the following quoted from the ——Hz website:

  • Safety: high seas, tropical storm warnings, ice accretion…
  • Shipping activity: moving oil rigs, submarine cable deployment and repairs…
  • Distress reports: MOB, ships lost at sea, migrant ship reports…
  • Military exercises (firing practice, no fly zones…)
  • Pirate at sea reports…

If you are interested in learning how to decode STD-C we also have a tutorial available here. 

The b4000Hz Inmarsat STD-C Decoder
The ——Hz Inmarsat STD-C Decoder

re-DECTed: An RTL-SDR DECT Decoder

Over on GitHub programmer ‘znuh’ has uploaded a new RTL-SDR compatible GNURadio based tool for DECT decoding. DECT is an acronym for ‘Digital Enhanced Cordless Telecommunications’, and is the wireless standard used by modern digital cordless phones. In most countries DECT communications take place at 1880 – 1900 MHz, and in the USA at 1920 – 1930 MHz. So in order to receive these frequencies you’ll need an RTL-SDR with an E4000 chip, or some other compatible SDR that can tune this high.

It appears that the decoder is not actually able to decode audio (at least not yet or without extra work perhaps), but it can at least output the DECT packets to Wireshark for analysis. This may be of interest to those wanting to learn more about the DECT protocol.

Update: Over on the Reddit thread for this software the original poster ‘sanjuro’ has given a hint on how to (in theory) decode the audio, he writes:

In theory you only need to dump B-field data into a file and then play with g726 codec. See documentation from previous de-DECTed project http://wiki.securityweekly.com/wiki/index.php/Episode158

The re-DECTed decoder outputting packets to Wireshark.
The re-DECTed decoder outputting packets to Wireshark.

Simple NOAA/Meteor Weather Satellite Antenna: A 137 MHz V-Dipole

Over on his blog Adam 9A4QV (seller of various RTL-SDR related goods including the LNA4ALL) has just made a post detailing a build of a high performance super simple NOAA/Meteor M2 weather satellite antenna. Most antenna designs for polar orbiting weather spacecraft are based on circularly polarized turnstile or QFH designs. However, Adams antenna is based on a very simple linearly polarized dipole, which makes construction almost trivial.

The idea is that by arranging a dipole into a horizontal ‘V’ shape, the radiation pattern will be directed skywards in a figure 0 (zero) pattern. This will be optimal for satellites travelling in front, above and behind the antenna. Since polar orbiting satellites always travel North to South or vice versa, we can take advantage of this fact simply by orienting the antenna North/South. 

There is also another advantage to Adams design. Since the antenna is horizontally polarized, all vertically polarized terrestrial signals will be reduced by 20 dB. Most terrestrial signals are broadcast in vertical polarization, so this can help significantly reduce interference and overloading on your RTL-SDR. Overloading is a big problem for many trying to receive weather satellites as they transmit at 137 MHz, which is close to the very powerful FM broadcast band, air band, pagers and business radio. In contrast a circularly polarized antenna like a QFH or turnstile only reduces vertically polarized terrestrial signals by 3 dB.

As the satellites broadcast in circular polarization there will be a 3 dB loss in Adams design from using a linear polarized antenna. But this can be considered as almost negligible. Adam also argues that the home construction of a QFH can never be perfect, so there will always be at least a ~1dB loss from inaccurate construction of these antennas anyway.

The final advantage to Adams design is that construction is extremely simple. Just connect one element to the center coax conductor, and the other to the shield, and spread apart by 120 degrees.

Adam 9A4QV's V-Dipole for 137 MHz Weather Satellites.
Adam 9A4QV’s V-Dipole for 137 MHz Weather Satellites.

Adam has tested the antenna and has gotten excellent results. If you want more information about the antenna design, Adam has also uploaded a pdf with a more indepth description of the design and his thoughts.

DIY 137 MHz WX sat V-dipole antenna

137 MHz NOAA WX sat reception using V-dipole antenna

First Steps Towards Decoding HD Radio

Programmer Phil Burr wrote in and wanted to share his newest code which is a partial implementation (no audio) of the iBiquity IBOC HD Radio standard. HD Radio is a proprietary broadcast radio protocol and is used only in North America. You may have noticed it before as the rectangular sidebands on the spectrum which surround standard analogue broadcast FM signals.

The audio codec specifications are not public and is thus not implemented here, so this code has very little use outside of being a good learning tool. But Phil does write that if anyone if able to figure out how to decode the codec, then this code may be a good starting point.

Phil writes:

I wrote this because I wanted to learn about digital broadcasts. Despite the fact that the audio codec used is iBiquity’s proprietary HDC codec, I decided that writing a receiver that could decode the air interface would be a great learning experience.

iBiquity’s HDC codec is supposedly based upon some of the same technologies as HE-AAC codec so it may be possible for some audio codec gurus, given access to the raw HDC audio packets, to write a decoder for the codec.

The receiver is somewhat limited. It only decodes FM MP1 profile transmissions (which happens to includes every IBOC FM transmitter in my area). It is also somewhat limited in the Layer2 packet demultiplexing. It likely needs a strong signal in order to decode signals reasonably well. However it is just enough to get access to the main program stream.

HD Radio Sidebands Visible on the Spectrum
HD Radio Sidebands Visible on the Spectrum

Reverse Engineering Honeywell 345 MHz Home Automation Sensors with an RTL-SDR

OpenHAB is an open source home automation software program which is designed to interface and manage all the various sensors and systems in an automated house. One problem however, is that many wireless sensors and actuators utilize a proprietary communications protocol that is not supported by OpenHAB.

In his home, Dan Englender had several Honeywell 5800 series 345 MHz wireless security door sensors, all of which interface using a proprietary protocol that is not yet implemented in OpenHAB. In order to get around this, Dan decided to reverse engineer the protocol and implement a decoder into OpenHAB himself. 

Dan’s four part write up covers the RF capture & demodulation, protocol reverse engineering and implementation into OpenHAB. First he looked up the frequency and bandwidth of the signal via the FCC filing information on fcc.io. Then he captured some packets from a door sensor using his RTL-SDR and GNU Radio, and then wrote a short Python program to decode the protocol and transmit the door open/closed information to OpenHAB. In the future he hopes to optimize the decoder so that it can comfortably run on a Raspberry Pi as the GNU Radio script uses quite a bit of computing power.

The final project is called decode345 and the code is available over on his GitHub.

Honeywell 345 MHz Door Sensor
Honeywell 345 MHz Door Sensor
Custom Door Sensor Status in OpenHAB
Custom Door Sensor Status in OpenHAB

[Also seen on Hackaday]

 

RTL-SDR Waterfall on a C.H.I.P

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.

Over on the C.H.I.P forums a user ‘Basketball’ has also submitted a photo showing his C.H.I.P with LCD screen running a Python based waterfall display with his RTL-SDR. His C.H.I.P system has been modified to be portable with a 3D printed case, 10000 mAh battery and 4.3″ LCD screen. Others on the forum have also noted that they have had FreqShow successfully running on their Pocket C.H.I.Ps as well.

So if you’re looking for a low cost computing platform to run your RTL-SDR the C.H.I.P may be a good choice. 

Thanks to Mike Ladd for the submitting the forum post to us.

CHIP_waterfall
C.H.I.P Running a Waterfall Display

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.

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