I’m a member of the Rymansat Project and working on enabling the decoding of our upcoming satellite RSP-03 in SatNOGS.
RSP-03 transmits telemetry beacons using GMSK modulation at 437.050 MHz, 9600bps.
To support this in SatNOGS, I have prepared and submitted a Merge Request (MR) to the satnogs-decoders repository.
Merge Request:
Included files:
decode_rsp03_gmsk.py: Python decoder for the beacon packets
However, to support the telemetry beacons in SatNOGS you have to add a decoder in kaitai struct format (.ksy) if you want SatNOGS to be able to decode frames.
Some quick notes, do note that I’m not reviewing on -decoders.
the ksy does not need _beacon in the file name.
you cannot add random new directories to the root, like /rsp03/, I think these belong in /contrib/rsp03/. The same goes for the /test_samples/, depending on their size.
no .gitkeep’s
no rewrite of .gitlab-ci.yml
You have to handle the AX.25 header (destination and source callsign, ctl and pid) in the .ksy decoder file.
To do so, please take a look at ax25frames.ksy.
[Line 68 has a little bug, it should be 0x1f.]
Your current decoder file says that beacon type 2 (I’m just guessing it’s the byte in bold in the hex data) has a payload size of 18 bytes and parses it like this:
packet2:
doc: “Housekeeping data (timestamp, temperature, status)”
seq:
- id: timestamp_os
type: u8
doc: “Telemetry OS Time [ms]”
- id: timestamp_sys
type: u8
doc: “Telemetry System Time [ms]”
- id: mobc_temp
type: s1
doc: “MOBC Temperature [°C]”
- id: system_status
type: u1
doc: “System Status”
If you want the decoder to start parsing the payload after the packet_id, you must tell it to do so.
Are you sure 18 bytes is correct?
Additionally, but this is a SatNOGS thing, you also have to include into the .ksy file which value with what name to make accessible to the SatNOGS database.
This is done by the :field lines in the first part of the ksy file, as you may already noticed in ax25frames.ksy.
Some few words in addition of what @dl7ndr said regarding the kaitai file. Once you will have handled AX25, please add a valid instruction on the callsign property to exclude bad/malformed frame being uploaded to SatNOGS DB (you can find multiple exemple on how to do it inside the ksy folder. Here for instance ksy/enso.ksy · master · librespacefoundation / SatNOGS / satnogs-decoders · GitLab line 141).
Regarding the MR itself, you should only add the ksy file. You can also add sample in the contrib folder (contrib · master · librespacefoundation / SatNOGS / satnogs-decoders · GitLab) if you want or add your name in the README file but that is it. Please remove the rsp-3 folder, gitkeep files, gitlab-ci.yml file and like i said previously, if you want to provide sample, put it in the contrib folder
.gitlab-ci.yml has been reverted to avoid unnecessary modifications.
The decoder has been moved under contrib/, with proper formatting and cleaned identifiers.
I also added the import: ax25frames.ksy directive in the .ksy file
(referencing: ksy/ax25frames.ksy · master · librespacefoundation / SatNOGS / satnogs-decoders).
Regarding the comment “Are you sure 18 bytes is correct?”,
you are absolutely right — that was my mistake. I have corrected the .ksy accordingly.
Please let me know if there’s anything else to address.
Hi,
looking at MR 471, the ksy file was moved to contrib, this was not what I meant.
all decoders belongs in /ksy, other examples, python scripts etc are welcome in /contrib/rsp03 or similar.
Something odd happened with your rebase, I think it was made into some merge and ended up inside the MR of INNOSAT16.
now, there’s several ways to reset this, but make sure the master is up to date and branch from that. if you have problems pushing, you can use --force to overwrite the remote branch.
normally you rebase the branch on master to make it up to date and put your commit on top of that.
make sure it’s only one commit with everything needed.
hope this helps.
Thank you for your feedback. I’ve updated the rsp03.ksy file and moved it from contrib/rsp03/ to the correct location under the ksy/ directory, as per your guidance.
I also inlined the AX.25 frame definition instead of using the import feature, and removed the invalid imports block that caused build failures. I’ve tried to align the structure to follow the conventions used in other satellites like snuglite.ksy and ax25frames.ksy.
I suspect it might be due to an outdated or incorrect syntax when referencing the AX.25 type in the type field. I’m reviewing the inline ax25_frame definition and expression syntax now.
Any advice or examples from existing working decoders would be greatly appreciated.
The provided link shows a 404 error.
But I found your rsp03.ksy here.
Under packet1 you are trying to parse 16 bytes of signed integer (s16). kaitai struct only supports 8 bytes (s8).
However, you are doing this 36 times. This would sum up to a at least 576 bytes packet. Did you mean 16 bits instead of bytes?
Under packet3 there are even s32 types.
Under packet2 there is a u5 type which is not supported by kaitai struct. You may use b40 (=5 x 8 bytes).
An also unsupported description is float.
At the beginning there are still the field: lines missing.
!472 MR request done.
Thank you very much for your previous guidance and feedback regarding the RSP-03 decoder implementation.
I have updated the rsp03.ksy file to support AX.25 UI frames (PID 0xF0) with full structure as described in the documentation below. The decoder now includes:
Start Flag (0x7E), Control (0x03), PID (0xF0), and End Flag (0x7E)
FCS (CRC-16) validation field
Payload parsing based on packet_type values
Strict structure aligned with the standard AX.25 UI frame format
Merge Request:
Request:
