Support of FOSM-1

[loic-fejoz]

Dear gr-satellites community,

This is my pleasure to announce FOSM-1 designed by an non-profit organisation Fédération Open Space Makers. This is a hamradio spacestation payload that should flight starting Q2. It has received IARU coordination.

The payload embark a camera, a Spino radio board, and a WASM engine so as to make it reconfigurable. It means that not only will it send Spino frames as already supported by gr-satellites but also experimental frames or, hopefully, adaptation of known protocols like cats or M17.

More information will be shared soon on our web page. One can watch my presentation at Amsat-F 2025 in French.

I have started a fork so as to propose you a pull-request soon: https://github.com/loic-fejoz/gr-satellites/tree/feat/fosm-1

I wonder how to best describe/declare the experimental framing?

[daniestevez]

Thanks for opening this discussion! Regarding experimental framing, it only makes sense to add support for this in gr-satellites (understood as a deframer and the corresponding framing field in the SatYAML) when this is something concrete. Since the payload is software reconfigurable, I imagine that the best approach is to keep extending the SatYAML and gr-satellites support as new protocols get used. For one-off experiments where a protocol is only going to be used shortly maybe it is not necessary to add this to gr-satellites. Some software elsewhere could serve for these one-offs. There might be things which probably fall somewhat out of scope of gr-satellites. For instance M17. We have had a similar situation with satellites that transmit Codec2 digital voice. In this case what gr-satellites did is to output data through an interface (in this case a UDP socket) so that the data can be processed by an external application (in this case a Codec2 CLI decoder that turns Codec2 data into audio).

[loic-fejoz]

Thanks for your quick response!

Ok so I have the initial version ready I guess. It just declares the Spino similarly as from Inspire-Sat 7.
Should I create a PR now?
Then, if I read you properly, I would create a PR every time we have an experiment fully covered by gr-satellites ; If not covered, just leverage the UDP socket.

Exact?

[daniestevez]

A PR now with the Spino framing sounds good. Probably the name of the SatYAML file should be that of the satellite, but the name of the payload can be listed in alternative_names:. Since the satellite has not launched yet, we need to use the temporary NORAD ID from SatNOGS DB.

Each time changes are needed they should go through a PR, that is correct.