digital modes – Page 6 – Daniel Estévez

Reverse engineering Outernet: modulation, coding and framing

Outernet is a company whose goal is to ease worldwide access to internet content. They aim to provide a downlink of selected internet content via geostationary satellites. Currently, they provide data streams from three Inmarsat satellites on the L-band (roughly around 1.5GHz). This gives them almost worldwide coverage. The downlink bitrate is about 2kbps or 20MB of content per day.

The downlink is used to stream files, mostly of educational or informational content, and recently it also streams some APRS data. As this is a new radio technology to play with, it is starting to get the attention of some Amateur Radio operators and other tech-savvy people.

Most of the Outernet software is open-source, except for some key parts of the receiver, which are closed-source and distributed as freeware binaries only. The details of the format of the signal are not publicly known, so the only way to receive the content is to use the Outernet closed-source binaries. Why Outernet has decided to do this escapes me. I find that this is contrary to the principles of broadcasting internet content. The protocol specifications should be public. Also, as an Amateur Radio operator, I find that it is not acceptable to work with a black box receiver of which I can’t know what kind of signal receives and how it does it. Indeed, the Amateur Radio spirit is quite related in some aspects to the Free Software movement philosophy.

For this reason, I have decided to reverse engineer the Outernet signal and protocol with the goal of publishing the details and building an open-source receiver. During the last few days, I’ve managed to reverse engineer all the specifications of the modulation, coding and framing. I’ve being posting all the development updates to my Twitter account. I’ve built a GNUradio Outernet receiver that is able to get Outernet frames from the L-band signal. The protocols used in these frames is still unknown, so there is still much reverse engineering work to do.

Simulating JT modes: how low can they get?

In this post I’ll show how one can use the signal generation tools in WSJT-X to do decoding simulations. This is nothing new, since the performance of the modes that WSJT-X offers has being thoroughly studied both with simulations and real off-air signals. However, these tools seem not very widely known amongst WSJT-X operators. Here I’ll give some examples of simulations for several JT modes. These can give the operators a hands-on experience of what the different modes can and cannot achieve.

Please note that when doing any sort of experiments, you should be careful before jumping to conclusions hastily. You should make sure that the tools you’re using are working as they should and also as you intend to (did you enter correctly all the parameters and settings?). Also, you should check that your results are reproducible and agree with the theory and other experiments.

Another warning: some of the software that I’ll be showing here, in particular the Franke-Taylor soft decoder for JT65 and the QRA64 mode, is still under development. The results that I show here may not reflect the optimal performance that the WSJT-X team aims to achieve in the final release version.

After all these warnings, let’s jump to study the modes. We’ll be considering the following modes: WSPR, JT9A, JT65A, JT65B and QRA64B. To give our tests some purpose, we want to find the decoding threshold for these different modes. This is the signal to noise ratio (SNR) below which the probability of a successful decode is too small to be useful (say, lower than 20%). For each mode, we will generate 100 test files containing a single signal with a fixed SNR. We will then see how many files can be successfully decoded for each SNR.

LilacSat-1 Codec 2 downlink

LilacSat-1 is one of the satellites that will form part of the QB50 constellation, a network of 50 cubesats built by different universities around the world that will conduct studies of the thermosphere. LilacSat-1 is Harbin Institute of Technology’s satellite in the QB50 constellation, and is expected to launch late this year. Incidentally, his “brother” LilacSat-2 launched in September 2015, and it has become a popular satellite because of its Amateur Radio FM repeater.

Apparently, LilacSat-1 will feature a very novel transponder configuration: FM uplink and Codec2 digital voice downlink. I have discovered this yesterday while browsing the last updates to the Harbin Institute of Technology gr-lilacsat github repository. In fact, there is no mention of digital voice in the IARU coordination page for LilacSat-1. According to the coordination, the transponder will be mode V/U (uplink in the 144MHz band and downlink in the 435MHz band). However, it seems that only downlink frequencies have been coordinated with IARU. Hopefully the uplink frequency will lie in the satellite subband this time. LilacSat-2 is infamous because of its uplink at 144.350MHz, which lies in the SSB subband in the Region 1.

Codec2 is the open source digital voice codec that is used in FreeDV. This makes LilacSat-1 very exciting, because Codec2 is the only codec for digital voice radio that is not riddled with patents. Moreover, it performs much better than its main competitor: the AMBE/IMBE family of codecs, which are used in D-STAR, DMR and Yaesu System Fusion. Codec2 can achieve the same voice quality as AMBE using roughly half the bitrate.

Harbin Institute of Technology has recently published a GNUradio decoder for the Codec2 downlink and an IQ recording to test the decoder. Here I take a quick look at this code and I talk a bit about the possibilities of using Codec2/FreeDV in satellites.

Decoding GOMX-1 telemetry

