[RSP-03] SatNOGS decoder support for GMSK beacon (MR submitted, CI pipeline issue)

dl7ndr · July 30, 2025, 4:16pm

Could you send me a link to the rsp03.ksy to take a look on it?

estima5633 · July 30, 2025, 9:17pm

Thanks for following up.
The rsp03.ksy file is already included in the Merge Request. You can view it via the “Changes” tab here:
Add rsp03.ksy for GMSK beacon decoding (AX.25 included) (!472) · Merge requests · librespacefoundation / SatNOGS / satnogs-decoders · GitLab

Please let me know if you still have trouble accessing the diff or need the file in another format. I’d be happy to help.

If not, I’d be happy to explore another way to send it — though I understand direct file sharing is not supported in this chat.
Please let me know the best method for you.

Best regards,
@czh00361

dl7ndr · July 31, 2025, 5:33am

I was just unsure because of the still missing field: lines and that you successfully validated the decoder on ide.kaitai.io.
It cannot be validated using the published frame structure samples.

After ctl and pid (0x03F0) you are doing

rsp03_payload:
seq:
- id: fcs
type: u2
doc: “Frame Check Sequence (CRC-16)”
- id: flag2
type: u1
doc: “AX.25 End Flag”
valid: 0x7e
- id: packet_type
type: u1

The structure however is
03 F0 00 18 4A 80 01 29 4E 7E 68 78 C0 02 11 00

Until 0x7e there is 0x4A 80 01 29 4E unparsed.
And after 0x7e there is still 0x68 78 C0 until the presumed packet_type 0x02.

Could you send me a sample frame you used to validate the decoder?

As for the field: lines, you may use almost every other decoder as a guide.

estima5633 · July 31, 2025, 11:00am

Dear @dl7ndr and maintainers,

Thank you for your earlier feedback.

In this updated version of MR !472, I have made the following improvements:

Added a fixed 5-byte header field (0x0018AD8001) to each of packet1, packet2, and packet3, as defined in the RSP-03 AX.25 GMSK beacon format.
Updated the Signed-off-by line to comply with the contribution guidelines.

Previously, I was unable to re-run the pipeline due to my GitLab CI/CD minutes being exhausted. However, I have now purchased additional CI minutes, and the pipeline has successfully completed.

I kindly invite you to review the MR at your convenience. Thank you again for your support!
!472 Add rsp03.ksy for GMSK beacon decoding (AX.25 included) (!472) · Merge requests · librespacefoundation / SatNOGS / satnogs-decoders · GitLab

Best regards,
@czh00361

estima5633 · July 31, 2025, 11:54am

Dear @dl7ndr

I would like to report that I have successfully verified the rsp03.ksy Kaitai Struct file using a binary test file (rsp03_sample_packet1.bin) via Kaitai IDE.

*.bin 03 F0 00 18 AD 80 01 29 4E 7E 68 78 C0 02 11 00 @dl7dnr send,thanks.

The AX.25 header, including destination/source callsign, SSID, and control fields, was correctly parsed.
The control field value 0x03 triggered the ui_frame structure as expected.
The pid, packet_type, and payload structure (packet1) were correctly interpreted.
The packet1 header field matched the expected fixed value 0x0018AD8001 (u40).
All fields were parsed without error, and the object tree confirmed proper type switching based on packet_type.

A screenshot of the successful decoding is available for reference.
I will proceed with additional test packets for packet2 and packet3, but I believe the current implementation is ready for further review.

Please let me know if you have any feedback or suggestions for improvement.

Best regards,

deckbsd · July 31, 2025, 1:48pm

Hello @estima5633 ,

I would suggest in addition of testing the decoder via Kaitai IDE to install satnogs-decoder and run your decoder using it.

Because, at this moment, your decoder won’t push anything into satnogs DB. The thing is, in addition to the kaitai structure/code you have to add the fields properties. These fields definition are used to tell satnogs-decoder which property of the frame have to be in the json data that will be pushed to DB. At this moment you have no fields defined, so, the json object is going to be empty and no data are going to be pushed into the DB. When i’m talking about fields definitions, i m talking about this (this sample is extracted from the ENSO decoder):

