[time-nuts] time messages
jimlux at earthlink.net
Mon May 26 14:26:26 EDT 2014
On 5/26/14, 11:13 AM, Magnus Danielson wrote:
> 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
yes.. that was sort of the idea..
On the other hand, since the consumer of the data should be aware of
where it's coming from, one could argue that they would know what the
uncertainty and holdover effects, and all they really need to know is
how long it's been since holdover (or whatever) started.
So then, what you really need is a more sophisticated "time source mode"
flag which is time source dependent (e.g. "invalid, valid, valid but in
holdover), and then the consumer would apply the appropriate algorithms.
In space applications, there's generally a fair amount of knowledge
about the behavior of the various devices, so all you really need is a
standardized way to communicate these things, rather than trying to send
the entire datasheet.
Although, down the road, I would hope that we get a bit more
abstraction, and the message consumer could request a "virtual data
sheet" from the message source. There is a standard (IEEE 1451) for
sensors that does this: giving calibration constants, etc. in a
Transducer Electronic Data Sheet (TEDS).
So far, though, what's been implemented (in space apps) has been things
like polynomial cal curves which are fine when the underlying physics is
polynomial, but not so hot when the underlying physics is, say, square
root (e.g. the sensor measures power, but the ultimate engineering unit
you really want is voltage) or log or exponential. (think of RF power
detector chips that return linear voltage as dB)
> Recommendations of how these should be set by GPS source or whatever may
> help people to understand how they should be properly used.
Yes, that's the "explanatory/informative" part of the spec, as opposed
to the "requirement/normative" part of the spec.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the time-nuts