Disable the IDLE_PACKET

[keck-in-space]

Is it possible to disable the IDLE_PACKET? Due to how we anticipate integration with another system we would like only meaningful data to be sent over our FSW interface. The idle packets are not needed for our use case. Can they be disabled?

[thomas-bc]

@keck-in-space can you clarify which IDLE_PACKET you're talking about and where you're seeing it? If it is about the IDLE pattern within the TM frames, this is specified by the CCSDS standard and we likely don't want to diverge from that.

If you're concerned with the overhead that may incur****, the recommendation is to use another framing protocol. The lightweight F´ protocol might be enough for you - or I encourage you to put in a feature request for a more modern CCSDS protocol such as USLP so that I'm not the only one talking about it all the time 😄

**** long digression: and why would anyone not be concerned — I'm not sure why TM was defined to be fixed-length, but it seems questionable with space's limited link budget. All standards defined by CCSDS since are variable length frames, AFAIK.

[SterlingPeet]

My experience in this realm is consistent with the era that the TM frame was ratified by CCSDS. I was really struggling to find integrated radio ICs in the early 2010s that could handle anything that was not a sync word followed by a fixed frame. I suspect this is consistent with the best practices and state-of-the-art of the aughts, when that was written and approved. At the time, I was trying to implement even older variable length frames 😆 .

Our F Prime 3.6 implementation of TM frame is primarily an effect of the GDS software compatibility, a choice that I was not involved with and cannot change.

Another note while were here: if were are talking about saving Space Packets to the disk, not saving idle packets makes a huge difference for us. When we save TM frames to the disk, we do have to inspect them and determine that the only contents are idle Space Packets, or we are literally saving whole TM frames of IDLE data and that is definitely not space efficient.

[thomas-bc]

Ah, that does make sense. And indeed from the TM blue book I just found:

To facilitate simple, reliable, and robust synchronization procedures, fixed-length protocol data units are used to transfer data through the weak-signal, noisy space links

Today I learned! 😄

[keck-in-space]

Thanks for the reply, @thomas-bc!

Yes, I was referring to the TM frames idle packet. At first we were a bit confused because in the past we have implemented the Space Packet Protocol (CCSDS 133.0-B-1) which doesn't use idle packets and not the TM Space Data Link protocol, as implemented here.

I definitely agree that we are mainly concerned with the additional overhead since our bus will store everything we send as time-tagged files. I was surprised that TM Space Data Link wasn't variable length as well.

I would love a more modern or even an older standard like the one we have previously used. For now though, perhaps the F´ protocol could work for us.

I hate to ask for this, but I did attempt to enable the F´ protocol and I could not get it to function. Is there a guide for how to move from the default ComCcsds topology to the ComFprime topology? I can show you what I tried if that's helpful. Thank you again for the help!

[thomas-bc]

Discussed through other channels and it seems you've implemented things with ComFprime correctly, maybe were missing on the fprime-gds --framing-selection fprime option. To be confirmed.

[keck-in-space]

That was it. Thank you, @thomas-bc!