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.

The first remark is that even though the IARU coordination sheets state that these satellites use 12.5kbaud GMSK, they are using 1250baud GMSK instead. In fact, for the first day after launch they were using some faster modulation for most of the packets, but they have been changed to 1250baud since Saturday. This change can be observed from the difference in the waterfalls of recordings done before and after the change.

In my first look at the packets, I identified that the 16 bit syncword 0x2DD4 was being used. This is the default syncword for the Si446x family of FSK transceiver chips from SiLabs and is also used in Lucky-7, so most likely the satellites are using this kind of chips. However, a look at the data revealed that it was most likely scrambled.

While trying to get in contact with the satellite team to get some technical details about the scrambler, I decided to take a look at the smogpgnd_x86_64 binary to see if I could pull out any useful details easily.

Here you can see the symbol table of the ELF binary smogpgnd_x86_64 as printed by objdump. There we see numerous references to AO-40, with several functions starting by ao40_ and presumably implementing the different functions of the AO-40 FEC protocol. There are also versions of these functions starting by ao40short_ (more on this later).

Interestingly, there are also functions that apparently perform AES128 encryption and decryption. I find this somewhat concerning. Encryption of Amateur transmissions is forbidden by the ITU Radio Regulations except for the control signals of Amateur satellites. Therefore, it is possible to encrypt telecommands (and perhaps also replies to telecommands from the satellite), but telemetry and other data downlinked from the satellite needs to be sent unencrypted. So far I don’t know if any of the data transmitted by the satellite is encrypted.

I’m also concerned about the origin the code used in smogpgnd_x86_64, since most of the code available online to implement the AO-40 FEC uses a strong copyleft licence. More specifically, the symbol ao40_spiral-vit_scalar.c suggests that code generated by SPIRAL is used in the Viterbi decoder. The code generated by SPIRAL is available under the GPL. The code of Phil Karn’s KA9Q libfec is available under the LGPL. This is also probably reused in smogpgnd_x86_64 (see the symbols ao40_Partab, ao40_decode_rs_8). Therefore, I wouldn’t be surprised if the satellite team is violating some open-source licences by distributing smogpgnd_x86_64 as a binary only.

The symbol table of smogpgnd_x86_64 has been very helpful. It turns out that SMOG-P implements the AO-40 FEC protocol completely, including the distributed syncword. A 5200 bit AO-40 FEC frame is sent as the payload of the packets transmitted by the Si446x. The 0x2DD4 is transmitted automatically by the chip before the payload, but the design intention is probably that the receiver should ignore that syncword and synchronize using the AO-40 distributed syncword.

However, this is not the end of the story. It turns out that SMOG-P transmits frames of three different sizes. These can be seen in the figure below. The frames are the parts of the signal where the amplitude is small. The rest if just noise between frames.

The long frames correspond to the 5200 bit AO-FEC frames. There are also some short frames which are approximately half the length of the long frames. This explains the ao40short_ functions, which hint at some modification of the AO-40 FEC protocol for frames of half the size. Perhaps this is achieved by using a single Reed-Solomon (160,128) codeword instead of two, but I will have to take a look at this in more detail.

There are also some very short frames. One of these frames is transmitted at the beginning and at the end of each burst of long or short frames. So far I don’t know anything about them. It is possible that they don’t use any FEC and are intended as some kind of signalling.

A recording of some long frames and of some short and very short frames have been added to satellite-recordings. A decoder for the long frames is now available in gr-satellites. The plan is to add support for short and very short frames once I figure out the details.

I have put a decode of the long frames recorded during the 2019-12-07 19:43 UTC pass on the Budapest University’s groundstation WebSDR in this gist. In a certain sense, the data seems somewhat strange.