GOMX-1 is a 2U cubesat from GomSpace that was launched in November 2013 into a sun-synchronous orbit. As far as I know, it was the first satellite with an ADS-B receiver payload. It transmits telemetry on the 70cm Amateur band, including some data from the ADS-B receiver, as GOMX-3 does. Some Amateurs, including me, had tried to decode its telemetry on several occasions, without success. GOMX-3 will decay in about 4 weeks, as it was launched from the ISS on October 2015. Therefore, it now becomes more interesting to decode GOMX-1, which is in a longer term orbit. After one more serious try, I’ve been able to decode the telemetry. This is the first time that an Amateur decodes telemetry from GOMX-1 completely. The decoder code can be found in gr-satellites and gr-ax100, including an example wav file in gr-ax100/examples/gomx-1.wav.

Some notes on BEESAT and Mobitex-NX

The family of BEESAT satellites from the TU Berlin transmit telemetry on the Amateur bands using the Mobitex-NX protocol. Some of the BEESAT satellites also include a digipeater using this same protocol. There is a GNUradio implementation from TU Berlin of a software TNC for these satellites. This software has some shortcomings (for instance, FEC decoding wasn’t working properly). I’ve made my own fork where I’ve fixed some of the problems. Here I’ll talk about various aspects of the Mobitex-NX protocol and the GNUradio implementation.

A brief try at decoding HORYU-4 1k2 AFSK telemetry

In the previous post I’ve talked about HORYU-4 CW telemetry. Here I report my findings when trying to decode 1200baud AFSK telemetry. Since the satellite transmits digital telemetry only over Japan, the recordings I’ve analysed have being kindly provided by Tetsurou JA0CAW. There is a telemetry format document from Kyutech, but as it is the case with the CW document, it is rather incomplete and lacks several important details.

How hard is it to decode 3CAT-2?

In a previous post, I looked at the telemetry packets transmitted by the satellite 3CAT-2. This satellite transmits 9600bps AX.25 BPSK packets in the Amateur 2m band. As far as I know, it is the only satellite that transmits fast BPSK without any form of forward error correction. LilacSat-2 uses a concatenated code with a (7, 1/2) convolutional inner code and a (255, 223) Reed-Solomon outer code. The remaining BPSK satellites transmit at 1200bps, either using AX.25 without FEC (the QB50p satellites, for instance), or with strong FEC (Funcube, for example). Therefore, I remark that 3CAT-2’s packets will be a bit difficult to decode without errors. But how difficult? Here I look at how to use the theory to calculate this, without resorting to simulations.

Receiving the Vaisala RS92-SGP radiosonde launched from Madrid-Barajas

Each day, at 01:00UTC and 11:00UTC a Vaisala RS92-SGP radiosonde is launched from Madrid-Barajas airport. This is a small electronics package tied to a helium balloon that ascends up to between 24 and 28km high before bursting and descending on parachute. It is designed to measure atmospheric parameters on its way up. It includes temperature, pressure and humidity sensors, as well as a GPS receiver. The launch on Wednesdays at 11:00UTC also includes a plug-in ozone sensor (which is a much larger and more expensive package). The data is transmitted at 403MHz using Manchester-encoded 4800bps GMSK and protected using Reed-Solomon. You can find more information about the RS92-SGP model in its technical datasheet and about the launches at Madrid-Barajas and other launches in Spain in the Spanish AIP Section 5.3 (other activities of a dangerous nature). Also, there is somebody who feeds the radiosonde data into the APRS network using SM2APRS, so you can track the launches by following OKER-11 on aprs.fi.

Usually, the Sondemonitor software is used to receive and plot the parameters measured by the radiosonde and track the GPS data. Of course, this program is very nice and complete, but it is shareware, costs 25€ and runs only in Windows. I wanted to try if it is possible to track the GPS data in Linux using free software.

Using the CC1101 and Beaglebone black for IP traffic on 70cm

Lately, I have been experimenting with using a CC1101 chip together with a Beaglebone black single board ARM computer to transmit IP traffic over the 70cm Amateur band. There has been a similar project from OEVSV, but I’ve never seen this project reach a final form. Edouard F4EXB has some code that uses the Raspberry Pi instead. Presumably, this will suffer from problems when using the higher data rates supported by the CC1101, as his software is not real-time.

The goal of my project is to build an affordable 70cm IP transceiver with a power of a few Watts. This can be used in the Hamnet Amateur Radio IP network. The modulation should not use more than a couple of hundreds of kHz’s of spectrum, as it doesn’t seem very sensible to take up much more spectrum in the 70cm band. Although the usual maximum bandwidth in the 70cm band is 20kHz, the IARU R1 bandplan allows for wideband experiments around 434.000MHz. A data rate of 128kbps with MSK modulation seems about right, as it uses roughly 200kHz of spectrum. Further on-the-air tests will perhaps change these parameters a bit.

KISS, HDLC, AX.25 and friends

A while ago, I uploaded my gr-kiss out-of-tree GNUradio module to Github. This is a set of blocks to handle KISS, HDLC and AX.25, which are the protocols used in amateur packet radio. There are several other OOT modules that do similar things, but I didn’t like the functionality of them very much. While programming this module, I’ve also noted that the documentation for these protocols is not so good sometimes. Here I’ll give a brief description of the protocols and explain how everything works together.