Frequency offset between GPS receivers!?

[nctnico]

Lately I have been doing some testing with a GPS receiver which disciplines an OCXO (uBlox LEA-M8F with a 16 bit DAC + OCXO). When I compare the 10MHz frequency with my BG7TBL GPSDO I notice that after a startup there is always a random but constant (over several hours) frequency offset (a few milli-Hertz). I'm getting a flat graph on the frequency counter.

For my test I use a cheap antenna under a non-metal roof; the antenna should have a clear view of the entire sky. It is right next to the antenna of the GPSDO (which is always on). Also I did not configure the GPS receiver to GPS only but I'm not sure whether it is worth trying.

My question is: am I doing something wrong or is this a normal effect?

[tszaboo]

You should either check the matching of the antenna, or use an active antenna. Or both, if possible.
Also, that cheap antenna could be a patch antenna. That works much better if it is mounted on a metal plate.
My main issue with cheap antennas is the lack of documentation. For example, I played with the Simcom GPS eval board. It kinda sorta works out of the box, but reception was bad. Only later did I see that I had to mount it on a metal plate, and it improved reception significantly (dont remember numbers). They dont tell you that you need to do this, and dont tell you the type of the antenna.

[CJay]

A few mHz could even be as simple/nasty as a little extra cable or even different velocity factor.

It may be possible to set a cable delay compensation parameter to calibrate it out

Remember the 'discovery' of faster than neutrinos a few years ago?

That was down to a loose fibre optic connector in the time measurement system...

[Kleinstein]

A vekocity factor of the cable can give a shift in the absolute time, but alone would not give a frequency difference. It would take something like a constant drift in the delay to cause a difference in frequency.

The likely cause for different frequencies is using different satelites (e.g. one receiver may include 1 or 2 more because of better reception) and maybe a different weight (not sure if they use weights or just in or out) to different sats. So improving the antenna may help.

A mHz difference over a longer time would however mean quite a bit of difference - that would be seconds in the absolute time. 

[CJay]

A vekocity factor of the cable can give a shift in the absolute time, but alone would not give a frequency difference. It would take something like a constant drift in the delay to cause a difference in frequency.

The likely cause for different frequencies is using different satelites (e.g. one receiver may include 1 or 2 more because of better reception) and maybe a different weight (not sure if they use weights or just in or out) to different sats. So improving the antenna may help.

A mHz difference over a longer time would however mean quite a bit of difference - that would be seconds in the absolute time. 

Ah, true, as it would be a constant, mea culpa, you are of course correct.

I wonder if there's scope for a distribution system so the antenna is shared?

[MIS42N]

Lately I have been doing some testing with a GPS receiver which disciplines an OCXO (uBlox LEA-M8F with a 16 bit DAC + OCXO). When I compare the 10MHz frequency with my BG7TBL GPSDO I notice that after a startup there is always a random but constant (over several hours) frequency offset (a few milli-Hertz). I'm getting a flat graph on the frequency counter.

A few mHz is a lot. Is this a phase difference rather than a frequency difference? that makes sense.

What is the sensitivity of the OCXO to the control voltage. I've measured 0.1V/Hz - use a 16-bit DAC with a 0-5V output, 0.1V is around 1300 steps, so quantization could cause an error of up to 0.4mHz. If the OCXO was more sensitive then the quantization error is bigger but "a few milli-Hertz" seems excessive.

I can't think of any mechanism that explains a constant frequency difference, except one oscillator is in fact not being disciplined. I built a GPSDO that stores the last control volts. Turn it on and don't discipline it, it stabilises fairly close to the target but not quite - a few mHz off.

[nctnico]

Lately I have been doing some testing with a GPS receiver which disciplines an OCXO (uBlox LEA-M8F with a 16 bit DAC + OCXO). When I compare the 10MHz frequency with my BG7TBL GPSDO I notice that after a startup there is always a random but constant (over several hours) frequency offset (a few milli-Hertz). I'm getting a flat graph on the frequency counter.

A few mHz is a lot. Is this a phase difference rather than a frequency difference? that makes sense.

What is the sensitivity of the OCXO to the control voltage. I've measured 0.1V/Hz - use a 16-bit DAC with a 0-5V output, 0.1V is around 1300 steps, so quantization could cause an error of up to 0.4mHz. If the OCXO was more sensitive then the quantization error is bigger but "a few milli-Hertz" seems excessive.

