[time-nuts] time messages

Jim Lux jimlux at earthlink.net
Mon May 26 13:43:22 EDT 2014


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)



More information about the time-nuts mailing list