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.
Tag: fec
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.
P25 vocoder FEC
Following a discussion with Carlos Cabezas EB4FBZ over on the Spanish telegram group Radiofrikis about using Codec2 with DMR, I set out to study the error correction used in DMR, since it quickly caught my eye as something rather interesting. As some may know, I’m not a fan of using DMR for Amateur Radio, so I don’t know much about its technical details. On the other hand, Carlos knows a lot about DMR, so I’ve learned much with this discussion.
In principle, DMR is codec agnostic, but all the existing implementations use a 2450bps AMBE codec. The details of the encoding and FEC are taken directly from the P25 Half Rate Vocoder specification, which encodes a 2450bps MBE stream as a 3600bps stream. Here I look at some interesting details regarding the FEC in this specification.
Using a Golay(24,12) decoder for Golay(23,12)
Yesterday I explained an algebraic decoding algorithm for Golay(24,12) and commented that it was not easy to adapt it to decode Golay(23,12). Today I’ve thought of a simple way to use any Golay(24,12) decoder to decode Golay(23,12).
Recall that a systematic Golay(23,12) code is obtained from a systematic Golay(24,12) by omitting the last component of each codeword (i.e., the codeword \((c_1,\ldots,c_{24})\) from the Golay(24,12) code gives the codeword \((c_1,\ldots,c_{23})\) from the Golay(23,12) code). Conversely, one can obtain a systematic Golay(24,12) code from a systematic Golay(23,12) code by adding a parity bit at the end. This means that \(c_{24} = \sum_{j=1}^{23} c_j\), since \(\sum_{j=1}^{24} c_j = 0\) for all words in a Golay(24,12) code.
The idea to decode a Golay(23,12) code with a Golay(24,12) decoder is first to restore the parity bit \(c_{24}\) and then apply the Golay(24,12) decoder. However, if there are errors in the received codeword, the restored parity bit can also be in error, increasing the number of errors in one.
The key remark is that both Golay(23,12) and Golay(24,12) are able to correct up to 3 errors. Therefore, we only care about restoring the parity bit correctly in the case when there are exactly 3 errors. If there are 2 or less errors, adding another error still gives a word decodable by the Golay(24,12) decoder.
Now note that if there are exactly 3 errors in \((c_1,\ldots,c_{23})\), then \(\sum_{j=1}^{23} c_j\) gives the opposite from the parity of the original codeword. Therefore, we should restore \(c_{24}\) as\[c_{24} = 1 + \sum_{j=1}^{23} c_j\]and then apply the Golay(24,12) decoder.
Algebraic decoding of Golay(24,12)
A couple years ago, I implemented a Golay(24,12) decoder to be used in the GOMX-1 decoder in gr-satellites. The implementation can be seen here. I followed the algorithm in the book The Art of Error Correction Coding, Section 2.2.3, without taking much care to understand why the algorithm worked. Now I am doing some experiments with Golay(24,12) and Golay(23,12) codes, so I have needed to revisit that algorithm and understand it well to adapt it to my needs. Here I explain how this algebraic decoder works.