I can't think of any mechanism that explains a constant frequency difference, except one oscillator is in fact not being disciplined. I built a GPSDO that stores the last control volts. Turn it on and don't discipline it, it stabilises fairly close to the target but not quite - a few mHz off.

It really is a frequency offset; I see the phase drifting continuously. The pull range of the OCXO is +/-700 ppb (0 to 3.3V) with a 0 to 2.5V control voltage (so 0.016ppb per bit) from the DAC (a good quality one from TI) using a high stability 2.5V reference chip.

Edit: one of the initial tests I did was to measure the OCXO itself (fixed control voltage) against the (reference) GPSDO and that didn't show a significant drift over a couple of hours (Adev: .2mHz, stdev: .9mHz).

[KE5FX]

Known issue, unfortunately.  How old is your BG7TBL GPSDO?  I would certainly hope he'd have fixed that by now.

[nctnico]

Known issue, unfortunately.  How old is your BG7TBL GPSDO?  I would certainly hope he'd have fixed that by now.

That was my initial thought as well but I'm seeing a much larger offset and I've also seen the DUT settle at a lower frequency compared to the BG7TBL. The BG7TBL I have here says 2017. I assume it is affected by the frequency offset bug. I hope I can start a long term test against a GPS disciplined Cesium clock later this week. See what is what.

[testpoint1]

A few mHz is a quite large tolerance, caused by OCXO/TCXO or its discipline circuit, usually, you can use a calibrated Rubidium clock to identify it.

[jfphp]

I have experienced (disciplined OCXO v. Cesium) a different offset with the antenna under the roof (tiles) and with the antenna in free air-space. Feeding coax had the same length.

[MIS42N]

A few mHz is a quite large tolerance, caused by OCXO/TCXO or its discipline circuit, usually, you can use a calibrated Rubidium clock to identify it.

It surprised me that something like this happens with microprocessor controlled disciplining. It wasn't a possibility I considered. I built a couple of GPSDOs, and in the process of developing more. From the first design, the microprocessor clocks from the OCXO. Then it is a simple matter to count cycles between GPS pulses and steer from that. In the long term the phase of the OCXO is locked to the GPS (but of course shows some deviation in the short term). The latest incarnation uses one of the 8-bit counters clocked at 10MHz and resets every 250 cycles. Count 40,000 and that's a nominal second. Disciplining tries to make it a real second. Job done.

[WPXS472]

I have fooled with numerous GPSDOs over the years. I have never seen two that when compared, were exactly together. The best I ever did was comparing a Z3801 to a Thunderbolt. They always stayed within the same cycle, but would drift a few nanoseconds back and forth. I mean a few, Lately, using a RFTG-u, and comparing several of the UCCM small GPSDOs, they always slowly drift in comparison to the RFTGu. Since my Z3801 has bit the dust, I have nothing to really compare the RFTGu to that I trust completely. I recently fired up a rubidium and let it stabilize over night. After playing with the C field adjustment for hours, the best I could do was a slip of 1 cycle every 15 minutes or so. If I were comparing two GPSDOs and they didn't drift at least a little, I would be really surprised.

[KE5FX]

Phase drift isn't the same thing as frequency drift or frequency offset.  A GPSDO has two jobs: 1) minimize the first of those effects; and 2) eliminate the second and third ones altogether, at least while locked.

[jfphp]

Silly experience : 3 hand help GPS in the wild, outside war regions. No one is giving the same position and even after end of the SA, position is jumping here and there in different amounts.

[nctnico]

Known issue, unfortunately.  How old is your BG7TBL GPSDO?  I would certainly hope he'd have fixed that by now.

That was my initial thought as well but I'm seeing a much larger offset and I've also seen the DUT settle at a lower frequency compared to the BG7TBL. The BG7TBL I have here says 2017. I assume it is affected by the frequency offset bug. I hope I can start a long term test against a GPS disciplined Cesium clock later this week. See what is what.

The test against the Cesium clock is running but it will take a couple of days before the results are in. Meanwhile the GPSDO under test/development starts to agree with the BG7TBL within less than 1mHz. I've ordered a second GPSDO and slightly better antennas to build a better setup which allows for better comparisons.

