The NanoCom U482C is a a transceiver made by GOMspace intended for cubesats and other small satellites. Currently, it seems to be out of production, since it has been superseded by the newer NanoCom AX100, but nevertheless the U482C is being flown in new satellites, such as the QB50 AU03 INSPIRE-2. The U482C is also used in GOMspace’s cubesat GOMX-1, so we may say that GOMX-1 is the reference satellite for U482C.
My gr-satellites project includes a partially reverse-engineered U482C decoder which is able to decode GOMX-1 and several other satellites. It does CCSDS descrambling and Reed-Solomon decoding. Recently, Jan PE0SAT made a recording of INSPIRE-2. I tried to decode it with gr-satellites and although the signal was very good, the Reed-Solomon decoder failed. The history behind this recording is interesting. After being released from the ISS near the end of May, INSPIRE-2 wasn’t transmitting as it should. The satellite team got in contact with Amateurs having powerful stations to try to telecommand the satellite and get it transmitting. Eventually, the CAMRAS 25m dish was used to telecommand and activate INSPIRE-2. Later, Jan made a recording from his groundstation.
After exchanging some emails with the satellite team, I learnt that the U482C also supports an \(r=1/2\), \(k=7\) convolutional code, which is used by INSPIRE-2 but not by other satellite I’ve seen. I have added Viterbi decoding support for the U482C decoder in gr-satellites, so that INSPIRE-2 can now be decoded. Here I describe some details of the implementation.
The convolutional code used by the U482C is an \(r=1/2\), \(k=7\) code with the usual NASA/CCSDS polynomials. However, it is important to note that the convention is first POLYA, then POLYB. None of the output bits are inverted, as it is the case in the NASA convention and the CCSDS convention. This left me wondering for a while, since I was only trying with the CCSDS convention and NASA convention, and my Viterbi decoder didn’t work.
The Viterbi decoder I’ve used is a hard decision decoder which operates on bytes. The code can be seen here. It is taken from gr-aausat, but it dates back to Phil Karn KA9Q.
Another thing I have learned by reading the U482C datasheet is that although most satellites use scrambling and Reed-Solomon, each of the three FEC algorithms (Viterbi, scrambling and Reed-Solomon) are optional. The packets contain flags which indicate the algorithms in use so that the receiver can do the decoding procedure properly. If you recall from my post on GOMX-1, the first 3 bytes of each packet are a Golay(24,12)-encoded field which contains the frame length as an 8bit integer. In this field there are also 3 flags for each of the FEC algorithms as follows:
frame_len = length_field & 0xff; viterbi_flag = length_field & 0x100; scrambler_flag = length_field & 0x200; rs_flag = length_field & 0x400;
Note that the most significant bit (0x800) is not used. It is marked as “reserved” by the datasheet.
The U482C decoder block in gr-satellites defaults to reading each of the flags from the packet and doing the decoding as appropriate. This behaviour is labeled as “Auto”. However, each of the three algorithms can also be fixed to “On” or “Off”, in case the satellite is sending incorrect flags or one wants to do some debugging.
It would be better to use a soft decision Viterbi decoder (operating on soft symbols) instead of a hard decision decoder. This is something I also want to do for the AAUSAT-4 decoder. However, using the hard decision decoder operating on bytes was easier to do and maintained compatibility with existing U482C decoders in gr-satellites, which take PDUs containing bytes (and not soft symbols). Perhaps I’ll do the change to soft decision in the future.