# How would I go about getting a small oscillator running at precisely 31,891,269,116 µHz?

I am looking to build an RTC module for Arduino that runs on Mars time. The conversion factor is 1.0274912510 Earth seconds to 1 Mars second.

Whilst I have managed to accomplish this programmatically with a <2 second resolution (which is not exactly ideal, I'd prefer something like 300 ms of accuracy) using fixed-point maths on an Arduino Uno connected to a regular RTC module, I am wondering if it would be possible to have some kind of low voltage oscillator running at precisely 31,891,269,116 µHz (31.891269116 kHz) which would, more or less, be interchangeable with a standard 32 kHz clock crystal (however, I would be open to other ideas so long as they aren't prohibitively expensive.)

Any ideas how this may be possible? Alternatively, some kind of timer that goes off once every 1.0274912510 seconds would also be acceptable.

• Why the weird unit (µHz?) That's 31.891 kHz. So, you are probably looking for a 32kHz watch crystal. – JRE Aug 29 '16 at 8:17
• Start with your requirements. You have specified extraordinary precision. Why? Elsewhere you say you can sort of do what you want with an Arduino. I'm sorry to tell you this, but you're kidding yourself, unless you're using something like a rubidium or cesium clock as a reference. So tell us what you're doing, and what your performance requirements are. That's functional requirements, not your derived performance. If you're trying to produce a clock which is locked to another, say so, and let us know just what your requirements (and tolerances) are. – WhatRoughBeast Aug 29 '16 at 11:19
• You're trying to solve your lack of programming skill with very expensive and custom hardware. You can easily implement a 256 bit floating point conversion in an Arduino, or whatever precision you want. – pipe Aug 29 '16 at 11:27
• I think this is a great example of why including more information upfront enables people to point you in the correct direction. Brian Drummond's answer is now the best one, or at least cheap and feasible for an amateur. It's also a good example of why you have to be careful when specifying precision and accuracy - there are a lot of parameters that are potentially relevant to a clock. We haven't even discussed temperature compensation or jitter yet. – pjc50 Aug 29 '16 at 11:36
• "The conversion factor is 1.0274912510 Earth seconds to 1 Mars second." -- are you confusing the difference in day lengths between Mars and Earth with the length of a second? The length of a solar day on Mars is 88 775 s, or 1.02749 Earth days (of 86 400 s). On the other and the second is defined by the radiation emitted by a cesium atom, and even taking time dilation to account, you'd need velocities of about 0.23 c to get that 2.7 % difference. – ilkkachu Aug 30 '16 at 9:13

Use a 32768kHz crystal like everybody else, but divide by 33669 instead, giving -5.08ppm error. (You can remove that by trimming the loading capacitance if you like).

It's not precise but for a Mars clock it'll be as good as any Earth quartz clock. That is, ignoring the problems of temperature compensation for Mars ambient temperatures, most watch crystals are only available cut for Earth use, unless you can find Martian suppliers...

I'd use the counter-timer peripherals in an MSP430 to do the division, and (assuming you're driving a standard quartz mechanical clock movement) generate bipolar 30ms pulses on its output pins every second, roughly following the original timings which you can measure on an oscilloscope.

Arduino or similar will do the job, but the MSP can be put to sleep between pulses, consuming under 1uA with the LF oscillator running. Here's an example design with source code and PCB for a watch - only Earth time so far, though that can probably be fixed by changing a constant.

• Thank you! Based upon other feedback, I think this looks like the most viable option without having to delve into the realm of atomic clocks so I have chosen it as the solution to my question. I also especially appreciate the design you've linked. – renegadeds Aug 29 '16 at 11:47
• Be aware that the significant figures that you gave will not be met with a standard RTC crystal. The 5ppm error from the math will likely be less than the crystal tolerance. – user2943160 Aug 29 '16 at 12:40
• @user2943160 if you have a good reference, you can hit 1ppm or so with initial trimming - there will be a few ppm drift over a few years and (oddly for tuning fork crystals) a parabolic variance with temperature. All the cheap quartz clocks in my house go at different rates, they were probably never trimmed at the factory, and aren't a whole lot better than a temperature compensated pendulum clock. – Brian Drummond Aug 29 '16 at 12:48
• +1 just for the "Martian suppliers". – Olin Lathrop Jul 17 '18 at 11:08

You can do better than Brian Drummond's suggestion. Although it may be true that your oscillator is the biggest source of error in the system, there's no reason to add additional systematic error when it's easy enough not to.

Set your timer interval to 33668 ticks, start a counter at 0, and on every timer interrupt, increment the counter by 6754.

If, after incrementing, the counter is >= 8105, then subtract 8105, and set the timer interval for the following second to 33669 ticks.

Otherwise, leave the counter alone and set the timer interval for the following second to 33668.

