[time-nuts] time messages

[Bob Camp]

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.