### Author Topic: Lars DIY GPSDO with Arduino and 1ns resolution TIC  (Read 91130 times)

texaspyro, Mike99 and 4 Guests are viewing this topic.

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #250 on: March 29, 2019, 01:23:15 am »
That is explained by Lars very nicely in "What is Lars Arduino based GPSDO Controller page 1-7.pdf", check the first post.
I've also attached a very interesting document to read.

Miti
That big spark at power up was by design!

The following users thanked this post: Theboel

#### Remco

• Contributor
• Posts: 11
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #251 on: March 29, 2019, 02:59:37 pm »
Reading the patent 'diagonally' it seems to be (almost) the same principle
as in Lars' GPSDO?

BTW. I cleaned / simplified some of Lars' code and am now busy with an
algorithm to let the time constant (TC) converge to it's optimal (= maximal?)
value after a lock has been obtained (locking/starting with a lower TC).

« Last Edit: March 29, 2019, 03:29:19 pm by Remco »

#### metrologist

• Super Contributor
• Posts: 1842
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #252 on: March 30, 2019, 02:48:49 pm »
I think there is a much earlier patent on the very concept.

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #253 on: March 30, 2019, 05:00:03 pm »
BTW. I cleaned / simplified some of Lars' code and am now busy with an
algorithm to let the time constant (TC) converge to it's optimal (= maximal?)
value after a lock has been obtained (locking/starting with a lower TC).

Does it calculate the optimum TC or just "converges" to a max value that you determine and program into it?
That big spark at power up was by design!

#### Remco

• Contributor
• Posts: 11
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #254 on: March 31, 2019, 01:14:07 pm »
From what I understand from Lars' philosophy is that the TC is a figure of merit
concerning the quality/stability of the system. In my words, the larger the TC
(where the system stays in lock) the better.

So what I now do, is start with a low TC and periodically (depending on the TC itself)
increase the TC (also depending on the TC itself and the stability of the system given this TC).
Now I use kind of exponential approach .. i.e. lower TC's will be increased less compared to large(r) TC's.

When the system starts to drift away 'too much' (i.e. TC seems too large) the TC
is lowered. The idea is to let the TC 'lock' (like a PLL) to its optimal (= maximal?) value
for a given system/setup and to figure out what 'too much' is.