[nctnico]

Meanwhile I have received the Trimble based GPSDO, bought 3 identical antennas and put these on a 30x40cm metal plate under the roof. And I have done a lot more testing. First of all it seems my BG7TBL GPSDO doesn't have the frequency offset bug.

The latest tests by using the 10MHz from the GPS receivers to derive a 1PPS signal. First I compared the BG7TBL GPSDO to the one from Trimble and I see the derived 1PPS wandering around by about 500ns (order of magnitude number!) . A comparison between the uBlox LEA-8MF GPSDO shows similar wander. I still need to do a test between the BG7TBL and the uBlox LEA-8MF but I don't expect to see different behaviour.

All in all it seems the conclusion is that long term (>24 hour) stability is OK but short term the receivers seems to drift apart in equal amounts.

[MIS42N]

All in all it seems the conclusion is that long term (>24 hour) stability is OK but short term the receivers seems to drift apart in equal amounts.

In my opinion, this is the outcome to be expected. I've looked at most GPSDO circuits that have appeared online, almost universally they use a phase locked loop to bring the local oscillator in line with the received GPS signal. Each PLL has a different setup so any variation in the GPS signal will cause different effects from different receivers. Even two supposedly identical receivers, the oscillator will behave differently. I recently built two GPSDOs using the same model of oscillator, one has a control voltage around 1.9V and a sensitivity to control of 0.11 V/Hz. The second is 2.8V and 0.13 V/Hz. So the same PLL circuit will behave slightly differently.

The general solution seems to be make the GPS signal as accurate as feasible. This means it has less instability and allows the PLL to have longer time constants. In the end you are dealing with a whole series of variables - intrinsic variability of GPS data due to swapping between satellites, varying delays because the satellites are moving, ionosphere effects, etc. Then the GPS receiver may or may not faithfully follow the received signal (I use NEO-6M, cheapest and possibly dirtiest of all). Then there is varying PLL strategies (which are also affected by the stability of the power supply, the PLL has to compensate for unwanted variations due to voltage changes on the control voltage supply). And then how good is the oscillator?

Using a PLL should guarantee long term agreement - the name after all is phase locked. Loss of agreement means loss of lock, means something is wrong.

My approach has been to use microprocessor power to avoid using a PLL. Instead the oscillator is allowed to "free run" {no change to the control voltage) for an extended period then apply one correction to correct any deviation. If you were to compare it to a PLL you'd see them diverge for some minutes then converge over more minutes. The advantage of this approach is the oscillator is mostly running at the limits of its own stability. May not be accurate but will be stable. Also it is possible to quantify the frequency error. If the oscillator diverges one cycle in 1000 seconds then it is within 1mHz of the GPS. I have seen better results than this under ideal conditions.

Another advantage is the GPS data can be 'dirty', it all averages out over time. Improvement to the system comes almost exclusively from improving the conditions for the oscillator - stable control voltage, stable supply voltage, stable temperature. This is what I am currently exploring. The holy grail is to get less than one cycle drift in a day. I think the satellites come into roughly the same position each day so the data from one whole day should be similar to the next. The it will become possible to work out an ageing factor and apply that as a second continuous correction. If this is achievable, it is a better standard than rubidium. May not be possible but we can dream.

[nctnico]

@MIS42N: Your approach is also something I'm contemplating. Maybe put a slowly adjusted (24 hour interval) OCXO behind the GPS receiver. I'm also wondering whether the 1PPS pulse from the GPS receiver is more accurate. Another option would be to configure the GPS receiver to make the output frequency coherent with the 1PPS pulse and see if that improves things.

[MIS42N]

I wrote up my project https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/msg3481886/#msg3481886. It is still a work in progress, I changed my mind about the output and built a version using a 74HC04 hex inverter to drive a square wave to a BNC connector. This is keeping the cost low. I don't have much in the way of test equipment so took the kit to a guy with more, but his was not up to showing exactly what came out the BNC. It was good enough to use as a reference source for an SDR (at which point he said "I want one").

