On 19 Feb, 2012, at 15:56 , Bill Woodcock wrote: > Hi. This is my first posting to this list, and I'm not a timekeeping > engineer, so my apologies in advance for my ignorance in this area. > > I'm building a small device to do one-way delay measurements through network. > Once I'm done with prototyping, I'm planning a production run of several > hundred of the devices. They'll have a GPS receiver, probably a Trimble > Resolution SMT, and they have a bit of battery so they can initially go > outdoors for ~30 minutes to get a good fix, but then they get taken indoors > and plugged into the network, and probably never get a clear view of a GPS or > GLONASS satellite again. > > - From that point forward (and we hope the devices will have an operational > life of at least ten years) they'll be dependent on their internal clock and > NTP, but we really need them to stay synchronized to within 100 microseconds. > 10 microseconds would be ideal, but 100 would be acceptable. And in order to > be useful, they need to stay synchronized at that level of precision > essentially forever.
> > My plan, such as it is, was just to get the best clock I could find within > budget, integrate it onto the motherboard we're laying out as the system > clock, and depend on NTPd to do the right thing with it. 10, or even 100, microseconds is tough with NTP. I don't think it is impossible, but it requires a good, reliable network connection and a bunch of work to identify and reduce the systematic errors. And if "NTP" == "ntpd" I'm not sure putting a better oscillator on the board is likely to help all by itself since ntpd's "magic" internal constants are organized to work with the class of oscillators you typically find in computers, and this would need to be redone to do anything useful with something better. I think making use of NTP at the 10-100 microsecond level might require doing your own software, the generic reference implementation probably won't cut it. Before doing that you might consider some alternatives: - If you are deploying this stuff in the US, and if cell phones (particularly Verizon or Sprint phones) work where you are installing the stuff, you might look at this for a time source: http://www.endruntechnologies.com/time-frequency-reference-cdma.htm This is good if it works everywhere you need it, and assuming CDMA networks continue to operate for another 10 years. - Failing that, look at IEEE 1588. The trouble with this is that it severely constrains the kind of network the equipment is attached to, and the gear used to build that network, but if this is in your control you can buy stuff for this without having to build it. If none of the above works, and you just can't get GPS antennas installed, then you may be stuck with NTP, but getting a reliable 10-100 microseconds out of that is a lot closer to the "research" part of R&D then the "development" part. I don't think running the generic reference implementation, ntpd, will deliver this. Dennis Ferguson _______________________________________________ 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.
