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.