[time-nuts] time messages
Bob Camp
kb8tq at n1k.org
Mon May 26 18:02:39 UTC 2014
Hi
Here’s my guess:
Powers of two sound fine. Anything more than that is getting into the “waste of bits” area.
Fully silly range might be +32 to -32. On a practical basis, some of that range is not useful (+32 for example).
Pick a number at one end or the other (zero or 255 or ...) for “I don’t know”. (let’s say +32)
Pick a couple of other end numbers as “reserved”. (say 28,29,30 and 31)
Let the rest of them define the precision.
That way you can express any meaningful precision, and still have a few messages lying around for the inevitable unforeseen extensions.
You have an 8 byte payload and have added six bits to it. If the protocol wants to see a byte as the smallest added chunk then indeed waste the two bits on a bit finer grained accuracy.
Bob
On May 26, 2014, at 1:43 PM, Jim Lux <jimlux at earthlink.net> 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)
> _______________________________________________
> 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_lists.febo.com
mailing list