Software – Page 17 – Daniel Estévez

Coding for HIT satellites (and other CCSDS satellites)

The Harbin Institute of Technology satellites LilacSat-2, BY70-1 and the upcoming LilacSat-1 all use a concatenated code with an \(r=1/2, k=7\) convolutional code and a (255,223) Reed-Solomon code according to the CCSDS TM Synchronization and Channel Coding blue book specifications. The GNU Radio decoder gr-lilacsat by Wei BG2BHC includes a custom implementation of the relevant part of the CCSDS stack, probably ported into GNU Radio from some other software.

Recently, I have been working on decoding KS-1Q and I’ve seen that it uses the same CCSDS coding as the HIT satellites. This has made me realise that most of this CCSDS coding can be processed using stock GNU Radio blocks, without the need for custom blocks. The only exception is Reed-Solomon decoding. This can be done easily with gr-libfec, which provides an easy interface from GNU Radio to Phil Karn’s libfec. Here I look at the details of the CCSDS coding and how to process it with GNU Radio. I’ve updated the decoders in gr-satellites to use this kind of processing. I’ll also talk about the small advantages of doing it in this way versus using the custom implementation in gr-lilacsat.

KS-1Q decoded

In a previous post, I talked about my attempts to decode KS-1Q. Lately, WarMonkey, who is part of the satellite team, has been giving me some extra information and finally I have been able to decode the packets from the satellite. The decoder is in gr-ks1q, together with a sample recording contributed by Scott K4KDR. I’ve also added support for KS-1Q in gr-satellites. Here I look at the coding of the packets in more detail.

Looking at BY70-1 image downlink

BY70-1 is a Chinese Amateur satellite that will launch on Monday 26 December. It has a V/U FM repeater, a camera and a 9k6 BPSK downlink on 70cm that transmits telemetry and the JPEG images taken by the camera. The BPSK downlink uses the same modulation and coding as LilacSat-2, of which I have spoken several times. Recently, Wei MingChuan BG2BHC has added support for the image downlink of BY70-1 to gr-lilacsat and a bit stream recording to test the image receiver.

Unfortunately, the image decoder is closed-source, as it contains some certification methods used to avoid fake packets over the internet. However, Wei gave me a brief description of how the image downlink protocol works. After seeing the closed-source decoder running, I had enough to figure out how the protocol works. I have implemented an open-source image decoder as a python GNU Radio block. It is in my gr-lilacsat fork, and it will soon be included in the upstream gr-lilacsat repository. Here I look at the protocol used for the image downlink.

About KS-1Q

In a previous post, I talked about the satellite CAS-2T on a recent Chinese launch. CAS-2T was designed to remain attached to the upper stage of the rocket and decay in a few days. However, due to an error in the launch, the upper stage of the rocket and CAS-2T where put on a long-term 1000km x 500km elliptical orbit. A few days after launch we learned that another satellite, called KS-1Q was also attached to the same upper stage of the rocket. This satellite transmits telemetry on the 70cm Amateur Satellite band.

I haven’t been able to completely decode telemetry from KS-1Q yet, mostly because the satellite team hasn’t given many technical details about the telemetry format. There is a technical brochure in Chinese, but it is not publicly available. I have asked the team if they could send me a copy, but they haven’t replied. Here I report my findings so far in case someone finds them useful.

Reverse-engineering Outernet in GNU Radio blog

I have published a post in the GNU Radio blog about my reverse engineered GNU Radio Outernet receiver gr-outernet. I cover more or less the same information as in a previous post in this blog, but I include lots of screenshots. Many thanks to Ben Hilburn and Johnathan Corgan for contacting me to write this post in the GNU Radio blog and for their useful suggestions.

Head over to the GNU Radio blog and read the post: Reverse-engineering Outernet.

Reverse engineering Outernet: time and file services

In my last two posts, I’ve being talking about my reverse engineering efforts with the Outernet signal and I’ve described the modulation, coding and framing and the L3 and L4 network protocols used in Outernet. This post is the last in this series. Here I talk about how the time and file services work. Recall that a Free Software implementation of an Outernet receiver based on these descriptions is now available at gr-outernet and free-outernet.

Reverse engineering Outernet: L3 and L4 protocols

This is a follow-up to my last post, where I talked about my efforts to reverse engineer the protocols used in the Outernet L-band signal. Here I will describe the L3 and L4 protocols that are used in Outernet.

This description is solely based upon my reverse engineering efforts. As there is no documentation available for this protocols, I get to name them as I like. Also, I’ll describe the protocols just from how they appear to work. Probably the developers at Outernet had something a bit different in mind. In any case, my understanding of how the protocols work seems quite good, as I have now a functional file receiver called free-outernet. In my next post I’ll talk about how the Outernet time service and file service work.

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.