This will give you (assuming a perfect 32.768kHz crystal) an average interval of

(33668 + 6754 / 8105) / 32768 ~= 1.0274912510006


seconds (less than one part-per-trillion error relative to 1.0274912510), instead of 1.0274963378906 seconds (almost 5 part-per-million error). This means that the long-term accuracy of your clock will be truly dependent on the accuracy of the oscillator; the error due to the mathematics will contribute substantially less than one tick of error per year. Although the length of any single second will have a relative error up to 25ppm, over longer and longer averaging intervals the error disappears.

This is Bresenham's algorithm applied to timekeeping, and the fraction 6754/8105 was found as follows:

32768 * 1.027491251 = 33668.833312768

The exact continued fraction for 33668.833312768 is [33668; 1, 4, 1, 1349, 1, 7].

Dropping the last term gives the approximant 33668 + 6754 / 8105, which has all parts that fit neatly into 16 bits.

An Oscillator running at precisely 31,891,269,116 µhz or a timer with 1.0274912510 seconds period would require a precision of at least $10^{-10}$. Your best bet is to use an atomic clock which can be as precise as $10^{-14}$.

• I was hoping to avoid expensive hardware if possible. Right now I am achieving this with a regular RTC module and an Arduino, and I am able to make the 1000ms to 1027.4912510ms conversion, however I only have roughly a 1-2 second resolution meaning it IS self correcting but isn't terribly precise. – renegadeds Aug 29 '16 at 10:25
• @renegadeds then you should make it clear in your question what precision is acceptable. And please provide some context: a single [arduino] tag would be a good hint that you're not building a high-precision lab stand. – Dmitry Grigoryev Aug 29 '16 at 10:43
• Noted, I have updated the question and added the Arduino tag. – renegadeds Aug 29 '16 at 11:21

It could be done with a rubidium or other atomic reference clock at 10MHz, perhaps a PLL to give (say) 100MHz, and then counted with a ~36 bit phase accumulator to give 0.001Hz resolution. The latter could be done with a small FPGA.

You can read up on Direct Digital Synthesis (DDS) methods. There are chips that do the DDS but maybe not with such a wide bit width.

Rubidium clock modules are available on the surplus market, or from makers such as Microsemi.

You don't define "expensive", so this is something of a shot in the dark.

Start with a commercially (including eBay) 10 MHz generator. Rubidium for choice, but whatever accuracy you can get sets your performance.

Now build a progammable divider of 28 bits length. At 10 MHz you can get away with 74HC CMOS logic, but you'll need to use a fast carry configuration. The output also triggers a divide by two flip-flop which provides bit 29.

The divider can run at a ratio of 10,274,912 or 10,274,913, depending on the state of bit 29. For a perfect 10 MHz input the effective output period for bit 28 will then be 1.02749125 seconds, which is approximately accurate to 1 ppb, or about 30 msec/yr. A less-accurate input, of course, will produce a less-accurate output.

Using bog-standard 74HC161s you can do this with 8 ICs, and if you're careful you might be able to use a standard prototyping strip board, although you'd want to be very careful about beefing up the ground system. Perfboard would be cheaper, more compact and more durable, but the wiring would be less convenient, since you'd need to solder the connections. You could then pot it in something like electronics-grade RTV (NOT the RTV you get at the hardware store), for a final module size in the range of 2 x 2 x 1/2 inches, not counting the oscillator.

EDIT

Note that your performance standard, being linked to "regular" RTCs, is actually in the range of 1 sec/day accuracy, which is 30 times worse than this approach. So, first off, you can do away with the bit 29 stage or, alternatively, divide your 10 MHz to 5 MHz and use a ratio of 5,137,456. This lower clock rate at the counters will allow a simpler carry structure, avoiding the fast carry which would be necessary at 10 MHz. Your accuracy is now on the order of 60 msec/yr for a perfect clock.

FURTHER EDIT

A quick look at eBay shows a large number of 10 MHz OCXOs for less than 20 bucks. These will typically have stabilities of 1 ppb or better, with 0.2 ppb a fairly common spec. Get one of these and you should be in good shape. You'd want to borrow a fairly high resolution frequency/period meter to determine the actual output frequency, then adjust the division ratio to match.

• Agreed, and even if OCXO isn't in the power budget, a TCXO is and can still improve upon a watch crystal. – hobbs Aug 29 '16 at 22:02

"Stratum 1" clocks are derived from $10^{-11}$ SC cut crystals used in ~\$250 VC-OCXO's (e.g. Vectron) unless you buy used. Then with tuning for sync to global clocks like WWV, VLF , GPS 10MHz or 1pps clock which are in turn sync'd to $10^{-14}$ atomic clocks via "locked to 3 satellites." Then you can calibrate to $10^{-11}$ error.

