fec – Page 2 – Daniel Estévez

LDPC code design for my QO-100 narrowband modem

A couple months ago I presented my work-in-progress design for a data modem intended to be used through the QO-100 NB transponder. The main design goal for this modem is to give the maximum data rate possible in a 2.7 kHz channel at 50 dB·Hz CN0. For the physical layer I settled on an RRC-filtered single-carrier modulation with 32APSK data symbols and an interleaved BPSK pilot sequence for synchronization. Simulation and over-the-air tests of this modulation showed good performance. The next step was designing an appropriate FEC.

Owing to the properties of the synchronization sequence, a natural size for the FEC codewords of this modem is 7595 bits (transmitted in 1519 data symbols). The modem uses a baudrate of 2570 baud, so at 50 dB·Hz CN0 the Es/N0 is 15.90 dB. In my previous post I considered using an LDPC code with a rate of 8/9 or 9/10 for FEC, taking as a reference the target Es/N0 performance of the DVB-S2 MODCODs. After some performing some simulations, it turns out that 9/10 is a bit too high with 7595 bit codewords (the DVB-S2 normal FECFRAMEs are 64800 bits long, giving a lower LDPC decoding threshold). Therefore, I’ve settled on trying to design a good rate 8/9 FEC. At this rate, the Eb/N0 is 9.42 dB.

Tianwen-1 high speed data signal

In a previous post I talked about how the high data rate signal of Tianwen-1 can be used to replay recorded telemetry. I did an analysis of the telemetry transmitted over the high speed data signal on 2020-07-30 and showed how to interpret the ADCS data, but left the detailed description of the modulation and coding for a future post.

Here I will talk about the modulation and coding, and how the signal switches from the ordinary low rate telemetry to the high speed signal. I also give GNU Radio decoder flowgraphs, tianwen1_hsd.grc, which works with the 8192 bit frames, and tianwen1_hsd_shortframes.grc, which works with the 2048 bit short frames.

Decoding Emirates Mars Mission Hope

Last Sunday 2020-07-19, the first mission of United Arab Emirates to Mars, known as Emirates Mars Mission “Hope probe” launched from Tanegashima, Japan. This probe is expect to reach Mars in approximately 200 days and study its atmosphere over the course of two years. The scientific instruments onboard the probe are a digital camera, an infrared spectrometer, and an ultraviolet spectrometer.

Shortly after launch, several Amateur radio operators and Amateur spacecraft trackers received signals from the X-band beacon of the Hope probe at 8402.655 MHz and posted reports on Twitter, such as Paul Marsh M0EYT, Ferrucio IW1DTU, Edgar Kaiser DF2MZ, and others. Since the spacecraft was still near Earth, its signal was so strong that a data modulation with a main lobe of approximately 20kHz wide and several sidelobes could easily be seen in the spectrum, which is shown below.

Emirates Mars Mision Hope X-band downlink spectrum

Paul has been quite kind to send me a recording that he made with his station on 2019-07-19 at 23:29 UTC and I have been decoding the data in GNU Radio and looking at the frames. The recording can be downloaded here (193MB). It is an int16 IQ recording at 99998 samples per second. This post is an account of my results.

Reverse-engineering the DSCS-III convolutional encoder

One thing I left open in my post yesterday was the convolutional encoder used for FEC in the DSCS-III X-band beacon data. I haven’t seen that the details of the convolutional encoder are described in Coppola’s Master’s thesis, but in a situation such as this one, it is quite easy to use some linear algebra to find the convolutional encoder specification. Here I explain how it is done.

Decoding BepiColombo

BepiColombo is a joint mission between ESA and JAXA to send two scientific spacecraft to Mercury. The two spacecraft, the Mercury Planetary Orbiter, built by ESA, and the Mercury Magnetospheric Orbiter, built by JAXA, travel together, joined by the Mercury Transfer Module, which provides propulsion and support during cruise, and will separate upon arrival to Mercury. The mission was launched on October 2018 and will arrive to an orbit around Mercury on December 2025. The long cruise consists of one Earth flyby, two Venus flybys, and six Mercury flybys.

The Earth flyby will happen in a few days, on 2020-04-10, so currently BepiColombo is quickly approaching Earth at a speed of 4km/s. Yesterday, on 2020-04-04, the spacecraft was 2 million km away from Earth, which is close enough so that Amateur DSN stations can receive the data modulation sidebands. Paul Marsh M0EYT, Jean-Luc Milette and others have been posting their reception reports on Twitter.

Paul sent me a short recording he made on 2020-04-04 at 15:16 UTC at a frequency of 8420.535MHz, so that I could see if it was possible to decode the signal. I’ve successfully decoded the frames, with very few errors. This post is a summary of my decoding.

Decoding ESA Solar Orbiter

Solar Orbiter is an ESA Sun observation satellite that was launched on February 10 from Cape Canaveral, USA. It will perform detailed measurements of the heliosphere from close distances reaching down to around 60 solar radii.

