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 <[email protected]> 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 -- [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.
