I'm in the middle of implementing a lightweight time distribution system
using SpaceWire (a fast point to point serial link with simple routers
to build networks).
SpaceWire provides a special token called a timecode which propagates
from a "tick source" to various nodes, but that just provides the "tone"
and I need to define a "at the tone the time is/was" message.
In practice, the uncertainty in the timecode/mark is somewhere around 1
microsecond, and it's bounded.
The actual format of the time is easy: CCSDS Unsegmented Code, which
basically 4 bytes of integer seconds, and 4 bytes of fractional seconds.
The question I have is how best to represent the underlying uncertainty
in that time message so that a consumer of time can make a decision
about things like "how many bits to trust" or gain on filtering
algorithms, etc.
Some IRIG messages have a "time figure of merit" field.
NTP has a precision field which is essentially "number of bits", and a
similar scheme would be possible here. So, if my underlying clock
generating the time ticks is good to say, 1/65538th of a second, my
precision field might be -16, if it's good to a second, precision would
be 0, and if it's only good to 16 seconds, it would be +4.
Is going in powers of 2 sufficient? The underlying clocks are likely
things like TCXOs and/or a GPS receiver. So you might have a 1ppm TCXO
or a 50 ppm TCXO. Or, a GPS receiver which puts out a 1pps with 10ns
uncertainty (e.g. 10 ppb .. -26 bits)
Is it worth having a separate field for "validity" or should that be
encoded as a "special value" for the precision field (in general, I
don't like "special values", but in the space biz, people DO like to
pack more info into fewer bits)
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
