MESAT-1 demodulation BPSK 1200 (LTM)

[kng]

Looking at a recording (48ksps) from Dwingeloo in observation 9808940
Trying some of the available BPSK SatYAML I get pretty much nothing.
The FoxTelem is able to demodulate it, usb demodulation in SDR# via audio monitor.
Seems like Fox1E, Huskysat and MESAT-1 is able to transmit this format, I believe the code for it is here.
Is this possible to make a satyaml for, or does it need a new deframer, or unknown :P

[daniestevez]

Incidentally I was looking at this this morning, also motivated by a Dwingeloo recording. A custom deframer will be needed for this satellite. As usual, there is not enough detailed documentation to write the deframer, so I was looking at the source code of FoxTelem to try to see how it work. I will use one of these recording to try to figure things out over the next few days, and maybe ask Chris G0KLA if I need help.

[ac2cz]

Looking at AO-73 satyaml, start with that. I think you would only need to change the framing.

[daniestevez]

Awesome! A custom deframer (a GNU Radio hier flowgraph that puts together several blocks to get from a soft-symbol stream to PDUs with frames) is needed. Here are some questions:

• Is there differential coding (as in AO-73)?
• Looking at the code, I saw that there is a 31-bit syncword given by this sequence. Is this placed at the beginning of the frame, or is it distributed over the whole frame as with AO-73?
• The payload seems to be 3 (223, 255) Reed-Solomon codewords, so no problem there. Are these "inteleaved" as recommended by CCSDS?
• Is there a scrambler?
• In https://github.com/ac2cz/FoxTelem/blob/master/spacecraft/LTM_BPSK.format, what do header_length and trailer_length mean?
• Are there any CRCs?
• I have identified the need to synchronize to the 31-bit syncword and the need to decode Reed-Solomon. Anything else I might have missed?

[ac2cz]

Yes, is is DBPSK.
Sync word is at the start of the packet and is not a sync vector across the packet like AO-73.
The RS words are interleaved, yes, with all the check bytes at the end.
No scrambler.
The format file contains:

1. mode=BPSK
2. bps=1200
3. frame_length=765 # This is the total length of the frame in words. Each word is 10 bits long. It is 8b10b encoded. Incorrect 10b to 8b lookups are used as erasures in the RS Decoders
4. data_length=669 # This plus trailer equals frame length
5. header_length=12 # There is a header defined in the file listed below. This comes before the 6 payloads of data
6. header_layout_file=LTM_header.csv
7. trailer_length=96 # The number of RS Check bytes. i.e. 3 sets of 32
8. word_length=10 # because of the 8b10b encoding
9. sync_word_length=31
10. rs_words=3
11. rs_padding=0,0,0 # The frame is entirely filled so no RS padding is needed at the receive
12. symbols_per_chunk=100 #Used internally by FoxTelem. The sample window size in bytes as I remember
13. rf_filter_width_hz=5000 # Used by FoxTelems SDR

Note that to get started you need to spot the 31 bit sync word, take the next 7650 bits after that in 10 bit chunks. Convert them to 8b bytes using a 10b8b lookup table then you have the bytes and can run the RS Decoders on them.

If that works then you can break it up into payloads. That starts to get a bit more complex, but all the info is available. There are 6 in each frame which vary by type and are defined in the MESAT frame types, which are all described in this: https://github.com/ac2cz/FoxTelem/blob/master/spacecraft/MESAT1.MASTER.

If that works then you have the raw data for each telemetry channel. We have a set of conversions, curves, lookup tables and math equations that convert the values into something human readable. I can describe all that as desired.

[daniestevez]

I had missed the 10b8b coding! This is more of a decoder implementation question than transmitter implementations, but I guess that if 10b8b decoding fails for a word, such word should ideally be marked as an erasure for the RS decoder? The interaction between 10b8b and RS is somewhat subtle to achieve best BER results, and I haven't thought so much about it. At some point I had the idea to decode 10b8b using Viterbi or BCJR, but never set to do it.

[ac2cz]

Yes, treat 10b lookup failures as an erasure in the RS decoders.

If you have more thoughts on how Veterbi would help decode this then I would be interested.