I only use the 1pps and NMEA data, haven't bothered with reprogramming the GPS module. Again to allow flexibility and keep cost down. I designed a simple line driver/receiver PCB using UA9638/9639 to push the data down an ethernet cable so the GPS module could be a distance from the GPSDO. This has tested error free for a day over 30 meters, allows the GPS module to be in an optimal position. I found early on that good reception is key to usable data. I found a program VisualGPS to check this, over time it can show the reception window. It also says most of the tracked satellite signal SNR are in the 40s, and HDOP is 1 or less most (>95%) of the time. I believe these are good figures.

[nctnico]

More testing while Dave was resqueing his servers... it turns out that the uBlox LEA-M8F needs to be configured to optimise for phase in order to get the best frequency stability.    When set to optimise for phase it stays within 50ns p-p compared to the Trimble when measured for 3 days. Comparison with a Cesium clock over a 3 day period shows no wander in a certain direction but there is no good way to have a decent GPS reception (antenna stuck to the side of a building) in that location so the peak-to-peak error is much larger compared to the measurement in my own lab. Then again the Trimble is likely to have a similar offset. I'm really dissapointed there is no way to get better GPS reception at the site where I have access to a Cesium clock to test against.

[MIS42N]

I'm really dissapointed there is no way to get better GPS reception at the site where I have access to a Cesium clock to test against.

I ran into a similar problem. The solution for me was to put the GPS module where there was a good signal and use a line driver/receiver pair to bring the signals from the GPS module down to the GPSDO. I am using just the 1pps and NMEA data so this works just fine. I don't know if that can be applied in your circumstances. I've attached an image of various bits and pieces I used. The line driver/receiver PCB boards were designed in KiCad and sent to JLCPCB. They were my first attempt and have errors but still usable.

The GPSDO was built with a 5 pin connector and originally attached to the GPS module by one of the rainbow cables. The line driver/receiver simply extends this, so the pinouts at the end are the same. The GPS module nearest the top is an old NEO-6M with a patch antenna on the back, repurposed from another project. The one at the bottom is a newer NEO-6M with a puck antenna and 3 meter lead. I've done comparative tests of the two in the same good viewing position, the SNR reported by VisualGPS for the puck antenna was about 7db better than the older module (to be expected) but I couldn't see any difference in the performance. The reported signals were up to 42db (usually 6 satellites above 35db) for the older module, and up to 49db (mostly above 40db) for the newer one. So there may be a threshold for SNR and there's no improvement above that.

I've shown a short Ethernet cable for illustration, my semi permanent setup is using a 16 meter cable (longer than needed but was available). The antenna is about 7 meters up, on the roof of the house. The comparative tests were done with a 30 meter cable on the garage roof. The signals are differential using two UTP, the other two provide the power and earth for the GPS and driver end. The driver receivers are UA9638/9.

[Ringmodulator]

More testing while Dave was resqueing his servers... it turns out that the uBlox LEA-M8F needs to be configured to optimise for phase in order to get the best frequency stability.    When set to optimise for phase it stays within 50ns p-p compared to the Trimble when measured for 3 days.

How/where did you configure this?
I suppose it is somwhere in the u-blox settings.

Chris

[Leo Bodnar]

Is there more or less standardised methodology for testing this?
Do you have some charts of how this difference behaves over time?
Even a standard GPS receiver needs a good hour to settle - navigation solution is usually fed through a IIR so the frequency will bounce a little bit until it levels off.
Leo

[nctnico]

More testing while Dave was resqueing his servers... it turns out that the uBlox LEA-M8F needs to be configured to optimise for phase in order to get the best frequency stability.    When set to optimise for phase it stays within 50ns p-p compared to the Trimble when measured for 3 days.

How/where did you configure this?
I suppose it is somwhere in the u-blox settings.

Yes. But since I'm controlling the receiver from software I set this using the CFG-SMGR message.

Is there more or less standardised methodology for testing this?
Do you have some charts of how this difference behaves over time?
Even a standard GPS receiver needs a good hour to settle - navigation solution is usually fed through a IIR so the frequency will bounce a little bit until it levels off.
Leo

It seems the accepted method for a GPSDO is to let the GPS receiver survey in for 24 hours to determine its position, have it operate in fixed position mode and then measure for at least 48 hours in order to have 2 earth (and satellite) rotations and get a rough estimate. The people I work with usually do stability tests for a minimum of 10 days. Unfortunately I can't share the 4 day chart but looking at it the same pattern -sort of- repeats every 24 hours. The measurement was taken at a latitude of 52 degrees north so GPS coverage isn't optimal to begin with.

