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

estima5633 · August 29, 2025, 3:59pm

Subject: Support request for RSP-03 tracking using ISS TLE before deployment

Hello @Deckbsd, @Fredy, and the SatNOGS community,

I would like to ask for your advice and support regarding the upcoming deployment of our RSP-03 satellite.

RSP-03 is currently inside the ISS, delivered via CRS-33, and waiting for deployment.
Since this is our first satellite launch in about three years ago(after RSP-00 and RSP-01), some of our team members are not very experienced with recent SatNOGS operations.

Currently, the satellite’s power is OFF and its NORAD ID has not yet been assigned.
However, we have published an ISS TLE on our website (https://rsp03.rymansat.com/en/track).

We are also planning to track the satellite using the CubeSat TLEs from CelesTrak (https://celestrak.org/NORAD/elements/gp.php?GROUP=cubesat&FORMAT=tle) once they become available.

Our main question is:

Is it possible to start SatNOGS operations using the ISS TLE before the official NORAD ID is released,
so that we can prepare for the first track and possibly receive the CW beacon right after deployment?

We have even added CW support into our .ksy decoder urgently so that SatNOGS and the amateur radio community could help us with early signal acquisition.

We understand this is a big request, but we would be very grateful for any advice or support you can provide on how to proceed — especially any possible ways to leverage SatNOGS stations and the global amateur radio community to detect the first signals.

Best regards,
Isamu Furukawa
RymanSat Project, RSP-03 Ground Station Team

fredy · August 29, 2025, 4:32pm

@estima5633

Sure, we are going to fully track RSP-03 through Network when it is deployed by using initially the ISS TLE at the time of deployment and generate new ones if needed, however usually ISS deployed satellites get quickly NORAD IDs, some hours to a couple of days from deployment.

The challenge would be to identify which object (NORAD ID) is the right for the satellite, in case that other satellites will be deployed with RSP-03 then it may need some days before they are separated enough to identify them, however if we have more info about the other satellites this may accelerate the identification process.

So, from you what is needed is the exact date and time of deployment, as soon as you have it, and if any other satellites will be deployed with yours at the same day. Any info you can share about them would be helpful, ideally we need their names and possible transmission frequencies of them.

One more thing, I see there are 7 transmitters in DB entry, while they are all of them in the same frequency, will be helpful to know which of these transmissions will be active right after the deployment (mode and baudrate). This will help us to schedule Network’s stations for the right transmission and will give us better opportunity to demodulate and decode the data.

If you have any questions on the above let me know.

dl7ndr · August 29, 2025, 6:25pm

done. → updated web uploader.

GFF540018C4000000040F08CA1D08

will be uploaded as

4746463534303031384334303030303030303430463038434131443038

estima5633 · August 30, 2025, 1:27am

Hello @fredy, All,

Thank you for your previous response and for your support regarding the tracking of RSP-03.

Here is the latest information we can provide at this moment:

Deployment date
The exact deployment date is not yet confirmed.
We expect to receive the official notice approximately one week before deployment.
Please keep these details within the SatNOGS community until the deployment date.

Additionally, we would like to ask if it is possible to temporarily assign the ISS TLE to a provisional NORAD ID for RSP-03 (98654).
If we can leverage SatNOGS observation data from the very first track right after deployment, it would be extremely helpful for early signal acquisition.

Other satellites deployed together with RSP-03
Based on the information we currently have, the following satellites are planned to be deployed together:

Satellite	Frequency (MHz)	Notes
RSP-03	437.050	GMSK 9600 AX.25 G3RUH + CW beacon
GHS-01 Gifu Sat	437.090	1k2AFSK, 9k6GMSK, Digitalker, CW
Stars-Me2	437.305 / 437.485 / 437.275 / 437.465	1k2AFSK, 9k6FSK, CW, JJ2YXO
BIRDS-X	437.375	4k8GMSK, APRS, CW
Atsushi	N/A	no transmission

RSP-03 transmitter configuration
After deployment, the satellite will normally transmit a beacon:
- GMSK 9600bps AX.25 G3RUH
- CW beacon
- Operating mode: MODE1 specification
IARU frequency coordination
RSP-03 coordination has been completed on 13 May 2023.
Reference: IARU coordination details

We will update you again once the deployment date is officially confirmed or if we receive additional technical details about the other satellites.

Best regards,
czh00361 (estima5633)
RymanSat Project — RSP-03 Ground Station Team

estima5633 · August 30, 2025, 3:17am

Hello @dl7ndr,

Thank you for updating the new RSP-03 CW Beacon Web Uploader.

I tested the new uploader using the following CW beacon strings:

GFF540018C4000000040F08CA1D08
H0036001AB91D000000001B7F303D
I0D08000000010090C1793B90C100

The uploader now successfully converts the entire ASCII strings into HEX and registers them correctly in the database.

Example from the DB:

2025-08-30 03:02:27 | 4746463534303031384334303030303030303430463038434131443038
2025-08-30 03:02:27 | 4830303336303031414239314430303030303030303142374633303344
2025-08-30 03:02:27 | 4930443038303030303030303130303930433137393342393043313030

Everything works perfectly now.
Thank you very much for your quick fix and support!

Best regards,
czh00361(estima5633)
RymanSat Project — RSP-03 Ground Station Team

dl7ndr · August 30, 2025, 7:07am

Did you think about extending your dashboard by a row for the CW beacon data?

As an example: LASARsat (last row “CW Beacon”)

estima5633 · August 30, 2025, 10:19am

Subject: RSP-03 — CW Beacon handling and Grafana integration

Hi @dl7ndr and @fredy,

I checked the LASARsat dashboard JSON and noticed that the CW panel queries the field cw_beacon directly from the telemetry InfluxDB measurement for $suid, grouped by station.

Just to confirm — for RSP-03, should we also expect SatNOGS to provide CW data points in the same way via the telemetry database, so that we can build Grafana panels around cw_beacon?

For our “first-light” phase, we’d like to keep the CW Grafana integration minimal — just:

daily count of decoded CW beacons
cumulative number of decoded CW beacons

I’d also like to explain our intention.

We really appreciate everyone’s support, especially dl7ndr for preparing the “RSP-03 CW Beacon Uploader.”
After SatNOGS recordings are uploaded, we expect many satellite fans and amateur radio operators will use the uploader to decode CW and contribute results back. To acknowledge their efforts, we’d like to show CW statistics on Grafana.

At this stage, I am the only one from RymanSat managing SatNOGS integration, while our ground station development team is just two members. Since we also need to work on other complex modulations (4FSK, OQPSK 24k) for RSP-03, I’d like to keep CW visualization minimal for now. But later, when we revisit the GMSK implementation, I hope we can improve the CW view together.

Additionally, I’d like to ask for your assistance in preparing the CW Grafana panel together:

Which database or datasource should we access when creating and testing the CW panel?
If CW uses the scratchpad during early operations, how should we switch between scratchpad and production telemetry dashboards later?
Are there any recommended workflows to verify CW integration safely without affecting production data?

If we can collaborate on preparing a clean, minimal “first-light” CW display for the community, it would be a huge help.

Best regards,
czh00361 (estima5633)
RymanSat Project — RSP-03 Ground Station Team

deckbsd · August 30, 2025, 11:51am

Hello @estima5633 ,

Regarding this :

No, you will have the fields you provided in your decoder (exactly the same as for the AX25 packet). The cw_beacon you see on the dashboard is a field defined into the LASARTSat decoder (line 13) .

Which database or datasource should we access when creating and testing the CW panel?

At this moment the RSP-03 dashboard is using the production SatNOGS influxDB database. So if you want to see the CW frames into it, you have to upload your testing frames in production (just change the api url) or change the datasource in the dashboard settings.

If CW uses the scratchpad during early operations, how should we switch between scratchpad and production telemetry dashboards later?

Both the dashboard you made in Scratchpad and the one in Telemetry, without changing the datasource are pointing to the SatNOGS Inluxdb prod database. Again the idea of using Scratchpad is to develop the dashboard. You can think about it like development environments, so Scratchpad is like acceptance/dev and telemetry is production. So if you have new dev to do on the dashboard, do it on the one into the Scratchpad folder, once it is done and tested, we will update the one in Telemetry.

Are there any recommended workflows to verify CW integration safely without affecting production data?

The test data are going to be deleted before the deployment of the Satellite, so don’t worry about uploading “bad” frames (using the temporary NORAD ID of RSP-03 of course).

If you want we can do the minimal display for you.

dl7ndr · August 30, 2025, 4:26pm

As @deckbsd (thanks for answering the questions) already explained, the field cw_beacon is an additional field in lasarsat.ksy.
I missed it to gave you a hint to add a field like that, sorry.

For uploading people it is really nice to see their own and from others uploaded beacons on the dashboard to confirm correct upload and compare it with the others, although it is not mandatory for displaying the beacon values.
You may think about adding this field into your .ksy. It just strings together (+) the already present cw values to reconstruct the original uploaded string.

For LASARsat it’s:

cw_beacon:
  value: '"u"+uptime_total_raw+"r"+reset_number_raw+"t"+temp_mcu_raw+"p"+temp_pa_raw'

Just to compare the difference without and with a beacon field:

CO-65 (no beacon field)
CO-57 (with beacon field)

But as you can see, there is no more contribution with having a beacon field.
Anyway, don’t expect many cw beacon upload(er)s.
People have to do it manually and even switching to the comfortable web uploader, the contributors didn’t increase.

I don’t know if uploaders will lose interest earlier if there are no graphs and other visualizations for showing the values.
For me it would be: “I take the effort to receive, read and upload the CW beacon, and you show me the decoded beacon values nicely displayed.”

If time is the problem, also I could assist you or even take over this part of the dashboard.

estima5633 · August 31, 2025, 6:10am

Hi all — quick question to confirm the expected flow for telemetry decoders.

We’ve just opened an MR for rsp03.ksy in satnogs-decoders (adds cw_beacon and cw_type for CW G/H/I, minimal and first-light safe).
SatNOGS-decoder !476
We also prepared rsp03.yml that publishes the CW fields to the DB (common cw_beacon/cw_type, plus a minimal numeric set for G/H/I).
rsp03.zip (3.8 KB)

Before I open the YAML MR, I’d like to confirm the canonical home and role of the YAML:

Division of responsibilities (our current understanding):

.ksy = binary parsing / structure definition only.
.yml = declares which parsed fields are exposed to SatNOGS-DB (key names, type/decoder), and those become the series/columns that Grafana can query.
Is this understanding correct?

Repository placement:
Should rsp03.yml be merged in satnogs-db (as the source of truth for published fields), while rsp03.ksy stays in satnogs-decoders?
Or do you prefer keeping a copy of the YAML next to the KSY in satnogs-decoders as well (for traceability or CI), with satnogs-db pulling from there?
Examples / conventions:

Is there a canonical example (e.g., CO-57 / LASARsat) showing where their YAML lives today?
Any naming conventions for field keys (e.g., cw_beacon, cw_type) or measurement usage we should follow?

CI / local checks:

Apart from yamllint, are there recommended checks to run locally before filing the YAML MR?
Any pipeline or validator that ensures the YAML matches the KSY fields?

Plan (once confirmed):

Keep CW Grafana minimal for first light: daily & cumulative counts and a small raw cw_beacon table; a few basic lines (voltage/current, antenna status).
We’ve compile-tested the KSY and validated against AX.25 samples. YAML is ready for MR once we confirm the correct repo and conventions.

Thanks a lot for the guidance!
— czh00361 (estima5633), RymanSat Project — RSP-03 Ground Station Team

deckbsd · August 31, 2025, 6:53am

Hello @estima5633 ,

We’ve compile-tested the KSY and validated against AX.25 samples. YAML is ready for MR once we confirm the correct repo and conventions.

Why are you talking about a YML file ? the kaitai structure and the fields definitions (which define the exposed properties/fields to the influxDB) should be in the same file KSY file, look at your actual decoder here .

If you want to modify the decoder, do it the same way We don’t use YML file in SatNOGS-decoders.

Best regards,

dl7ndr · August 31, 2025, 8:56am

No, there isn’t.

Please check, if you are missing

  :field cw_beacon: ax25_frame.cw_beacon
  :field cw_type: ax25_frame.cw_type

estima5633 · August 31, 2025, 10:55am

Hi @deckbsd, @dl7ndr,

I’ve just updated MR !476 with the latest changes:

Added the missing :field definitions for cw_beacon and cw_type in rsp03.ksy.
Rewrote the MR description for better clarity.
Now fully understand that .yml files are not required for SatNOGS decoders,
and that all field definitions should live inside the .ksy file.

Once this MR is approved and merged, I’ll begin updating the Grafana dashboards
to include CW-related panels (daily/cumulative counts and raw beacon table).

Thank you very much for your continuous guidance and support throughout this process!
Your feedback has been extremely helpful.

Best regards,
czh00361 (estima5633)
Remansat Project

deckbsd · August 31, 2025, 11:24am

Thanks, almost ok ,

Like @dl7ndr said, be aware that you didn’t add a :field definition for the new cw_type and cw_beacon properties, so it won’t be available on DB/Grafana side

Please add the fields to make the properties accessible in the RSP-03 dashboard.

estima5633 · August 31, 2025, 3:14pm

Subject: [SatNOGS] New MR !477: Update RSP-03 decoder (rsp03.ksy) and CW beacon fields

Hi. @deckbsd, @dl7ndr, all

I have submitted a new merge request for the RSP-03 decoder with CW.
(!476 closed)

MR: !477
Link: https://gitlab.com/librespacefoundation/satnogs/satnogs-decoders/-/merge_requests/477

Summary of changes

Updated rsp03.ksy to separate CW beacons into G, H, and I types.
Added dedicated cw_type_g, cw_type_h, and cw_type_i fields, which now return ASCII (“G”, “H”, “I”) for Grafana/InfluxDB integration.
Added cw_beacon_g/h/i fields for direct display of full CW beacon data.
Removed duplicate :field definitions for consistency.
Verified that Kaitai compiler runs without errors.
Successfully tested decoding of sample CW G/H/I frames.

Thank you for your continued support!

Best regards,
czh00361 (estima5633)
Rymansat Project

deckbsd · August 31, 2025, 6:49pm

Hello,

I doesn’t work using satnogs-decoder. The cw_types and cw_beacons field are not returned. The reason is, the path are not correct, you don’t have to put the cw_i/g/h (sequences) ,you have to do it like this (by just using the ids) :

  :field cw_beacon_g: ax25_frame.cw_beacon_g
  :field cw_type_g: ax25_frame.cw_type_g
  :field cw_beacon_h: ax25_frame.cw_beacon_h
  :field cw_type_h: ax25_frame.cw_type_h
  :field cw_beacon_i: ax25_frame.cw_beacon_i
  :field cw_type_i: ax25_frame.cw_type_i

also like @dl7ndr suggested, maybe it would be easier to do :

  :field cw_beacon: ax25_frame.cw_beacon
  :field cw_type: ax25_frame.cw_type

And then renaming the properties cw_beacon_i/g/h by cw_beacon and cw_type_i/g/h by cw_type in each CW type kaitai structure you have.

That way, it will be easier to get the stats you want (like for instance, by just doing a COUNT with a GROUP BY on only cw_type instead of playing with 3 columns (cw_type_i, cw_type_g cw_type_h) to show how many frames of each type have been received). But this is your call

Best regards,

estima5633 · August 31, 2025, 9:39pm

Subject: Update on RSP-03 CW fields implementation

Hi @deckbsd,

Thank you very much for your detailed advice and suggestions regarding the CW beacon fields and cw_type.
I fully understand that unifying them into a single cw_beacon and cw_type would make the statistics and Grafana dashboards much simpler, as you explained.

However, due to my current limitations with Kaitai Struct and compiler errors, I was not able to make the unified approach work correctly.
For now, I’ve decided to proceed with the separate fields (cw_beacon_g, cw_beacon_h, cw_beacon_i and cw_type_g, cw_type_h, cw_type_i) as a temporary solution.

I would like to confirm decoder behavior first, so it would be really helpful if we could proceed with the current MR based on this simpler (A) approach.
Later, once I gain more experience, I plan to revisit and refactor the .ksy to follow your recommended unified structure.

Thank you again for your kind support and understanding!

Best regards,
czh00361 (estima5633)
Rymansat Project

deckbsd · September 1, 2025, 8:04am

Hello @estima5633 ,

Yes sure. Basically, here is how to do it :

rsp03.txt (67.3 KB)

So either you can let the one in the MR as is, or just copy paste this one. Either way, i won’ t be able to test and merge the MR before tomorrow afternoon anyway

Have a nice day,

estima5633 · September 1, 2025, 10:11am

Hi @deckbsd,

Thanks a lot for the detailed guidance and the sample file.
I’ve applied your rsp03.ksy (CW paths and exported fields) to my MR and pushed the update.

At the moment I’m still not confident with the unified approach in Kaitai, so I’m proceeding with the separate CW fields as a temporary solution, as you suggested. This lets me verify the decoder behavior on SatNOGS first.

Could you please take another look and merge when convenient?
(RSP-03: Update rsp03.ksy and CW beacon fields (!477) · Merge requests · librespacefoundation / SatNOGS / satnogs-decoders · GitLab)

Many thanks again!
czh00361(estima5633)
Rymansat Project

deckbsd · September 1, 2025, 11:02am

Hello,

Something weird just appears in the MR :

Not sure of how the changes have been done, but something went wrong. Are you more than one working on it ?

That said … i m not following you

You said that you still want to go with the separated cw_beacon and cw_type fields (so cw_type_i, cw_type_g, cw_type_h and cw_beacon_i, cw_beacon_g, cw_beacon_h), which again is totally fine but in the same time you just updated the decoder in the MR with the unified approach (so with just one cw_beacon and cw_type fields).

So to be clear :

if you want to go with the separated fields, keep using :
This fields declaration :

  :field cw_beacon_g: ax25_frame.cw_beacon_g
  :field cw_type_g: ax25_frame.cw_type_g
  :field cw_beacon_h: ax25_frame.cw_beacon_h
  :field cw_type_h: ax25_frame.cw_type_h
  :field cw_beacon_i: ax25_frame.cw_beacon_i
  :field cw_type_i: ax25_frame.cw_type_i

and properties declaration in the kaitai structure :
in cw_g:

...
      cw_type_g:
        value: no001_message_identifier
      cw_beacon_g:
        value: no001_message_identifier+no002_telemetry_type_hex+no003_cobc_boot_count_hex+no004_cobc_uptime_seconds_hex+no005_cobc_temperature_degc_hex+no006_satellite_operation_mode_hex+no007_antenna_deployment_status_hex+no008_uplink_reception_count_hex+no009_battery_1_voltage_mv_hex+no010_battery_1_charging_current_first_half_ma_hex

in cw_h :

...
      cw_type_h:
        value: no001_message_identifier
      cw_beacon_h:
        value: no001_message_identifier+no002_battery_1_charging_current_second_half_ma_hex+no003_battery_1_discharging_current_ma_hex+no004_battery_1_temperature_degc_hex+no005_battery_2_voltage_mv_hex+no006_battery_2_charging_current_ma_hex+no007_battery_2_discharging_current_ma_hex+no008_battery_2_temperature_degc_hex+no009_subsystem_power_fault_status_hex+no010_subsystem_power_onoff_status_hex+no011_tobc_main_boot_count_hex

in cw_i :

...
      cw_type_i:
        value: no001_message_identifier
      cw_beacon_i:
        value: no001_message_identifier+no002_main_tobc_operating_time_hour_hex+no003_main_tobc_reception_count_hex+no004_sub_tobc_boot_count_hex+no005_sub_tobc_operating_time_hour_hex+no006_sub_tobc_reception_count_hex+no007_aobc_operation_mode_hex+no008_attctrl_power_status_hex+no009_x_axis_angular_velocity_mdeg_s_hex+no010_y_axis_angular_velocity_mdeg_s_hex+no011_z_axis_angular_velocity_mdeg_s_hex+no012_mobc_operation_mode_hex

OR if you want to go with the unified approach :

This fields declaration :

  :field cw_beacon: ax25_frame.cw_beacon
  :field cw_type: ax25_frame.cw_type

and properties declaration in the kaitai structure like this :
in cw_g:

...
      cw_type:
        value: no001_message_identifier
      cw_beacon:
        value: no001_message_identifier+no002_telemetry_type_hex+no003_cobc_boot_count_hex+no004_cobc_uptime_seconds_hex+no005_cobc_temperature_degc_hex+no006_satellite_operation_mode_hex+no007_antenna_deployment_status_hex+no008_uplink_reception_count_hex+no009_battery_1_voltage_mv_hex+no010_battery_1_charging_current_first_half_ma_hex

in cw_h :

...
      cw_type:
        value: no001_message_identifier
      cw_beacon:
        value: no001_message_identifier+no002_battery_1_charging_current_second_half_ma_hex+no003_battery_1_discharging_current_ma_hex+no004_battery_1_temperature_degc_hex+no005_battery_2_voltage_mv_hex+no006_battery_2_charging_current_ma_hex+no007_battery_2_discharging_current_ma_hex+no008_battery_2_temperature_degc_hex+no009_subsystem_power_fault_status_hex+no010_subsystem_power_onoff_status_hex+no011_tobc_main_boot_count_hex

in cw_i :

...
      cw_type:
        value: no001_message_identifier
      cw_beacon:
        value: no001_message_identifier+no002_main_tobc_operating_time_hour_hex+no003_main_tobc_reception_count_hex+no004_sub_tobc_boot_count_hex+no005_sub_tobc_operating_time_hour_hex+no006_sub_tobc_reception_count_hex+no007_aobc_operation_mode_hex+no008_attctrl_power_status_hex+no009_x_axis_angular_velocity_mdeg_s_hex+no010_y_axis_angular_velocity_mdeg_s_hex+no011_z_axis_angular_velocity_mdeg_s_hex+no012_mobc_operation_mode_hex

So the message here is, if you wanted to stay with the separated approach you didn’ t had to update it with my suggestion in the txt file. The decoder in the txt file was to show you how to apply the unified approach.

So whatever you want to chose, update the decoder accordingly as you which and i will review it tomorrow