As a follow-up to the first in this series of whitepapers, this document proposes a set of specifications and extensions for the CCSDS Space Packet Protocol in the context of FRC.

Part II.pdf (106.9 KB)

As a follow-up to the first in this series of whitepapers, this document proposes a set of specifications and extensions for the CCSDS Space Packet Protocol in the context of FRC.

Part II.pdf (106.9 KB)

This is an awesome series of white papers, and I’m looking into implementing this on our team. Thanks for your contribution!

Could you provide an example of the Time Code Field you recommended in the paper? I’m having a little trouble visualizing what the three octets of fractional time would look like.

Sure! Basically, the fractional part of the timecode allows you to specify times with sub-second resolution using binary fractions. The first bit “after the decimal point” represents 1/2 second, the next bit represents 1/4 second, and so on. So, with a one-octet (8-bit) fractional time field, the LSB (least-significant bit) of the fractional time field would represent 1/(2^8), or 1/256th, of a second. With each 1/256th of a second that passes, the fractional time field increments. When it’s at 255, the fractional time field then rolls over to 0, and the lowest bit of the integer time field (representing 1 second) increments by 1. I’m proposing a three-octet fractional time field, so it would increment every 1/(2^24) second. Does that make more sense?

As I understood this, this was simply a 3-byte integer representing the number of 2⁻²⁴ seconds since the integer second began. As some examples, 0x000001 would be 2⁻²⁴, 0x800000 would be a half second, and 0xffffff would be 2⁻²⁴ seconds before the integer second increases.

Added: a few more examples: 1/1024 second would be 0x004000, 1/1000 second would be 0x4189.

Yep, that makes sense. Thank you both!