GREENCUBE decoded frames incorrect

[Jacob-Higgins]

GREENCUBE is decoded successfully to get the frames in hex. But the hex values do not match up with what is expected according to the GREENCUBE team. When looking at the 105byte length telemetry frames, excluding the header bytes (first 4), the next 2 bytes in hex should be either 3612, 3611, or 3610 (https://www.s5lab.space/GreenCube_telemetry_20220721.ods). In my decoded frames, these 2 bytes are almost exclusively 761a. Is anyone able to help here as to whether this is an issue, or I am interpreting the frame hex incorrectly.

[daniestevez]

The frames output by gr-satellites contain the CSP header. Have you taken this into account?

[Jacob-Higgins]

Hi Dani, yes I believe so. By my understanding, the csp header is the first 32 bits, and hence the first 4 hex pairs, of the pdu. So i am therefore looking at the 5th byte as the start of the data. For example, this is a frame outputted by the gr_satellites command line tool, and it matches the output of a flowgraph i constructed with BPSK demodulator and AX100 deframer blocks into a message debug block, hence i believe the start of the data to be 761a :

***** VERBOSE PDU DEBUG PRINT ******
()
pdu length = 105 bytes
pdu vector contents =
0000: 82 92 3e 00 76 1a 01 cb 65 40 40 ad 00 ac 03 94
0010: 03 a0 02 da 02 ff 03 13 13 13 12 13 13 00 37 00
0020: 0b 20 57 00 17 bc 01 74 7d ff 96 20 95 01 f9 00
0030: a0 5a b0 33 00 17 00 7f 00 5d fc 06 10 bc 24 e6
0040: 0b 44 0e 0e 0e 0e 00 00 00 09 00 07 00 00 00 00
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 00 00 00 83 01 eb 83 d5 c5

---

[daniestevez]

Yeah. Some fields clearly don't match the documentation, since the telemety identifier isn't 0x3612, 0x3611 or 0x3610. However other fields do seem to match the documentation and are in the correct location. For instance, 0x654040ad is a reasonable UNIX time, and the 6 0x13 or 0x12 bytes are reasonable EPS temperatures.

[Jacob-Higgins]

Indeed, I will caution by saying some fields such as bus voltage are seemingly incorrect at 1V, and would expect them to be much closer to 4.5V -5V for a bus. Also on some of the digipeater packets, the messages seem to contain unreadable symbols. Could this be a case of a poor signal quality, or is there a deeper underlying issue here. For example, in the documentation it says that all of the network link layer is passed through a G3RUH scrambler on the sat side (https://www.s5lab.space/index.php/decoding-ledsat-2/), am i correct that the descrambling occurs as part of the gr-satellites "GOMspace AX100 Deframer" block?

[daniestevez]

The GREENCUBE SatYAML file in gr-satellites specifies "AX100 ASM+Golay framing". This includes CCSDS descrambling (not G3RUH descrambling!). There is a Reed-Solomon (255, 223) code as part of the decoding. While this is not a 100% reliable test for packet integrity, it gives a reasonable confidence that the decoded packets are correct, specially if the Reed-Solomon decoder corrected only a few or none byte errors. I think that the main thing going on here is that the S5Lab documentation is inaccurate.