Also plan to experiment with making the gain relative to the TC. Found out that while in lock
I can reach larger TC's by increasing the gain.
In the current run gain is fixed to 4x the 'h1-h65535' determined gain (which was 135, I took 128 so it's 512 now).

(Intermediate) results are that my system (not T-compensated) can reach TC 1024 (and
even higher, but I clamped it to 1024 cf Lars' comments), stays in
lock for several hours but then ... looses lock. So my challenge is to find a condition
to prevent lock loss.

« Last Edit: March 31, 2019, 01:37:34 pm by Remco »

#### Remco

• Contributor
• Posts: 11
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #255 on: March 31, 2019, 05:35:54 pm »
I use temperature sensors in my GPSDO with OCXO and it makes a big difference.

Yep, just discovered the reason for this. A2 is floating and sampling A2 is almost the same as sampling noise ; -)

In the (current) sketch A2 readings are default taken into account to calculate the DAC value, as a result this
DAC value has intrinsic noise.

Solution for this issue:

2. Connect A2 to ground
3. Fixate A2 readings (which I did for the time being, LM35's have been ordered ; -)

« Last Edit: March 31, 2019, 06:00:22 pm by Remco »

#### Remco

• Contributor
• Posts: 11
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #256 on: April 02, 2019, 02:46:38 pm »
When the system starts to drift away 'too much' (i.e. TC seems too large) the TC
is lowered. The idea is to let the TC 'lock' (like a PLL) to its optimal (= maximal?) value
for a given system/setup and to figure out what 'too much' is.

OK, after some experimenting with the following conditions:

- 'open contraption' (not in a casing yet & OCXO = Bliley)
- no temperature compensation

The GPSDO is ca. 15cm away from my computer mouse.
When I'm behind the computer, the TC varies around 250 +- 80
(depending on my coffee mug with fresh coffee ; -).

When away the TC varies around 500 +- 100.

It didn't loose lock (yet) and I think I found a criterion to
forecast/prevent an upcoming 'out of lock' situation.

#### Johnny B Good

• Frequent Contributor
• Posts: 446
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #257 on: April 04, 2019, 04:56:08 pm »
You're not using the M8T sawtooth correction, right? (Since Lars' GPSDO doesn't utilize it.)

Previously you posted that you use the "UBX-CFG-NAV5" message - the implication seems to me to be that that message automatically sets the elevation mask in some way. Usually that wouldn't leave you with only a few satellites but if more than half of the sky was already blocked, sure, I could see you ending up with only a few.

The Skytraq/Navspark units are significantly more sensitive than the Ublox GPSs. maybe in your situation you would do better with one of them. They are so sensitive that for me, they work indoors without needing to be near a window at all.

I realise this is just over four months late but I felt impelled to give that statement about sensitivity some context. I've already read the whole of this thread two or three weeks earlier and was reading it again to refresh my memory since it's been so revealing a discussion on the subject of DIYing a GPSDO. There are still several points I only have a vague grasp on but I'm hoping to learn more by osmosis.

About two months back, I got a sudden and desperate urge to create an accurate 10MHz reference to substitute for the currently un-receivable WWV broadcasts I'd previously used nearly three decades ago as a calibration source so landed up buying a cheap u_Blox NEO M8N based Arduino/Rpi module which I could use immediately to provide a 10MHz calibration signal. As a substitute for the WWV 10MHz broadcasts, it's a vast improvement in spite of the jitter from dividing a 48MHz TCXO down to 10MHz (the least of the issues with disciplining an XO) and the varying ticks as it adjusts the PPS to stay synchronised to GPS (UTC) time by skipping/adding one full 20.8333ns clock period.

Such a polluted 10MHz signal whilst unusable as an external oscillator reference for comms and test gear, more than adequately serves as a calibration reference by which to trim internal clock oscillators. In my naivety, I'd assumed that the 48MHz TCXO in the u-blox module was simply being continually adjusted to hold it exactly on frequency, only to eventually figure out the horrible truth of the matter by careful comparison with a cheap AWG driven by a 0.1ppm TCXO that could keep the drift down to one or two ppb per half hour or so (stable enough to observe what was actually happening to the PPS when programmed to a jitter free 8MHz), using the signal generator to trigger the 'scope to reveal the jumps in phase of the 8MHz PPS signal.

Such corrective jumps can be heard as individual pulses on an HF radio tuned to the fundamental in NBFM mode and also on the third harmonic at 24MHz where these pulses are then three times the amplitude. Setting the PPS to 100KHz and listening to the 99th harmonic seems to produce a click amplitude similar to the 8MHz PPS signal as one might expect. However, the level of the click modulation disappears into the noise when listening to the 100KHz PPS frequency itself.

Prior to that discovery, I'd had high hopes of being able to clean up the PPS signal using a 3N502 clock multiplier chip to multiply the 4MHz PPS to a nice clean, jitter free 10MHz. However, that random dropping/adding of a clock pulse to correct in a method that parodies the "Leap Second" UTC correction mechanism every 5th of a second to every ten seconds or longer, rather put paid to that scheme. The result being that I do now see the point of all this extra complexity of an add on VCOCXO with startling clarity.  The truth of the matter is that the starting point of any GPSDO should be the VCOCXO with the GPS module and associated paraphernalia as the "After market add-on".

Anyhow, that explains my interest in this thread but to get back to the observations made regarding GPS receiver sensitivity, I feel I should add my own observations just to provide the wider context. Whilst the M8N may not have been an optimum choice for a GPSDO project, it does appear to compare well against the old and once well regarded Navman Jupiter T's 10KHz jitter performance (as best as I can make out from the data sheet at any rate).

That 20.8333ns jitter will always be present regardless of whatever frequency the PPS line has been programmed to emit. The benefit of choosing a lower frequency is that this jitter represents a much smaller phase modulation (75 milli degrees at 10KHz  versus 75 degrees at 10MHz). Whether this is any help towards reducing the effect of this "Leap Cycle" correction on the final PLL control signal, I'm not at all sure. TBH, any benefit is most likely simply going to be down to the longer time constant required with such a large division ratio in the PLL (the resulting 7.5 microdegree phase shifts on the 1Hz PPS seem to be just as big a problem). In short, it seems to me that it's this 20.8333ns random jitter that mandates long time constants in the PLL control driving the Vfc pin of the VCOCXO to filter out the effect of such phase jumps on the VCOCXO's output.

All that aside, whilst I was discovering the reason for the module's attached patch antenna proving to be a mere ornamental adornment[1], I discovered that, after the patch-ectomy (and removal of the microscopic LNA chip), the module could still retain lock on half a dozen or more satellites for several minutes after disconnecting the external active antenna (or the original patch antenna I'd now re-purposed with a 15cm flylead for use as a plug in passive test antenna)

Quite frankly, the module didn't need the help of a LNA chip to use the attached patch antenna. It seemed to manage remarkably well from what it could pick up on the 18mm's worth of strip-line between the SMA socket and the RF in pin whilst sat on my work bench some 16 feet away from the window. I suspect it might be just sensitive enough to acquire satellite lock given clear unobstructed sight of the sky but since it's raining right now, that experiment will have to wait a while.

The rain abated and I connected it up to a usb battery bank, after programming it to display a 5Hz 25% pulse to show the unlocked state with a 100KHz 50% for the locked state, and took it outside to get an unobstructed sky view. It did re-acquire enough satellites to get a lock after losing lock in the transition from 1st floor 'office'/'workshop' into the fresh air of the outside world.

After losing lock for several minutes whilst in the back kitchen, I was able to re-acquire lock each time I took it back outside, confirming that it could reliably receive satellites sans antenna connection without the use of a boost from an external antenna to get it to lock onto the signals as appears to be the case when indoors. Such are the vagaries of the SDR  technology employed to detect such weak satellite signals that it should need such a strong hint of the signals it should remain locked onto in this case.

I'd previously observed it maintaining lock after disconnecting the antenna for ten minutes and longer before finally losing the signals completely, never to show even a hint ever again, or at least for maybe half an hour or more for even so much as a fleeting glimmer of signal. I had a sneaking suspicion that it was so close to the edge that direct sky exposure might well prove sufficient to allow it to acquire the signals without an antenna connection so it was rather gratifying to see such a positive result.

[1] This failure of the built in patch antenna, which by all accounts (and despite its less than ideal location on the backside of the module) should have produced workable signals, remained a mystery for several weeks before I finally discovered that it was merely held in place by a single solder connection and an adhesive pad, allowing me to remove it undamaged and with only minor damage to the through plated hole on the board used for the feed pin connection which will never ever be used ever again.

Lifting the patch antenna had finally revealed the true cause of its failure to provide anything other than fleeting signals, namely, several signal carrying traces within the ground-plane the antenna had been sat on. Little wonder it had totally failed to produce any useful signals. I can only suppose that this had once worked with previous versions of these modules with ground-planes devoid of any such signal traces and the manufacturer had simply overlooked this change and through inertia carried on fitting an antenna that was now doomed to certain failure by being grossly overloaded with RFI from those circuit traces.

Manufacturers can be such idiots at times. In this case, the antenna (and the LNA chip) had become a complete waste of BOMs as well as a source of frustration to the end user, many of whom would be making RMA applications. Others, like myself who were planning on using an external active antenna anyway, would save themselves (and the vendor) the trouble of RMAing the module, especially after discovering that a 3/4 wave 14cm piece of wire plugged into the SMA socket would serve as an effective substitute for a patch antenna despite the presence of the LNA attached halfway down the strip-line connecting the socket to the RF In pin of the u-blox module burdening the external antenna socket with an unwanted shunt impedance.

Removal of the microscopic LNA chip improved the performance of that 3/4 wave antenna. Strapping the patch antenna directly to the RF in line after the LNA-ectomy via a 4mm wire link failed to produce any signals but, after the patch antenna had been recovered from the board and a short co-ax fly lead soldered onto it to allow it to be reconnected via the antenna socket, it was able to give noticeably stronger signals than even the makeshift 3/4 wave antenna had given.
It may have been a useless adornment as supplied but, successfully divorced from the module, that patch antenna has now become  a rather handy passive test antenna.

JBG

« Last Edit: April 04, 2019, 09:21:06 pm by Johnny B Good »

#### jimharman

• Newbie
• Posts: 3
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #258 on: April 05, 2019, 03:01:14 am »
I have built an Arduino-based GPSDO with hardware and software based on Lars's design and have been been very pleased with the results, but I lack the equipment needed to properly characterize its performance. Following some discussion on the Time-nuts list, Bert Kehren offered to test it using his setup, which uses a cesium standard as its reference. It is currently warming up in his lab and he will be starting a 24-hour test run tomorrow. Here is Bert's initial report and some photos, results to follow.

-----
Recently Lars GPSDO came up on time nuts. I was working with Lars but we focused on other subjects. Never got around to test one. So when Jim Harman mentioned it I contacted him off list and offered to test his unit. He send me a picture of his unit. Oh boy but a promises is a promises. Encouraged him to stabilize it for shipping. Got it in the mail today. See attached picture. Had it up and running in 5 minutes. 5 minutes later 1 E -10. 10 minutes later 3 E-11. After an hour up and down in the E-12 range like all the other ones.
Will let it stabilize for 48 hours and do a 24 hour plot like we have done on all our other GPSDO's to better understand frequency over time due to ionosphere. Mainly due to the delay of ublox F9.
Jim can go in detail about his work with Lars

Bert
------
The first photo shows the unit in its original cardboard box, the second as currently packaged in a sturdier plastic box, and the third is Bert's test setup, showing a frequency error of 1E-12.

#### Remco

• Contributor
• Posts: 11
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #259 on: April 05, 2019, 10:08:56 am »
@jimharman  Very interesting and promising results. Do I see a 12bit MCP4725 I2C DAC ?

In other words, did you rewrite the code to use that DAC?

#### jimharman

• Newbie
• Posts: 3
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #260 on: April 05, 2019, 12:57:42 pm »
Yes, switching to the MCP4725 is one of the changes I made. I wanted to avoid the original design's sensitivity to the 5V supply voltage. My OCXO has a 4V reference output and I use that to power the DAC. I use a resistor network between the DAC and the VFC pin of the OCXO to shift the DC level and reduce the control range, effectively increasing the 12 bit resolution of the DAC. A change I am contemplating is to switch to a AD5680 18 bit DAC.

A schematic is attached. Recent changes, not reflected in this schematic, are a circuit to linearize the diode-R-C integrator and also output buffers for the 10 MHz and 1 pps.

Earlier comments in this thread have indicated that people are having trouble with DC offset at the A/D. Having a short, low impedance ground system is essential.

Also I found that the fast risetime of the 5 MHz input to the processor can cause a lot of ground bounce. Adding the 100 ohm resistor in series with that line (R2 in the schematic) was a big help in cleaning up the ground noise.

#### Remco

• Contributor
• Posts: 11
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #261 on: April 05, 2019, 02:31:25 pm »
I remember having read in this thread somwehere that somebody else mentioned having issues
with the 5 MHz signal and solved it with a pullup (or pulldown) resistor.

I placed the resistor ('R2') and see if the contraption behaves different. Thanks for the hint.
« Last Edit: April 05, 2019, 03:33:52 pm by Remco »

#### imo

• Super Contributor
• Posts: 2653
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #262 on: April 05, 2019, 05:08:46 pm »
The R1=470ohm in above schematics is rather large for 10MHz, I would go with 50-100ohm as well.

#### jimharman

• Newbie
• Posts: 3
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #263 on: April 05, 2019, 07:08:51 pm »
I agree the 470 on the 10 MHz is big. The reason I chose that value is that the OCXO and the rest of the circuitry are on separate 5V supplies and there is a possibility that the OCXO might be powered and the rest of the system not. The 470 prevents drawing excessive current from the OCXO in this situation. It might be unnecessary, but the circuit works with it in place and better safe than sorry.

Performance especially temperature sensitivity might be a little better with a smaller resistor.

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #264 on: April 06, 2019, 03:11:07 am »
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL. I'm in process of designing a proper pcb that:
* Has a Ublox Neo-M8T GNSS timing module
* Can accept multiple OCXO types, sine, square, 5V, 12V
* Can accept PPS from an external GNSS
* Can use the PWM DAC or I2C DAC AD5693 with integrated voltage reference
* Has an active and passive offset and gain control circuit
* Has an integrated distribution amplifier with probably 4x10MHz outputs

Would be nice to have a jitter free PPS output, I'm still thinking how to do that, probably divide it from the 1MHz ot 5MHz output and synchronize it to the mid point of the GNSS PPS.
I experimented a bit with AD5693 DAC and it seems to be very good.
I'm not convinced that 18bits DAC would be necessary, reducing the DAC range to use most of the 16bit swing should be enough.

The project goes slow as I'm pretty busy but I'm more than half way through with the schematic.
Suggestions are welcomed.
« Last Edit: April 06, 2019, 03:14:29 am by Miti »
That big spark at power up was by design!

#### imo

• Super Contributor
• Posts: 2653
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #265 on: April 06, 2019, 05:34:18 am »
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL.
The 10MHz of Neo7 is broken, as discussed many times. The only "clean" output is with frequencies where f=48MHz/N, N is an integer.

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #266 on: April 06, 2019, 11:53:13 am »
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL.
The 10MHz of Neo7 is broken, as discussed many times. The only "clean" output is with frequencies where f=48MHz/N, N is an integer.

I know that but broken or not, it is still 10MHz. Take a look.
That big spark at power up was by design!

#### Johnny B Good

• Frequent Contributor
• Posts: 446
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #267 on: April 06, 2019, 04:42:17 pm »
This thread is alive again. My GPSDO is locked for almost three months with a TC =600. I compare it with a Ublox set to output 10 MHz and there's a tiny drift left and right between the two outputs but never one full period, as it is expected from a PLL.
The 10MHz of Neo7 is broken, as discussed many times. The only "clean" output is with frequencies where f=48MHz/N, N is an integer.

I know that but broken or not, it is still 10MHz. Take a look.

It turns out that the jitter you see when dividing the 48MHz TCXO clock of a NEO M8x module down to 10MHz is simply the consequence of using a non-integer divisor and is inconsequential compared to the insurmountable issue of the "leap cycles" correction system used to keep the PPS synchronised to GPS or UTC time (a parody of the leap seconds corrections to maintain UTC). That jitter is the least of your problems when it comes to disciplining a VCOCXO with a GPS module.

The NEO M8N can be programmed to output jitter free waveforms at 12, 8, 6, 3, 2, 1 MHz and successively lower frequencies by powers of two until you hit the limit at 15,625Hz (you can only program frequencies to the nearest whole number, fractions aren't allowed - the next lower frequency of 7,812.5Hz, therefore cannot be programmed).

If you program a frequency of 16MHz (48/3) and trigger your 'scope from a reasonably stable 16 or 8 MHz signal, you get to see the ratio of the displayed PPS waveform alternate between 67% and 33% duty cycle each time a "leap cycle" correction is applied. This also occurs with divisors of 5, 7, 9, 11 (all odd divisor values in fact).

If you have an HF reciever capable of monitoring these frequencies in NBFM mode, including odd harmonics, you can hear these 'leap cycle' corrections as regularish ticks[1], provided you choose a jitter free divisor. Monitoring the 10MHz or its third harmonic results in a background cacophony of chirps and beeps which seems to obscure this 'tick' noise. Monitoring the 8MHz will reveal this phase modulation which is (predictably) amplified when listening to the third harmonic by a factor of three.

Since it's only the relatively long time constants used in the Vfc output from the PLL which filter these phase discontinuities out, the minor 'jitter noise' in the 10MHz PPS signal becomes of no consequence in the face of this much larger issue. The raw 10MHz on the PPS line, whilst perfectly fine as an alternative to the 10MHz WWV time and frequency standard broadcast for calibrating oscillators, is totally unusable as an external clock reference for radio and test gear, hence the need to use a separate XO, preferably a voltage tunable OCXO as the external 10MHz reference for such equipment.

The GPS module is merely the after-market add-on that disciplines this high quality XO to keep it locked to an atomic clock reference, albeit with very slow phase variations from the primary atomic clock reference that disciplines the Caesium atomic clocks in the GPS and GLONAS satellites themselves.

In my naivety, I thought I could get round the 10MHz jitter issue by simply choosing a 4MHz jitter free PPS I could multiply back up to 10MHz with an ultra low jitter 3N502 clock multiplier chip until I finally recognised the rather cack handed method used to to keep the PPS synchronised to GPS/UTC by skipping or adding a full 20.8333ns cycle of the 48MHz TCXO rather than, as I'd assumed, by phase locking that 48MHz clock frequency reference.

In hindsight, this "'leap cycle' adjustment is simply a limit of the GPS methodology for keeping the PPS synchronised to GPS time sufficient to the basic navigation requirements (the 20.8333ns jumps in phase only account for a positional variation of some 20 feet of error which can be integrated over several seconds to reduce this error to a matter of just 2 or 3 metres in the final positional computations). Producing a low phase noise frequency reference was never in the original remit of the Navstar requirements other than as perhaps an optional external add-on disciplined oscillator. Optional because such additional complexity is surplus to the basic navigation function of the original Navstar (GPS) system.

In short, stop getting all fixated on this 10MHz 'jitter issue', the 'leap cycle' corrections are the real problem. Solve that one and the 'jitter issue' simply vanishes into the noise.

[1] The rate at which these 'ticks' occur, depends on how close to the exact 48MHz frequency the TCXO has managed to get (or not) and I have experienced tick rates varying from 4 or 5 ticks a second to ticks occurring once every 5 to 10 seconds and sometimes even longer.

JBG

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #268 on: April 06, 2019, 07:13:30 pm »
The raw 10MHz on the PPS line, whilst perfectly fine as an alternative to the 10MHz WWV time and frequency standard broadcast for calibrating oscillators, is totally unusable as an external clock reference for radio and test gear, hence the need to use a separate XO, preferably a voltage tunable OCXO as the external 10MHz reference for such equipment.

Well, I can tell you that it was way better that the original TCXO installed in my HP 5385A frequency counter, before I had the GPSDO.
It may even work in the HP 8594E Spectrum Analyzer as it feeds a 600MHz PLL. So as long as that PLL locks on the external jittery 10MHz reference, and assuming that it has a reasonably long TC, it should convert into a clean 600MHz. I'll do a test one day.
My point is that it depending on the application, the jitterey 10MHz that comes out of the Ublox module may be way better, long term, than a free running OCXO, XTAL, TCXO....
That big spark at power up was by design!

#### Johnny B Good

• Frequent Contributor
• Posts: 446
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #269 on: April 06, 2019, 09:36:16 pm »
The raw 10MHz on the PPS line, whilst perfectly fine as an alternative to the 10MHz WWV time and frequency standard broadcast for calibrating oscillators, is totally unusable as an external clock reference for radio and test gear, hence the need to use a separate XO, preferably a voltage tunable OCXO as the external 10MHz reference for such equipment.

Well, I can tell you that it was way better that the original TCXO installed in my HP 5385A frequency counter, before I had the GPSDO.
It may even work in the HP 8594E Spectrum Analyzer as it feeds a 600MHz PLL. So as long as that PLL locks on the external jittery 10MHz reference, and assuming that it has a reasonably long TC, it should convert into a clean 600MHz. I'll do a test one day.
My point is that it depending on the application, the jitterey 10MHz that comes out of the Ublox module may be way better, long term, than a free running OCXO, XTAL, TCXO....

You're unlikely to have that last statement refuted here (qualified perhaps but not refuted).

I'd qualify it by saying that it's not a matter of "may" so much as "will definitively" (be way better that is!). Long term, the PPS is never going to be adrift from GPS (and, leap seconds allowing, UTC) by more than 50ns for the foreseeable future, barring any outages of service. Indeed, even in the event of a disruption, the PPS will be resynchronised automatically once the service is restored, including the actual time of any timepieces relying on the service since all the time data to reset any clock is part of the navigation data payload.

Given a stable enough VCOCXO and an intelligent micro-controller algorithm which tracks the Vfc trend to provide the best possible hold over performance from the VCOCXO, the 'free running' OCXO may well be able to stay in phase over a several hours long outage successfully masking such outage effects on the reference frequency output from the GPSDO.

As for my own requirements, I'd be quite happy if my own GPSDO (when I finally get hold of a suitable VCOCXO and other bits at the end of this month to build one) can manage such a trick over rather more modest time scales measured in minutes.

There'll be time enough to develop such hours long hold over performance afterwards once I've got a basic GPSDO good enough for use as an external 10MHz clock reference to drive my cheap FY6600 AWG and anything else that can utilise or be modified to utilise an external clock reference.

JBG
« Last Edit: April 08, 2019, 01:27:40 am by Johnny B Good »

#### bingo600

• Super Contributor
• Posts: 1511
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #270 on: April 10, 2019, 07:15:24 pm »
Would be nice to have a jitter free PPS output, I'm still thinking how to do that, probably divide it from the 1MHz ot 5MHz output and synchronize it to the mid point of the GNSS PPS.

Take it from the 10Mhz and use a

PicDiv
or
AVR
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg2042386/#msg2042386

/Bingo

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #271 on: April 11, 2019, 07:49:53 pm »
Right but it has to be synchronized with the GPS PPS to have a real PPS.
That big spark at power up was by design!

#### texaspyro

• Super Contributor
• Posts: 1403
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #272 on: April 11, 2019, 09:09:23 pm »

Take it from the 10Mhz and use a

PicDiv
or
AVR

No need for a PICDIV  since the Lars GPSDO is already dividing the 10 MHz down to 1 Hz.

#### Miti

• Frequent Contributor
• Posts: 871
• Country:
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #273 on: April 12, 2019, 02:53:52 am »

Take it from the 10Mhz and use a

PicDiv
or
AVR

No need for a PICDIV  since the Lars GPSDO is already dividing the 10 MHz down to 1 Hz.

Where does it do that? Am I missing something?
That big spark at power up was by design!

#### texaspyro

• Super Contributor
• Posts: 1403
##### Re: Lars DIY GPSDO with Arduino and 1ns resolution TIC
« Reply #274 on: April 12, 2019, 03:35:21 am »
Where does it do that? Am I missing something?

Ooops,  I think that was in a modified version that I saw a schematic for...

Smf