Decoding FloripaSat-1

FloripaSat-1 is a 1U cubesat developed by Universidade Federal Santa Catarina, Brazil. It was launched two days ago from Taiyuan, China, together with the Chinese-Brazilian Earth observation satellite CBERS 4A and other small satellites. FloripaSat-1 transmits in the 145MHz and 436MHz Amateur satellite bands using the NGHam protocol developed by Jon Petter Skagmo LA3JPA in 2014. NGHam is intended as a modern replacement for AX.25 in packet radio. It uses a 32 bit syncword, a CCSDS scrambler, and Reed-Solomon FEC. Additionally, FloripaSat-1 transmits also using AX.25, for retrocompatibility and performance comparison.

The information published online about the protocols used by FloripaSat-1 makes a great impression at first. There are descriptions of the coding and telemetry format and an open source decoder. However, a deeper look reveals many flaws. The documentation doesn’t describe accurately or in enough detail what the satellite is transmitting, and several functions are not implemented in the open source decoder. To my best knowledge, the NGHam Reed-Solomon and the whole AX.25 implementations in the satellite seem to be broken, and these are not implemented in the decoder.

Nevertheless, I have added a decoder for FloripaSat-1 to gr-satellites maint-3.8 branch, covering the functions that do work. This post gives a closer look at some of the technical details.

Implementing the NGHam protocol in GNU Radio is easy enough, since the documentation in the README is quite clear and the source code is also easy to follow. However, I got stuck when trying to perform Reed-Solomon decoding of some packets transmitted by FloripaSat-1. My implementation used the parameters given in the NGHam source code, but decoding would fail.

After some reading of the source code of grs, the open source decoder published by the FloripaSat-1 team, I noticed that in its version of the NGHam library the Reed-Solomon decoder parameters are initialized to zero. Effectively this turns Reed-Solomon decoding into a nop that always succeeds without correcting any possibly corrupted bytes.

Remarkably, the Reed-Solomon parity check bytes in the frames transmitted by the satellite look “fine” (they are not constant values or something like that). However I don’t want to waste more time in trying to make sense out of something that doesn’t even work in the official decoder. It might be the case that Reed-Solomon encoding in the satellite implementation is broken and so decoding has being disabled in the official decoder.

The satellite beacon in the 145MHz band is first transmitted in NGHam and then in AX.25. This is also broken. A conventional AX.25 decoder doesn’t detect the frames. There are many ways in which AX.25 can be badly implemented (just take a look at my post about ESEO). I have spent some time looking at the AX.25 packets to try to detect obvious mistakes that might be easily fixed, without any luck. Additionally, AX.25 decoding is not implemented in the grs official decoder. So again, I’m not going to waste time in trying to make sense of something that might not work at all.

This being said, the gr-satellites decoder implements the functionality that I have seen to be working in the satellite and in the grs decoder. Decoding of NGHam packets works, except for Reed-Solomon checking (so the packet needs to be received intact in order for the CRC-16 to be correct), as does parsing of beacon packets in the 145MHz band.

Decoding of downlink packets in the 436MHz band doesn’t really work, since I am not sure about the format. There is a brief description of the format in the online documentation, but it seems that this is not implemented in grs. In fact, with the sample recording given with grs, the decoder detects three NGHam downlink packets, but doesn’t show the values of the telemetry variables.