[time-nuts] Low-long-term-drift clock for board level integration?
dennis.c.ferguson at gmail.com
Mon Feb 20 03:28:13 UTC 2012
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
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.
More information about the time-nuts