If you are in the USA, you might recognize HD Radio (aka NRSC-5) signals as the rectangular looking bars on the frequency spectrum that surround common broadcast FM radio signals. These signals only exist in the USA and they carry digital audio data which can be received by special HD Radio receivers. Earlier in the year in June a breakthrough in HD Radio decoding for SDRs like the RTL-SDR was achieved by Theori when he was able to piece together a full HD Radio software audio decoder that works in real time.
It turns out that some of these HD Radio signals run by iHeartRadio also contain other data streams such as live weather and traffic data that is consumed by HD Radio based car GPS receivers or audio head units in US vehicles. HDRadio.com also write that they can embed other data such as sports scores and emergency messages into the data stream as well.
KYDronePilot's Python script utilizes Theori's decoder to save all received weather and traffic data maps for a folder. Below is an example of traffic and weather data that he received.
HD Radio Received Traffic DataHD Radio Received Weather Data
Inmarsat STD-C is an L-band geosynchronous satellite signal that transmits at 1.541450 GHz. This means that the signal can be received with a simple patch antenna, LNA and RTL-SDR dongle. The satellite is geosynchronous (stationary in the sky), so no tracking is required. On the STD-C channel you'll see messages mainly for mariners at sea such as weather updates, military operational warnings, pirate sightings/reports, submarine activity, search and rescue messages and more. If you are interested we have a tutorial based on other software packages available here which also shows some STD-C message examples. The tutorial can easily be adapted for use with Scytale-C instead.
We've also seen on Twitter that Scytale-C beta tester @otti has noted that a SDR# plugin based on Scytale-C seems to be in the works.
An Important Note on the Coding Ethics of Scytale-C + Tekmanoid Decoder Updates
We feel that it is responsible to make a note on coding and licencing ethics about this software. Originally the software was illegally decompiled by 'microp11' from the closed source Tekmanoid STD-C decoder written by Alex and re-released in a different programming language with a different GUI as the 'open source' B4000Hz software. After Alex took action and micrcop11 realized what he did was wrong he took B4000Hz down. Since then microp11 notes that he has written Scytale-C fully from scratch without the closed source code knowledge. But to be unquestionably legal a full two man clean-room rewrite would probably need to be done as once knowledge of source code is acquired it can be difficult to think of a separate implementation (a somewhat related post discussing this on StackExchange).
However, Alex has noted microp11's passion, and microp11's remorse at the initial decompilation and release of B4000Hz, and has decided to take the higher road and not pursue any further DMCA complaints. Instead he has kindly decided to allow the software to exist, but with acknowledgement of Tekmanoid included. We're glad that the matter was resolved amicably, but still if you use the Scytale-C software we would urge you to still consider the free or paid version of the Tekmanoid STD-C decoder to support Alex.
Recently Alex has updated his software to include a spectrum analyzer and more appealing method of displaying EGC messages. Alex writes regarding his Tekmanoid STD-C decoder:
This software [Tekmanoid STD-C Decoder] is closed source and has been since it was first released around 2009. At that time I made a choice to keep the source private but share the executable EGC app for free with the public, so that others could have some fun on the L-band!
The "pro" EGC-LES version was developed in parallel the same year but kept private, nobody even knew it existed. Although I recognized its potential financial value I didn't take "advantage" of it. Firstly because it was a personal hobby project (can't put a price on intellectual property) and second, because I didn't want to help to further expose people's private communications to the open public.
In February 2017 a raw clone of my de-compiled code was made public, to be later withdrawn with an apology. That is the moment I decided to release the PRO version as payware to the public. Many new features present in today's PRO version have been proposed by users and my aim is to satisfy everyone's wishes.
Recently another similar project was released from the same author, with lots of documents to support the code and only minute traces of the initial de-compilation. This time one could indeed claim to have built it "from scratch" - codewise at least. The fact still remains that *part* of the knowledge (not 'code' necessarily) required to put it together was obtained from this initial reverse engineering process.
Despite the negativity surrounding this case, I decided to withdraw my takedown request on the project in exchange for an acknowledgement to the original Tekmanoid decoder, as this person himself wished to include from the start anyway.
To end it with another positive note, I can only hope this newcomer will bring something new to the scene, and that we will see some interesting things!
Below is a video of the updated Tekmanoid decoder.
Tekmanoid EGC+LES pro decoder
Update: Microp11 wrote to us after this post went out and wrote the following:
I just want to let you know that scytalec is not a re-write. It is another solution of solving the problem of decoding the Inmarsat-C. Written from scratch. Inadvertently any Inmarsat-C decoder in the 1.5GHz band will have the same the building blocks and they are now documented in detail in the bibliography published with my code. The information is hard to find. All the information is from publicly available sources only. Such that the code will be able to withstand the obstacles or remaining open source. The majority of the documentation is technical manuals, as they each in part reveal a piece of the puzzle, and collectively they contain an almost complete communication protocol. Some are books and they must be the specific revision mention within the bibliography. Moreover if any coder will read the documentation they will actually be able to write a better decoder as I found parts of it too late for a more elegant code writing. And this is the whole idea of scytalec, that anyone can do it if they put their mind to it. There is enough documentation to tackle the C-band as well. And giving enough time, I might be planning on doing that after the sdr# plugin I’m working at. Not alone, as I was and I am being helped by others to which I am grateful and their names were and will be mentioned within the code. Just so you will have an idea of how deep the documentation correctness went for this project, even if a code comment was incorrect, say I was referring to a frame as a “block” or “part” I would get an admonishing email on that. So yes, I have high reasons to stand by this code originality.
Over on their website the team behind the QIRX SDR software have written up an investigation into the feasibility of using RTL-SDR for phase coherent experiments. Phase coherent receivers can allow for experimenters such as interferometry, passive radar, direction finding, etc. In their experiment they connected the clocks of two RTL-SDR dongles together so that each dongle is running from a common clock. They then used their software to check if there was coherence on a DAB signal that they were receiving. To do this they used the null symbol present in DAB signal data to trigger the IQ display for each dongle. One display shows the difference in IQ data between the two dongles. If there is phase coherence then the graph should display zero. Their results found the following:
It has been possible to achieve phase-coherent operation of two I/Q data streams.
It has NOT been possible to achieve phase-coherent operation on every run of the system.
The system showed sub-sample time delay between the two receivers (if the interpretation of the observed behaviour is correct), varying randomly between different runs. A time delay of the two receivers sufficiently small for DAB demodulation of interleaved signals could only be achieved by pure chance. No attempts have been made to solve this problem during the experiments.
The system showed varying phase differences between the two receivers, changing at a constant rate. Three different changing rates have been observed during the experiments. A working solution has been found for this phenomenon, consisting in an continuous permanent correction of the phase angles of every sample. This imposes a considerable enhanced processing load. The occurrence of three different relative phase angle rotation speeds seemed strange. With the lack of documentation any attempt to interpret this behavior seems pure speculation.
Most readers of this blog are probably familiar with the more commonly received APT images that are broadcast by the NOAA satellites at 137 MHz, or perhaps the LRPT images also broadcast at 137 MHz by the Russian Meteor M2 satellite. HRPT signals are a little different and more difficult to receive as they are broadcast in the L-band at about 1.7 GHz. Receiving them requires a dish antenna (or high gain Yagi antenna), L-band dish feed, LNA and a high bandwidth SDR such as an Airspy Mini. The result is a high resolution and uncompressed image with several more color channels compared to APT and LRPT images.
In his video Tysonpower shows how he receives the signal with his 3D printed L-band feed, a 80cm offset dish antenna (or 1.2m dish antenna), two SPF5189Z based LNAs and an Airspy Mini. As L-band signals are fairly directional Tysonpower points the dish antenna manually at the satellite as it passes over. He notes that a mechanised rotator would work a lot better though. For software he uses the commercial software available directly from USA-Satcom.com.
SourceForge user randaller has recently released a potentially useful Python program called FM2TXT. The FM2TXT program uses the Google speech recognition libraries and an RTL-SDR to listen to any broadcast FM station and automatically transcribe the speech into text. The code seems to be basically an interface for the Google speech recognition API, so is nothing fancy, but still may be of interest to some. Also at the moment it seems like it only works with broadcast FM (WFM), but as the code is open source and consists of a simple single Python file it shouldn't be too hard to adapt it for other NFM signals too.
No word yet on the accuracy of the speech recognition or how well it works with poor reception. If you are interested there is also a Reddit thread discussing the software here.
At the end of last month we uploaded a post highlighting the SDRAngel software, which is a general purpose SDR program with some interesting features such as built in digital speech decoders for DMR, D-Star and Fusion. This avoids the need to pipe audio into a separate digital speech decoder program such as DSD+. SDRAngel also has transmit capabilities which makes it useful for SDRs such as the HackRF, PlutoSDR, LimeSDR etc.
Now over on YouTube and his blog K2GOG has uploaded a video tutorial about using SDRAngel. The tutorial starts with installing SDRAngel and explaining that you'll need a 64-bit system and OS to run it. He then goes on to show how to do FM reception and finally how to do digital speech decoding.
Recently GitHub user randaller released a piece of software that utilizes the RTL-SDR and neural networks for RF signal identification. An artificial neural network is an machine learning technique that is based on approximate computational models of neurons in a brain. By training the neural network on various samples of signals it can learn them just like a human brain could. A neural network trained on signal classification can then be used by anyone to identify unknown signals. Randallers neural network software can learn either from raw IQ data, FFT processed samples, slightly demodulated data, or demodulated audio data. The tensorflow machine learning library is used as the base code, and the deep learning technique is used.
At the moment the software is only really proof of concept, and the currently trained model is only able to identify WFM, TV SECAM Carriers and TETRA. It should be possible to train the network further by providing your own samples too, but a good graphics card is required for this as the software makes use of GPU processing for training. The output of the software is a percentage which shows how confident the neural network is that it is identifying a signal correctly.
Last week we posted about some interesting conference talk videos from GNU Radio Con 17. One of the videos was a talk by Sam Whiting who in conjunction with colleagues Dana Sorensen and Todd Moon from Utah State University have created an Android app that uses two coherent RTL-SDR dongles for direction finding. A coherent RTL-SDR can be created simply by removing the clock on one RTL-SDR and connecting the clock from another, so that they both share the same clock. The V3 RTL-SDR has a clock selector header which can be used to facilitate this as well.
Over on his YouTube account Sam Whiting has uploaded two videos showing the app in action. The backend GNU Radio code for direction analysis is available on GitHub, but unfortunately the Android code/apk is not available to the public as the code is owned by the funders of the project.
In the videos the app shows two arrows, one of which points towards the source of a transmission at a frequency that is being monitored. The second arrow is simply there due to the direction ambiguity produced by the methods used.
![[EN subs] HRPT - Erste Bilder! und mein Setup](https://www.rtl-sdr.com/wp-content/plugins/wp-youtube-lyte/lyteCache.php?origThumbUrl=https%3A%2F%2Fi.ytimg.com%2Fvi%2FxuqsLo48eWg%2F0.jpg)
