AOCJY2 10 MHz OCXO time source

[CommanderLake]

Not sure where to put this so I'll put it here...

So I got me a 5 ppb AOCJY2 10 MHz OCXO purely out of scientific curiosity and so far I have established that my Picoscope oscilloscope is 15.4μs/s slow so now I want to try using it to keep track of time to see how accurate it is in the long term.
I would like to do this using purely logic components such as decade counters and maybe read the tick count divided by 10000 somehow over serial to a PC, I can use a Picaxe microcontroller, any thoughts?

 

[CommanderLake]

I mean if I were to divide 10MHz with 4 decade counters then count the 1KHz pulses even a 16 bit counter would only get to 65.535 seconds so what kind of counter do I need to keep track of time for a long time?

 

[Harald Kapp]

what kind of counter do I need to keep track of time for a long time?

A 32 bit counter or a 64 bit counter?
At 1 kHz the pulses can be easily counted by a microcontroller with the length of the counter almost only limited by the memory of the µC.

I want to try using it to keep track of time to see how accurate it is in the long term.

What are you going to use as a reference that is more accurate than the OCXO? Unless your reference is better than the OCXO by a factor of 10 or more any such experiment is imho little significant. Usually you'd use the OCXO as the stable reference...

 

[CommanderLake]

A 64 bit counter would be nice but I cant find any, maybe I just don't know what to search?
All I'd need is 64 flip-flops and something to read the output pins in theory.

The obvious reference would be an internet time service, there's nothing more accurate than the atomic clocks they use.

 

[Harald Kapp]

A 64 bit counter would be nice but I cant find any, maybe I just don't know what to search?

Use 4 × 16 bit counters in series. E.g. 4 × 74F525 if you want to go discrete no matter what the effort.
A small µC at less than 10 $ can do the job with a little programming. An ESP32 for example comes with a WIFI interface so you can directly get NTP-time and do the comparison on board.

 

[CommanderLake]

The SN74LV8154 can be used as a 32bit counter but even dividing the 10MHz clock by 10000 barely gets to 50 days and I don't see any way of rolling one over to another because it only has a rollover pin for the A counter not the B.
Alternatively I could connect the 10MHz clock directly to the counter and roll over the A counter of 3 of those devices to each other where the last one will have both counters used to get 64bit.

 

[CommanderLake]

So I got the counters I mentioned above in the alternate configuration where package 1 counter A overflows to package 2 counter A overflows to package 3 counter A then B.
I'm using a Picaxe 40X2 μC with an external 16MHz oscillator to run it at 64MHz because its incredibly easy to code for and program, it reads and transmits the 8 bytes (64bit integer) over a serial connection at 76800 baud in about 2ms.

After 12 hours my computers clock has drifted by 1.558 seconds behind while the AOCJY2 10 MHz OCXO has drifted about 0.025 seconds behind using ntp0.linx.net which is a stratum 1 time server as my reference where multiple measurements showed a deviation of up to 1ms.
I was hoping it would be a bit more accurate than 25ms in 12 hours but 63 times more accurate than my system clock is pretty good, maybe there is something I can improve upon somewhere, I know the power supply to the oscillator is very stable.
The USB serial adapter driver has a latency timer that only goes down to 1ms giving me a small amount of variation between measurements so I'm going to try using an RS232 serial port adapter with my motherboards built in serial port to see if that gets more consistent results.

 

[CommanderLake]

Actually I didn't have the control voltage pin connected to anything so I've hooked that up to a 1K trim pot VCC to GND and calibrated it to 1.65v which is half the 3.3v supply right in the center of the adjustment range which is +-700PPB.

 

[CommanderLake]

As it turns out the serial send is instant and only the read is affected by the latency timer which must be polling the serial adapter for incoming data so after comparing my new time source to the HPET in my PC where I get the HPET time immediately before sending the serial request shows a deviation between the two of around 20μS (judging by eye).
With such precision I can see the HPET drift in realtime with continuous updates!

This is just a log of my progress at this point.

 

[CommanderLake]

