Lars DIY GPSDO with Arduino and 1ns resolution TIC

[bingo600]

https://wenzel.com/library/time-frequency-articles/waveform-conversion-part-i-sine-to-square/


/Bingo

[Johnny B Good]

 Some sine wave OCXOs produce a distorted (and jittery) output if you don't terminate them right across the output and ground pins with a resistor that approximates to their output impedance as I eventually discovered with a set of CQE 10MHz OCXOs (DOC1478 - exactly the same as used by Symmetricom).

 I'd previously run a very basic impedance test on the 6 spare ones I had to hand and 'measured' Zo values ranging from a low of 74 to a high of 90 ohms. I compromised and soldered a 100 ohm resistor across the output pins which cured the peculiar jitter on the output of the 74HC14 Schmidt trigger gates I'd not been able to eliminate by adjustment of the 5K bias trimpot feeding the input via a 33K ohm resistor.

 Once I'd added the 100 ohm terminating resistance, I was able to get a jitter free 1:1 ratio square wave to feed the divide by 100 stage feeding the PLL and the buffer circuit driving the LPF feed to the 10MHz out BNC socket.

 I'd only noticed this 'distorted sine wave' output from the OCXO itself when I probed it with my DSO. I'd checked it and its siblings early on and hadn't noticed this issue the first time round (AFAICR, they'd all looked like perfect sine wave outputs) but when I retested the rest of my "Fleet", they all showed the same effect. I can only assume I must have had some sort of resistive loading in circuit the first time round.

 Coincidentally, I'm testing the Vref voltages on my spares right now to pick a replacement for the one in my updated James Miller version GPSDO after seeing the EFC voltage wandering up and down between a low of 2.282 and a high of 2,287 volts over the past week or two with an unexpected excursion to 2.288 volts and a sudden plummet to 2.243 after drumming my fingers on top of the GPSDO just prior to inverting it to apply the full 2G tipover treatment. The output shifted some 2 or 3 cycle's worth against my RFS before the PLL output caught up and restored stability, eventually settling at 2.2865v where it had been hovering about +/- 0.5mV an hour or so earlier.

 Despite it responding as expected to the next 2GT effect test with no weird response to my finger drumming vibration test, I've decided to change it out since its ageing trend has been so dominated by these up and down excursions, it's been impossible to determine whether it is following an ageing trend of any sort.

 The 13MHz CQE OCXO I'd used in my MK I had exhibited a positive EFC aging trend of around 1mV per week within the power off/power on induced retrace events where the EFC would slowly drop to a mV or two below the previous high tide value before getting back on track and resume its upward trend a day or two later.

 Although I'm mindful of the possibility of it being an intermittent fault elsewhere, I'll go after the most likely culprit and swap out the OCXO first before trying to prove the existence of an intermittent fault that may or may not actually be present. It's not the easiest of components to swap out but I have to start somewhere.

John

[thinkfat]

Some sine wave OCXOs produce a distorted (and jittery) output if you don't terminate them right across the output and ground pins with a resistor that approximates to their output impedance as I eventually discovered with a set of CQE 10MHz OCXOs (DOC1478 - exactly the same as used by Symmetricom).

 I'd previously run a very basic impedance test on the 6 spare ones I had to hand and 'measured' Zo values ranging from a low of 74 to a high of 90 ohms. I compromised and soldered a 100 ohm resistor across the output pins which cured the peculiar jitter on the output of the 74HC14 Schmidt trigger gates I'd not been able to eliminate by adjustment of the 5K bias trimpot feeding the input via a 33K ohm resistor.

 Once I'd added the 100 ohm terminating resistance, I was able to get a jitter free 1:1 ratio square wave to feed the divide by 100 stage feeding the PLL and the buffer circuit driving the LPF feed to the 10MHz out BNC socket.

 I'd only noticed this 'distorted sine wave' output from the OCXO itself when I probed it with my DSO. I'd checked it and its siblings early on and hadn't noticed this issue the first time round (AFAICR, they'd all looked like perfect sine wave outputs) but when I retested the rest of my "Fleet", they all showed the same effect. I can only assume I must have had some sort of resistive loading in circuit the first time round.

 Coincidentally, I'm testing the Vref voltages on my spares right now to pick a replacement for the one in my updated James Miller version GPSDO after seeing the EFC voltage wandering up and down between a low of 2.282 and a high of 2,287 volts over the past week or two with an unexpected excursion to 2.288 volts and a sudden plummet to 2.243 after drumming my fingers on top of the GPSDO just prior to inverting it to apply the full 2G tipover treatment. The output shifted some 2 or 3 cycle's worth against my RFS before the PLL output caught up and restored stability, eventually settling at 2.2865v where it had been hovering about +/- 0.5mV an hour or so earlier.

 Despite it responding as expected to the next 2GT effect test with no weird response to my finger drumming vibration test, I've decided to change it out since its ageing trend has been so dominated by these up and down excursions, it's been impossible to determine whether it is following an ageing trend of any sort.

 The 13MHz CQE OCXO I'd used in my MK I had exhibited a positive EFC aging trend of around 1mV per week within the power off/power on induced retrace events where the EFC would slowly drop to a mV or two below the previous high tide value before getting back on track and resume its upward trend a day or two later.

 Although I'm mindful of the possibility of it being an intermittent fault elsewhere, I'll go after the most likely culprit and swap out the OCXO first before trying to prove the existence of an intermittent fault that may or may not actually be present. It's not the easiest of components to swap out but I have to start somewhere.

