Hi,
Would it be possible to add VZLUSAT-2 into the SatNOGS DB? It’s a 3U CubeSat by Czech Aerospace Research Centre, launch is scheduled for December 18th 2020. All the relevant information can be found in the following issue on GitLab: https://gitlab.com/librespacefoundation/satnogs-ops/-/issues/132. Let me know if there’s anything missing.
I also have a Kaitai struct decoder ready and tested, would it also be possible to add a dashboard? Thanks!
The Satellite has been added with the temporary NORAD ID 99768.
cc’ing @DL4PD for checking about the kaitai struct and the dashboard.
@jgromes for giving you access to create/edit the dashboard, please make sure you have logged in at dashboard.satnogs.org with the same credentials you have logged in here.
Thanks, really appreciate that!
I’m logged into the dashboard site with the same email as here.
Could you please open a merge request to SatNOGS-decoders?
Merge request open at https://gitlab.com/librespacefoundation/satnogs/satnogs-decoders/-/merge_requests/179
Thanks for that, looks good at a first glimpse!
Is there anything we can do to protect from foreign data? Like any magic string or payload length inside the data that indicates it is definitely from VZLUSAT-2?
The beacon contains a string “VZLUSAT-2” immediately after the Cubesat Space Protocol header (it’s marked as unparsed bytes in the ksy file). Other than that, there’s also the CSP header itself, which applies to both beacon and data drop packets, and since it will always use the same addresses, ports, priority and flags, it will always be the same 4 bytes, so we could use that as well (though it’s slightly weaker).
The string would be really good! You can just change it to contents: instead of size: - or whatever you use at that position.
Ah, OK - I’m pretty new to KSY, didn’t know there was an option to specify string literals. I’ll update the merge request.
It is not just specifying the string literals, it can be used as magic to abort further decoding. You have to imagine that probably another satellite is passing by and the several (also 3rd party) demodulators generate data from another satellite. Or the user uploading data to satnogs-db has falsely chosen the wrong NORAD-ID to upload data from another satellite.
It is not always easy to protect from such, but with a unique identifier, like a callsign or a binary constant, we are pretty safe!
I get that, just didn’t know how to specify it in Kaitai. The beacon has a 4 bytes of CSP header + 9 bytes “callsign” and the data drop has 4 bytes of CSP with an extra command ID byte, so that 5 fixed bytes - hopefully that’s enough to verify it’s parsing the correct thing.
The string literal will be enough protection 