I'm really dissapointed there is no way to get better GPS reception at the site where I have access to a Cesium clock to test against.

I ran into a similar problem. The solution for me was to put the GPS module where there was a good signal and use a line driver/receiver pair to bring the signals from the GPS module down to the GPSDO.

In my situation it is the builder owner not allowing to put a GPS antenna on the roof. Cabling and GPS antenna are not the problem.

[fourfathom]

The measurement was taken at a latitude of 52 degrees north so GPS coverage isn't optimal to begin with.

Why is your latitude a problem?  Looking at the GPS satellite constellation it looks like good global coverage.

[Leo Bodnar]

It seems the accepted method for a GPSDO is to let the GPS receiver survey in for 24 hours to determine its position, have it operate in fixed position mode and then measure for at least 48 hours in order to have 2 earth (and satellite) rotations and get a rough estimate. The people I work with usually do stability tests for a minimum of 10 days. Unfortunately I can't share the 4 day chart but looking at it the same pattern -sort of- repeats every 24 hours. The measurement was taken at a latitude of 52 degrees north so GPS coverage isn't optimal to begin with.

I'd like to see some visual performance plots from bad, average and the best receivers.
I have tested two Ublox series 8 FW 3.01 based oscillators, gave them 2-3 hours to settle (oscillator PLL loop BW was set to about 1Hz) with two magnetic puck antennas in a living room.  After 8 hours run I had peak-to-peak phase drift 6ns and average frequency drift 1.3E-13.
Of course, they both might have identical systematic frequency error but at least they don't diverge too much between themselves.
Leo
P.S. My lattitude is 52.1N

[Leo Bodnar]

Why is your latitude a problem?  Looking at the GPS satellite constellation it looks like good global coverage.

DOP is actually slightly better (lower) for middle lattitudes between 50 and 60, but only marginally so. As to anecdotal confirmation - I flew a balloon fitted with Ublox series 8 GPS tracker and it passed within 9km from the North Pole. Number of GPS satellites in the solution was 12-13 while, typically, down in middle lattitudes it only had 9-10.  Could be due to antenna polarisation or man-made RFI - who knows, but GPS was happy.
Leo

[MIS42N]

The measurement was taken at a latitude of 52 degrees north so GPS coverage isn't optimal to begin with.

Why is your latitude a problem?  Looking at the GPS satellite constellation it looks like good global coverage.

The satellites are orbiting on planes inclined to the equator around 60 degrees (slightly different for the different countries) so a receiver located 60 degrees north would see most satellites either overhead or to the south. If the receiver was positioned on a north facing wall, it would be dealing with satellites further away and probably less of them.

I found this out running VisualGPS overnight to see my receiving window. I live approx 30 degrees south, there was a big scallop out of the window to the south. There aren't any obstructions so I did a bit of research, and this was the explanation. 

[nctnico]

It seems the accepted method for a GPSDO is to let the GPS receiver survey in for 24 hours to determine its position, have it operate in fixed position mode and then measure for at least 48 hours in order to have 2 earth (and satellite) rotations and get a rough estimate. The people I work with usually do stability tests for a minimum of 10 days. Unfortunately I can't share the 4 day chart but looking at it the same pattern -sort of- repeats every 24 hours. The measurement was taken at a latitude of 52 degrees north so GPS coverage isn't optimal to begin with.

I'd like to see some visual performance plots from bad, average and the best receivers.
I have tested two Ublox series 8 FW 3.01 based oscillators, gave them 2-3 hours to settle (oscillator PLL loop BW was set to about 1Hz) with two magnetic puck antennas in a living room.  After 8 hours run I had peak-to-peak phase drift 6ns and average frequency drift 1.3E-13.
Of course, they both might have identical systematic frequency error but at least they don't diverge too much between themselves.
Leo

The uBlox (+ external OCXO) compared to a Trimble GPSO showed a 50ns pp drift (with identical antennas on a metal plate under a wooden roof with no tall buildings around). With an antenna hanging on the outside of a building the comparison with the Cesium clock shows a 175ns pp drift. I think it is a reasonable assumption that two identical modules will drift the same amount if they see the same GPS signal. In both measurements I used a 1PPS derived from the frequency coming from the GPS module; not the 1PPS coming from the module itself.

