[time-nuts] time messages
Magnus Danielson
magnus at rubidium.dyndns.org
Mon May 26 14:13:04 EDT 2014
Hi Jim,
On 05/26/2014 07:43 PM, Jim Lux wrote:
> 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)
I think that power of 2 suffice for most applications. Your 64 bit
format requires a 6 bit field, so you could use up the other two bits of
that byte to hold the bits after the leading 1.x times the exponent, if
you would like a little more refinement.
An interesting approach is found in C37.118 variant of IRIG-B, in which
one field gives the hold-over mode precision in power of 10 steps so
that as you go into hold-over you can step this to reflect the expected
range of deviation from "real" phase. Then, when in lock (a special case
of this first field) the precision of in-lock performance is given,
again in power of 10 steps. A special case of one of these can be "invalid".
Recommendations of how these should be set by GPS source or whatever may
help people to understand how they should be properly used.
Cheers,
Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts
mailing list