Yet another DIY GPSDO - yes, another one

[thinkfat]

Hey Marko! I'm pretty new to designing electronics, that's why I trying to force this as much as possible to be a software project hah. But to your point, yeah essentially we end up in the middle of the last pulse... it seems to follow pretty consistently when it's +1, the next one will be -1 and vice versa (but sometimes not). I'm a visual learner so I'd have to see your idea in action.

I appreciate the feedback everyone.

Well, with this type of design, this is the best you can hope for. The control loop now needs to be tuned so that the time between the "bounces" is maximized, i.e. the drift of the OCXO against the GNSS is minimized.

[trrriple]

I'm curious what the effect or reporting the average of the last two sample counts to timeLab vs always reporting the previous sample count. Or is this cheating somehow? 

[S57UUU]

Wouldn't any symmetrical distribution average out? A sawtooth is a quasi uniform distribution, should work?
I see more of a problem when the internal clock frequency passes an integer value in Hz, and the sawtooth slows down, even beyond measurement interval.

Another possibility would be to measure the time between two changes (in the same direction) of the captured value. The inverse value could then be used to do a FLL.  But sawtooth could make this a bit hard? Maybe one would be able to keep the pps in the middle of the 100ns window, so that so that a +-10ns sawtooth would not hit the edges (most of the time)?

Marko Cebokli

[Carsten]

Wouldn't any symmetrical distribution average out? A sawtooth is a quasi uniform distribution, should work?

If it were a perfect, zero mean, coherently sampled sawtooth it would average out over integer multiples of its period. However, in reality it's quite unlikely to meet all of these criteria. GNSS receivers' sawtooths are far from perfect. That's why timing GNSS receivers typically offer additional information to correct the quantization error.

Maybe one would be able to keep the pps in the middle of the 100ns window, so that so that a +-10ns sawtooth would not hit the edges (most of the time)?

Realizing that is not trivial, because you cannot determine where within the 100 ns window the PPS edge is currently located, so within that window you cannot determine the current drift. Like thinkfat pointed out above, you can only try to minimize the transitions.

There really is no replacement for PPS time measurement resolution. A straightforward way to achieve that would be to use your MCU's timer capture, if you can lock its PLL to your OCXO's output. With the black pill that will require some hardware modification, but will give you ten times the timing resolution (10 ns).

[S57UUU]