Now it drifted forward by 6ms in 17 hours so all I have to do is tweak the trim pot on the voltage control pin then wait an increasingly long period of time.

 

[CommanderLake]

I suppose I should post a picture...



Its hard to tell due to the error from inconsistent network latency to the time servers but it now appears to have drifted forward by 2-3ms in about 13.5 hours

 

[CommanderLake]

So far the drift is less than 1ms per day and I've optimized the PICAXE program to the point it takes less than 1ms to read and return the 8 bytes of data, the tricky part was the high speed serial output was occupied by one of the pins connected to the second counter bus so I used a 1k resistor to protect the counter output from the serial output and a tiny ZVN3310A MOSFET to switch the serial output on and off using the last available pin on the PICAXE to control the gate so that other activity on the pin wouldn't create noise on the serial output.
Using a scope to measure, from the moment the PICAXE activates the first pin to begin reading the counters to the end of the transmission of the last byte at 1Mbaud is 685.5μS, I love optimizing things its so rewarding!

 

[CommanderLake]

The problem I'm seeing now is the slightest temperature variation of the trimpot affects the control voltage and therefore the accuracy of the clock so I need some form of voltage source that's not affected by temperature fluctuation.

 

[Harald Kapp]

To be expected.
What's the use of an OCXO with +- 5 ppb stability when you can pull the frequency by +- 0.7 ppm (a factor of +- 140) and then not using an ultra stable control voltage?
As I see it the frequency of the OCXO should be 10 MHz (within tolerances) without control voltage applied. Afaik the control voltage is used in applications where the frequency needs to be adjusted away from the nominal value to track e.g. the frequency of a received signal. I wouldn't expect this to be the case here.

The best voltage references I can find by a quick search are +. 1 ppm or +- 0.25 ppm. These are quite expensive. But as soon as you use a potentiometer to adjust the voltage his precision is lost within the tolerances and the drift of the potentiometer. Even a fixed voltage divider for adjusting the control voltage would have a significant influence using affordable 0.1 % resistors. And don't assume once you have set the required ratio that this will be invariant with temperature: even if the nominal ppm over temperature is the same for both resistors, due to differences in the material and he production the ratio may change with temperature.

As I see it, the only way to fix this would be to include the voltage reference, the divider and the oscillator within one enclosure and heat this assembly to a well regulated temperature. But then again, why use an OXCO if you have to provide your own oven?

 

[CommanderLake]

I assumed it wouldn't need a control voltage but its far less accurate without one, the trimpot I'm using has a 100ppm/C stability, a 10ppm/C one looks to be about £60. Maybe there's some sort of digitally controlled temperature compensating regulator a bit like a TI PGA2310/11 volume control IC which I have used for audio applications.

The trimpot in the picture has a 25ppm/C stability which I replaced with one with a longer track thinking it would be more accurate but I didn't think about the temperature stability so I've put that one back in to see how it goes.

Actually the track resistance affects the output voltage depending on the load so if I use a precision op-amp to virtually eliminate the load on the trimpot maybe that will be more accurate, I have a spare OPA197 I'll try.

 

[CommanderLake]

Putting the trimpot through the OPA197 made a huge difference now its extremely stable over a wide temperature range.

 

[Harald Kapp]

I wonder how this happens.

 

[bertus]

Hello,

I wonder how this happens.

Could it be a load problem of the potmeter.

Bertus

 

[CommanderLake]

The voltage fluctuation of the pot is determined by the load which is 10kΩ on the control voltage input, its basically a voltage divider.

 

[CommanderLake]

If you don't mind me sharing something else I've been working on with the Falstad circuit simulator (yes I know its a childish graphical thing) I came up with a circuit that synthesizes a serial interface which outputs the counter values, its not quite complete it doesn't roll over the counters just for simulation sake and it doesn't have the high order byte of each 16 bit counter but it generates a real inverted serial output with 1 stop bit and 1 clock between bytes...
If you hold the L by "Serial In" for a few clock cycles it will output the signal for all 8 bytes once which can be seen in the middle graph at the bottom: https://tinyurl.com/y2rrmttu