John

That's very interesting. I've been looking at the output of my GPSDO with my DSO running an FFT, I use a sine wave OCXO (brand new Taitien NA-10M-2503 bought via Digikey) and I generate the 10MHz output by first squaring up the OCXO, then feeding it into a 74AC04 and from there into a low pass filter to get back to a sine wave. I noticed a very, very slight "hump" in the spectrum, at +/- 1.6MHz off of the carrier and down around -95dBc. At first I suspected an amplitude modulation through the power distribution network, but it turned out it came out of the sine-to-square block already, so it was a phase modulation, not AM, in other words jitter.

The OCXO is not terminated properly, its output more or less goes directly into a tank circuit and from there into a biased inverter gate. Now that you mention jitter I'll try adding some termination resistor on the PCB, the OCXO data sheet says the output impedance is 50 Ohms, so that's what I'll add. I'll see if that noisy hump is gone afterwards.

[thinkfat]

Gave it a try and soldered a 49.9 Ohm resistor between ground and OCXO output. It did improve the situation somewhat, the phase modulation is attenuated a bit more, it's now almost down in the noise. The output gained a few more harmonics, though, but that is not really a concern.

[Miti]

Well, I was partially wrong about how the 10MHz is generated in the Ublox modules but I think the statement that the jitter is independent of the output frequency, is valid, but please correct me if I'm wrong. The 10MHz is made of three types of pulses, all multiple of the 20.833ns, the period of the 48MHz internal clock of the module. One is 5 x 20.833ns with a duty cycle of 60%, a 5 x 20.833ns with a duty cycle of 20% and one with 4 x 20.833ns with a duty cycle of 50%, at least that's what I see on the scope. These must be combined in such a way that in the end, there are 10 million pulses in a second. So since the source of the jitter is the same for the PPS and for the 10MHz, the jitter of the rising or falling edge must be the period of the 48MHz clock. Is my logic correct?
Also, 1MHz and 100KHz seem to follow the same logic, the jitter seems to be the same. In my case it is about 22ns, probably the signal level is not ideal.

[cncjerry]

Some ocxos cant drive 50 ohms directly; some require it.  Good example is my HP 10811.  It likes a 50 ohm load.  I get a larger signal with a high impedance load but the signal is cleaner with 50ohms.

Check your DSO setting If you see a large change when probing to make sure you dont have it in 50ohm mode with a high impedance probe on it. 

Something else to consider.  If you are using an oscillator that has 1PPS output in addition to 10Mhz, some Rubidiums are like that, make sure it is divided down from the oscillator if you plan to use it in timing, as it will be more stable, generally.  At least that is my findings.  I tested my X72 PPS output vs the 10Mhz divided down with a wentzel two transistor followed by a PICDIV chip. So if you plan to provide 1PPS output from your GPSDO package, I suggest you divide it down from the disciplined oscillator like that.  Or provide both.

[thinkfat]

Some ocxos cant drive 50 ohms directly; some require it.  Good example is my HP 10811.  It likes a 50 ohm load.  I get a larger signal with a high impedance load but the signal is cleaner with 50ohms.

Check your DSO setting If you see a large change when probing to make sure you dont have it in 50ohm mode with a high impedance probe on it. 

Something else to consider.  If you are using an oscillator that has 1PPS output in addition to 10Mhz, some Rubidiums are like that, make sure it is divided down from the oscillator if you plan to use it in timing, as it will be more stable, generally.  At least that is my findings.  I tested my X72 PPS output vs the 10Mhz divided down with a wentzel two transistor followed by a PICDIV chip. So if you plan to provide 1PPS output from your GPSDO package, I suggest you divide it down from the disciplined oscillator like that.  Or provide both.

50 Ohm for this particular OCXO might be a bit too harsh, though the data sheet says the output impedance is 50 Ohms, the signal quality definitely isn't great. The data sheet specifies the 3rd harmonic with < 30dBc, it still keeps this spec, but that's not very demanding.

Regarding the 1PPS output: not enough to just divide down the 10MHz, you also need to align the pulse to UTC top-of-second.

[Mike99]

Same thing with your 10Mhz input.  Square it up if needed using a two-transistor or other circuit from Wentzel.

For those who like to experiment, here are a couple more ways to do it:

http://www.ko4bb.com/getsimple/index.php?id=clock-shaping

Mike

[Johnny B Good]