[3isenhorn]

Hi all,
I would like to join the discussion
So in my opinion a constant offset cannot be explained by different GNSS reception. Of course, an error is generated by different reception/processing chains, e.g. weighting. However, this should not be constant over a long period of time as satellites disappear or come out in view, so the processing difference should vary over time.

For my test I use a cheap antenna under a non-metal roof; the antenna should have a clear view of the entire sky. It is right next to the antenna of the GPSDO (which is always on). Also I did not configure the GPS receiver to GPS only but I'm not sure whether it is worth trying.

Have you tried using only GPS in the meantime? Since all GNS systems have their own reference time, could there be a problem when they are all combined to UTC, resulting in a constant offset?

[MegaVolt]

The classic GPSDO circuit consists of an ADC that controls an oscillator. The ADC has a minimum step. And perhaps it is this minimum step that gives the fixed error. We cannot set the signal to less than 1 LSB.

[MIS42N]

I just read through all the posts to see if we are still discussing frequency offsets or phase variations. My definition of a frequency offset is comparing two oscillators one will over time produce more cycles than the other. If one oscillator is 10MHz exact, and one is 10,000,000.0001Hz, then the second one will create an extra cycle in 10,000 seconds and an extra 8.64 cycles in a day. If the two oscillators are in phase at time t then they are 180 out of phase at t + 5000 seconds.

A phase variation in the short term looks just like a frequency offset. Take the same two oscillators, but after 5000 seconds change the 10,000,000.0001Hz to 9,999,999.9999Hz then after 10,000 seconds they both will have produced the same number of cycles. Flip the frequency every 5000 seconds and the two will produce the same number of cycles (+-half a cycle) over any period of time.

But, at 5000 seconds, and not knowing the control mechanism, one cannot tell if there's a frequency offset or a phase offset (at that moment it is of course both).  nctnico started off describing the problem as a frequency offset but since has talked of p-p differences of ns which is more the language of differences of phase. So I am looking for confirmation that nctnico is looking at the dynamic phase differences of oscillators and not long term frequency differences. Long term frequency differences in GPS disciplined systems just don't make sense (except if there is an error in implementation). Long term frequency differences do make sense when compared to rubidium or cesium clocks because they are not as good as the NIST clocks that are used to ensure the long term validity of the GPS system.

I believe all the GPS receivers mentioned are single frequency receivers (the L1 band) and therefore don't have the ionospheric correction capabilities of the dual band receivers. So it is no surprise the oscillators wander a small amount due to this. MegaVolt also mentioned the problem introduced by 'course' ADC control.

Which leads to the question, what is the aim. In developing a cheap GPSDO solution my target was to maintain the OCXO at 10MHz +- 0.01Hz. In discussions with a few people this is satisfactory for a reference for all the local amateur radio enthusiasts. I've achieved that. I believe an order of magnitude better (+-0.001Hz) can be achieved for not much more, but I haven't found anyone that says that is a requirement, just a nice to have. The next magnitude (+-0.0001Hz) is a bit of a hurdle, on paper it can be done for less than $200, but I haven't found anyone who wants it.

So are we really just a lot of aimless tinkerers? [my hand is slowly raised]

[Leo Bodnar]

Stability and accuracy often have different users: metrology mostly needs accuracy while applied practical use like HAM radio mostly needs stability.
Say, WSPR on 23cm (1.2GHz) band would have needed better than 1E-9 stability over 2 minutes if decoder wasn't tracking the drift (I think it does.)
This is 0.01Hz for 10MHz reference.  I don't know if this was a silly example or not but 1Hz drift on 23cm band is not science fiction.
Leo

[Melt-O-Tronic]

I'd like to throw a suggestion out here, even though I'm a newb and this thread is already full of posters I admire as "Titans Of Timing" (new term!) . . .

