Multiplexing video data and telemetry via downlink

[ReggieMarr]

Hi all,

I've been working on a flight software project in which one of the necessary features is to multiplex video data alongside telemetry. Originally originally the plan was to create some custom component to leverage one of ffpmegs muxers and to combine a video stream with a subset of the system's telemetry and then send that via a queue to a component which would interface with the transport layer.

This seemed doable and would provide a lot of control over bandwidth use and performance but at the same time it would come with the downsides that the output would no longer be something that fprime-gds or yamcs would be able to understand.

However after doing some research I came across CCSDS and in particular found that the Space Packet Protocol (SPP) and the Unified Space Data Link Protocol (USLP), the former of which seeming more light weight but with only a few mentions of multiplexing support and the later seeming to have a lot but possibly being a bit more heavy weight and beastly to contend with.

Simultaneously I've seen that there is already work ongoing on both the fprime and fprime-gds side of things which seems promising.

To that end I'd be curious what is driving that and if there might be some insight to be gained in how this can be leverage for my use case and if so how I could contribute.

[thomas-bc]

The CCSDS protocols you mentioned are something we have had on our radar for some time, and the community seems eager to adopt them as well. For these reasons we are seriously considering how we could integrate them in the framework.

We have had an effort that had us investigate how integrating those into the framework could look like, and this is where these PRs you found are coming from.

#2900 is improving the deframing/routing stack by making deframers easier to implement and swap in, swap out and chain up. We will be picking up that work shortly.
Using that improvement, we have deframers for the Space Packet and Telecommand (TC) protocols. We also wish to mirror those improvements on the framing stack, and implement the TM protocol.

As for USLP, it does look very promising. We added it to our roadmap, but unsure how it will be prioritized vs. the other protocols that have been around for a little longer.

The past few months we have had to spend a lot of effort onto releasing v3.5.0 on time for our October workshop, so that ate a lot of our time. Hopefully we'll get back to CCSDS soon, but this is also pending some internal prioritization of the work that I can't speak for at the moment...

Hopefully that clears things up a little!

[thomas-bc]

So perhaps I misunderstand some aspects of these protocols.

I feel that... haha. These protocols have so much specification and nitty-details that it makes them quite challenging to understand, IMHO. I'm not expert there, definitely take my word with a grain of salt.

As I understand it TM would be used as the downlink protocol and TC for the uplink correct ?

Yes that is my understanding as well.

Would multiplexing video data on the downlink by leveraging virtual channels then be a reasonable use case or am I missing something?

That I do not know.

As for USLP...
The Overview Green Book you just linked does mention " It is envisioned that USLP will be used as the data link layer protocol for all future robotic and crewed space missions. "
For this reason and the half-an-hour I spent browsing through its spec, my understanding is that USLP builds upon --and is intended to be a replacement of-- the TC and TM protocols, in order to provide a unified protocol that can be used for all uplink/downlink/inter-vehicle.
That is why it caught my eye. But this also means that because it's a newer protocol, it may have less adoption at the current moment? But definitely something I would keep my eye on.

[ReggieMarr]

After some more review it seems like even the spp might be good for my needs. In my mind I'm thinking SPP (aka TM and TC impls) riding on CSP for inter-vehicle communication and then SPP over RF for the downlink and leveraging virtual channels to mux video.
Not really sure what the delta is between the current state and getting TM complete and then from there a potential impl of USLP however it seems like collaborating on this may actually be more efficient than implementing something custom independent of fprime. Would it be possible to connect so that we could chat about this in more detail ?

[thomas-bc]

@ReggieMarr the easiest way to reach out to the team will be to send an email to [email protected]

[ReggieMarr]

FYI I rebased your branch onto the devel branch of fprime on my fork (which if you like I can make a MR from).

Would you be able to speak to why the SpaceDataLinkDeframers were removed ? I've been toying with them a bit in an effort to better understand the protocol, how a TM framer might be implemented and whether it would server my muxing needs and they seem to have been pretty good implementations but I feel like I'm missing some wider context.

[thomas-bc]

They were removed for now to focus the current PR on refactoring the Deframer/Router/Accumulator stack. The CCSDS Deframers were implemented for an internal research effort, but as you can see they're lacking tests, documentation, etc. that we would require before merging into core F´.
So basically yeah, keeping the scope of the PR tighter around this current refactor, not worrying about all the CCSDS add-ons just yet.

[ReggieMarr]

@LeStarch The fork that I've started developing on can be found here note that its very much a WIP however I'm planning on doing a cleanup tomorrow

[LeStarch]

@gcgandhi as you start looking into CCSDS framing/deframing, here is work that an outside group keyed us into. Might be worth a look!

[ReggieMarr]

I figure I'd update progress on my end here.

Basically I've iterated on the existing ccsds data link layer implementation. The current implementation accounts for functional components outlined in the TM SpaceDataLink Spec with functional stratification derived from both that and other related specifications.
Briefly the functional components are responsible for the following:

• Packet Processing (i.e. packetizing user data in order to frame it in a virtual channel)
• Virtual Channel Generation
• Virtual Channel Multiplexing
• Master Channel Generation
• Master Channel Multiplexing
• Control Info generation, insertion and propagation for all frames
• Error correction

Right now I'm just handling test data that gets propagated through a local component for a loop back test, the data gets put into a virtual channel frame and "multiplexed" (there's only one virtual channel so the multiplexing is effectively just a pass through to a queue atm).
This then passes through the other components to get the higher level control fields/crc checks applied.

Next step is apply refactoring to the deframer/TC side of things. Probably after that break things out into a hub model.

@LeStarch my current work is probably past the peak churn point but there's a fair bit more to be done prior to merge (not least of which includes adding an sdd.md, unit tests and apply clangd with the correct config).
Given that at which point does it make sense to open an MR?