Gave it a try and soldered a 49.9 Ohm resistor between ground and OCXO output. It did improve the situation somewhat, the phase modulation is attenuated a bit more, it's now almost down in the noise. The output gained a few more harmonics, though, but that is not really a concern.

 I'm glad to hear my observation regarding the need to terminate some types of OCXO came in useful for you.

 From my own experiments with frequency injection locking with my collection of CQE 10MHz OCXOs, I'm guessing that most of these sine wave output types are unbuffered, presumably to keep phase noise performance as high as the end user can achieve with careful design of the circuitry it will be driving into. Appealing to the OCXO manufacturer on the basis of "It's not our problem chum, it's yours! (to deal with as you see fit)".

 Trying to figure out the best route to inject my reference frequency into these OCXOs eventually proved to be via the output pin rather than via the Vref or EFC pins (I had even considered the Vcc pin) in the hope that sufficient energy would 'pollute' the oscillator circuit in order to obtain a result that's often all too easy to achieve by accident of bad circuit layout.

 In my case, I suspect the absence of the expected loading had caused the oscillator to overdrive itself into saturation and recover every other cycle, hence the distinct 2ns jitter on the edges before and after the triggered edge (and every alternate edge before and after).

 I never did ever track down any datasheets for any of the CQE OCXOs, hence my playing safe with my very first 13MHz cmos square wave acquisition by powering it off a 5 volt rail on the off chance of it being a 5 volt only part that would otherwise emit its magic smoke when subjected to a 12v rail. When I purchase my first three of the 10MHz units of the seven in total I landed up buying, I felt I could afford to risk a fiver's worth of OCXO on a 12v test.

 Although the original 13MHz unit looked physically identical (and drew the same 280mA initial warm up current which for the 12v 10MHz units remained the same regardless of whether they were being powered from a 5 or 12v rail), I decided to stick with a 5v setup in the very first (MK I) GPSDO just to keep to a single power rail and prove I could create a 10MHz GPSDO using a 13MHz OCXO 'just because I could'.

 Anyway, the upshot of all that being that I can only guess that the recommended loading impedance, despite my basic output impedance testing showing a range from 74 to 90 ohms for the 10MHz units, is likely to have been the classic 50 ohm figure. The output of a signal source in a unidirectional system is more or less irrelevant with regard to matching a load provided the load matches whatever the chosen impedance of its connecting length of transmission line happens to be.

 In the absence of any meaningful length of transmission line, the choice tends to be a little more arbitrary and since the "transmission line" in my case consisted of 15mm or so of a wire link, largely comprised of a 1nF capacitor and 150 ohm resistor in series, I compromised by using a 100 ohm resistor directly across the output pins in order not to bog down the 1.5v pk-pk sine wave output feeding the input of a 74HC14 inverter driving the 74HC390 and another inverter driving the remaining 4 inverters feeding the 10MHz LPF through 150 ohm resistors.

 They were all dc coupled so I could use the one bias trimpot to optimise the effective switching threshold for the 10MHz output buffer stage which was ac coupled to the LPF. I'd added an extra 1.6uH 10MHz peaking inductor across the middle cap in the classic 5 element Butterworth LPF which also neatly ties the filter to the ground reference point.

 BTW, I did swap the OCXO out that evening and had it up and running for initial tests after checking the 'other usual suspects' I'd had in mind as possible contenders for the sudden EFC transient and 3% phase shift in the PLL's 100KHz input that I'd provoked with my finger tapping test.

 However, after letting the EFC voltage settle to its new value of 2.4210, I did another finger tapping test and got an unpleasant surprise as it suddenly shifted half a cycle or so at 10MHz before stabilising. It hasn't responded to the many vibration tests  over the past two days since, so I suspect I may simply have relieved some pent up stress in the "Stress Compensated Cut" crystal inside my "NOS" OCXO. I guess only time will tell but apart from that little 'surprise', it seems to be behaving itself just fine.

 The EFC has dropped another 8mV and I'm expecting it to come to a halt and start going up again based on my previous experience with the 13MHz unit. I'm assuming that the 13MHz unit's retrace behaviour is typical - it may well not be. I'm just going to have to keep my eye on the EFC voltage (as I normally do) for the next few days and see what happens before I start running any power cycle tests.

John

[Johnny B Good]

 Just a quick update on my OCXO swap out "repair".

 In the intervening 6 days since my previous post, the EFC has dropped by another 3mV with still no sign of it "bottoming out". It's now hovering around the 2.4097 to 2.4100 volt mark. The reducing EFC trend has slowed down but there is still no sign of any reversal as I'd experienced with the 13MHz "Five Volt" OCXO (which btw, did well and truly prove itself to be a 12 volt unit after all!).

 I could simply be observing an upward frequency ageing effect (reducing EFC voltage) that will continue unabated, albeit one that gets slower and slower over time. Also worth noting is that thus far, I've not been able to provoke any more frequency jumps with my finger tapping vibration tests - so far, so good (until it isn't).

John

[MIS42N]