I've looked at a "sawtooths" from three specimens of ublox NEO 6M modules, and they look even more scrambled that the ones in your link (will attach a graph Monday, when home). However, they aren't that far from zero mean (they don't have the big steps seen in the leapsecond link - those might be specific to the Motorola receiver tested there).
Of course you can not be coherent with the period (most of the time you would be hard pressed to even see a period in there), but who cares - in a longer average, the fraction of a period cut at the beginning/end, will not greatly spoil the result. 
I am not suggesting you could get "absolute precision" (like sampling an integer number of periods of a perfect sawtooth), but  just about reducing the noise, by say 10 times in a few minutes average.

Yes, it will be a problem when the sawtooth gets "slow", agree there, noted that in previous post. Also saw it in real life on an Oscilloquartz GPSDO (http://lea.hamradio.si/~s57uuu/scdsp/frcomp/index.html#OSAvs5350).

As for the second method, maybe it wouldn't even be necessary to keep in the middle. Just observing the change of the captured value over longer time would mostly eliminate sawtooth effects, because close to the edge, they would come in +1 -1 pairs, cancelling out most of the time.

Marko Cebokli

[S57UUU]

So here is a recording of the "sawtooth" ("qerr" value from the TIM-TP UBX message).
Clearly, the NEO M6 has a much worse clock oscilator than the Motorola. But that, paradoxically, seems to be better for a GPSDO.
Tomorrow I will try some averaging and maybe a histogram.

Marko Cebokli

[S57UUU]

Forgot to tell, the horizontal scale is one second per pixel (about 12.5 min total graph), and vertical scale is plus minus 12 ns.

[nealix]

Question re M8N UBX config message in the code;

In the source code, during startup/setup, a UBX message is sent to the M8N GPS module to set the
mode into "stationary".    When I tried installing an M9N gps module on my breadboard, this part
of the project code fails.   I can assume that the M9N GPS modules have changed or extended the
code needed to set the mode into stationary?

Does anyone know where I can find an example, or find details of the config commands, for both module
types, so that I can figure out what needs to change in the code?   Alternatively, does anyone already
know what command code to send to a M9N module to set stationary mode?

Thanks,

Neal

[Carsten]

ublox' 9th generation receivers have an entirely new configuration interface and ublox recommends to use it. The old configuration message format is officially deprecated, but still kinda supported. Using the old message to set the stationary mode should still work, but I haven't tried it.

IMHO, the new configuration interface is vastly superior to the old format and I ended up rewriting my software to employ the new interface. If you want to use it, too, you have to set the CFG-NAVSPG-DYNMODEL config key to STAT (2). Unfortunately, I don't have the binary message for that available.

[S57UUU]

I made a small program to average qerr (the "sawtooth") and draw a histogram, see below.
The top graph is just the last 12 minutes of raw qerr data from the ublox, the mid graph is a running "boxcar" average over 100 samples. Works quite well!
Below is the histogram of qerr over a few hours. The peak at zero is a program bug, bad rounding (everything from -1 to +1 went into bin zero).
Note that the "scrambledness" of the qerr is not caused by bad GPS reception. I used a good antenna with practically unobstructed view of the whole sky.
On the other hand, when I replaced the ublox's internal 26MHz oscillator with an OCXO, I got a very nice sawtooth, like the Motorola in the leapsecond link.

[AndrewBCN]

...
Does anyone know where I can find an example, or find details of the config commands, for both module
types, so that I can figure out what needs to change in the code?
...

Hi Neal,
The config commands and protocols are described in detail in the rather long u-blox Receiver Description for the respective GPS receivers.
For the M8 (474 pages) : https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf
For the M9 (252 pages) : https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf

[S57UUU]

Here is qerr with a Telequarz 26 MHz OCXO. Clearly, this would average much worse than the jagged qerr with the original osc.

[nealix]

@Carsten and @AndrewBCN:
Thanks for the pointers on the UBLOX M9N GPS module;
CFG-NAVSPG-DYNMODEL config key to STAT (2).  for setting stationary mode.

I attempted to work this programming out, for educational value, with only the UBLOX documents mentioned in the post, and a blank sheet of paper.  I worked out the M9N CFG NAVSPG DYNMODEL message payload in hex
and wrote it down.  Then I decided to validate this learning attempt by doing the same message in U-Center 22.02 and watching the hex message that is actually sent to the receiver module if I command it to stationary mode.

FYI, at this point, I learned that there is a mistake (two actually) in the UBLOX document.   UBLOX interrface description, https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf,
on page 87, has the data structure (field definitions) for the UBX-CFG-VALSET message, used to set values in the runtime RAM database.   Page 87 is wrong.   At payload byte offsets 0 and 1, they claim these are one byte values,
U1 and X1 (one byte each), followed by the two bytes of reserved zeros [U1]2.    In fact, while running this config message in Ucenter, the version is 2 bytes, and is equal to 0x09 at byte offset zero, followed by 0x00 at byte 01.
And next, the Layers bitmask, instead of one byte, is actually 0x00 at offset 03, followed by the actual bitmask for RAM, 0x01 at byte offset 4 in the payload.   After that comes the two reserved sets of 0x00.
In U-Center I can watch both the sent hexadecimal message for configuration, along with the checksum, and also the CFG-ACK-ACK message that comes back, along with it's checksum bytes.
So U-Center proved to be a useful shortcut, and also a "Document Validation Tool" :-)    I hate it when the manufacturer's programming docs are wrong.   Apparently not enough employees at UBLOX to actually review
what some other person wrote, BEFORE they ship it :-)

For reference to help others, U-Center shows that it sends this string of bytes to the M9N in order to set STATIONARY mode;
B5 62 06 8A 09 00 00 01 00 00 21 00 11 20 02 EE 4B

U-center also shows that this, below, is the success acknowledge response (UBX-ACK-ACK);
B5 62 05 01 02 00 06 8A 98 C1

FYI only.

Neal

[thinkfat]

