Open Source Data Link Protocol Implementation

Hi, I have aquestion about the LibreSpace Open Space Data Link Protocol Implementation the code for which is here librespacefoundation / Open Space Data Link Protocol · GitLab. I hope this is the right place to post, as I didn’t see any other comments / questions about this topic!

The background to the question is we are working on an implementation of the Yamcs Mission Control System which will use the CCSDS COP-1 protocol. It is intended that the spacecraft will utilise the LibreSpace Open Space Data Link Protocol (which implements COP-1), but whilst we are waiting for the spacecraft implementation to be developed, we were hoping to use the LibreSpace osdlp-operator CLI interface to test the ground system. The version of the CLI interface with the ground side FOP configuration seems to be a nice facility with some built in TCs on the ground side which allows a few permutations using COP-1 to be quickly implemented and tested. Our idea though would be to start an instance of osdlp-operator with the FARM configuration as an emulator for the spacecraft, and send it some TCs from Yamcs, purely just to test that Yamcs and the link handle CCSDS COP-1 correctly.

We can already create a link using two osdlp-operator instances, in this case the ground side is provided with an instance with the FOP configuration. However we notice that in all cases the ground side osdlp-operator instance reports “RX: Only Idle Data”. This seems to be because the FARM implementation in both osdlp-operator and in the QUBIK OBC implementation here librespacefoundation / Qubik / COMMS Software · GitLab is very slim, and is only able to send an “idle” Frame Data Unit back, using the function osdlp_tm_transmit_idle_fdu(), rather than actual data.

So we were wondering if this approach on the spacecraft side was there as a stop gap pending a fuller implementation that would allow data to be returned, or if we are missing something and this response is intended. We note that the Open Space Data Link Protocol library has a function “osdlp_tm_transmit()” which takes data as an argument and is presumably what we actually require to send data.

Are we missing something in the approach, or should we work ourselves on expanding the osdlp-operator FARM implementation to allow data to be sent? The FOP implementation seems to already expect scenarios where data is returned in the response to the TC.

Brian M0GKK

2 Likes

Hello @briany1000 ! Thank you for your question.

As i understand it you are trying to run locally two instances of the OSDLP one for the FOP and one for the FARM. Unfortunately the FARM implementation for the local execution scenario is very basic. As you said, the only thing it does is to respond with and idle FDU every time it receives a packet as an acknowledgment. Essentially you would have to implement your own functionality and call the osdlp_tm_transmit according to the commands you are sending to it from FOP, based on the needs of your mission. An example of this you can find here Core/Src/telemetry.c · master · librespacefoundation / Qubik / COMMS Software · GitLab. This is the code for the telemetry part of the QUBIK mission. You will find a transmit_tm function which basically does for the satellite what you want to do locally in the FARM instance. But this is always implementation specific. You would also have to populate the farm_configuration and fop_configuration files with the parameters of your mission.

If I haven’t answered any of your questions please don’t hesitate to reach out again.

With regards,
George

3 Likes

Hey George, thanks very much for the reply. That is what I thought, but it is good to confirm I am not missing anything.
Regards
Brian M0GKK