The current features of this decoder are as follows:
- FEC decoding of both long frames and short frames using the code from bbctl (this code is included in the Gnuradio decoder)
- CSP header parsing according to the specifications in Wikipedia
- Parsing of the COM and EPS fields in telemetry beacons, using the code from the university team
In the future, I would like to be able to parse more data from the satellite, but I don’t have the format specifications. I’m trying to get the university team to send me some information.
The basic information about the packet format used by AAUSAT-4 is listed in their website. However, there are certain things that are not explained so well. AAUSAT-4 can transmit two types of frames: long frames and short frames. Long frames are marked by the FSM byte 0x59 and contain 250 bytes of FEC, which after decoding yield 92 data bytes. Short frames are marked by the FSM byte 0xA6 and contain 128 bytes of FEC, which after decoding yield 31 data bytes. The first 2 bytes in these data are the length in bytes of the CSP packet (not counting its 4 byte CSP header). The length is stored as a big-endian unsigned 16-bit integer. The next bytes contain the CSP packet, and the last bytes are padding to obtain the full 92 or 31 data bytes. The FEC routines from bbctl handle this length field automatically, and they return just the CSP packet.
The first 4 bytes of the CSP packet are the CSP header. The last 2 bytes are an HMAC field. The HMAC implementation uses SHA-1, and only the first 2 bytes from the digest are used as the HMAC field. However, the key used by the satellite is unknown.
The code from the university team contains this information about the assignation of CSP addresses. This can be used to classify the packets.
ESP = 0 FP = 1 LOG = 1 SWISS = 1 AIS2 = 3 UHF = 4 ADCS1 = 5 ADCS2 = 6 MCC = 9
Apparently, telemetry beacons should come from address 4 (UHF) and the destination address should be 9 (MCC), port 10. This seems to be the case.
Jan PE0SAT has a some IQ recordings from AAUSAT-4 that can be used to test my decoder. I’m using the flowgraph in
examples/oz4cub-pe0sat.grc. I use gr-gpredict-doppler to do Doppler correction. Knowing that PE0SAT is in the locator JO21ho, the rest of the information, such as time and centre frequency is in the filename for the recording.
Today I have processed his recording from 20160428. This is still in 2400 bauds (I think they’re running 9200 bauds now). You can find the decoding log from my software in Gist. In total, it is almost 10kB of data from the satellite. That is quite good, given that the team states in a post in the AAUSAT-4 blog today that they can download up to 20kB per pass. In this recording, the satellite only sends two brief streams of packets to the ground station.
As I don’t have the details for the format of the data, I can’t parse it. However, it is interesting to see which of this data is ASCII. If you look at the packets represented as python strings, you can see that there are several NULL-terminated ASCII strings inside some packets. A more close look reveals patterns such as this one:
Enabled on BAT1\x00fference 10\x008 mV\x00reading 679.\x00
It seems that these are the contents of some buffer where NULL-terminated strings have been stored on top of each other. The software is probably supposed to process only the first string it finds. I find this a quite curious.
Let’s see what can we decode in the future. It would be really awesome to be able to decode some IQ data from the AIS receiver. I think this would be the first time that Amateurs get to play with IQ data from an SDR in space.