jphickey
commented
2 years ago This really just seems to expose the fact that CFDP data traffic is in fact not telemetry. Nor is it a command.
It is data.
The fact that the data is being somewhat inappropriately stuffed into a "command" or "telemetry" packet was in itself a hack to make the software bus happy, because it was the proverbial hammer, and thus we had to make CFDP data look like the proverbial nail.
Adding an option to pad out would just be adding more bubble gum and duct tape to a solution that was already based on quite a bit of bubble gum and duct tape.
The more I think about it, what we really need is to add a variant to SB pipes to make them follow a "lockless point to point" model for high speed data transfer (i.e. one publisher, one subscriber, with buffering and flow control such that backpressure to the sender is possible) as opposed to a broadcast model. These would carry neither commands nor telemetry - just bulk data. So it would be a somewhat new concept for software bus to handle, but it would be much better suited to the task of carrying CFDP data.
Either that or we just provide an option to use a (yet-to-be-defined) PSP API to pass the frames direct to hardware - because they are probably going through a different radio I/F than the CMD/TLM anyway. I'm still unconvinced that CI/TO should be handling bulk data like CFDP PDUs at all, from a system design point of view.
Checklist (Please check before submitting)
Is your feature request related to a problem? Please describe. Some systems can't handle variable sized telemetry packets.
Describe the solution you'd like Add an option to zero-fill the related CCSDS packets.
Describe alternatives you've considered None.
Additional context None
Requester Info Jacob Hageman