Ever asked yourself how is it technically possible that ESA satellites can be controlled through NASA’s Deep Space Network?
The key is interoperability and standards.
ESA, NASA and many other public and private space organizations use the CCSDS Space Link Extension (SLE) services to route radio link frames between Ground Stations and Mission Control Centers.
An overview here: https://public.ccsds.org/Pubs/910x0g2.pdf
Although very successful and widely used among agencies and commercial entities, SLE is not well known to many others, including, likely, you!
Based on the great work in the scope of NASA’s open source multi-mission operations system (https://github.com/NASA-AMMOS/AIT-DSN),
we at LibreCube have created an SLE User package in Python that you can find here: https://gitlab.com/librecube/lib/python-sle-user
The SLE User sits typically at the Mission Control Center, to connect to remote Ground Stations that host an SLE Provider.
The SLE User, however, is only part of the solution.
Our team at VisionSpace Technologies has created an open source SLE Provider application: https://github.com/visionspacetec/sle-provider
Currently it supports Cortex baseband equipment, but work is underway to connect it with off-the-shelf, low-cost Software Defined Radios.
We are proposing the integration of the SLE services with SatNOGS, to enable live telemetry flow to data centers and mission control software.
The implemented SLE Provider and User are not limited to CCSDS compliant frames.
Interested? Try it out yourself, and get in contact with us!
It sounds really interesting! I think that at some point SatNOGS Network will have to implement such an interface towards the goal of adding transmitting capabilities. Of course, to get there we will have to solve a bunch of open issues like scheduling, link handovers as well as legal stuff.
In the current version, there are no legal problems with forwarding frames and transmitting them, because the service for it has not been implemented yet.
When the frame forwarding service will be implemented in the future it will only be activated if you create an forward session on the SLE Provider and make it accessible to the public network SLE User.
The SLE Provider is designed to support simultaneous connection with multiple clients, each having different permissions.
A “Service Instance” (a scheduled pass with some properties like return or forward link) is bound to an SLE User and its traffic can be encrypted.
Using this you can have a public connection to the SatNOGS Network, hosting an SLE User and to your Mission Control System (MCS) at the same time. The SatNOGS User would only have a return telemetry service instance and the MCS could have return and forwarding service instances.
Because of the point-to-point architecture the delays for the MCS are kept low and also no telecommand data is ever being passes using the SatNOGS Network.
I hope this resolved some of your concerns but if anything remains unclear do not hesitate to ask
I want to give you a short update on what happened in the past few weeks.
We can now receive AX.25 and CCSDS frames from GNU Radio and forward them to users in real time.
This was tested with recordings from the network (see Feeding OGG files back into gr-satnogs flowgraphs) and with high data rate telemetry from an ESA spacecraft.
The same UDP port is used that is included in SatNOGS flowgraphs by default, so no further changes are needed there if you just want to receive AX.25 frames.
We will present all of this in more detail at the OSCW19 in Athens.
Here I have a short question - will it be possible to “rent-a-station” for a short live demonstration in Athens?
Maybe just a temporary one, it does not has to be connected to the (dev-)network.
I could bring a Raspberry or just install the packages on the station.
I will just not be able to bring a turnstile or something similar in my carry-on baggage.
over the past months, during the ESA OPS Innovations Cup, we develop a new level of integration of the SLE provider with SatNOGS.
Based on Docker, we developed a scalable Docker Swarm application that can be used to serve any CubeSat mission data from SatNOGS Network observations on demand in real time or in offline mode.
It uses the public API of the network, so only data from the network can be accessed. If this is a problem for you, please let us know, it will be extended to the DB if needed (I am aware of the future migration). It can be deployed locally for single mission or in a cloud environment for multi mission use.
For installation and configuration please visit our GitHub page and raise an issue or leave me a message if something is not working as expected or needs more detailed explanation.
It was successfully tested with ESAs SCOS2000 Mission Control System for OPS-SAT, which was the reference for this project.
We would love to tests this also with other missions that plan to use or are already using a MCS that has SLE capability. In case any pre-processing of your frames from SatNOGS Network is necessary before feeding it into your MCS, like wrapping into CCSDS TM frames or Space Packets, please let me know.
This could also be used in the future to add telecommanding capability to the network. To be clear about this point there is no way this could currently be used (as it is) for telecommanding. Only telemetry can be received.
All developments are still available under the AGPLv3 license.
