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
"invalid".
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.
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.
_______________________________________________
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.