To make another f, such as your frequency requires an offset of 2.07% of 1pps so this is not doable by tuning a watch crystal at $10^{-6}$ stability.

A "fraction N synth" type PLL is used to derive any ratio of a reference such as 10Mhz from some GPS units.

If a TCXO oscillator has a stability of 1ppm, it can only be tuned a bit more than this and not 2.07% offset from 1 pps or 1.0274912510 Hz, so a PLL with a fractional N chip (s) is one way to do this with a VC-OCXO or mechanical cap tuned OCXO.

added - To generate the 1pps on MARs time, then the divide ratio is 26,337.44856 using 5 integer digits and a residue of 5 digits.

• If you can tune the Xtal to 0.01 ppm it will only be stable usually to 1ppm unless an micro-oven is made at ~30'C as Tempco is usually null around body temp for some XTALS not necessarily MEMs. Unless Vcc and temp is contant within 0.1 deg 'C anything trying to correct residue error better than 0.01 ppm is impossible , even 0.1ppm is hard short term and long term aging will be at least 1ppm per year.

• Thus in theory if you had a calibrated 1ppm clock from a GPS to tune 1ppm Earth time, it would be impossible to expect better accuracy correcting for residual.

• Residue error value of divider per sec. is 44856/100000 (+26,337)

• Converting 44856 to binary = 1010111100111000
• This needs a residue counter to toggle between /44856 and 45857

• We do this residue division by truncating the binary residue number to 8 bits then rotating the bits so MSB becomes LSB.

• 10101111 becomes 11110101

• Every second a residue counter from 11110101 and where each "n" bit position =1 is the count value in binary n^2 where the divide integer ratio is 45857 instead of 44856. Since the LSB =1, it means every 2nd count toggles until 101 seconds then the divider choice is toggled for the next 1pps count. This is repeated to choose which divider is used for the next second, then increment pointer, until pointer reaches end and wait for next 1pps earth clock.

• This process is repeated for the entire count of this rotated binary residue or 10101111>11110101= 245 seconds so that a fractional N synth divider of 1pps Mars time is created every second with corrections made every 245 sec cycle to stay on time. for long term.

-perhaps floating point divider ratio for clock is easier.

You can fairly trivially solve this in software without changing the hardware at all (though you might want a more stable reference frequency), by using binary fractions, and you can do it in a way that gives you millisecond resolution and can easily be made free enough of cumulative conversion errors to let you see the fundamental accuracy of any source you could reference it to, including an atomic clock.

What you would do is modify your timer interrupt to accumulate into a very wide register, and on each interrupt add a fairly long value that is as precise a representation of the ratio of an Earth millisecond to a "Mars millisecond" as you desire.

Let's say for sake of argument that you wanted a 32-bit resolution for the conversion. You could use a 64-bit accumulator, with the lower 32 bits representing the fraction What you would do is figure out the appropriate value, slightly less than 2^32, which represents the conversion factor. Each time your Earth millisecond interrupt fires, you add this value to the accumulator. Any time you want to query the clock, you return the upper 32 bits, which is the number of whole Mars milliseconds elapsed, while the lower 32 bits are only preserved internally to avoid rounding error.

Using long binary fractions like this allows you to perform a conversion with as much accuracy as you desire. 32 bits is almost certainly too long for the fraction, while 32 bits for the whole milliseconds may be too short, but you can adjust as desired.

Incidentally, this technique of accumulating in a long register but only reporting some number of most significant bits is how direct digital synthesis can produce extremely high frequency resolution.

You could also consider doing part of the conversion by changing the ratio of the divider from the 8 or 16 MHz system clock to the millisecond interrupt, moving it closer to the interval of a "Mars millisecond". Especially if you want something more accurate than a cheap crystal you may be dealing with a customary 10 MHz reference disciplined by a GPS or more directly by an atomic clock, so you could substitute that for the usual AVR 8/16 MHz clock source and recalculate divider ratios accordingly.

The direct digital synthesis (DDS) or Numerical Controlled Oscillator approach is quite a simple way to get any desired level of resolution of an output frequency with no dependence on the clock frequency.

In this approach you have a high resolution phase accumulator. Every loop around you add a phase increment which also has fine resolution. The output is the highest bit of the accumulator.

When using it to give a squarewave, the edges are can only change with the input clock (or software loop rate), so the edge jitters from where it should be, but over time, there is no cumulative error -you can make resolution as high as you want.

You can do it in software quite easily (e.g on AVR), and some micros now have NCO hardware. http://ww1.microchip.com/downloads/en/AppNotes/90003131A.pdf A small PIC could do this in hardware with 20bit (1ppm) resolution, from a 32kHz xtal, or from an accurate 10MHz oven.

Look into getting an ovenised custom quartz crystal running at some integer multiple of your desired frequency. They don't cost much more than a standard frequency. Websearch "custom quartz crystal"