-
-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decoding Reaktor Hello World #218
Comments
Hi Bob, Regarding the comparison between v3-alpha4 and the current version, in v3-alpha4 did you use the flowgraph in The fact that the initial 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. |
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 |
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
((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
((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
The text was updated successfully, but these errors were encountered: