OCXO-based Real-Time Clock

Thread Starter

benha

Joined Jan 4, 2011
71
Hi,

[Disclaimer: Not an electronics guy, but I've Googled enough to, I hope, ask the right questions.]

I'd like to have a very accurate, standalone (not-GPS/Radio-regulated) clock that I can use for celestial navigation. Accuracy matters a lot here, so I'm trying to get down to something in the 0.1 PPM range.

Not much exists on the market at any sort of reasonable price point, so I'm thinking I'll need to build what I'm after, and my current thinking is that something based on the Arduino platform will be the easiest path to success.

If I were happy with 10ish PPM, there are lots of packages out there that provide realtime clock capabilities that make things straightforward. You know: Turning the oscillations of a crystal into something meaningful like date and time. (EG: http://www.sparkfun.com/products/99)

But I'm looking for greater accuracy. It appears that an OCXO oscillator will give me the level of accuracy I need, but I'm not sure what I need to do to build the intelligence layer on top of the oscillator to translate to date and time.

Are there clock modules that can accept an OCXO as an input? The clock modules I've seen (EG: http://www.maxim-ic.com/datasheet/index.mvp/id/2688) do appear to support external _crystals_ but they all want 32.768kHz and I haven't seen an OCXO rated at that.

Any tips/pointers would be much appreciated!

Thanks,
-Ben
 

crutschow

Joined Mar 14, 2008
34,280
If you can buy an OCXO with a frequency that is a binary multiple (multiplied by factors of 2) of 32.768kHz then you can use a simple binary divider counter chip to generate the 32.768kHz. For example a 1.0486MHz clock can be divided by 32 (5 binary divider stages) to generate 32.768kHz.

The reason they use 32.768kHz is because it can also be divided by a binary counter (15 stages) to generate a 1 second clock pulse (2^15 = 32768).
 

SgtWookie

Joined Jul 17, 2007
22,230
Well, Roman Black has some interesting ideas on his site:
http://www.romanblack.com

Here's an inexpensive way to build your own OCXO:
http://www.romanblack.com/xoven.htm

and hook that up with his zero-error 1 second timer:
http://www.romanblack.com/one_sec.htm
but there is some even more interesting code below that.

Now, I don't know what kind of accuracy you'll be able to achieve even with keeping the xtal and uC temp at a constant, along with using Bresenham timing techniques. If you want really, really accurate, you'd need to go to a rubidium oscillator. You may be lucky and find one available on the surplus market.

Take a look at what this fellow did with his surplus-market rubidium oscillator:
http://www.vaxman.de/projects/rb_clock/
His came from the predecessor to this company:
http://www.symmetricom.com/products/frequency-references/rubidium-frequency-standard/

Here's a new rubidium oscillator that's PCB mountable:
http://www.spectratime.com/products/isource/
Ultra-low cost at $900/ea.

You can get reasonably accurate, reasonably inexpensively. The more accurate you want it to be, the more expensive things get - and power requirements go up a good bit, too. You need to keep the entire oscillators' temperature constant; and it takes power to keep things warm.

It would be a lot less expensive to go with a GPS receiver.
 
Last edited:

Thread Starter

benha

Joined Jan 4, 2011
71
Ok. That's valuable insight.

That said, most of what I find seems to be in "round numbers." 10MHz is the most common. Is there a similar trick for converting from something like that to what I need?

I'm also continuing to Google and I think I may have another approach. A 2nd hand 10MHz Rubidium oscillator can be had on eBay for a lot less than a new OCXO (which I'm beginning to realize is an outrageously expensive component.)

Given the Arduino has a processor in it, I suppose I could take the 10MHz pulse from the Rubidium box and divide it by 10 million to get a 1PPS pulse, which is exactly what I'd need to drive a clock. Though I'm not sure what, exactly, I'd need to put in the loop to count cycles from the oscillator.

Interesting...

-Ben
 

SgtWookie

Joined Jul 17, 2007
22,230
You would use the Rubidium oscillator for the uC's clock, and then just execute loops until enough machine cycles have gone by to increment the time & date.

[eta]
I hadn't looked until now; there seem to be some real deals to be had if the product is what they say it is.

Those rubidium oscillators should be several orders of magnitude more accurate than an OCXO.
 
Last edited:

crutschow

Joined Mar 14, 2008
34,280
You would use the Rubidium oscillator for the uC's clock, and then just execute loops until enough machine cycles have gone by to increment the time & date.

.............
As long as you knew exactly how many clock pulses it takes to execute all the machine cycles, including incrementing the time & date. Obviously if you are going for high accuracy, you can't be off by even one clock count.

I would think you would need a dedicated divide by 10 million counter (7 decade counters such as seven 74HC4017 ICs) to accurately get the 1pps count.
 

SgtWookie

Joined Jul 17, 2007
22,230
As long as you knew exactly how many clock pulses it takes to execute all the machine cycles, including incrementing the time & date. Obviously if you are going for high accuracy, you can't be off by even one clock count.
That's absolutely right, and you DO have to keep track of every machine cycle, filling in with loops or NOP's depending on what would be more of a space saver.

I would think you would need a dedicated divide by 10 million counter (7 decade counters such as seven 74HC4017 ICs) to accurately get the 1pps count.
Not really, as if the uC itself is being clocked by the accurate 10MHz, it can do all the counting itself.

Now, if your application also needed to use interrupts, programming could get hairy. For simplicity's sake, one could use a "little PIC" like a 12F675 or cheaper as the /1e6, and feed that to a bigger pic. I'd much rather use one eight-pin PIC12F675 for about a buck than seven 4017's.
 

Thread Starter

benha

Joined Jan 4, 2011
71
OK.

You guys are pointing me in good directions. I've continued to investigate and here's what I've found:

Some Rubidium Oscillators that can be had cheaply on eBay, in addition to running at 10MHz, will also output a 1PPS pulse:
http://www.ebay.com/itm/Symmetricom...Television_Test_Equipment&hash=item45ff920bad

Dallas' DS1341/42 RTC Chip supports an external sync 1PPS signal that is used when present, and then it'll default back to a standard crystal oscillator when not.

So...

It seems to me I can build an Arduino shield based on the DS1341/42 and the DS32KHZ clock (though I'm not positive that this clock will work for that chip) and then have an optional plug for an input from the rubidium oscillator. That gives me a high-power-consumption, high-accuracy version of the clock for "normal" operation, and the ability to fail back to a low-power-consumption, good-accuracy version (rubidium-free) for times when I need to run on batteries.

-Ben
 

MrChips

Joined Oct 2, 2009
30,706
No. You do not have to count machine cycles on a MCU. If it is done properly using an internal timer and interrupts, you can generate any time-of-day period running in the background, even in sleep mode.

An alternative is you can use the 32768Hz OCXO to drive an external RTC chip interfaced to a MCU.
 

THE_RB

Joined Feb 11, 2008
5,438
Thank you for mentioning my page SgtWookie, I already have code there that just needs one number changed for generating an exact 1 second period from a 10MHz clock source;
Rich (BB code):
C code for a 1 second period with a 2.5MHz PIC timer (a 10MHz xtal OCXO); 

  // uses 1 variable; unsigned long bres
  // gets here every TMR0 int (every 256 ticks)

  bres += 256;          // add 256 ticks to bresenham total

  if(bres >= 2500000)   // if reached 1 second!
  {
    bres -= 2500000;    // subtract 1 second, retain error
    do_1sec_event();    // update clock, etc
  }
or this variation;
Rich (BB code):
C code for a 1 second period with a 2.5MHz PIC timer (a 10MHz xtal OCXO); 
Uses number *100, to give extremely fine calibration ability!
(You can tweak the value 250000000 for calibration ajustment.)

  // uses 1 variable; unsigned long bres
  // gets here every TMR0 int (every 256 ticks)

  bres += 25600;          // add 256 ticks to bresenham total

  if(bres >= 250000000)    // if reached 1 second!
  {
    bres -= 250000000;     // subtract 1 second, retain error
    do_1sec_event();       // update clock, etc
  }
One problem with OCXOs is that many are defective (second hand ones from ebay etc) and drift badly, and new ones are VERY expensive. And they will use a LOT of power (if this is a battery device!) and can take an hour to stabilise, so they need to be using a lot of power 24 hours a day really.

My personal preference for this nav device would be to use GPS to constantly check and set a clock, and a cheap $20 10MHz TCXO (good for about 1-2 PPM) that keeps the clock going in times of GPS blackout if you are worried about ocean storms etc. Even at 2 PPM error TCXO it will give very good time keeping for some hours here and there from GPS blackout.

(edit) From memory, the TCXO used INSIDE most brand name GPS modules is good for 1-2 PPM anyway, so you can just use a GPS unit as your entire clock. In times of GPS blackout the GPS unit will still keep time (and output the time) using its internal TCXO.
 
Last edited:

Thread Starter

benha

Joined Jan 4, 2011
71
This is a wonderful bounty of information. Thanks, folks.

An FYI on my aversion to GPS in this application is that, basically, if you had GPS you'd be navigating with it. So, while it's a semi-absurd proposition that the GPS system would somehow go offline, I'd like a clock that's independent of GPS or radio time signals (since you might be out of range).

I like the idea of a TCXO-RTC based "default" system that's run on batteries in the event of power failure, with a Rubidium 1PPM generator plugged in to keep it as accurate as possible under normal circumstances.

I can pack it all in a compact pelican case with a display and a solar cell mounted on the outside. I haven't done the math yet, but I'm betting a solar cell/charger combined with a modest battery could power the TCXO/RTC version of the clock indefinitely in the event of a power failure as long as you only activated the display when you were taking sightings. Losing the Rubidium to conserve power unit once you're "up the creek" wouldn't be a big deal since at that point you're probably headed home anyway and with the TCXO you wouldn't see a meaningful drift over the length of time you'll be using the clock for navigation.

Yes, I know I'm being a bit obsessive here. It's also just an interesting challenge to try to create a self-contained, hyper-accurate timekeeper :)

-Ben
 

THE_RB

Joined Feb 11, 2008
5,438
...
It's also just an interesting challenge to try to create a self-contained, hyper-accurate timekeeper :)
...
I agree! It sounds like fun. It's just that getting 1 PPM on a timekeeper is hard enough, so getting <1 PPM and also having big power limits like "portable" and "solar powered" start making it real hard.

Can you quantify some other factors, like how long the time has to remain accurate without any external time comparison, expected power consumption, and things like that?

I don't want to sound negative but if you expect it to keep perfect time for weeks on low power and greatly changing temperatures etc it's going to be near impossible. If it's just for a few days that is not so bad.
 

MrChips

Joined Oct 2, 2009
30,706
I am working on an auto-calibrating long clock based on the 10,000 Year Clock.

http://longnow.org/

You can power a xtal driven RTC and LCD display for a very long time (> 10 years) on a watch crystal and solar cell. You would not need a TCXO, just an ordinary 32768Hz Xtal oscillator. What you have to do is to synchronize the time once in a while when the sun peaks to noon.
 

Thread Starter

benha

Joined Jan 4, 2011
71
You would not need a TCXO, just an ordinary 32768Hz Xtal oscillator. What you have to do is to synchronize the time once in a while when the sun peaks to noon.
Heh. Right. But that presumes you know where you are. Which becomes a bit circular when the point is to have the instrument to determine that. ;)

In my case, the requirement for it running on low power is a fringe one. Really, the only time you'd be in that circumstance is if you were in a liferaft. While the longest recorded liferaft survival in history was, I think, 133 days I think a 30-day envelope is more than enough. If you're bobbing in a raft longer than that, you're probably not navigating anymore anyway.

The rest of the time, even if your nav aids all die there should still be power. A typical cruising vessel has multiple independent power sources that are up to the task and it's unlikely that whatever incident took your normal nav gear offline would ruin them all.
 

MrChips

Joined Oct 2, 2009
30,706
Just to clarify a few points. The Long Clock does not need to know physical location. I just uses a signal from the sun at its zenith to do a correction on the time.

I don't understand the relationship for time-of-day clock and a GPS unit. I gather that you need an accurate clock for celestial navigational purposes in the event that GPS service is lost. How accurate does the clock have to be, both in terms of relative accuracy (resolution) and absolute accuracy (absolute error)?
 

crutschow

Joined Mar 14, 2008
34,280
Just to clarify a few points. The Long Clock does not need to know physical location. I just uses a signal from the sun at its zenith to do a correction on the time.

...........
But you need to know your location for setting the time at the zenith for it to be of any use as a navigation device. You have a circular situation.:rolleyes:
 

Thread Starter

benha