doc: |
  :field callsign: ax25_frame.ax25_header.dest_callsign_raw.callsign_ror.callsign
  :field ssid_mask: ax25_frame.ax25_header.dest_ssid_raw.ssid_mask
  :field ssid: ax25_frame.ax25_header.dest_ssid_raw.ssid
  :field src_callsign_raw_callsign: ax25_frame.ax25_header.src_callsign_raw.callsign_ror.callsign
  :field src_ssid_raw_ssid_mask: ax25_frame.ax25_header.src_ssid_raw.ssid_mask
  :field src_ssid_raw_ssid: ax25_frame.ax25_header.src_ssid_raw.ssid
  :field repeater_rpt_instance_rpt_callsign_raw_callsign: ax25_frame.ax25_header.repeater.rpt_instance.rpt_callsign_raw.callsign_ror.callsign
  :field repeater_rpt_instance_rpt_ssid_raw_ssid_mask: ax25_frame.ax25_header.repeater.rpt_instance.rpt_ssid_raw.ssid_mask
  :field repeater_rpt_instance_rpt_ssid_raw_ssid: ax25_frame.ax25_header.repeater.rpt_instance.rpt_ssid_raw.ssid
  :field ctl: ax25_frame.ax25_header.ctl
  :field pid: ax25_frame.payload.pid
  :field length: ax25_frame.payload.ax25_info.length
  :field frame_type: ax25_frame.payload.ax25_info.frame_type
  :field var_ts: ax25_frame.payload.ax25_info.var_ts
...

You can use the script contrib/generate_field_docstring.py · master · librespacefoundation / SatNOGS / satnogs-decoders · GitLab to help you generating the fields. It will do 90% of the job but you will have to review the result and modify it accordingly to your needs.

dl7ndr · July 31, 2025, 4:51pm

I’m looking at this version of rsp03.ksy and cannot verify it in ide.kaitai.io.

You are now parsing control and pid two times. First in header, then additionally in payload.

Referring to 03 F0 00 18 4A 80 01 29 4E 7E 68 78 C0 02 11 00 and looking at

rsp03_payload:
seq:
- id: control
type: u1
doc: “0x03”
- id: pid
type: u1
doc: “0xF0”
- id: packet_type
type: u1
- id: payload
type:
switch-on: packet_type
cases:
1: packet1
2: packet2
3: packet3

you would need to discard 0x0018AD8001 at the bold part. 0x294e is the fcs? And then comes 0x7e as flag2.
After that you still need to discard 0x6878c0 to finally parse the packet_type.

Can you point me to rsp03_sample_packet1.bin you’ve mentioned. Perhaps it’s just me who is wrong.

estima5633 · August 2, 2025, 1:21am

Hello @dl7ndr ,@deckbsd SA2KNG

Following your earlier feedback, I have updated the RSP-03 decoder as follows:

Added :fields definitions to rsp03.ksy (AX.25 common in ui_frame.doc: |, payload Packet1/2/3 in rsp03_payload.doc: |).
YAML (rsp03.yml) updated to include matching fields: entries (AX.25 + Packet1/2/3 = 8/109/28/72, total 217). CW beacon entries removed as RSP-03 will switch to MODE2 (GMSK only) after launch.
README updated with detailed field counts and validation notes.
Verified decoding on 3 sample .bin frames for Packet1, Packet2, Packet3 with no parse errors.

I have prepared these files (rsp03.ksy, rsp03.yml, README.md, and the 3 sample .bin frames) as a review bundle.

MR !472 UPLOAD done.

… I have prepared these files as a review bundle and attached the ZIP on Activity to this MR for your review.
Note: The review bundle (rsp03_review_bundle.zip) has been successfully attached to this MR, so you can download it directly from here.

However, as a new user in this chat, when I try to attach the bundle here I get the message:
“Sorry, new users can not upload attachments.”
This prevents me from directly sharing the files on the community platform.

Could you please advise:

The correct repository/path where the YAML,Readme.md… should be stored.
The preferred way to share the review bundle with you (e.g., cloud link, email, etc.).

Thank you for your guidance and support.

Best, Regard
czh00361

estima5633 · August 2, 2025, 1:40am

Hello @dl7ndr and reviewers,

Following your earlier feedback, I have updated the RSP-03 decoder:

Added :fields definitions to rsp03.ksy (AX.25 common in ui_frame.doc: |, payload Packet1/2/3 in rsp03_payload.doc: |).
YAML (rsp03.yml) updated to include matching fields: entries (AX.25 + Packet1/2/3 = 8/109/28/72, total 217). CW beacon entries removed as RSP-03 will switch to MODE2 (GMSK only) after launch.
README updated with detailed field counts and validation notes.
Verified decoding on 3 sample .bin frames for Packet1, Packet2, Packet3 with no parse errors.

