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 -- [email protected]
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
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.