Joined Jan 4, 2011
71
Yeah, so figuring out your local noon is easy. But you don't care what time it is locally. You care what time it is at the Greenwich Observatory. Well, you actually care about UTC, but whatever.

Then you figure out what UTC is when your local azimuth says it's "noon" and determine the difference between them. That can then be easily translated into your Longitude. (There's a great book on the development of the marine chronometer by Dava Sobel called Longitude, by the way.)

Anyway precision isn't that important since the procedures for taking sights would be hard pressed to get you to much less than half-second resolution.

Accuracy is a big deal. Every second your clock is off translates to 1/4 NM of positional error.

So if your clock is off by a minute, you're going to be off by 15 miles. May not sound like much, but this isn't the only source of error and the errors can compound, so you want it to be as close as possible.

A 1 PPM error translates to about .09 second per day, or about a half minute per year. That's more than fine for this purpose since virtually any voyage would be no more than a month and once ashore you can reset your clock. But (1) who's to say you'd be able to get accurate time when you get to shore, and (2) did I mention I'm being a bit obsessive? I mean, if you had to rely on this clock indefinitely then over time you'd end up with a wide discrepancy. ;-)

20 PPM, on the other hand, would quickly get you into dangerous territory from a navigational perspective. Depending on temperature conditions, you can pretty easily get past 20 PPM without a compensated crystal and that's a bummer.
 
