In a previous post, I talked about the satellite CAS-2T on a recent Chinese launch. CAS-2T was designed to remain attached to the upper stage of the rocket and decay in a few days. However, due to an error in the launch, the upper stage of the rocket and CAS-2T where put on a long-term 1000km x 500km elliptical orbit. A few days after launch we learned that another satellite, called KS-1Q was also attached to the same upper stage of the rocket. This satellite transmits telemetry on the 70cm Amateur Satellite band.
I haven’t been able to completely decode telemetry from KS-1Q yet, mostly because the satellite team hasn’t given many technical details about the telemetry format. There is a technical brochure in Chinese, but it is not publicly available. I have asked the team if they could send me a copy, but they haven’t replied. Here I report my findings so far in case someone finds them useful.
The modulation is 20kbaud FSK. I have used Michael Ossmann’s whole packet clock recovery to extract the bits from some packets recorded by Scott K4KDR. You can see the result of whole packet clock recovery on one of these packets in this gist. There is a preamble and postamble of alternating 0’s and 1’s.
The satellite team have announced that the FEC used is an r=1/2, k=7 convolutional code with CCSDS polynomials and a (255,223) Reed-Solomon code. We also know that the frames have 223 bytes worth of data, indicating that no padding is used for Reed-Solomon. No scrambler is used. Mingchuan BG2BHC has been in contact with the KS-1Q team and he has provided us some of this information.
The main problem is that I don’t know how long is the syncword or what should the contents of the data look like. Therefore, I don’t know where the FEC encoded data starts inside the packet. I have made a small python script that tries to perform FEC decoding starting at all possible offsets within the packet. The problem with this approach is that, due to the nature of the FEC used, decoding also succeeds when the offset is the correct one plus or minus a small multiple of 16 symbols. Therefore, it can’t be used to find the correct offset.
The python script is in this gist. Through trial and error I’ve learnt that the Reed-Solomon code used is CCSDS with dual basis, which corresponds to
decode_rs_ccsds() in Phil Karn’s KA9Q libfec. Many other satellites use the conventional representation instead, which corresponds to
decode_rs_8(). When running this python script, I get decodes with a low number of bit and byte errors, indicating that my understanding of the FEC is correct. However, as remarked above, this is not enough to determine where the FEC data starts within the packet.
Summary of the technical details:
- FEC: Concatenated code with CCSDS r=1/2, k=7 convolutional code and CCSDS (255,223) Reed-Solomon with dual basis representation
- Payload length: 223 bytes
- Syncword length: unknown
- Presence of some data between syncword and FEC encoded payload: unknown
- Convolutional code tail-ending: unknown