EEVblog #61 - Crystal Oscillator Drift

[gnosis]

This was a very interesting episode.  But it made me wonder, why didn't you just use NTP?  Or maybe some other time synchronization software like chrony (which is designed for computers that only rarely connect to a network)?

Was it just that the spec required the probes to be without onboard microcomputers (perhaps having to do with the limited power requirement, or cost)?  Or was it that there are problems getting a network connection from so far under the ocean?

And if computer/network -dependent protocols like NTP are inappropriate for some reason, what about asking on one of the NTP mailing lists for ideas for how to measure and correct for clock drift?

Those mailing lists are full of complete clock geeks.. and I can't believe something like what you were looking to do would be completely new to them.  Even if using NTP was out of the question, I bet some of them could have suggested some other known method.

PS: I'm really loving your episodes.  Please keep up the great work!

[DJPhil]

You have to remember that Dave's speaking of a job he had in the past. I'm not sure how long ago it was, but I'd guess sometime around 2000 +/- 4 years or so, and that changes available technology somewhat. You can be relatively sure that at the time this was likely the most cost effective method of getting things done. You can be sure that there was definitely at least one microcontroller in there, but probably not a modern, power hungry, peripheral studded one with networking capabilities.

NTP's performance is heavily network dependent and difficult to make more accurate than about 1ms (I think the best examples are around 1/10th that), so it's a nightmare to use to discipline an oscillator. It takes known good absolute time and propagates it through a packet switched network, attempting to correct latency via several methods. Dave quotes the application as requiring a stability of 10^-8, or roughly 10ns (100MHz). Imagine adding a +/- 1ms jitter, that's worsening things by a factor of 10,000!

Thinking about how it might be done differently nowadays, it's hard to say. The best idea is likely to be simply take advantage of the newer technology to do the same thing. If it's within the power budget, and there's a solution to inter-device and surface communication, they might use a GPS disciplined clock source on a buoy operating primarily from solar power. It might be more cost and complication than it's worth in the long run though.

Here's a great article from QST on building your own GPS disciplined frequency standard. It's on my list of future projects when money gets better. You can bet that Dave and the folks he worked with knew of things like this at the time (it might be related to how they synced the devices before deployment) and that they'd have used something like this if it were possible/cost effective.

Hope that helps.

[EEVblog]

This was a very interesting episode.  But it made me wonder, why didn't you just use NTP?  Or maybe some other time synchronization software like chrony (which is designed for computers that only rarely connect to a network)?

Was it just that the spec required the probes to be without onboard microcomputers (perhaps having to do with the limited power requirement, or cost)?  Or was it that there are problems getting a network connection from so far under the ocean?

Bingo.
It's kinda hard to get network access when you are 2km down on the ocean floor.
Battery life and power budget is the major design requirement, as these things have to stay down continuously recording for months at a time. That is what forced the use of a non-oven oscillator or other more traditional disciplined oscillators.

Trust me, this is a very unique field, with many unique problems that are not as easy to solve as you might think.
If you can come up with a way to get a very stable autonomous oscillator that draws very little power then you will take the geophysical industry by storm and make squillions of dollars. It's a very major problem that billion dollar companies are trying to solve.

Dave.

[EEVblog]

You have to remember that Dave's speaking of a job he had in the past. I'm not sure how long ago it was, but I'd guess sometime around 2000 +/- 4 years or so, and that changes available technology somewhat. You can be relatively sure that at the time this was likely the most cost effective method of getting things done. You can be sure that there was definitely at least one microcontroller in there, but probably not a modern, power hungry, peripheral studded one with networking capabilities.

The device had a TMS320 processor and FPGA. In fact it's the device that you see in my main blog photo.

NTP's performance is heavily network dependent and difficult to make more accurate than about 1ms (I think the best examples are around 1/10th that), so it's a nightmare to use to discipline an oscillator. It takes known good absolute time and propagates it through a packet switched network, attempting to correct latency via several methods. Dave quotes the application as requiring a stability of 10^-8, or roughly 10ns (100MHz). Imagine adding a +/- 1ms jitter, that's worsening things by a factor of 10,000!

Thinking about how it might be done differently nowadays, it's hard to say. The best idea is likely to be simply take advantage of the newer technology to do the same thing. If it's within the power budget, and there's a solution to inter-device and surface communication, they might use a GPS disciplined clock source on a buoy operating primarily from solar power. It might be more cost and complication than it's worth in the long run though.

There is no inter-device or surface communications, these are essentially autonomous data loggers.
As I said, power budget is the key.
Today's technology probably hasn't improved a lot in terms of low power stable oscillators, but now solid state hard drive storage would be fully viable.

Here's a great article from QST on building your own GPS disciplined frequency standard. It's on my list of future projects when money gets better. You can bet that Dave and the folks he worked with knew of things like this at the time (it might be related to how they synced the devices before deployment) and that they'd have used something like this if it were possible/cost effective.

Yes, the devices had to GPS synchronised before and after deployment. And they have to stay stable and consistent between units over time, temperature (freezing point on the ocean floor, to 60degC+ on the back deck of boats) and shock/vibration.

Dave.

[gnosis]

Thank you for the prompt and thorough responses.  Seems the clock drift problem with the requirements you were under was much more difficult than I expected.