As a new user, I cannot upload attachments directly to the forum.
To ensure you can access the files, I have placed the review bundle (rsp03.ksy, rsp03.yml, README.md, and 3 sample .bin frames) on My Google Drive:
The link will be available for a limited time (e.g., 30 days) for review purposes only.
Please download the files before the expiration date.

[Google Drive Link Here]

Please let me know if you can access the link and if you have any preferred alternative for sharing.

Thank you for your guidance and support.

dl7ndr · August 2, 2025, 10:29pm

Do you mean something like this came out?

It’s only decoding the header, and even that incorrectly.

Your attached 3 sample .bin files differ greatly from what the sample .wav file is delivering.

rsp03_GMSKpacket1.bin:

7E AA AA AA AA AA AA 60 94 A6 62 B2 9E B2 61 03 F0 01 80 AD 18 00 29 4E 00 00 6E 68 01 11 22 78 56 34 12 01 02 03 04 05 06 07 08 08 07 06 05 04 03 02 01 00 01 01 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 00 00 7E

The first beacon from .wav file:

94 A6 62 B2 A0 82 60 94 A6 62 B2 9E B2 E1 03 F0 00 18 AD 80 01 29 4E 7E 68 78 C0 01 11 00 54 00 00 00 AE 67 2F 03 00 00 00 00 AD 51 61 2D 98 01 00 00 00 04 0F 08 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 FE FF 00 00 00 00 01 00 2F 00 00 00 18 00 25 00 24 13 24 0C 64 00 00 00 E1 FF 00 00 E1 FF 00 00 1B 00 00 00 E1 FF 00 00 E1 FF 00 00 01 00 00 00 00 00 00 00 CA 1D 00 00 F0 FF 1A 00 D1 1E 04 00 04 AE 17 00 85 1D 00 00 4A 00 1B 00 5F 03 FB FF 70 CA 28 00 7F 30 8C B0 00 3D 0E 00 7C 08 00 01 01 00 21 0E 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00

Please provide us the exact AX.25 beacon format and a sample file (.wav and .bin) from what you expect to be decoded from your satellite.
This must start with the destination callsign, not with 0x7e.

You don’t need a Readme.md. Regarding the .yml, I have no idea.
You should be able to attach .zip files to your post.

estima5633 · August 3, 2025, 9:51am

Dear @dl7drn ,All

Many thanks again for the detailed feedback and support.
Looking forward to final review and merge.

Following our recent discussions and feedback from dl7drn, deckbsd, and others, I have updated the rsp03.ksy decoder:

Implemented head5[] to validate the fixed 5-byte header for Packet1, Packet2, and Packet3, avoiding scope access issues.
Quoted the ternary expression in expected_len to ensure proper YAML parsing.
Retained size-eos: true to handle payload parsing without FCS, as required for SatNOGS observations.

The Merge Request (!472) and Kaita check has now passed all CI checks.

Please provide us the exact AX.25 beacon format and a sample file (.wav and .bin)

I am attaching three AX.25 binary sample files (from dl7drn’s decoded frames) for reference and testing:
packet1_ax25_dl7drn_no_fcs.zip (1005 Bytes)

packet1_ax25_dl7drn.bin
packet2_ax25_dl7drn.bin
packet3_ax25_dl7drn.bin

These binaries can be loaded into the Kaitai Web IDE to verify proper decoding against the updated .ksy.

Best,Regard
CZH00361

P.S. The satellite is planned for launch in late August. One of our volunteer members in charge of ground station setup is currently unable to work due to illness, and I only joined RymanSat in June with limited experience in programming and GitLab workflows. I apologize for any delays or inefficiencies and will do my best to improve and learn quickly.

I hope to share the enjoyment of satellite communications with people around the world, and I am looking forward to having RymanSat signals received globally through the Powerfull SatNOGS network .

dl7ndr · August 3, 2025, 3:11pm

I’ve corrected everything and tested it with decode_frame.py.

rsp03.ksy + decode_frame_results.zip (6.8 KB)

It’s now again your part to verify whether the results of the decoder meet your expectations.

estima5633 · August 3, 2025, 6:37pm

Dear. @dl7ndr, SatNOGS support member.