FYI, at this point, I learned that there is a mistake (two actually) in the UBLOX document.   UBLOX interrface description, https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf,
on page 87, has the data structure (field definitions) for the UBX-CFG-VALSET message, used to set values in the runtime RAM database.   Page 87 is wrong.   At payload byte offsets 0 and 1, they claim these are one byte values,
U1 and X1 (one byte each), followed by the two bytes of reserved zeros [U1]2.    In fact, while running this config message in Ucenter, the version is 2 bytes, and is equal to 0x09 at byte offset zero, followed by 0x00 at byte 01.
And next, the Layers bitmask, instead of one byte, is actually 0x00 at offset 03, followed by the actual bitmask for RAM, 0x01 at byte offset 4 in the payload.   After that comes the two reserved sets of 0x00.
In U-Center I can watch both the sent hexadecimal message for configuration, along with the checksum, and also the CFG-ACK-ACK message that comes back, along with it's checksum bytes.
So U-Center proved to be a useful shortcut, and also a "Document Validation Tool" :-)    I hate it when the manufacturer's programming docs are wrong.   Apparently not enough employees at UBLOX to actually review
what some other person wrote, BEFORE they ship it :-)

For reference to help others, U-Center shows that it sends this string of bytes to the M9N in order to set STATIONARY mode;
B5 62 06 8A 09 00 00 01 00 00 21 00 11 20 02 EE 4B

Neal, you got that wrong.

Code: [Select]

B5 62: UBX header
06 8A: message class and id
09 00: payload length (4 + 5 configuration values)
00: message version
01: layer = RAM
00 00: Reserved
21 00 11 20 02: 5 configuration values
EE 4B: checksum

It's exactly as specified.

[nealix]

@ThinkFat:

Thanks for that.   It looks like I misunderstood the "4+[0..n]" shown in the message structure banner in the middle of that page.
I now can see that the "4" applies to the Header and Class and ID fields.   The [0..n] part is more vague, and not specifically clear
like the payload fields in the table.   It would have been helpful if UBLOX simply called out the length field as 2 bytes, little endian.
Either way, watching what U-Center message bytes that were actually sent, along with your helpful reply, has made it clear.

In U-Center, I was able to issue a read/ get value, to confirm that the receiver has been set into stationary mode.

Thanks for the help,

Neal

[nealix]

OK, I found the page in the UBLOX manual that I had missed, page 43, section 3.2, makes the field length in bytes perfectly clear;
https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf

Neal

[MIS42N]

I don't know if it is of interest to this group, but I use a different algorithm to a PLL and it works quite well. The caveat is that the voltage change/frequency change ratio of the OCXO be known. My GPSDO runs a calibration to determine this and writes it to flash memory.

The circuitry receives the 1pps from the GPS module, times it to the nearest 25ns. If the OCXO and GPS are in sync, the difference is called 0. If there is a difference, it is measured in 25ns intervals so a difference of one cycle would be -4 or +4 depending on if the OCXO is fast or slow.

The algorithm accumulates the values in an accumulator array of 16 bit values, the array is 2 x n - n depends on the longest useful accumulation interval, the interval is 3*2^n-1 seconds. The idea is to accumulate information over 3 consecutive time intervals, then try to fit the curve at^2+b^t+c (t=time) to the curve to find out the current deviation of the OCXO. This is done over different time scales, each being 3*2^n seconds.
The shortest time is 3 seconds. The algorithm to fill the array at each scale is:
For the first received difference at the scale, fill in accumulator 1
For the second received difference, fill in accumulator 2, add accumulators 1 and 2 together and hand to the next scale
For the third received difference, do the curve calculation, determine an estimated error at the time, test it against a limit.
If the limit is exceeded, apply a correction to the control voltage. If the limit is not exceeded, make the third difference the new first difference in accumulator 1
The received difference at 2^0 is just the 25ns difference from the circuitry. For higher values of n it is an accumulation over a time period e.g. n=8 uses three intervals of 256 seconds.
In practice it is useful to nominate a maximum n, and if that interval is reached do a correction.
This algorithm has proven unbreakable. It will start disciplining after about 2 minutes of warm up of the OCXO and keeps lock from then on. After 15 minutes with an OSC5A2B02 the OCXO becomes relatively stable and the output is +-1 or 2 parts per billion of 10MHz.
 

[nealix]

Does anyone know of a "completed" DIY GPSDO project that;

1.  uses parts or modules that are still available
2.  uses a PLL rather than an FLL
3.  will share schematics and code?

