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

I just saw you modification, perfect , thanks you :slight_smile:

I will let you know when it will be reviewed and merged (probably tomorrow afternoon )

1 Like

Hi @deckbsd,

I’ve decided to go with the unified approach, as you suggested.
Thank you very much for providing the rsp03.txt — it really helped me a lot!

I initially used the separated fields only because I couldn’t make Kaitai compile successfully at that time, and it was meant to be temporary.
With your guidance, I was able to adopt the unified approach and resolve the conflict using your rsp03.txt version.

The pipeline has passed successfully, so I’ll wait for your review and merge tomorrow.
I really appreciate your help and support!

Best regards,
czh00361 (estima5633)
Rymansat project

1 Like

Hello @estima5633 ,

The MR with the latest RSP-03 decoder update has been tested, merged and deployed :slight_smile:

Best regards,

1 Like

Hi @deckbsd,@dl7ndr,

I’ve heard that CW signals are usually noisy and not always very reliable,
so I understand that visualizing CW telemetry might be challenging.

For RSP-03, my current goal is mainly to support the first-light reception,
so I’m planning to make heavy use of time-series graphs for CW frames.
However, the dashboards don’t look very good visually at the moment.
https://dashboard.satnogs.org/d/beutvu93yfq4gb/rsp-03?orgId=1&from=now-30d&to=now&timezone=utc&var-filter=
If you have any advice on improving the visualization,
or know of other satellites that have a similar purpose
and already use Grafana dashboards effectively,
I would really appreciate it if you could share any references or examples.

Best regards,
czh00361 (estima5633)
Rymansat project

Guess this is due to only a few values.
Your panels look good.

However, currently you use queries like this:

SELECT mean("cw_h_no003_Batt1_Discharging_mA") FROM /^$suid$/ WHERE $timeFilter GROUP BY time($__interval) fill(null)

I would remove mean and GROUP BY time($__interval) to get all and the real values displayed. Currently with only a few values, this options don’t apply, but later they could remove (group) some values and only display mean values.

Additionally, you could also let for example COBC Uptime [sec] display as a time-series graph.

For examples, feel free to take a look on dashboards of other CW beaconing satellites under :five:.

2 Likes

Hello @estima5633 ,

Since @dl7ndr already replied regarding the dashboard and i agree with him i will answer just about this :

I’ve heard that CW signals are usually noisy and not always very reliable,
so I understand that visualizing CW telemetry might be challenging.

Yes that is why the CW demodulated data on network are not automatically decoded even if a decoder is linked to the sat. The data are only automatically decoded when the data are upload manually directly in DB via the telemetry endpoint :slight_smile:

so I understand that visualizing CW telemetry might be challenging.

It is going to be challenging in terms of amount of data, since the data are not automatically decoded, few persons are uploading CW data manually after an observation :stuck_out_tongue:

1 Like

Hi @deckbsd, @dl7ndr, @fredy,

Thank you for clarifying the CW data handling on SatNOGS Network.

I understand now that CW frames are not automatically decoded and require
manual uploads to the SatNOGS DB via the telemetry endpoint.
This means that CW visualization on Grafana will largely depend on the number of
frames uploaded manually by the community.

Initially, our plan was to focus on GMSK + AX.25 as the primary method for stable telemetry reception.
However, after discussions within the RymanSat Project team, we decided that CW telemetry
will be an important source of data, especially right after deployment when we want to quickly track the satellite status.

In Japan, many amateur radio operators are already familiar with receiving and manually decoding CW telemetry,
so we expect CW data to play a significant role in the early phase.
For example, frames like GFF540018C4000000040F08CA1D08 will be visualized on Grafana
to share early health status more broadly.

For RSP-03, I have updated rsp03.ksy to correctly handle CW-G/H/I frames:

  • Fixed endian handling for all battery voltage/current fields.
  • Split multi-byte fields into low/high byte segments.
  • Verified decoding against RSP-03 CW test frames.
  • Confirmed successful Kaitai compilation and matching JSON output.

The updated decoder has already been submitted via MR:
!478 - Add CW decoder updates for RSP-03

With deployment approaching soon, our team feels a strong sense of responsibility
to make full use of SatNOGS to support both the global community and local amateur radio enthusiasts.
We plan to manually upload CW frames during the commissioning phase
so that Grafana dashboards can display at least the basic CW telemetry.

I’ve just submitted the updated RSP-03 CW decoder as part of the following merge request:
MR: !478 - Add CW decoder updates for RSP-03
Thanks many advice for yours.

During this work, I also updated the CW beacon format to handle little-endian fields correctly.

Thank you very much for your continued support —
we aim to make RSP-03 telemetry both useful and enjoyable for everyone!

Thanks. Best Regards,
czh00361(estima5633)
Rymansat Project

2 Likes

Hello @estima5633 ,

I merged your MR, but i didn’t deploy it because i noticed a little “problem” afterwards. It is related to the Identifier fields. Here are the issues :

It’s because of the way you declared the identifier fields :

for G :
:field cw_g_no001_Message_Identifier: ax25_frame.no001_message_identifier
for H:
:field cw_h_no001_Message_Identifier: ax25_frame.no001_message_identifier
for I :
:field cw_i_no001_Message_Identifier: ax25_frame.no001_message_identifier

the thing is, the path ax25_frame.no001_message_identifier is always valid whatever the CW frame type that is being decoded, so for instance, if the decoder is decoding a I CW frame, like in the screenshot you are going to have the identifier field of G, H and I because ax25_frame.no001_message_identifier does exist and is the referred path for cw_g_no001_Message_Identifier, cw_h_no001_Message_Identifier and cw_i_no001_Message_Identifier in that order, same for H, you will have also the G identifier.