Updated rsp03.ksy to match dl7drn’s simplified and verified version, which focuses on robust parsing and consistent field mapping.
Verified with decode_frame.py to produce identical results to the expected outputs.

If needed in future operations, fixed-header and payload-length validation logic from earlier versions can be reintroduced as optional checks.

Finalized with dl7drn’s checked rsp03.ksy and verified with decode_frame.py.
Many thanks for your great support.

Best,Regard
czh00361

estima5633 · August 3, 2025, 6:49pm

Dear. @deckbsd @SA2KNG

The MR for rsp03.ksy has passed all checks:

It is now waiting for approval from an eligible user.
Could someone from the maintainers please review and approve?
Thank you very much!

deckbsd · August 5, 2025, 6:13am

Hello

I will review it at least for today. But just a thing i see already is that your MR is containing 15 commits, can you please squash your commits into one ? We keep the commit history as clean as possible, so adding a decoder should be made of one commit only

estima5633 · August 5, 2025, 1:57pm

Dear @deckbsd,

Thank you for reviewing this!

Yes, I’ll squash all commits into one for clarity and to follow project standards. I’ll push an updated MR shortly.

Really appreciate your time and support.

Best regards,
czh00361 / JS1YOY
RSP-03 Ground Segment

estima5633 · August 7, 2025, 11:21am

Dear @deckbsd

Thank you again for your previous guidance and kind feedback.

As suggested, I have now squashed the commits into a single one on the feature/rsp03_clean branch. The updated merge request is still available here:

Add rsp03.ksy for GMSK beacon decoding (AX.25 included) (!472) · Merge requests · librespacefoundation / SatNOGS / satnogs-decoders · GitLab

Commit message:
feat(rsp03): Add AX.25 GMSK decoder with beacon format v1

Please let me know if there are any further changes or improvements required.
I appreciate your continued support!

Best regards,
czh00361
RSP-03 Ground Segment Team / RymanSat Project

deckbsd · August 7, 2025, 6:32pm

Hello @estima5633 ,

It is almost perfect. Can you please just add a valid condition on the callsign structure. This is needed to avoid uploading noise/bad formed/or unrelated frames into the DB. I have provided a sample to you in the previous messages, this one from the ENSO decoder :

  callsign:
    seq:
      - id: callsign
        type: str
        encoding: ASCII
        size: 6
        valid:
          any-of:
            - '"F4KJX "'
            - '"FX6FRC"'

(be aware that you will have to put all the possible src and dest callsigns in the valid statement because this type in common to both).

so for you, something like :

  callsign:
    seq:
      - id: callsign
        type: str
        encoding: ASCII
        size: 6
        valid:
          any-of:
            - '"?UUUUU"'
            - '"0JS1YO"'

Once it is done, you can add the modifications and do a git commit --amend and after that git push --force your_token to avoid creating a new commit

estima5633 · August 8, 2025, 2:29pm

Dear @deckbsd

Thanks you for your request.
Added valid condition for callsign (ASCII, 6 chars) with allowed values JS1YOY (satellite) and JS1YPA (ground station). and Kaitai cheched.
Squashed the previous commits into one for cleaner history.(git commit --amend)
Force-pushed to feature/rsp03_clean.
Thank you for the review and guidance.

add in rsp03.ksy

callsign:
  seq:
    - id: callsign
      type: str
      encoding: ASCII
      size: 6
      valid:
        any-of:
          - '"JS1YOY"'
          - '"JS1YPA"'

Best regards,
czh00361
RSP-03 Ground Segment Team / RymanSat Project

estima5633 · August 8, 2025, 10:13pm

Dear @deckbsd, @deckbsd , @dl7ndr
The launch of RSP-03 on August 21 is approaching, and I and Rymansat members are very excited to see it in orbit soon.
As an amateur contributor, this is my very first Merge Request to SatNOGS, and I apologize if my process has not always followed the most efficient or standard workflow. I greatly appreciate the guidance and patience from the community so far.

After this MR is merged, we will still need to add the TLE for RSP-03 after launch, once the NORAD ID is confirmed. Since I am not yet familiar with the exact process for TLE registration in the SatNOGS DB, I would greatly appreciate the support from the SatNOGS team and community members to ensure it is correctly set up.
This will help make RSP-03 reception possible for the amateur radio community worldwide from the very first passes.
Thank you very much for your understanding and support.