While waiting for Andrew to return this summer, I thought I would study and educate myself more on the PLL
option, and how it is wired, what low pass filter is used, which frequency is used in the PLL phase detector (not 1 PPS after
reading posts from @ThinkFat), and what the software does since the MCU inserts itself in the PLL loop.
Unfortunately, the more I googled down the rabit-hole, the more that I found unfinished projects, or projects
from someone who had done it but does not wish to share the code or the schematics, etc etc.
I know that LARS uses a PLL and it is a working/finished project, but his PLL is unique in that the two
frequencies compared for phase are not the same.   Several other projects try to compare 1HZ and 1PPS,
but the better ones program the GPS module to put out 10Khz or even 100Khz and compare that with
the same divided down output of the OCXO.

If anyone knows of a PLL based GPSDO project that meets the 3 criteria listed above, then that should keep
me busy studying and learning until Andrew returns later on.

Cheers,

Neal

[Johnny B Good]

@nealix

 Since you've had no response so far, I'll point you to a reply I made to bob near the beginning of this topic thread (page 5 reply #123) which may answer all your stated conditions (except for the 'code' since none is used) 

[nealix]

Thanks John:

I reviewed that and it helps.
I guess an honest question for you and the rest of the forum is this:   For casual home use, for test equipment and radio use, I certainly don't need more accuracy than +/- 0.001 Hertz, and Andrew's simple FLL GPS already does that just fine.   
I can go build the Jame's Miller PLL GPSDO with junk box parts right now, and I might be wrong in thinking that it would also do approx +/- 0.001 Hertz accuracy, or does it's PLL do much better?
I am having trouble understanding the interest in Lar's GPSDO, since it looks like it has taken each builder weeks or months of labor screwing around and adjusting to get it stable and locking and where they want?
Or is that just for fun since they are time nuts searching for supreme accuracy beyond basic need? Certainly by comparison, Andrew's STM32 FLL and James PLL design just simply power up and work, no fuss.
Lar's design appears, to the newbie reader, like an untame race car with a loose steering wheel, sensitive to where you are, what parts you build it with, and many other variables.   That reduces the value
proposition, unless it is simply about education and game?

A.   No disrespect for Lar's, it is a cleaver and amazing project, but a lot of work and adjusting.
B.   Sorry for this off-topic post in Andrew's thread, but I am trying to understand the need, and value, for going much further on this project (such as PLL) if it already works so well with the FLL.

I guess I don't know how to determine if there is a real need to go beyond the simple FLL design, for  non-commercial simple at-home use?   It seems like I already have more accuracy than I really need?

Opinions, comments, thoughts, reprimands? :-)

Cheers,

Neal

[thinkfat]

Well. If the current solution is good enough, the engineer in me says: "stop right there!". Going further than your needs means you'll be drifting into time-nuts territory quickly, and that's a deep rabbit hole I can tell ya.

[Johnny B Good]

Hi nealix,

 I'd have replied sooner but I've been testing an SA22C which I'll be using as a 'referee' to decide whether my suspicions that the GPS might currently be suffering fall out from the Ukraine war in the form of electronic countermeasures (whether Russian or even American activities or both).

 I've been testing the thermal  control algorithm of an LPRO 101's base plate temperature running on a Nano3 mcu which controls an 80mm fan cooled heatsink bolted onto said base plate. Early this month, I noticed some peculiar 'one off' 10 to 20 ns phase jumps between the GPSDO's and LPRO's waveform traces. I actually caught one such event in the act!

 Initially, I'd suspected a developing problem in the LPRO or the 19v laptop charging brick used to power it but, after taking the lid off the LPRO for the first time almost two years on from its initial purchase to check the lamp and clean some 20 years or more's worth of atmospheric contaminants off the glassware in a successful attempt to raise the lamp voltage and fix the low servo signal amplitude, these random "glitches" still persisted, leading me to consider the possibility that the GPS itself was being effected by the Ukraine war.

 Today, I decided to disable the SBAS option which initially had shown a reduction of the ionospheric errors that normally account for most of the 7 to 8ns phase wander in the output from my G3RUH based GPSDO since I suspected this was the 'low hanging fruit' most likely to suffer the attentions of the Russian military's electronic countermeasures division.

 After allowing ten minutes for things to settle down, I did see a significant improvement over the 5ns pk-pk phase wander in between the randomly spaced 'transient events' over the past 3 weeks or so. IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernised version of the G3RUH design (in peace time at least!) but bearing in mind that a 1mHz offset requires a sustained 100ps per second phase drift rate (one full cycle slip at 10MHz over a 1000 second interval), you can be the judge of that by examining the 10 screenshots taken over a 20 minute time period started just after the GPSDO had recovered from its loss of SBAS assistance (or hindrance!) that I've attached to this reply.