I wished I'd looked at this forum some years ago. I have designed a low cost GPSDO, really to see just how basic a functional system can be. The cost of the prototype was less than $20 AU (excluding power supply - from the bit box). I use a different approach to most designs, basically (1) the microprocessor uses the oscillator output as its clock (2) the output PWM providing the control voltage is dithered (mark/space ratio varied by 1 bit) every 250uS which, averaged over less than a second gives equivalent of 24 bit DAC (3) correction to the control voltage is calculated and applied at intervals, small deviations of the input 1ppS have no effect. The results of the prototype are modest, to be expected as it is a very basic circuit making no attempt at refinement. However the software is written to be dynamic and my next prototype will try to use the same software in a more sophisticated circuit to prove the point. Software is written in PIC assembler, not sure if it could be done any other way but my bent is writing software. The averaging algorithm uses 32 bit signed arithmetic to calculate a linear least squares fit of the 1ppS information to derive an average. The minimum averaging period is 5 seconds, the maximum is 2048. Correction is applied if the average deviation exceeds a dynamic limit (the more measurements made, the more reliable the average becomes. It is actually beneficial to work with a GPS having some jitter!)

The actual performance varies between about 3 x 10^9 frequency deviation to 3 x 10^10. There are a number of factors - (1) poor viewing - the GPS doesn't see much of the sky (2) the power supply is a switch mode 5V supply of unknown quality, originally powering a superseded piece of equipment (3) the oscillator was chosen on price rather than performance. The next prototype will address all of these - (1) using an external antenna to acquire a better signal (2) control voltage to be derived from a MAX6350CPA+ Voltage Reference (3) oscillator to be a Morion MV89. Items on order at the moment.

I've attached the circuit. It omits the 5V supply and 2 bypass capacitors. The actual circuit has the 3 active components, power supply, 6 capacitors, 4 resistors, 1 LED. Can it be simpler than that?

[Mike99]

I'm confused and need some advice please  .

I have aged my "new old stock" Vectron OCXO for 2 months, improved the location of my outdoor GPS antenna and surveyed-in the accuracy of my NEO-M8T to 0.75 metres.

Now I'm trying different time constants for the GPSDO and when I plot the MDEVs they appear to be upside down compared to what I've seen on here. The stability is gradually getting worse.

Here's one such plot, together with graphs from the log. Time is measured in seconds from when it acquired lock.

Any suggestions please?

Mike

[Mike99]

There are a number of factors - (1) poor viewing - the GPS doesn't see much of the sky

This is crucial, as I discovered. I bought an NEO-M8T timing receiver thinking I would get a stable 1pps with my active antenna on the house wall under the eaves. It was facing north and could see less than half the sky, but I thought having 12 good satellite signals would be OK - wrong! The best positional accuracy I could get was 8 metres and the M8T requires 1 metre or better for a stable timing signal.

I extended the mounting bracket to give the antenna an overhead view of the sky and the difference was dramatic. It didn't bring in many more satellites but the accuracy improved to 0.75 metres.

Here are pictures of the before and after antenna mounts.

Mike

 

[thinkfat]

I'm confused and need some advice please  .

I have aged my "new old stock" Vectron OCXO for 2 months, improved the location of my outdoor GPS antenna and surveyed-in the accuracy of my NEO-M8T to 0.75 metres.

Now I'm trying different time constants for the GPSDO and when I plot the MDEVs they appear to be upside down compared to what I've seen on here. The stability is gradually getting worse.

Here's one such plot, together with graphs from the log. Time is measured in seconds from when it acquired lock.

Any suggestions please?

Mike

There's still a fair amount of drift visible in the DAC data. The MDEV result reflects that. Your TIC data looks good, though. Nothing to worry about.

You have roughly one day of data in your logs (close to 80,000s ?)  What you see might be a diurnal effect due to temperature changes. Plot the temperature data alongside and see if there's a correlation.

Apart from that, let me repeat: the DAC data tells you a lot about your overall system, and only very little about your output stability and accuracy.

The only independent reference you have is the GPS, so plot the TIC data instead, properly scaled (times 1e-9), imported into TimeLab as phase data. For larger "tau" you'll see it approaching the 1e-13 ranges. You have enough data to see tau=20000. MDEV should approach and maybe cross the 1e-12 line and maybe even get into high 1e-13 territory.

There are a number of factors - (1) poor viewing - the GPS doesn't see much of the sky

This is crucial, as I discovered. I bought an NEO-M8T timing receiver thinking I would get a stable 1pps with my active antenna on the house wall under the eaves. It was facing north and could see less than half the sky, but I thought having 12 good satellite signals would be OK - wrong! The best positional accuracy I could get was 8 metres and the M8T requires 1 metre or better for a stable timing signal.

I extended the mounting bracket to give the antenna an overhead view of the sky and the difference was dramatic. It didn't bring in many more satellites but the accuracy improved to 0.75 metres.

Here are pictures of the before and after antenna mounts.

Mike

 

If you're on the northern hemisphere, an antenna facing north is the worst option. The further north you are, the less satellites you will have available. Find a spot with at least some visibility towards the south. A window facing to the west or east is not too bad in a pinch.

