You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CCSDS telemetry packets include a timestamp in the CCSDS headers. Command packets, on the other hand, do not. Also, if CCSDS timestamps are generated by something other than the local CPU, the timestamp may reflect when the packet was generated but not when the packet was received/stored by DS. Thirdly, if the CCSDS timestamp is generated using a different clock that is not in sync, the timestamps may not coincide. This is particularly important in multi-CPU environments, such as when cFS busses are connected via SBN.
This will particularly help with replay using the ds_replay application as the timestamps will accurately reflect when DS received the packets and will be in the correct order.
I suggest adding, for each packet stored in DS, a DS packet header containing a timestamp. This header could also include sequence count, message length (although easy to compute using the CCSDS header, a DS-generated length would make for easier access), byte position in file, or other fields.
Of course, all of this adds to the amount of data stored in DS files, so all should be optional. The DS file header should include the necessary metadata to determine what the DS packet header will contain.
Imported from GSFCCFS-766
The text was updated successfully, but these errors were encountered:
CCSDS telemetry packets include a timestamp in the CCSDS headers. Command packets, on the other hand, do not. Also, if CCSDS timestamps are generated by something other than the local CPU, the timestamp may reflect when the packet was generated but not when the packet was received/stored by DS. Thirdly, if the CCSDS timestamp is generated using a different clock that is not in sync, the timestamps may not coincide. This is particularly important in multi-CPU environments, such as when cFS busses are connected via SBN.
This will particularly help with replay using the ds_replay application as the timestamps will accurately reflect when DS received the packets and will be in the correct order.
I suggest adding, for each packet stored in DS, a DS packet header containing a timestamp. This header could also include sequence count, message length (although easy to compute using the CCSDS header, a DS-generated length would make for easier access), byte position in file, or other fields.
Of course, all of this adds to the amount of data stored in DS files, so all should be optional. The DS file header should include the necessary metadata to determine what the DS packet header will contain.
Imported from GSFCCFS-766
The text was updated successfully, but these errors were encountered: