Again great job!
Sorry, I have no idea.
Could you paste your updated ksy file?
1 Like
Updated file -
uwe3.ksy.zip (2.8 KB)
1 Like
2 Likes
Great work, this is a really useful reconstruction.
Since you mentioned submitting this to the official satnogs-decoders repository as a PR, maybe one thing that could help is to keep the current assumptions explicit next to the decoder.
Especially for fields inferred from samples rather than confirmed from an official spec, even a small companion note with offset, type/endianess, unit, scaling, validation source and confidence/status would make future review easier.
For the unresolved state byte, I would probably keep it as state_raw for now and mark the semantics as unknown. Then it could be compared across more SatNOGS frames to see whether it correlates with uptime, power values, battery state, temperature, or specific operating conditions.
That way the decoder stays useful, but the assumptions remain visible and maintainable.
2 Likes
1 Like
Thanks @frovelli , really good suggestions. Done:
- Renamed the state byte to
state_rawand marked it as semantics unknown, with a note to compare it across frames against uptime, power and battery values - Added explicit
[confirmed],[inferred]and[unknown]tags to every field in the KSY, citing the 270-frame sample, DK3WN cross-reference, and the community members who helped verify specific fields
Ready to open the PR. One question before I do, is there a preferred format in the satnogs-decoders repo for companion notes (a FIELDS.md alongside the .ksy, or inline doc strings are sufficient)?
Thank you @bali , glad itās useful!
73!
Great, that sounds like a very clean approach.
Iām not a satnogs-decoders maintainer, so take this only as a practical suggestion, but from a quick look at the repo/wiki I donāt see an obvious FIELDS.md convention.
It looks like the preferred path is to keep the decoder self-contained in the KSY as much as possible: use doc-ref for the source/reference material, keep the exposed fields in the doc: / :field section, and add short inline notes or comments for the [confirmed], [inferred] and [unknown] assumptions.
If the validation notes are too detailed for the KSY itself, I would probably put the longer explanation in the Merge Request description and ask the maintainers there whether they prefer an additional companion file.
That way the PR follows the existing structure first, without introducing a new file convention unless the reviewers ask for it.
1 Like