As usual, Amateur observers have been interested in tracking this mission since launch, but apparently ESA refused to publish state vectors to aid them locate the spacecraft. However, 18 hours after launch, Solar Orbiter was found by Amateurs, first visually, and then by radio. Since then, it has been actively tracked by several Amateur DSN stations, which are publishing reception reports on Twitter and other media.

On February 13, the spacecraft deployed its high gain antenna. Since it is not so far from Earth yet, even stations with relatively small dishes are able to receive the data modulation on the X band downlink signal. Spectrum plots showing the sidelobes of this signal have been published in Twitter by Paul Marsh M0EYT, Ferruccio IW1DTU, and others.

I have used an IQ recording made by Paul on 2020-02-13 16:43:25 UTC at 8427.070MHz to decode the data transmitted by Solar Orbiter. In this post, I show the details.

Third alpha for gr-satellites 3

gr-satellites v3 is a large refactor of the gr-satellites codebase that I introduced in September. Since then, I have been working and releasing alphas to showcase the new features and get feedback from the community. Today I have released the third alpha in the series: v3-alpha2.

Each of the alphas has focused on a different topic or feature, and v3-alpha2 focuses on extending the number of satellites supported and bringing back most of the satellites supported in gr-satellites v2. Whereas previous alphas supported only a few different satellites, this alpha supports a large number. Therefore, I think that this is the first gr-satellites v3 release that is really useful. I expect that interested people will be able to use v3-alpha2 as a replacement of gr-satellites v2 in their usual activities.

In this post, I explain the main features that this alpha brings. For the basic usage of gr-satellites v3, please refer to the post about the second alpha.

SMOG-P short codes

In my previous post I talked about the FEC used by the SMOG-P and ATL-1. In there, I reverse-engineered the long frames transmitted by SMOG-P and found that they use the AO-40 FEC protocol.

After publishing that post I started reverse-engineering the short frames. Meanwhile, Peter Horvath pointed me to a Github repository containing an implementation of the FEC used for short frames and long frames. I hadn’t seen that repository before (it’s not easy to search for SMOG-P or ATL-1 in Google, as many unrelated results come up). Indeed this repository contains the source of a FEC decoder for the short frames, so there is no need to reverse-engineer it.

Timur Kristóf, the author of that repository, says that the team plans to release the source for the decoder, but that they are currently very busy with the early operations of the satellites. This is very good news.

I have studied the code in the Github repository and included a decoder for the short FEC frames in gr-satellites.

Decoding SMOG-P and ATL-1

Last Friday, an Electron rocket from Rocket Lab was launched from Mahia Launch Complex, New Zealand, carrying the ALE-2 microsatellite and 6 PocketQubes into a 400km polar orbit. Two of these PocketQubes are SMOG-P and ATL-1 from Budapest University of Technology and Economics.

They transmit in the 70cm Amateur satellite band, and although they have beeen successfully coordinated with IARU (see here and here), documentation about the protocols they use has not been published. There is some groundstation software available here, but the interesting part is implemented in the atlgnd_x86_64 and smogpgnd_x86_64 binary executables, for which source code is not available. As far as I know both satellites transmit using the same (or very similar) protocols.

In this post I describe my first attempts at reverse-engineering the transmissions of SMOG-P, with successful results. Preliminary support for decoding SMOG-P and ATL-1 has been added to gr-satellites in the maint-3.8 branch.

QO-100 beacon FEC decoder

Since the BPSK beacon on the QO-100 narrowband transponder was first activated, I had thought that it only transmitted messages using the AO-40 uncoded protocol. However, a Twitter conversation a few days ago with Rob Janssen PE1CHL convinced me that FEC messages might be sent in between uncoded messages.

The AO-40 FEC protocol used a concatenated code with a (160, 128) Reed-Solomon code and an r=1/2, k=7 convolutional code, together with scrambling and interleaving to achieve very good performance. The same protocol has then been used in the FUNcube satellites, so I have an AO-40 FEC decoder in gr-satellites since I added support for AO-73.

It is quite easy to notice that the QO-100 beacon transmits both uncoded and FEC messages. Indeed, using my gr-satellites decoder, I see that an uncoded message is transmitted every 23 seconds approximately. Since an uncoded message comprises 514 bytes, it takes 10.28 seconds to transmit it at 400baud, so something else must be sent between uncoded messages.

A FEC message is formed by 5200 symbols (after applying FEC), so it takes 13 seconds to transmit at 400baud. This gives us the total 23.28 seconds that I had observed between uncoded messages. Note that the contents of the uncoded and FEC blocks are different. An uncoded block contains 8 lines of 64 characters plus 2 bytes of CRC. A FEC block only contains 4 lines of 64 characters, and no CRC.

I have added a FEC decoder to the QO-100 decoder in gr-satellites, so that it now decodes both FEC and uncoded messages.