[Gerhard_dk4xp]

This is crucial, as I discovered. I bought an NEO-M8T timing receiver thinking I would get a stable 1pps with my active antenna on the house wall under the eaves. It was facing north and could see less than half the sky, but I thought having 12 good satellite signals would be OK - wrong!

Free sight to the north does not bring a lot. Looking at the map displayed
by Lady Heather, you see that the sats don't go that far north.

http://www.ke5fx.com/heather/readme.htm

cheers, Gerhard

[Mike99]

There's still a fair amount of drift visible in the DAC data. The MDEV result reflects that. Your TIC data looks good, though. Nothing to worry about.

You have roughly one day of data in your logs (close to 80,000s ?)  What you see might be a diurnal effect due to temperature changes. Plot the temperature data alongside and see if there's a correlation.

Apart from that, let me repeat: the DAC data tells you a lot about your overall system, and only very little about your output stability and accuracy.

The only independent reference you have is the GPS, so plot the TIC data instead, properly scaled (times 1e-9), imported into TimeLab as phase data. For larger "tau" you'll see it approaching the 1e-13 ranges. You have enough data to see tau=20000. MDEV should approach and maybe cross the 1e-12 line and maybe even get into high 1e-13 territory.

Thank you, that's just the nudge I needed to make some sense of it  .

Here are the plots you suggested. The GPSDO is enclosed in a box but the OCXO is not insulated yet and I'm not using temperature compensation (understanding that will be another question later on  ).

Mike

[Mike99]

Free sight to the north does not bring a lot. Looking at the map displayed
by Lady Heather, you see that the sats don't go that far north.

http://www.ke5fx.com/heather/readme.htm

cheers, Gerhard

Apologies I suffered from a brain fade. The antenna is facing east.

Mike

[dl6lr]

If you're on the northern hemisphere, an antenna facing north is the worst option. The further north you are, the less satellites you will have available. Find a spot with at least some visibility towards the south. A window facing to the west or east is not too bad in a pinch.

Yeah, this is my coverage, still a test setup and has to be improved with a timing antenna mounted in a better position.

The satellites dont go much further north, this is 53.7N

[MIS42N]

Yes I found the view of the sky is important. This is not my first GPSDO, the previous one had an external antenna, but lived in the garage. If I had to update the software the CPU was pulled out, put in the programmer in the house, then back out to the garage. This one is still being refined but I am using in circuit programming permanently connected to the computer so it is in the house running off an antenna next to a window. Wonderful for rapid development but woeful for stability. I think I've nailed the control system, the refinements are to the "user interface" i.e. what the one LED is doing, and what gets logged via the serial port. I am trying for the most basic system that is still usable. So far the LED does single flash at startup, external oscillator working. Fast flashing at startup, running off internal oscillator because no external oscillator. If on external oscillator will go dead until NEMA messages are being decoded (usually a second or two) then at two second intervals flash the satellites in view. One long flash, none. One short flash, 1-3. Two flashes 4-9, three flashes 10 or more. Once the NEMA messages says the data is valid then the system enters run mode, which is where the current refinement is needed. At present it is a short flash for each valid 1ppS (received and NEMA says valid) but no indication of lock. Getting there.

[Johnny B Good]

