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?

[ReggieMarr]

Also @gcgandhi I'm really focused on the data link layer, currently my plan is to create a repo that provides it as a library/sub-topology once I've proven it out with my reference project (but I'm happy to contribute that work in the form of an MR so long as I'm not stepping on your toes).
I'm not sure what your approach would be and if part of your SOW is SPP however if you'd like to collaborate on this it's worth noting that I don't currently have VCP support on my roadmap (aka the data link service that could consume space packets).

I have however been attempting to architect things such that this service could easily added on.

[ReggieMarr]

@LeStarch @gcgandhi I had to de-priortize this work for a bit so it took me longer than I'd thought to come back but just hacked together a little proof of concept and I've got the full TM chain working and muxing 3 virtual channels.

I haven't added much in the way of robustness and I do a lot of excessive copies and stuff that made sense for development but less so for production however in adhering to the spec I ended up with some mechanisms that may be useful.

For example is I send frames between channels using the priority queue like this:

// "Pull" a frame from a queue that contains buffers which can extract them
template <typename ChannelTemplateConfig>
bool ChannelBase<ChannelTemplateConfig>::pullFrame(Queue_t& queue, FPrimeTransferFrame& frame) {
    Os::Queue::Status qStatus;
    bool status;
    // NOTE this is a hugely inefficient way of sending the channel info around.
    // This is just done for now as a convinient mechanism for testing out the architecture.
    // TODO replace with either a standard queue or queued component interfaces + buffer memory management
    serialBuffer.resetDeser();
    serialBuffer.setBuffLen(frame.SERIALIZED_SIZE);

    FwQueuePriorityType currentPriority = m_priority;
    FwSizeType actualSize;
    qStatus =
        queue.receive(serialBuffer.getBuffAddr(), frame.SERIALIZED_SIZE, m_blockType, actualSize, currentPriority);
    FW_ASSERT(qStatus == Os::Queue::Status::OP_OK, qStatus);
    FW_ASSERT(actualSize == static_cast<FwSizeType>(FPrimeTransferFrame::SERIALIZED_SIZE), actualSize,
              static_cast<FwSizeType>(FPrimeTransferFrame::SERIALIZED_SIZE));

    status = frame.extract(serialBuffer);
    FW_ASSERT(status);
    return true;
}

template <typename ChannelTemplateConfig>
bool ChannelBase<ChannelTemplateConfig>::pushFrame(Queue_t& queue, FPrimeTransferFrame& frame) {
    Os::Queue::Status qStatus;
    bool status;
    // NOTE this is a hugely inefficient way of sending the channel info around.
    // This is just done for now as a convinient mechanism for testing out the architecture.
    // TODO replace with either a standard queue or queued component interfaces + buffer memory management
    serialBuffer.setBuffLen(frame.SERIALIZED_SIZE);
    serialBuffer.resetSer();
    status = frame.insert(serialBuffer);
    FW_ASSERT(status);

    qStatus = queue.send(serialBuffer.getBuffAddr(), frame.SERIALIZED_SIZE, m_priority, m_blockType);
    FW_ASSERT(qStatus == Os::Queue::Status::OP_OK, qStatus);
    return true;
}

Note I took this approach because my immediate goals were:
1). Getting something working through the chain and doing stuff like this made it easy to inspect.
2). Was creating something robust architecturally and I really wanted to be faithful to the spec.
3). I also wanted to be able to easily swap configurations (so create frames at the virtual channel vs master channel level, leverage secondary headers, ocf, ect).
4). I wanted a design that I could easily port to multiple other protocols (specifically CCSDS variants).

I figured if I got those done then flattening the layers and reducing my copying would be easier rather than starting with a restrictive but performant design and trying to make that work for my con-ops. I'm now going to be moving a bit in that direction and while considering whether each channel should be made into a component (passive for Vc's active queues for MC's) I realized it may have wider implications for our development that might be worth sharing.

E.g. The channels could possibly be used to create a multiple producer, single consumer queue (or mpmc depending on how its configured). I thought that might be useful as a mechanism for this issue and I wonder if @zimri-leisher or @timcanham had thoughts on that.

I'd be curious to hear your thoughts and once its a bit more cleaned up I'd be happy to make an MR if desired.

[zimri-leisher]

There's a lot here, and I don't think I understand the context fully, but in terms of how this applies to #3013, components which store telemetry will only need to implement a "getter port" of type Fw.Tlm:

  port Tlm(
            $id: FwChanIdType @< Telemetry Channel ID
            ref timeTag: Fw.Time @< Time Tag
            ref val: TlmBuffer @< Buffer containing serialized telemetry value
          )

This will allow runtime access to the telemetry database for the advanced sequencing language.

[ReggieMarr]

Ah fair enough, I'll summarize the context.
I'm working on a project for a space vehicle (launching next fall) which requires a robust space link capable of muxing video and telemetry data. Was initially developing a CSP-inspired in-house solution but then came across CCSDS and realized that there seemed to be some interest/effort on the F' side to support this as well (albeit with slightly different goals/timelines).

Since then we've decided to experiment with doing some open development for the following tasks:

1. CCSDS data link F' implementation
2. SAM3x8E and SAMV71 F' reference application
3. F' -> yamcs hub model reference application

The repo I've linked to is a PoC implementation of the first task that focused on leveraging existing CCSDS F' work and expanding upon it, focusing on TM support, with some basic TC support as well.

WRT your internal telem issue I just thought it was interesting and that it's implementation might have some parallels to what I've had to do for this; Aka collect data emitted from a variety of sources into something like channels, then propogate them to consuming users in a manner which supports one or many consumers for a particular piece of telemetry, is thread safe and manages the associated memory allocation/deallocation.