Last week I received the first telemetry from the GOLT-T flat sat. So I have been working on that. For those interested here are some notes about what I am doing. Luckily the ground segment is not weighed down by ITAR or other considerations. So all my code and progress is "open source" and available.
The GOLF-T telemetry came to me in an audio file recorded from an SDR, likely HDSDR. The RF was directly transmitted by the flat stat and then demodulated. It's a PSK signal so Upper Sideband was likely used and the PSK demodulated audio was centered at about 1500Hz.
I ran it through FoxTelem with the Costas loop decoder and it locked onto the signal easily, finding a bunch of the 31 bit SYNC words which separate frames. So that's good. But nothing decoded, which was to be expected. In GOLF-T we have changed the format, specifically the length of the frame. FoxTelem has to know the length of the frame to decode it, unlike the Pacsat Ground station which can handle variable length frames of data.
The telemetry format is modelled on FOX-1E and HuskySat, which both use 8 bytes of header followed by 6 payloads each 78 bytes and then 96 "check" bytes for the Reed Solomon Forward Error Correction. So 572 bytes for what we call a "frame". The bytes are encoded as 10 bit "words" in a scheme called 8b10b. There are two 10b values for every 8b value and the spacecraft choses 10b values so that we have a balanced number of 1s and 0s in the downlink. This is important when decoding to stay locked onto the signal and to be able to recover the "clock" which is the exact rate and offset of the bits.
For FOX-1E/HuskySat we surround the 572 bytes with 31 bit SYNC words of a known pattern. The transmission is continuous, with one frame following the next. The forward error correction scheme is block based with 223 bytes in a block (and 32 check bytes) so it works best with fixed size frames of data. So FoxTelem "expects" the frame to be 572 bytes long. The GOLF-T frame is not, hence no decodes.
So I set out and updated the code to allow a new format, "Golf PSK" if you like, that has 12 bytes in the header and 6 payloads each 92 bytes long. Again with 96 check bytes. So now FoxTelem is looking for 660 byte long frames, or 6600 bits, because each byte is encoded in 10 bits.
But of course that failed with FoxTelem complaining that Spacecraft id 0 was not setup and decode of the frame was not possible. We had decided to use id 8 for GOLF-T, so that was not expected. Something was wrong.
Looking at my debug printouts it really looked like the flat sat was sending the wrong header, so I engaged in an email conversation with the software team. Everything looked good on their end so perhaps a bug in FoxTelem? Maybe the way I had changed things to deal with a new layout? This is the "fun" part of decoding a new spacecraft. We don't even know if the flight software is producing the right format yet. The errors could be (in fact are likely) at both ends of the process.
I resorted to examining the sent bits by hand. For the FOX spacecraft I used to do that in Audacity, which is a program for examining audio files. With FSK you can see the actual bits in the audio waveform once it is demodulated. The audio is literally a bit shaped waveform. But that is not the case with PSK. The audio waveform is still PSK, just at audio frequencies. So you go a little bit crazy trying to follow the phase shifts and the differential encoding scheme to work out the resulting bits.
A while ago I wrote a "mode" in FoxTelem called DebugValues that freezes the audio waveform and the demodulated bits. You can then page through them 40 bits at a time. I updated that mode to also print out the differential bit value on the screen. In our BPSK scheme we don't directly transmit the 1s and 0s as two phase angles. Instead if the phase changes it is a 0. If the phase stays the same it is a 1.
With the decoded bits printed on the screen, and after a tedious couple of hours, I found the SYNC markers for the first few frames. You can see two FoxTelem sets of 40 bits above. The SYNC word is highlighted in yellow and the first "byte" is in blue. The blue bits are 0x195 and that 10b word maps to 0x46. That is 70 in decimal and based on the way the id was coded into the bits is what we expected. It proves that the flat sat is sending a valid format, at least for the header. So something was going wrong in FoxTelem. It was not reading the correct bytes after the SYNC marker.
I'll post more here as I debug it.
73
Chris
g0kla/ac2Cz
Enter Comments Here:
Copyright 2001-2021 Chris Thompson
Send me an email