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 his YouTube Channel Mile Kokotov has uploaded a video that compares three mid priced SDRs: the Airspy HF+, the SDRplay RSP1A and the ColibriNANO. Each SDR is compared on several ALPHA and NBD morse code stations which exist in his tests from between 14 kHz to 474 kHz. He writes:
In this video I am comparing three SDR-Receivers. I have made few recordings with every receiver with the same antenna and choose the best one (one with the best SNR = signal-to-noise ratio). My intention was to ensure the same conditions for all three SDR`s in order to make as fair as possible comparison. For example, I was set the frequency span displayed on the window to be as same as possible for all three receivers. The vertical axis for the signal stregth, was set to be equal (in decibels) too.Airspy HF+ and ColibriNANO was set to their minimum sample rate (48 kHz). RSP1A was set to minimum sample rate (2 MHz and 8 decimation).
No DSP enhancing on the SDR`s was used except APF (Audio peak filter) on ColibriNANO (I forgot to swith off).
The differences between each receiver as very difficult to detect as only really challenging signal conditions will really set them apart. Mile also added in a comment:
You should not expect the difference to be very obvious! If you compare one average transceiver (which cost about $ 1000 USD) and top class transceiver which cost ten times more, the difference in the receiving the average signals will be very small too. Almost negligible! But when you have difficult conditions, the very weak signal between many strong signals, than the better receiver will receive the weak signal readable enough, but cheaper receiver will not. Today it is not a problem to design and produce the sensitive receiver, but it is very difficult to design and produce high dynamic receiver for reasonable price! The Airspy HF+ and RSP1A are very very good SDR-receivers. They have different customers target and have strong and weak sides. For example Airspy HF+ has better dynamics in frequency range where it is designed for, but RSP1A, on the other hand, has broadband coverage...
Late last month we posted about the Fairwaves XTRX SDR which is a Mini PCIE TX/RX capable SDR with 10 MHz - 3.7 GHz tuning range and 120 MSPS sample rate that costs $199 US and is currently crowdfunding on CrowdSupply. At the time of this post the XTRX is currently 84% funded.
Recently the XTRX team released an update regarding the HF performance below 30 MHz. The update shows that signal attenuation starts to significantly reduce in the HF bands with the 3dB point being at 11 MHz. At 6 MHz the attenuation is at 13 dB, and at 2 MHz it's up to 29 dB. This attenuation may not be too bad though especially for strong HF signals, or perhaps a preamp like the LNA4HF could be used. They attempted to review their design to reduce the attenuation, but found that there is no easy fix especially with having such restricted space as in a PCIE card.
They also note that HF reception with the LMS7002 chip used on the XTRX can be problematic as the LO is fixed to a minimum of 30 MHz. So to receive below 30 MHz the receiving bandwidth needs to be increased which can cause saturation from any strong out of band signals. However, they tested with some very simple external bandpass filters for the 49m band (5.8 - 6.2 MHz) and had decent results.
The XTRX team also added a new breakout header to the board which provides direct connections to the LMS7002 chip ADCs for direct sampling. This could provide even better HF performance with an appropriate custom frontend.
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.
![[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)