[Johnny B Good]

 Here's what happened after that screenshot sequence was acquired. Looks like yet another 'random event' to me.

 The 'scope displays the date and time in the bottom right hand corner btw.

[nealix]

IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernized version of the G3RUH design...

Hi John:

You may have mentioned it previously, but where would I find a schematic for the improved version of the
G3RUH design?  I should definitely build one up, as I seem to have enough parts in my bins.

Cheers,

Neal

[Johnny B Good]

IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernized version of the G3RUH design...

Hi John:

You may have mentioned it previously, but where would I find a schematic for the improved version of the
G3RUH design?  I should definitely build one up, as I seem to have enough parts in my bins.

Cheers,

Neal

That reply to Bob that I pointed you to shows a picture of the circuit diagram I'd hand drawn for the MK II version. It's a high enough resolution image if you download it and use a graphics application to view or print it out on an A4 sheet.

https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/msg3620946/#msg3620946


Not everything in that circuit is essential to its primary function as I proved when I first lashed up a version of Gyro's minimalistic version of the G3RUH design linked to below and minimised it even further. I left out the cmos RRO opamp because I didn't have one to hand at the time and fed the PLL output straight into the EFC pin of my 13MHz square wave OCXO which fed some TTL magic to produce the required 10MHz square wave locked to the OCXO as a "Proof of Concept" exercise.

https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133

 The main improvement arose out the u-blox gps receiver modules we were using in place of the Jupiter-T that James had used to halve the 74390 IC count of the earlier designs that phase locked directly from the 1PPS to just two ICs (actually one and a half versus three and a half 74390 ICs  ). The ublox modules could be programmed to output any frequency to the nearest Hz locked to the received 1PPS over the range of 1 to 16,000,000 Hz plus of course they had better sensitivity and supported a lot more than the Jupiter-T's limit of 12 (or was it 8?) channels.

 I, as did Gyro for pretty much the same reasons, chose to PLL at 100KHz since it seemed a reasonable compromise between complexity (only single 74390 required) and odd harmonic spectral power density in the 1.7GHz band that could compromise the GPS signals if the PLL had been run at the OCXO's output frequency. I did actually experiment with PLLing at 1 and 10MHz and observed a reduction in the C/No levels. Admittedly this was with a simple unscreened wire link on a breadboard setup without the obligatory 33 ohm series resistor at the source end to tame the generation of the higher order harmonics - something I took account of when designing the MK II even though I was PLLing at a mere 100KHz via a short piece of co-ax... inside of an aluminium enclosure.

 The startup accelerator circuit can be omitted if you're using a PLL TC of 1000 seconds or less and don't mind waiting some 25 to 30 minutes to achieve a stable lock (you really need to allow the OCXO a good 20 to 30 minutes for it to settle down anyway). Also, you can replace the '4046 with a 7486 quad XOR gate - I only went for the '4046 option to allow me to experiment with its three different PLL detector options, discovering that the XOR detector proved to be the best option in this case.

 The connection between the OCXO's Vref pin and a resistor network tapped at 1 volt intervals allowed me to use a cheap 9999 counts Mestek on its millivolt range by measuring in my case, how many millivolts the EFC voltage was above the 2 volt tapping (the Vref pin provides an extremely temperature stable reference at low 1mA or less loadings). It's not essential (indeed your OCXO might not even have such a pin to connect to) unless you want to try the same trick to track EFC variations down to a tenth of a mV without tying up a more expensive 4 1/2 or 5 1/2 digit benchmeter).

 Anyway, that should be enough to let you make a start on lashing up a gpsdo on a solderless breadboard to experiment with.

 I've attached three more screenshots covering the last 5 hours of run time. I have to admit that I succumbed to temptation just after the second screen grab and tweaked it up by about 10μHz some 5 hours back. I don't think it made that much difference because it looks like the GPS swerved itself back on track about 4 1/2 hours ago and it's looked pretty much the same since then on.

 I'll clear the persistence in a short while before retiring for the night to see how much it's drifted by the late morning (some 7 or 8 hours' worth of run time).