So to solve this issue, it is similar to the previous topic about cw_type and cw_beacon . Either you modify your field definition to have only one identifier field like so (this will be the unified solution) :

:field cw_no001_Message_Identifier: ax25_frame.no001_message_identifier

and remove the 2 other identifiers fields.

OR you make 3 diffents path by renaming the property in the structure (sequences) like this :

for cw_g :

- id: g_no001_message_identifier
        type: str
        size: 1
        encoding: ASCII
        valid: '"G"'

for cw_i :

- id: i_no001_message_identifier
        type: str
        size: 1
        encoding: ASCII
        valid: '"I"'

for cw_h :

- id: h_no001_message_identifier
        type: str
        size: 1
        encoding: ASCII
        valid: '"H"'

and then modify the fields like this :

for G :
:field cw_g_no001_Message_Identifier: ax25_frame.g_no001_message_identifier
for H:
:field cw_h_no001_Message_Identifier: ax25_frame.h_no001_message_identifier
for I :
:field cw_i_no001_Message_Identifier: ax25_frame.i_no001_message_identifier

And also the places where the identifiers properties are used, so in cw_type and cw_beacon of the different sequences.

I hope my explanations were clear enought :slight_smile: So the main goal here whatever the approach you will choose is to have only one occurrence of an identifier field per CW frame.

Hi @deckbsd,

Thank you for merging MR !478.
I will wait a bit to confirm if the little-endian fixes for CW data are reflected in Grafana.

I’ve also reviewed your suggestion about unifying the CW message identifier fields,
and I have already prepared a local update of rsp03.ksy that implements the change:

:field cw_no001_Message_Identifier: ax25_frame.no001_message_identifier

Once I confirm that the Grafana deployment is updated and working as expected,
I plan to submit a follow-up MR with this change.

Before that, could you please confirm if the Grafana deployment for rsp03.ksy changes is already in progress?
If it takes time, I will wait for the deployment to complete first.

Best regards,
czh00361 (estima5633)
Rymansat poroject

Hello @estima5633 ,

Yes it is deployed.

Best regards,

Hi @deckbsd,

I’ve just submitted a follow-up MR to unify the CW message identifier fields as suggested:
MR: !479(https://gitlab.com/librespacefoundation/satnogs/satnogs-decoders/-/merge_requests/479)

This change removes duplicate G/H/I identifier fields and replaces them with a single cw_no001_Message_Identifier.
This should simplify Grafana visualization and keep the data clean.

Best regards,
czh00361 (estima5633)
Rymansat Project

Hello,

Thanks you, but please, remove these lines completely :
#:field cw_g_no001_Message_Identifier: ax25_frame.no001_message_identifier
#:field cw_h_no001_Message_Identifier: ax25_frame.no001_message_identifier
#:field cw_i_no001_Message_Identifier: ax25_frame.no001_message_identifier

The parser is still taking it into account :

After that i will merge it :slight_smile:

Best regards,

1 Like

Hi @deckbsd,
I force-pushed updates to MR !479.
The duplicated CW identifier fields (cw_g_no001_*, cw_h_no001_*, cw_i_no001_*) were removed completely, leaving only the unified field:
cw_no001_Message_Identifier: ax25_frame.no001_message_identifier.
Pipeline is running/passed.
Please take another look when you have a moment.

Thanks Best Regard,
czh00361(estima5633)
Rymansat project

1 Like

Hello @estima5633 ,

The MR has been merged and deployed.

Best regards,

2 Likes

Subject: RSP-03 — Promote scratchpad to telemetry

Hi @fredy, @deckbsd san
I’ve finished validating the decoders (GMSK Pkt1/2/3 and CW) using ±5% analog variations and single-bit flips—looks good.

Could you confirm the process to promote the scratchpad dashboards/queries to telemetry (target repo/MR, naming conventions)? I can attach the dashboard JSON and the verified no*** field list.

Timeline:

  • Release: Sep 19, 2025 (JST, evening)
  • Final NORAD ID: Sep 18, 2025 (JST) — to be updated by fredy san

Thanks, Best Regards,
czh00361 (estima5633)
Rymansat project

1 Like

Subject: RSP-03 CW Beacon Uploader — update target to final NORAD ID

Hi @deckbsd, @dl7ndr san
Could you please update the CW Beacon Uploader’s upload target/link to the final RSP-03 NORAD ID once fredy updates it on Sep 18, 2025 (JST)? We expect satellite release on Sep 19 (JST, evening) and would like the uploader ready. I can send an immediate test packet after the link is updated.

Thanks, Best Regards,
czh00361 (estima5633)
Rymansat project

1 Like

Hello @estima5633 ,

The RSP-03 dashboard in Telemetry has been updated with the RSP-03 decoder from Scratchpad. So the newer RSP-03 dashboard is in production :slight_smile:

I have made a suggestion on the sat DB page to modify the link ( @fredy ).

Best regard,

1 Like

I’ve updated the CW Beacon Uploader to the standard database (not db-dev).

The final NORAD ID has to be determined (usually days) after the deploy.
We will start uploading to the temporary ID. I’ll update the uploader to the final ID after it was determined and the DB entry was changed to it.

1 Like

I have slight changes in mind regarding the CW beacon panels on the dashboard.
Would it be ok for you if I’ll just do it?

1 Like

Hi @dl7ndr.

Thanks

Other members are currently working on the scratchpad for adding panel, We stop to add new panel now.

Please go ahead your CW chang. and reply me to finish your change.

Thanks
czh00361(estima5633)
Rymansat project