Decoding Reaktor Hello World

[N6RFM]

Hi Dani,

Been exploring Reaktor Hello World telemetry. While trying to use the parser described here https://github.com/ReaktorSpaceLab/rhw-ham , when using a satyaml decoder I noticed that the hex output to the console did not begin with 71 versus the RHW example.

When using the satyaml approach to decode the same wav file, I get this output.
Packet number 1

• MESSAGE DEBUG PRINT PDU VERBOSE *
  ((transmitter . 9k6 FSK downlink))
  pdu_length = 113
  contents =
  0000: 01 07 01 86 00 00 62 b8 2e 00 5c f8 48 03 00 65
  0010: 0c 34 00 8f 00 00 00 5d 00 00 00 0a 00 02 06 02
  0020: 02 02 02 02 02 02 02 02 02 02 a6 a9 00 00 34 a9
  0030: 00 00 00 fe ff 02 00 02 00 02 00 02 00 70 02 71
  0040: 00 60 08 ae 0d 2f 00 05 00 00 00 00 00 00 00 00
  0050: 00 77 08 be 0c 00 00 00 00 36 0b 81 0b 0d 06 0d
  0060: 06 c0 06 c0 06 00 04 00 3f 6d 61 04 d9 b6 b4 0f
  0070: ff

---

To further investigate, I went back to the earlier decoder in gr-satellites-3-alpha4 to replay the wav test file. That output is below.

2021-01-09 19:44:53
Packet number 0

• MESSAGE DEBUG PRINT PDU VERBOSE *
  ((syncword . 0))
  pdu_length = 114
  contents =
  0000: 71 01 07 01 86 00 00 62 f6 2e 00 5c fe 48 03 00
  0010: c5 0c 34 00 8f 00 00 00 5d 00 00 00 0a 00 02 06
  0020: 02 02 02 02 02 02 02 02 02 02 02 e4 a9 00 00 72
  0030: a9 00 00 00 fe ff 03 00 04 00 03 00 03 00 86 02
  0040: d4 05 60 08 aa 0d 2f 00 05 00 00 00 00 00 00 00
  0050: 00 00 78 08 bc 0c 00 00 00 00 45 0b 91 0b 0d 06
  0060: 22 09 c0 06 c0 06 00 04 00 3f 6f 73 04 d9 5d b3
  0070: bd ff

---

Not only has the leading 07 been stripped, but there are also some other differences, perhaps checksum related?

To use the RHW parser, it's a simple matter of adding back the 71 to the beginning of the hex string, but the discordance prompts this report as I wonder if somehow the hex values are correct when using the satyaml decoder.

Any suggestions?

Thanks,

Bob N6RFM

[daniestevez]

Hi Bob,

Regarding the comparison between v3-alpha4 and the current version, in v3-alpha4 did you use the flowgraph in apps/ or the gr_satellites command line tool? The reason I'm asking is because I can't find any relevant changes in the RHW SatYAML-based decoder since it was first added to SatYAML (some time before v3-alpha4). I haven't checked the old flowgraph in apps/, which comes from gr-satellites v2.

The fact that the initial 0x71 length field is stripped is intentional. I guess that this is related to the thread about the standardization of the frame formats in SatNOGS DB and to #208.

I'm hesitant to hastily make changes to how frames are treated (for instance, changing from stripping the length field to not stripping it) because this will introduce different frame formats in SatNOGS DB.

For AAUSAT-4 we had the collaboration of Nick, the satellite operator, and we decided a standard frame format (and by the way we decided to strip the initial length field, since it was kind of useless once you have decoded the message). For Reaktor Hello World I'm guessing that the fact that the tool from the team needs the initial length field would be a reason in favour of not stripping it. Perhaps it would be good to get their input on this.

Regarding the other differences between the frames, I think you are comparing different frames from the two runs. The first line already has some bytes that are different.

[N6RFM]

Hi Dani,

Correct. Data was from different runs. Just re-ran the RHW wav file into the satyaml and v3-alpha4 /apps flowgraphs at the same time using parallel UDP streams. Other than the satyaml decoder stripping the 0x71, the results are identical. Thanks reminder on why the 0x71 is lost.

I certainly understand and agree not to make changes given just having satisfied the goal of a standardized frame format. I'll reach out to the RHW team and see what they say. Will keep you posted if I get a response.

Thanks as always!

Bob