Yes I found the view of the sky is important. This is not my first GPSDO, the previous one had an external antenna, but lived in the garage. If I had to update the software the CPU was pulled out, put in the programmer in the house, then back out to the garage. This one is still being refined but I am using in circuit programming permanently connected to the computer so it is in the house running off an antenna next to a window. Wonderful for rapid development but woeful for stability. I think I've nailed the control system, the refinements are to the "user interface" i.e. what the one LED is doing, and what gets logged via the serial port. I am trying for the most basic system that is still usable. So far the LED does single flash at startup, external oscillator working. Fast flashing at startup, running off internal oscillator because no external oscillator. If on external oscillator will go dead until NEMA messages are being decoded (usually a second or two) then at two second intervals flash the satellites in view. One long flash, none. One short flash, 1-3. Two flashes 4-9, three flashes 10 or more. Once the NEMA messages says the data is valid then the system enters run mode, which is where the current refinement is needed. At present it is a short flash for each valid 1ppS (received and NEMA says valid) but no indication of lock. Getting there.

 An unobstructed all round sky view is very important for getting the best results out of any GPSDO setup.

 The first 5 images, attached below, show a series of u-centre sky maps after upgrading my best M8N fake module to a genuine M8T. The first is the last of a series where I'd followed the perceived wisdom of sticking to just a single constellation (GPS in this case) with the remaining four showing the GPS and Galileo constellations after I'd run tests to compare the discrepancy of the time-pulse arrival times (indirectly in my case) between the GPS and the Russian Glonas (18ns) and then the European Galileo (2 or 3 ns) constellations.

 Whilst the Russian SVs offer an extra 2dB boost over the GPS signal strengths and shrink the hole in the northern sky, the larger discrepancy in the timepulse does seem to compromise the performance of the GPSDO (a modern respin of the James Miller design BTW), the Galileo constellation having more closely aligned time pulse seemed to offer an improvement so I decided to leave it setup that way for a day or two before deciding whether to stick with the perceived wisdom of using only a single constellation for best results or carry on and gain more reliable coverage out of an increased elevation filter mask  angle of 30deg.

 After finally getting the M8T to complete a survey in operation (I'd had to slacken my optimistic 10cm variation setting to 17cm to force it to complete the process), I'd finally been able to prove I could still get valid timing data from just a single SV alone and had initially set the elevation filter mask to 42 deg. However, with just GPS SVs, I could be left with only a single SV above the elevation mask angle setting which was a little worrying since the M8T could land up seeing only a single GPS SV that could quite easily be one marked out of service, hence a loss of 'lock' and my lowering the elevation mask setting to 30deg to avoid such an eventuality.

 Adding the Galileo SVs into the mix considerably reduces the risk of having only out of service SVs above the elevation mask angle setting. Since there doesn't seem to be any degradation of timing stability over that of using only the GPS SVs alone, I've stuck with that configuration ever since.

 One of the main issues with using a navigation centric GPS module like the M8N in a DIY GPSDO (whether it's a "basic" James Miller design or a properly built and configured Lars type) is the subsonic (3mHz or so) 30 to 50ns phase modulation due to the effects of the ionosphere on propagation delay. Switching to the M8T reduced such subsonic phase modulations by around an order of magnitude (a 5 to 7 ns pk to pk phase shift around the nominal 10MHz output frequency of the GPSDO).

 For a very long time, I'd been trying to more accurately quantify this subsonic 'phase wobble' by using the 2G tipover effect to fine tune the OCXO in my much modified FY6600-60M AWG to simulate the stability of a RFS for an hour or two given a stable room temperature. All this "micro-management" effort eventually 'broke me' into spending almost 200 quid on an Efratom LPR101 some two months ago (not quite soon enough to test the MK I GPSDO with its M8N receiver module) and I've since been able to verify my initial guesstimate of 6 to 7ns Pk-Pk subsonic phase modulation using the M8T in the MK II design I'm currently running. One of these days, I'll resurrect that MK I on a solderless breadboard lashup to confirm my 30 to 50ns subsonic phase wobbles guesstimate .

 Anyway, all of that is by way of a preamble to what the next 17 images are demonstrating (take note of the date/time shown in the bottom RH corner). I started that test run at 21:30 and only thought to start capturing screenshots some 16 minutes later. Although the sequence covers a span of 110 minutes, the whole run time amounted to 121 minutes before I quit due to the dropping room temperature resulted in a drift of frequency in the RFS which I have yet to mount into a thermostatically controlled enclosure.

 CH1 is the 'wobbly' GPSDO output. CH2 is the AWG proxy for the more stable RFS which I'm triggering from to emphasise that I'm looking at the way the GPSDO is wobbling compared to an atomic reference free of the ionospheric effects afflicting the GPSDO.

 Holding an independent frequency reference to within a nanosecond or two of the average frequency of a GPSDO for more than an hour at a time is a very tall order even for a temperature (and pressure) stabilised Rubidium oscillator, never mind my own setup at the mercy of room temperature variations.

 Even so, I had to make good use of the FY6600-60M's external reference feature that allowed me to fine tune the RFS output in uHz increments by using the AWG as its proxy to save wearing out the RFS's trimpot. I won't be trying to fine tune the RFS any further until after I've got it safely housed in its own thermostatically controlled enclosure - the use of the AWG as a proxy, is a rather neat way to get round this, hopefully temporary, situation.

 Although my initial motivation for the RFS purchase had been to provide a secondary atomic standard reference, free of the destabilising effect of the ionosphere (and by an order of magnitude less, that of the troposphere) on GPS (GNSS) derived timing and frequency standards by which to quantify these deficiencies built into the GPS/GNSS systems, I do plan to ultimately use it in this Lars based design (or something very similar).

 As most of you seem to be discovering, this business of disciplining an OCXO against the flawed timing and frequency reference of a GNSS based time and frequency transfer setup, has rather too much of the "Catch 22" element to be truly trustworthy.

 Even the best DOCXOs can "go rogue" from time to time and any microcontroller based setup, based on the assumption that the only variables are OCXO ageing and the effects of the ADC's tempco is almost certain to fall foul of the unpredictable behaviour of the OCXO (and room temperature on critical internal voltage rails). I plan to be as fully cognisant of the many factors that can trip up such microcontroller based solutions. Using the Lars design to control an RFS should let me neatly bypass the "rogue OCXO" issue (effectively cheating the limitations of an OCXO based solution and taking full advantage of the extremely long time constants that can be realised using a microcontroller )

 If you haven't already tried building a basic GPSDO and examined its limitations in some detail before embarking on this Lars DIY GPSDO project, you're going to leave yourself at a disadvantage. The attached images should help demonstrate the limitations of a GPSDO based on a single frequency timing receiver. You can cheat the worst limitation by spending 200+ quid on a ZED9 module which should eliminate the ionospheric effects, leaving you just the tropospheric moisture content mediated errors to contend with (about an order of magnitude less than the ionospheric effect).

 I've just hit the new reduced from 25 to 10 attachments limit (along with the reduced from 5000KB to 4000KB individual size - not an issue in this case). It seems I'll have to make another two supplementary posts to send all 22 images (1.9MiB in total).

John

[Johnny B Good]

Another ten images

[Johnny B Good]

Last two images

[MIS42N]

Even the best DOCXOs can "go rogue" from time to time and any microcontroller based setup, based on the assumption that the only variables are OCXO ageing and the effects of the ADC's tempco is almost certain to fall foul of the unpredictable behaviour of the OCXO (and room temperature on critical internal voltage rails). I plan to be as fully cognisant of the many factors that can trip up such microcontroller based solutions. Using the Lars design to control an RFS should let me neatly bypass the "rogue OCXO" issue (effectively cheating the limitations of an OCXO based solution and taking full advantage of the extremely long time constants that can be realised using a microcontroller )

I don't know if I am missing something somewhere, but the majority of designs I've seen use a phase locked loop in hardware or software. I thought this is a flawed approach because the OCXO has to follow deviations of the GPS signal to some extent. A short time constant catches the rogue but wobbles about. The long time constant wobbles less (but still does to some extent) but can't catch the rogue. The approach I use is to let the OCXO 'free run' with a fixed control voltage and collect the second to second deviations of the 1ppS from expected. The particular design I outlined above measures arrival to within 25nS and the software attempts to steer the OCXO such that half the 1ppS arrive early and half late on average. The arrival times are averaged using least squares linear interpolation to arrive at an estimated deviation from desired, and if this is too great a correction is applied to the control voltage to reverse the drift. The calculation is done every second from 5 to 8 seconds, then every 2 seconds from 10 to 16, every 4 seconds from 20 to 32 and so on up to every 256 seconds from 1024 to 2048 seconds. If the OCXO is still within limits a correction is applied anyway (unless there is no deviation at all).

As the calculation period extends, the allowable deviation is reduced. This presumes that the statistical average of many measurements is more accurate than one measurement. This tactic catches rogue events, and for changes of less than 1Hz will adjust the control voltage accordingly. That is a programming consideration mainly due to needing more arithmetic precision to cater for huge changes and not lose detail for tiny adjustments.

I had assumed (make an ass of u and me) that the GPS averaged over 2000 seconds would be highly accurate but talk of a 3mHz subsonic wobble worries me. I thought the design of the GPS system was such that this didn't happen - a spatial fix estimated from 3 satellites and compensation applied by using more satellites. The software uses a diminishing error limit, in testing so far (i.e real life) it has managed a few times to run to 64 second testing intervals (which starts after 256 seconds) with a limit of 1/16th cycle deviation. That's getting below 1 x 10^-10 deviation, not bad for such a cheap setup. And that is the intent of this exercise, a usable system with the least components.

Another thing I can't get my head around is Allan deviation. If the phase of the oscillator is locked in the long term to the GPS (mine is), the plot seems almost meaningless except for the first few seconds. Of course the long term plot shows that the oscillator is following the GPS faithfully. Or is there something more meaningful.

Regarding temperature stability, I found this to be the limiting factor with my first attempt. The OCXO was a Morion MV89 and I believe it was not affected by temperature. However, the control voltage was buffered through an op amp and I think it was a problem. Note the current design derives the control voltage directly from the PWM through a fairly low resistance network. For the next effort I intend to buffer this through a 2N7000 BF250 (I think that's the one) pair, sourcing their voltage from a MAX6350CPA+ which claims to be stable to 1ppm/C. I have the MAX6350CPA+ on order, costs more than all the components of the circuit above put together. We shall see.

[Johnny B Good]

@MIS42N

 That issue with subsonic phase shifts due to ionospheric disturbances is the main (and inescapable) problem with GNSS based GPSDOs relying on single frequency receivers regardless of whether they're microcontroller based or a simple hardware PLL setup. Dual frequency GPS timing receivers such as that ZED9 I mentioned can all but eliminate the ionospheric errors but that still leaves the effect of the precipitable moisture content in the troposphere (rain clouds?) which, fortunately is about an order of magnitude lower.

 Given a long enough time constant and a stable enough oscillator (a DOCXO or a RFS), it becomes possible to average out these short term perturbations. If you can average over a full 24 hour period, you can get very close to the 1E-14 limit of the GNSS ground based master clocks. This is where a microcontroller based system using Kalman filtering comes into its own but care has to be taken to account for every contingency that the traditional basic hardware PLL designs can effortlessly take in their stride (at least over time constants in the range 100 to 5000 seconds, given a stable enough oscillator to discipline).

 When it comes to disciplining a RFS, a microcontroller based solution is the only viable way to obtain the full benefit which is why I'm keeping a close eye on this topic thread. I'm not sure why a 3mHz 6 to 7ns wobble should be a worry since that represents a cycle time between a pk to pk excursion and back of around 5 minutes or so. It's rather random in nature but the higher frequency components of this phase wobble have much lower amplitude and the lower frequency components disappear into the 'noise floor' of the system anyway.

 They're only a problem when you're trying to calibrate a free running 10MHz OCXO in less than half an hour or if you plan on using it as a reference to drive transverters beyond the 1GHz mark to operate in the microwave bands using slow data rate narrow band digital communication modes. Slow rate 5Hz deviations of carrier frequencies can be readily tolerated when using SSB voice communications, allowing operation in this case up to 10GHz and beyond.

 Choosing the optimum time constant depends entirely on the stability of the oscillator's behaviour. You might expect an OCXO to be pretty immune to external temperature variations but once you start chasing after parts per trillion accuracy, you soon discover the effect of temperature on the humble OCXO leaving you hankering after a high quality DOCXO upgrade or even a suitable RFS.

 You mentioned the expense of a good voltage reference (MAX6350CPA+) so, despite the fact that you've already got one on order, I think it's worth considering the temperature stabilised voltage reference available from the better quality OCXOs which provide this on their Vref pin. Even if this comes from a humble LDO supplying the oscillator and the oven controller, it's worth considering that, once warmed up to temperature, it's supplying a constant current and its internal reference is temperature stabilised making it only second in stability to that of an expensive lab standard (at least for use with a low constant current external load such as the 1mA of my reference voltage supply).

 I'm taking advantage of the Vref pin on the CQE 12v 10MHz OCXO to provide a DC offset voltage in 1v steps via a string of matched 1K resistors fed via a 120ohm resistor from the Vref pin to allow me to monitor the EFC voltage in tenths of a millivolt using a cheap (13 quid) Mestek 9999 counts meter to measure the 408.7mV difference between the 2 volt tap and the EFC pin, effectively saving me the expense of a 5 1/2 digit bench meter costing around 450 quid. It's not so much the absolute accuracy of this 2v dv offset so much as its stability. The important aspect of this measurement being that I can monitor the variations in 100uV increments and be able to trust that the only changes are due solely to the variation in EFC voltage with very little to none at all from my 2v offset reference.

 I'm only using it as a means of saving the need for an expensive bench meter to monitor the EFC pin voltage but if I needed an extremely stable 5 or 3.3 volt rail to supply a DAC or a buffer to a PWM DAC signal, I could simply use a cheap cmos RRO opamp as a voltage follower to drive sub 50mA loads in this case.

 I've set the buck converter, which allows my GPSDO to run off cheap wallwarts over an input voltage range of 6.8 to 24 volts at 1.4W (warmed up), to output 5.17v onto the Vcc rail. This slightly higher Vcc voltage was chosen primarily to allow a cmos RRO opamp to buffer the EFC input over the range 0.1 to 5 volts but could also allow the use of another such opamp to supply sub 50mA loads at a regulated 5 volt if such a need where to ever arise. In the case of a maximum of 100nA meter current, there simply was no need to buffer the multitapped potentiometer supplying dc offsets in one volt steps (0, 1, 2, 3 and 4 volt taps).

 Any modest dc offsets and temperature drift effects in the buffer amp driving the EFC line are totally irrelevant in a basic hardware PLL controlled OCXO design since the negative feedback mode of such a basic PLL automatically compensates for any such offsets. The only effect visible when I forced the GPSDO to be raised in temperature by some 7 degrees was a modest 1mV drop in the EFC voltage, leaving the frequency output untouched. Undoubtedly the combined effect of an external temperature increase upon the OCXO and changes to the opamp's dc offset causing it to reduce the EFC voltage to maintain lock with the 100KHz output on the PPS line from the M8T module.

 When you're trying to use very long integration times in a microcontroller based design to reduce the phase shift wobbles of the GNSS system, you need to compensate for any such external temperature shifts to maintain stability and this is often easier said than done. However, the rewards for getting this right is not only better performance given a decent oscillator worthy of such effort but also a more effective hold-over performance in the event of loss of GPS lock compared to the more limited hold-over performance, if any, of a basic hardware PLL design.

 Those screenshots I posted represent the actual performance compared to a RFS free of the effects of ionospheric disturbances which effect all GPSDO designs to a greater or lesser degree. In effect it's "a cut to the chase" bypassing all the trivia of Adev and Mdev plots typically used to describe the performance. Basically, it's a "No Frills" representation of how a GPSDO is actually performing, given an accurately calibrated reference. It would be interesting to see how some of these Lars based GPSDOs compare using this same "No Frills" approach.

John

[Mike99]

May I jump in with a quick question about temperature compensation?

I know how to calculate tempCoeff, but what's the best way to establish the number of DAC steps per degC?

I've been studying my logs and can't get a consistent answer.

Thanks,

Mike