Thank you very much for your kind feedback and continuous support.
I really appreciate your help in moving the dashboard to Telemetry and adding the “stable” and “active” tags.
I fully understand that no MR is needed, and that the dashboard is now in the right place, waiting for approval.
After the launch, I will carefully monitor how the dashboard works with real data, and I will be ready to make improvements or adjustments if necessary.
Thanks again for your support and guidance!
Best Regards,
czh00361(estima5633)
Rymansat Project
P.S. The launch is scheduled for this weekend, and we are very excited to see RSP-03 deployed from the ISS.
Actually, our RymanSat ground station team is also in the final push, finishing up the control programs for the satellite.
I’d like to share a quick update on RSP-03 (RymanSat Project):
Launch: RSP-03 was launched today, Aug 24 at 15:45 JST, on Falcon 9 Block 5 (CRS SpX-33). Arrival at the ISS is expected tomorrow, and deployment is planned within about one month. https://rsp03.rymansat.com/
Ground segment: Our ground station preparation is on track. In the early phase we’re also considering operating with a CW beacon.
[rsp03_fixed_with_cw_fields_clean_v10.zip|attachment]
Launch: RSP-03 was launched today, 24 Aug 2025 at 15:45 JST (UTC+9) on Falcon 9 Block 5 (CRS SpX-33).
It is scheduled to arrive at the ISS tomorrow, with deployment expected within about one month.
Project page: https://rsp03.rymansat.com/
Operations plan: Our ground stations are on track. In addition to AX.25 GMSK, we plan to utilize a CW beacon during the early phase.
Decoder (KSY): We prepared a single Kaitai .ksy that handles both AX.25 and CW (G/H/I) beacons.
The schema passes Kaitai syntax checks. We verified with AX.25 samples (flag/CRC removed) and exercised the CW path using ASCII → hex → numeric parsing.
Next step: We plan to open an MR to satnogs-decoders with this KSY.
If you have any feedback on naming conventions, units, or which fields to prioritize for publishing, I’ll incorporate it promptly and proceed with the MR. rsp03_fixed_with_cw_fields_clean_v10.zip (7.9 KB)
I would say that you can proceed with the MR, just please remember to provide some test samples for the CW frames.
Just a word on how CW is handled in SatNOGS so you know. CW is a bit of a special case because when an observation related to a CW transmitter occurs, if there are some data uploaded to SatNOGS network (visible in the data tab of an observation page), these data aren’t automatically decoded into DB even if there is a decoder (aka kaitai file) linked to the sat.
The reason for this is that there is a very large amount of gibberish when CW is demodulated and we want to avoid populating DB with garbage data.
So in order to have CW data being uploaded into SatNOGS DB, it has to be done manually either using curl ( curl --data “noradID=XXX&source=callsign×tamp=2024-08-29T18:45:00Z&frame=796F6D6F6769206A7331796D782003030303030320a580ff6005&locator=longLat&longitude=XXXE&latitude=XXXXN” https://db.satnogs.org/api/telemetry/ ) or sids.
This MR adds the CW ASCII path (G/H/I) alongside the existing AX.25 decoder in a single KSY.
Kaitai syntax checks passed and I compiled to both Python and JavaScript successfully.
If anything looks off (naming, units, or field selection), I’m happy to update quickly.
(Next, I’ll upload the CW samples to SatNOGS DB using curl.)
Best regards,
czh00361 (estima5633)
Rymansat Project
P.S. CRS-33 of SPACEX has safely arrived at the ISS—fantastic to watch live on NASA’s stream!
RSP-03 is currently planned for deployment in late September (subject to operations).
Just posting it here too in case you see this before the comment i left on the MR.
On the MR, please remove the extra spaces/tabs between the CW fields name and path, like for instance : :field cw_g_no001_Message_Identifier: ax25_frame.no001_message_identifier to :field cw_g_no001_Message_Identifier: ax25_frame.no001_message_identifier .
Because at this moment the decoder return an empty json object ({}) for the CW frames because the parser expects only one space between field name and path
I’ve checked your updated decoder on ide.kaitai.io only.
It works!
However, just to think about it for a moment:
Currently, your decoder needs the CW beacon, which is a string in hexadecimal, ASCII formatted.
This means if someone reads the hex CW beacon to
There would be a way to do this conversion automated so the uploading person could enter the hexadecimal values.
Anyway, it would be less complex for both the decoder and the uploader script to process the string in hexadecimal right from the beginning on.
Actually it is the other way around. CW gives you text (ASCII, which apart from the I/H/G represent hex, but it still has to be considered as text) and then you need to convert it to hex.
Subject: CW ASCII → HEX helper and POST to SatNOGS DB — is this correct?
Hi all,
I wrote a small PowerShell helper to take an ASCII CW string (e.g., GFF540…), convert it to HEX and POST it to SatNOGS DB. Could you please confirm this payload/flow looks correct?
PowerShell script (ASCII → HEX → POST)
# Read ASCII CW (e.g., "GFF5400...")
$cw = (Get-Content .\cw_g.txt -Raw).Trim()
# ASCII -> HEX (uppercase, no spaces)
$hex = ($cw.ToCharArray() | ForEach-Object { '{0:X2}' -f [byte][char]$_ }) -join ''
# Build and POST
$body = @{
noradID = '98654' # will be replaced by the official NORAD after deployment
source = 'JS1YOY' # receiving callsign
timestamp = (Get-Date).ToUniversalTime().ToString('s') + 'Z' # ISO-8601 UTC
frame = $hex # HEX-encoded CW string
}
Invoke-RestMethod -Method Post -Uri 'https://db.satnogs.org/api/telemetry/' `
-ContentType 'application/x-www-form-urlencoded' -Body $body
=== DRY RUN ===
ASCII input: GFF540018C4000000040F08CA1D08
Hex frame: 4746463534303031384334303030303030303430463038434131443038
POST URL: https://db.satnogs.org/api/telemetry/
Payload:
frame=4746463534303031384334303030303030303430463038434131443038
noradID=98654
source=JS1YOY
timestamp=2025-08-27T13:11:43Z
If the payload format looks good, once RSP-03 has an official NORAD ID and a SatNOGS DB entry exists, I’ll remove -DryRun and submit the three CW sample frames (G/H/I) to that entry for verification.
Until then I’ll keep the helper in dry-run mode only.
Thanks a lot!
czh00361(estima5633)
Rymansat Project
Yes, the format is correct, the decoder update has been released.
BUT please be careful to upload frame with the right timestamp. Doing (Get-Date).ToUniversalTime().ToString('s') will get the execution time and date of the script. So it is ok, if it is just to upload testing frame or if the script is part of a workflow that will upload the frame directly when it is received, but if you want to uploade a frame from a SatNOGS observation (or from any other sources) afterwards, please use the timestamp of the observation to keep the receiving history of the data as clean as possible.
I tested the new RSP-03 CW Beacon Uploader (thanks, DL7NDR).
I submitted three sample beacons (G/H/I) with UTC 2025-07-21 13:34:31, callsign JS2GBE, locator PM85ma.
They appear on db-dev.satnogs.org and decode with the released rsp03 decoder.
For production we will stick to the “G/H/I + 28 hex digits” ASCII form and use the actual observation UTC timestamp.
My test result RSP-03 CW Beacon Uploader and csv contents.
Yes , there is something off, you have to upload your frame in HEX format (so for instance 4746… for the G ones) if you want it to be decoded by your decoder. If you upload directly GFF… It won t work you can use your PowerShell script to upload test data to prod to see the result in dashboard side(or use dev db in your dashboard)
I didn’t checked everything earlier, but why in your uploader you don’t just translate all the text into hex (like @estima5633 did in the powershell script) and not just the first character. That way there is no need to modify the decoder again and it follows the way the upload works for the most part (frame = hexdump).
SatNOGS keeps the audio; observers decode to CW text G/H/I (e.g. GFF...).
The DB expects a hex dump of bytes in frame= (e.g. 474646...).
Upload paths now working
dl7ndr’s web uploader: accepts GFF…, converts to hex dump, posts to DB-dev.
My PowerShell helper: converts GFF… → 4746… and posts (-DryRun verified).
Decision
Keep the KSY as in master (ASCII → .to_i(16)), so the DB continues to receive hex dump.
Question
In DB-dev export I see a row starting 47FF54… for a GFF… input.
I expected 47464635… (G=0x47, F=0x46, F=0x46, 5=0x35).
Is 47FF54… expected in dev, or should it be the full hex dump 47464635…?
Thanks for the support—this aligns with deck’s guidance that “frame = hexdump”.
The DB expects a hex dump of bytes in frame= (e.g. 474646...).
Yes, but it is also true that for CW there are not explicit rules, it mostly depend on the decoder (kaitai) file behind. But keeping the actual RSP-03 decoder as is follows this logic which is applied on let’s say digital packet.
dl7ndr’s web uploader: accepts GFF…, converts to hex dump, posts to DB-dev.
At this moment not exactly, (see the last post from him), it converts only the first character (I/H/G) and keep the rest unchanged.
Question
To answer your question, 47FF54... was a test from Daniel (see his last post and the previous answer). But i heard that we stay with the last version of the decoder, so you don’t need to worry about it.
Thanks, that clarifies it.
We’ll keep the current decoder on master. For uploads we’ll ensure frame= is the full hex dump (474646...), using my PowerShell script until the web uploader converts the whole string (not just the first char). The 47FF54... row was just a test artifact. We’ll re-test once the uploader is updated and will keep using the observation timestamp
Best Regard,
czh00361(estima5633)
Rymansat Project
