GREENCUBE decoded frames incorrect about gr-satellites HOT 5 OPEN

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

from gr-satellites.

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

from gr-satellites.

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.

from gr-satellites.

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?

from gr-satellites.

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.

from gr-satellites.