Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fixed size CCSDS packet option #193

Open
3 tasks done
skliper opened this issue Feb 8, 2022 · 1 comment
Open
3 tasks done

Add fixed size CCSDS packet option #193

skliper opened this issue Feb 8, 2022 · 1 comment

Comments

@skliper
Copy link
Contributor

skliper commented Feb 8, 2022

Checklist (Please check before submitting)

  • I reviewed the Contributing Guide.
  • I reviewed the CF README.md file to see if the feature is in the major future work.
  • I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

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

@jphickey
Copy link
Contributor

jphickey commented Feb 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants