Hi czh00361,
I’ll only comment on rsp03_beacon.ksy.
As far as I understand, you want to let SatNOGS decode the three GMSK beacon types as in RSP-03_GMSK_HKBeaconSample.wav.
Let us take a look at the second HK beacon type:
94 A6 62 B2 A0 82 60 94 A6 62 B2 9E B2 E1 03 F0 00 18 4A 80 01 29 4E 7E 68 78 C0 02 11 00 0C 68 2F 03 00 00 00 00 0B 52 61 2D 98 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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.
Daniel