In comparing two GPS receivers to each other, it may be better to run them off the same active antenna with a low phase offset power divider close to the receivers.  That will minimize differences in feedlines and calculation differences arising from different antenna centers.  You only have to be concerned about which receiver is providing power to the antenna and make sure the other is AC-coupled without introducing more line length.  Or you could DC-block both receivers and power the antenna with a bias-T in the main line.  You may have to do this anyway if the splitter blocks DC (my Mini Circuits ZAP3D-2 does not block DC).

Also, if you lock both your receivers in position hold (timing) mode to the same coordinates, you'll get a better solution.  And if those coordinates are accurate to the true antenna position, the solution will be even better.

To that end, your M8F with Lady Heather can save RINEX files.  You can save captures up to 48 hours long and upload these files to NRCan's PPP tool on the 2nd Monday after your datasets are complete.  They will return to you a full post-processing analysis with a computed centroid.  If you lock both your receivers to this coordinate, you'll have a great solution.

I find the PPP output to be far better than the self-survey.  And averaging numerous PPP batches over several months is even better, especially if you have mild OCD.   

[MIS42N]

Stability and accuracy often have different users: metrology mostly needs accuracy while applied practical use like HAM radio mostly needs stability.
Say, WSPR on 23cm (1.2GHz) band would have needed better than 1E-9 stability over 2 minutes if decoder wasn't tracking the drift (I think it does.)
This is 0.01Hz for 10MHz reference.  I don't know if this was a silly example or not but 1Hz drift on 23cm band is not science fiction.
Leo

Is a GPS locked 10MHz +- 0.01Hz offering both? I have been following these threads about GPSDOs for a few months and am still a little confused as to what people want to achieve. An oscillator locked to the GPS is always going to be accurate in the long term because the GPS is itself locked to the NIST standard long term. The GPSDOs I build use a microprocessor to count cycles and make sure that long term there is always 10M cycles per second.

Nobody seems to be that worried about the short term frequency. Graphs of peoples' DAC values show short term (seconds to minutes) changes, which are changes of frequency to bring the phase of the oscillator into agreement with the GPS. But the GPS itself is subject to short term excursions so I see these as unwanted artifacts of PLL control. Am I alone in this thought? Where people are seeing phase differences between GPSDOs is simply variations in the way each GPSDO tackles the mismatch between OCXO and GPS. If the GPS was free of short term variations then there is no reason to have anything more than a constant phase difference between GPSDOs due to delays in the different systems.

Or am I missing something?

[Leo Bodnar]

An oscillator locked to the GPS is always going to be accurate in the long term because the GPS is itself locked to the NIST standard long term.

Don't take it for granted - in the long term we are two dead people, but short term this does not stop us talking.  Similarly, phase undulations can't be decoupled from frequency stability if your gate time is finite.  If your antenna cable is slowly saturating with mositure and its velocity factor slowly varies or your phase detector threshold moves due to aging components - does it cause output phase drift or constant frequency offset?  To some people it's an academic problem and to some - a real issue.
Leo

[MIS42N]

An oscillator locked to the GPS is always going to be accurate in the long term because the GPS is itself locked to the NIST standard long term.

Don't take it for granted - in the long term we are two dead people, but short term this does not stop us talking.  Similarly, phase undulations can't be decoupled from frequency stability if your gate time is finite.  If your antenna cable is slowly saturating with mositure and its velocity factor slowly varies or your phase detector threshold moves due to aging components - does it cause output phase drift or constant frequency offset?  To some people it's an academic problem and to some - a real issue.
Leo

You got me. In the real world, there is unlikely that anything be accurate. We compare things to the limit of our ability to do so, and give an estimate of uncertainty. I am interested in frequency, and at some stage one has to set a target and try to achieve it. I abandoned PLL as a method because I don't have a reference to compare against. Instead I determined the V/Hz relationship of the OCXO control voltage to frequency. Then a change of voltage can be interpreted as a change of frequency. Since all control voltage changes are intended to bring the frequency into agreement to the GPS it can be deduced the frequency was out by less than the Hz change required to bring the oscillator back to agreement.