Last edited:

Thread Starter

benha

Joined Jan 4, 2011
71
Just to clarify a few points. The Long Clock does not need to know physical location. I just uses a signal from the sun at its zenith to do a correction on the time.

This is because the Long Clock doesn't move. If it weren't in a fixed location things would be different.

Incidentally, how does the Long Clock compensate for continental drift? Over 10,000 years at, say, 7cm per year movement, it will move by 700m. That's 0.378NM which, depending on how much of that vector is longitudinal, could account for a time error of as much as a second and a half!

Oh, wait, it's just calculating local time so I guess it'll be fine...

:p
 

MrChips

Joined Oct 2, 2009
30,706
But you need to know your location for setting the time at the zenith for it to be of any use as a navigation device. You have a circular situation.:rolleyes:
No, I don't see this. The time of zenith is when the sun reaches the max height. This time is 12:00 noon. You do not need to know your location.
 

Thread Starter

benha

Joined Jan 4, 2011
71
No, I don't see this. The time of zenith is when the sun reaches the max height. This time is 12:00 noon. You do not need to know your location.
See above. Figuring out your longitude requires you to know what time it is at a known point, conventionally GMT/UTC, when it's a particular time where you are. Noon is an easy example. You can figure out noon locally without a clock. But what time is it in Greenwich then? If you know where you are then you can calculate the time there. If you know the time there you can calculate where you are. You don't know where you are, so you need the time in Greenwich.
 
Top