To get an implied 10MHz +- 0.01 Hz the arrival times of 1pps from the GPS module is determined to the nearest 25ns. Cheap GPS module will introduce 30ns variability in this due to the GPS not having its own locked local oscillator. Apply a statistical best fit to a large number of these gives an average and a slope. The slope is the change of frequency relative to the average 1pps arrival allowing an estimate of the current deviation of phase at the end of the measurement period. Statistical averaging of a large number of readings reduces the uncertainty of the measurement. I choose a phase shift limit of 1-1/2 cycles over 256 seconds as a limit condition for implying meeting the target. If the frequency was at the limit it would be 2-1/2 cycles out, the extra cycle buffer is 100ns, and this is much more than the raw error (25+30ns), and statistically the averaged error would be around 12ns to 99% confidence.

This deals with the transfer of readings from GPS to uP but not errors in the GPS. Long term recording of GPS positions vary by about 5 meters, implying errors in calculated arrival time of 5/300us, say 15ns to be generous. Even with worst case deviations at beginning and end of measurement period the errors don't add up to the 100ns buffer.

This method does assume the OCXO is stable for the measurement period of 256 seconds, I think this is a reasonable assumption.

If the paradigm is pushed into longer and longer measurement periods there comes a time where stability of the OCXO becomes an issue. I have some evidence that this is a few hours. So a verifiable frequency within 1E-11 may be feasible.

If it were possible to control all the variables for 12 days, then the satellites themselves become the limiting factor. So my accurate becomes "accurate with 1E-14". Of course, if the aim is determining time accurately, rather than frequency, that introduces a whole new world of pain. I'm not going there.

[Kleinstein]

It is true that most systems have some error. However for the GPS freuquency the part that needs to be accurate is a frequency divider. A divider from some 10 MHz to 1 Hz (the 1pps signal as one option to implement an PGSDO) can be build with no error. In discrete logic it is actually difficult to make a small error there  .

The main idea with a GPSDO is to mix the short time (e.g. 30 minutes) stability/low jitter of the TCXO or similar and the long time stability and accuracy of GPS. So it is essentially a kind of slow PLL to slowly and robust (ignore signal drop out and simiar) trimm the oscillator to get the best of both. AFAIK the corss over between a good crstal oscillator and GPS reception is somewhere in the range of some 10 minutes to a few hours. Because of the relatively long time constant for the corss over the implementation is usually digital with a µC or similar and not as a classic analog PLL. A robust implementation (no excessive reaction to short large errors) is also much easier and better done digital.  I have not looked at the details, but I would consider the change in satelite configuration one of the more difficult parts to handle without much extra jitter. Getting the long time frequency right is more like the easy part.

It somewhat seems that the specific GPSDO circuit from the start of the thread did something wrong in the PLL / frequency divider implemented in a µC.

[MIS42N]

It is true that most systems have some error. However for the GPS freuquency the part that needs to be accurate is a frequency divider. A divider from some 10 MHz to 1 Hz (the 1pps signal as one option to implement an PGSDO) can be build with no error. In discrete logic it is actually difficult to make a small error there  .

The main idea with a GPSDO is to mix the short time (e.g. 30 minutes) stability/low jitter of the TCXO or similar and the long time stability and accuracy of GPS. So it is essentially a kind of slow PLL to slowly and robust (ignore signal drop out and simiar) trimm the oscillator to get the best of both. AFAIK the corss over between a good crstal oscillator and GPS reception is somewhere in the range of some 10 minutes to a few hours. Because of the relatively long time constant for the corss over the implementation is usually digital with a µC or similar and not as a classic analog PLL. A robust implementation (no excessive reaction to short large errors) is also much easier and better done digital.  I have not looked at the details, but I would consider the change in satelite configuration one of the more difficult parts to handle without much extra jitter. Getting the long time frequency right is more like the easy part.

It somewhat seems that the specific GPSDO circuit from the start of the thread did something wrong in the PLL / frequency divider implemented in a µC.

I think most of us know this. See my post #19 this thread. Use oscillator as clock to uP, easy to count 10M between 1pps. Satellite transition is only a worry using PLL with short time constant. Since I don't use PLL and accept a noisy 1pps signal it has no effect.

[AndyFl]

A few years ago I came across an issue where several GPS modules (receiver built into antenna unit) were installed near to each other for basestations on a radio network.  They all had problems with stability and sometimes failed to lock reliably.

The solution was to separate the units by at least 2 metres from each other. It appears that they radiated on-frequency signals from the amplifiers (local oscillator?) which caused interference to each other.

Worth bearing in mind if you are comparing units side by side. 

Andy