Budget GPSDO - complete

[trobbins]

I was able to adjust the 10MHz varicap oscillator in my HP3325A synthesiser, and the 10MHz TCXO in my Systron Donner 6250A counter (circa 1975) to MIS24N's GPSDO over the last few days.  I have the GPSDO showing it is within 0.01Hz of 10MHz (from a consistent 1 sec indicator flash, that only sometimes double flashes to show it is outside of 0.01Hz).  I'm still waiting on some TTL to USB interfaces to look more closely at the detailed data available from the PIC.  I have the two cheapest chinese Neo7M GPS receivers and confirmed the active antenna could see more than 8 sats.  I'm just using a smps 5V plugpack for regulated rail, so nothing special for powering.

The SD counter was initially about 9Hz high - it has a 1Hz resolution and now displays to 10MHz +/1 Hz.  It powers up about 7-9Hz low and then settles after about 15 minutes.

My HP3325A's oscillator is not crystal derived and a commanded 10MHz generates a slow drift with some cycling of a few Hz that averaged about +9Hz.  So adjustment was more about moving the average to 10MHz.  The 3325A has 0.1Hz command resolution, which can only really be used with the GPSDO as the external reference.  The 3325A external ref takes in up to 10MHz, and accepts the GPSDO default signal level to achieve PLL sync.  Using a scope to display the GPSDO output and a 9,999,999.9Hz commanded signal from the synced 3325A shows a nice slow roll between waveforms.

Very happy and pleased with the outcome, and a big credit to MIS42N for all the development work, as preparation of the GPSDO module was somewhat of a breeze !

[MIS42N]

The not so budget GPSDO is now running with a purpose built power supply. It has a buck converter taking a nominal 12V and putting out 6.9V. In theory the input could be anywhere from 9V to 24V but only tested with around 12V. There are 3 devices using the 6.9V. The OCXO has a dedicated 5V regulator (LM1085). Another LM1085 supplies 5V to the rest of the circuit. The third device is a boost converter to deliver a nominal 12V to supply a precision voltage reference, a MAX6350.

The PIC PWM is now buffered using a complementary FET pair 2N7000/BS250. The pair are supplied by the voltage reference to provide a stable control voltage.
The PIC serial output is buffered by opto couplers 2 x 4N25.

So how does it perform? At first it had trouble reliably delivering 10MHz +- 0.01Hz but this was using a 'new' scavenged OSC5A2B02 OCXO and it needed 'burning in'. After 2 weeks running it is mostly delivering 10MHz +- 0.001Hz and still improving.

This justifies the use of the FET buffering. Previously the reported control voltage varied with temperature (and other factors). This was likely due to variations in the PWM output voltage which in turn is dependent on the supply. Now the only variation appears to be due to settling of the OCXO, about 400uV a day.

The algorithm currently makes adjustments every 1536 seconds (if nothing causes it to take action earlier). In that time the OCXO is allowed to lose or gain up to one cycle, with adjustments designed to reverse the loss/gain in the next measurement period. Most measurement periods it is now less.

Until now there has been no drift compensation. It looks like it is worth trying it now most other factors are controlled.

The software was designed with the intent to handle both positive (increase control voltage increases frequency) and negative (increase control voltage decreases frequency) control. This was not previously tested. The FET buffer is effectively an inverter, the software handled it. Very satisfying.

Next step is to see how the system behaves driving a better OCXO. I have a Morion MV89 to try. Also the current design can be committed to a PCB. The system is quite modular, for people who just want a basic GPSDO it will be simple to supply 5V and replace the power supply, opto coupler, FET buffer with wire links just leaving the original 'budget GPSDO' design.

[trobbins]

I've been able to set up two of MIS42N's GPSDO pcb assemblies, as well as connect each assembly to its own GPS receiver, and to view the rolling drift behaviour of the two trained 10MHz OCXO signals on a scope. 

It's very gratifying to see the two outputs in very close sync with little differential drift.  One of the GPS receivers connects to an active antenna that can be easily placed where it can track at least 8 satellites.  The other GPS receiver I have only has an on-board passive antenna and it sometimes struggles to track 7 satellites even when placed in the same outside location.

Each GPSDO assembly has a TTL output that can be patched to a USB interface (I use an RS232 go-between) which then allows PuTTY to view the GPSDO diagnostics/status, or to pass through the NMEA signals to see the operating status of the GPS receiver on something like VisualGPSView (as per the photo).

I'm not trying to achieve a lot better the 1ppb performance, so both GPSDO are simply powered direct from a 5V regulated smps plugpack, and the 6-8 satellite tracking is providing many minutes/cycle of scope roll, so nicely better than 1ppb (0.01Hz) differential error, and each GPSDO assembly has a flashing LED configured to indicate when error is within 1ppb, and a PuTTY connection confirms the actual ppb level is easily under 1.

[MIS42N]

Although I haven't updated this for a while, the project has not been abandoned. A new PCB has been created incorporating suggestions from others and some ideas. It still uses the same basic circuit as the original PCB - i.e. PIC16F1455 controller, 74HC04 buffer, OSC5A2B02 oscillator. The main improvement is to isolate the OCXO electrically from the rest of the circuitry, as users have found the original system was sensitive to changes such as attaching a lead to the BNC socket. The isolation consists of opto couplers for the serial connection, control voltage buffering, and dual linear regulators - one for the OCXO, one for the rest of the circuitry. - previously the serial connection could have an earthing problem with the earth connected to a PC and also whatever was connected to the BNC, creating a possible loop.

The power supply has changed from 5V to a nominal 12V, using a buck converter to drop this to around 7V to supply the two LDO regulators.

Provision is made on the PCB for the option of a precision voltage source for the control voltage. The MAX6350 is quite expensive and not common so testing is being done to see if the benefit justifies the extra expense. Preliminary results say ... probably not. The option can be bypassed by running a jumper from the OCXO LDO to the control voltage buffer.

Also allowance is made to add a line receiver and Ethernet socket if the GPS unit needs to be located remotely (a technique discussed in this topic some time ago).

The PCB has been made narrower, and it is possible to shoehorn the buck converter, GPSDO circuit, GPS module into a UB3 jiffy box. Also the PCB has mounting holes for M3 screws.

The software now incorporates the ability to update using the xmodem facility in teraterm, directly from a hex file. If the circuitry is in a box, this allows updates without opening the box. And does not require a PIC programmer.

Attached is the nominal circuit used to create the PCB. It shows a line driver instead of a line receiver, the pins are the same and there didn't seem to be a receiver template. Also the opto couplers being used are 4N35, not 4N25, and the resistor values are different.

[MIS42N]

Fits OK in a UB3 Jiffy box (I can't find out if this is a size unique to Australia, or something international). The interconnects are 10cm jumper cables with female DuPont connectors. The buck converter is mounted on its side on the right of the interior photo. It is attached by solid copper wires scavenged from an earth wire. The unpopulated areas of the PCB are for alternate configurations.

[MIS42N]

I created a kit for sale in Australia for $55, all the parts for a working GPSDO except the 12V power supply, and the constructor supply an enclosure if they wanted one. That included a NEO-7 with active antenna on a 3m lead, USB/serial converter, and buck converter. And postage. A few people took up the offer and at least one has it running successfully.

I was disappointed in the performance of the system with less than ideal antenna placement. I began testing with the antenna indoors near a window, with another building about a meter away. So quite a limited view of the sky. The performance was marginal, able to hold 10MHz±0.01Hz (i.e. 1 part per billion) most of the time but with occasional excursions into the 0.02Hz range. The disciplining algorithm was a quadratic fit to the data, so sensitive to frequency drift in the OCXO. But drift in the PPS signal from the GPS was being misinterpreted.

So I reverted back to a least squares linear algorithm. I abandoned it a while back because the way I implemented it, it couldn't do better than ±0.005Hz because of limitations in the 32 bit arithmetic. The quadratic fit was implemented a different way so didn't have that limitation. Reworking the quadratic fit method to a linear fit kept the better resolution, and as a bonus can still provide long term frequency drift information that could be used for drift compensation.

Results speak for themselves:



The adjustments are made at 1536 second intervals (usually - sooner if the GPS gets out of hand, but it didn't in this 20 hour period). Mainly running better than 10MHz±1mHz

[MIS42N]

Built another testing GPSDO so I have one for testing extra hardware, the other for software.

The hardware test rig has the UA9639 line receiver option so I can test with the GPS antenna on the roof, the GPS module under the eaves, many meters of Ethernet cable connecting to the GPSDO which is sitting next to my PC. The UA9639 is in a socket, so I can pull it and connect the GPS module to the GPSDO if needed (which is how the other GPSDO is set up - module is in the enclosure). Previous versions had the line receiver on a separate board with its own power supply, this PCB has the provision on the board - but untested until last week.

The results are now very satisfactory. As usual, the new OCXO took nearly a week to settle. Now most corrections are less than 5 parts in 10^-11 at about 25 minute intervals. This is better than can be achieved with a 16 bit DAC [The OSC5A2B02 has a sensitivity of about 0.1V/Hz (1 part in 10^-7). A 16-bit DAC delivering 0-5V has around 1300 steps for 0.1V change. So 1 bit change is about 7 parts in 10^-11]. The programming effort to get a synthesized 24-bit DAC by dithering is paying off .

The next hardware step is to add the precision 5V supply for the control voltage. There is some daily variation of the reported control voltage, which is probably related to temperature. The PCB also has provision for this, bypassed at the moment.

The software mods are to include a drift compensation. Most OCXOs exhibit some small drift over time, this shows up as a small change in the control voltage. The idea is that after a while it will be the same each day, so knowing the change in one day the control could make small changes at regular intervals the next day. May not be worth it, but it is unlikely to have a negative impact. The processor is not working very hard, I think maybe 10% CPU and half the programming memory so might as well use a bit more.

The other thing I would like to try is making compensation to the GPS readings. Yes, I could buy a timing module, but the basis of this project was to get maximum bang for buck. Either use the DOP (dilution of precision) figures to downgrade readings with bad DOP, or to find an average position and downgrade readings when the reported position is way off on the assumption the time will also be off. Or both?

I am somewhat mystified by the lack of comments by others. Have I gone off into some backwater that is not that interesting? Way back I asked for comments and got a few - prefer 12V supply (tick), a PCB that has M3 mounting holes (tick) and fits a standard enclosure (tick). Maybe the PIC and assembler puts people off. Or is it the title - a work in progress. Well, it's truthful. My belief is an OCXO GPSDO can be as good or better than a rubidium standard. So far I've not encountered any brick walls that says it can't be done. So the story continues.

[S57UUU]

Don't worry if we are just lurking, keep up the good work!
I am reading your posts with big interest, because I am also working on a GPSDO (in secret :-).
Will publish all details on my webpage when done. Currently I am doing some experiments, like connecting two Trimble GPSDOs of the same type, to the same antenna (designed an amplified 4way GPS divider), and comparing their outputs, to exclude external errors (ionosphere, multipath ...), and see what the errors are in the receivers themselves, etc.

Maybe one suggestion, based on what you write above, would be to record both position errors and control voltage variance for several days, and analyze the two for correlations.

Marko Cebokli

[spostma]

As I do not need a very precise frequency standard yet,
am following your project with interest and learning from your work.
BTW, I love PICs. I respect all that you achieve in pure PIC ASM!

[MIS42N]

Maybe one suggestion, based on what you write above, would be to record both position errors and control voltage variance for several days, and analyze the two for correlations.

I thought that too. The software was written to pass through the NMEA data or the control voltage but not both. So I added a debug function to do it. To distinguish between the two data streams, which come through the same serial connection, the NMEA data is sent with the high bit set. The ASCII character set uses 7 bits but the data is sent with 8 bits, so that 8th bit is used to split the data. It was a tricky bit of programming, the NMEA data originates in an interrupt handler, the control voltage data from the mainline. There is the possibility of an interrupt happening while the mainline is queuing a character, with the chance of a total stuff up. So the character queuing routine was rewritten to handle this. The enhanced PIC saves several registers when an interrupt happens, so the queuing routine uses only those. There is a pointer that needs updating, so interrupts are disabled while that happens. Seems to work OK.

The combined data stream is separated by a BASIC script file on the PC. So that achieves the recording function. Analyzing is proving more difficult. With good GPS data, there isn't a lot to see. With not so good GPS data, the control voltage is pulled around and it is difficult to determine if the GPS data is bad or the control voltage has been pulled too far. I am having trouble getting my head around the problem - another 'work in progress'.

A note to anyone designing their own GPSDO. The best design decision I made with GPSDO version 2 was to electrically isolate the OCXO as much as I could. It has its own linear regulator, the control voltage is buffered via a pair of FETs, the 74HC04 used for output is off another regulator. So the OCXO is not affected (much) by the processor, or loads being attached.

It's good to know this is of interest to some people. Should I think about putting this up on GitHub? I haven't done it so far because I don't know how. Maybe I should know how.

 

[MIS42N]

The quest continues.

The newly built GPSDO (same base PCB as the previous version) was run for a week, then shut down to fit the MAX6350 5V precision regulator. A few days later we went away for a week and I left the PC on, recording data from both GPSDOs.

The software in the older GPSDO was modified to provide drift compensation. As noted before, this is probably a waste of time but it is now debugged and working. It is quite simple - the nominal control voltage (a 24 bit variable) is added every second to an accumulator (creating a 48 bit sum). This is subtracted from the accumulator for the previous day (at UTC 000000 - trivial information), the difference divided by 86400 to get the difference between the average voltage for the 2 days. The difference is multiplied by 65536 (2^16) then divided by 86400. The result is (the change in control voltage)*2^16 to be applied each second (multiply by 2^16 because it is much less than the least significant bit of the 24 bit number). That result is then added to a 16 bit variable every second, when the 16 bit variable overflows/underflows then the 24 bit control voltage is increased or decreased by 1. This usually happens at intervals of hundreds of seconds, each change equates to a frequency change of about 3 parts in 10^-13 so has almost no effect short term but over many minutes has a tiny effect which *may* be beneficial.

Ten days of data was collected from the system with the precision regulator, the results are in the chart attached. The top line clearly shows when we came home, the voltage wiggles up and down for 3 days. This is likely due to daily temperature variation - while the house was empty it would be little affected by the weather outside, but once we opened a few windows and doors, the inside temperature would change more. Which leaves the question - is the gradual rise due to the house slowly warming, or is it oscillator drift. The good news is the regulation kept the oscillator 10MHz±1mHz for almost all the time, including when we were in the house.

After changing from a quadratic to a linear curve fitting algorithm for averaging results, there was no need to take three successive averages of the phase errors, two would be enough. So the algorithm has been rewritten yet again, in the last few days, to use two averages. An explanation: if the two averages are A and B then B-A gives the phase change between the two averages. A phase change is caused by a frequency error. If the phase change is D, then the phase error at the end of the two measurement periods is (A+B)/2+D. Compensating for both should drive the oscillator to zero phase error with respect to the GPS. In reality there will be a residual at the end of the next measurement period so the process is repeated.

The averaging is done over 2 periods of 2^n seconds, currently trialling n=10, two periods of 1024 seconds. Initial results are that this is a bit long, it gives the OCXO time to wander too much. The algorithm catches the wanders, but it is preferable to set the maximum period for least wander - a compromise between gathering enough data points to iron out second by second GPS variability, and allowing the OCXO too much leeway to wander off. The three point algorithm seemed OK with 3 periods of 512 seconds, so 2 periods of 512 seconds may be better.

There isn't much to do now with this design. I believe it is as cheap as a GPSDO can be, and still produce 10MHz within 1 part per billion and verify it. There are many designs on the Internet, but I have not seen one that can measure its own performance the way this one does. Anyone can count cycles for 10,000 seconds and say on average the design is producing 10MHz within a certain tolerance. But with a 16 bit DAC and corrections applied every few seconds or minutes, there is no way to verify the frequency at any point in time, except by comparison with a better standard (GPS locked rubidium or cesium).

Further development is feasible (try to correlate GPS position errors with GPS 1pps errors) but is there a point? I have asked in the past if anyone has a use for better than 1 part per billion in a hobby situation but not received a sensible reply. So I am thinking in a month or two I'll close off this thread. Maybe with a report of some description. What do people want to know that I haven't already covered?

[S57UUU]

I am playing with radio astronomy and interferometry.
http://lea.hamradio.si/~s57uuu/astro/sidi1_2/obs/dec-10.htm
http://lea.hamradio.si/~s57uuu/astro/sidi1_2/index.htm
Some day I would like to try VLBI, where accuracy beyond 1E-10 is desirable, especially on the higher frequencies. I hope to go down in the -12 range, using disciplined rubidiums.

Marko Cebokli

[MIS42N]

Some day I would like to try VLBI, where accuracy beyond 1E-10 is desirable, especially on the higher frequencies. I hope to go down in the -12 range, using disciplined rubidiums.
Marko Cebokli

That's impressive work you are doing. I think we share the same philosophies to some extent - keep the cost down, don't rely on complex systems with unknowns. That's why I use assembler for this project - the whole program is a single (large) source file containing everything. There is no included libraries except the one for the PIC16F1455 symbols. I use a 32 bit signed arithmetic package (included in the source) written by someone else (with attribution). I am tempted to rewrite it as it is for the original PIC designs that didn't include the arithmetic ADDWFC and SUBWFB instructions (ADD with carry, SUBtract with borrow) so the package had to program around it with extra instructions. However, if it isn't broken, don't fix it.

I can see why you want better timekeeping. You won't get it with the hardware I've used. The OSC5A2B02 has a sensitivity around 0.1V/Hz, the better OCXOs can be 1V/Hz which is 10 times better already. Also, the NEO GPS has quite variable 1pps and you need something better (LEA?) with a decent antenna (quadrafiliar?). The software approach used in this project may work with a few modifications. Because the intermediate GPS modules still have jitter, this actually works to the advantage of a design limited to 25ns intervals. If the disciplining drifts the oscillator so half the received 1pps are 0 phase offset and half are 25ns later, the average over many 1pps is 12.5ns later. And with many samples the statistical uncertainty is 1 or 2 ns. I believe a straight OCXO solution can reach 10^-11 accuracy, but 10^-12 is more than an order of magnitude more difficult. I estimated to go from 10^-9 to 10^-10 required about a 30 times improvement (longer integration period to get statistically valid 1pps readings; and, because longer periods are needed, a more stable oscillator). I think -11 to -12 would be similar.

I am thinking of trying for more accuracy with different hardware but the same software, just to see if it works as I think it should. However, that field is crowded with other designs by people with a lot more money than I have. So it will be for my own satisfaction. The software is very generic, it will handle positive or negative slope control of the oscillator (the original design was a positive slope, this design appears as a negative slope because the signal is inverted by the FET pair. The software detected it during calibration and worked without change). There is a 1 line change to modify the software to 'see' what looks like a negative slope (as in the current design) as a positive slope and report it correctly. Also, the calibration on first power up determines the sensitivity of the OCXO and stores it as a 12 bit precision value with an exponent, so the arithmetic will always stay within the 32 bit limit. And it should handle averaging periods of more than a day, which is unlikely to be used in real life. The synthesized 24 bit DAC from PWM dithering is able to adjust in amounts of about 3 parts in 10^-13 with the current OCXO, with a 1V/Hz this would be 3 parts in 10^-14. So not a limitation.

At some point, I will 'freeze' the software and fully document it. Maybe you could adapt it for your own use.

[S57UUU]

I did some PIC programming in the past, simple stuff, 16F84 etc. So, hopefully, it won't be too hard to read your code. Now I mostly work with MSP430 chips.

Currently I am trying to test a bunch of different OCXOs and rubidiums, that I gathered off Ebay. I have no absolute reference (except for a pair of Trimble GPSDOs), so I am just doing comparisons of stability, and measuring the phase noise. For the last few months I have been "on the verge" of publishing all that online, but I always think of one more measurement that would be nice to do :-)  The problem is, any such measurement takes at least days.

Also playing with disciplining. One approach is to derive the 26MHz clock for a NEO6 from the disciplined 10MHz OCXO with a PLL, and then use the errors reported in the UBX messages to discipline. This avoids the 1PPS problems completely. No need for external measurements, the Ublox internal DSP does that for me.  The whole setup is not as simple as I would like, but it shows promise.
I only have simple feedback loops in the software, no drift estimation/compensation, etc. That's why I'm interested in your experiments with this stuff.

[LADmachining]

I have been meaning to post in this thread for some time, but for one reason and another it has not been done up to now.

A version of the GPSDO was built according to the schematic and code posted in Lars' GPSDO thread.  This was running well with a CTI OSC5A2B02, until that OCXO unexplicably died and refuses to warm up any more.  This was removed and changed for a Vectron OCO100-67, which has been performing well since then (about 6 months).  I don't yet have the PCB in an enclosure, and my workshop is an unheated garage. 



The graphs below show the performance since 31/10:




The NEMA and PPS signals are provided by a NEO-M8T GNSS board in fixed location mode.  These signals are buffered and split 4 ways to feed the other GPSDOs I am running (1x Lars GPSDO with a Bliley NV47A1282, 1x Yannick Turcotte GPSDO with CTI OSC5A2B02 and 1x STM32 GPSDO (AndrewBCN)).

Thank you for making your design available - I am looking to build the V2 design as shown in post 53 once I have managed to source some of the components.  Given the simplicity of your design, I think this is the one that will be incorporated within a 10MHz distibution amplifier I built that was described in Practical Electronics / Silicon Chip magazines.  Would be good if you could put your code / designs on Github - makes it much easier to see if there have been any code updates etc.  Thanks again!

Anthony

[MIS42N]

I have been meaning to post in this thread for some time, but for one reason and another it has not been done up to now.

[...]

Thank you for making your design available - I am looking to build the V2 design as shown in post 53 once I have managed to source some of the components.  Given the simplicity of your design, I think this is the one that will be incorporated within a 10MHz distibution amplifier I built that was described in Practical Electronics / Silicon Chip magazines.  Would be good if you could put your code / designs on Github - makes it much easier to see if there have been any code updates etc.  Thanks again!

Anthony

Hello Anthony. Did I publish enough that you could build it? I have had a few people build versions, but they have contacted me and I've sent more details and the source code.

Do you know which copy of Silicon Chip your distribution amplifier was published - I've subscribed for quite a few years.

In fact, now the project is almost 'finished', I'm discussing getting it published in Silicon Chip. They are enthusiastic, will probably appear next year.

Yes - Github - I should make time to do that.

[LADmachining]

Hello Anthony. Did I publish enough that you could build it? I have had a few people build versions, but they have contacted me and I've sent more details and the source code.

Do you know which copy of Silicon Chip your distribution amplifier was published - I've subscribed for quite a few years.

In fact, now the project is almost 'finished', I'm discussing getting it published in Silicon Chip. They are enthusiastic, will probably appear next year.

Yes - Github - I should make time to do that.

Yes, the V1 was built fine, and I think the V2 will be the same.  The only bit I wasn't sure about were the comments in post #53 about the line driver ICs on the V2 schematic having the wrong symbols, but as I won't be using those I have ignored them.

Is the PIC firmware for V2 the same as V1?

I can't claim any glory for the distribution amplifier unfortunately.  It was in the April 2021 issue of Practical Electronics.  I thought they shared designs with SC, but that project doesn't appear in the Silicon Chip project index.  Let me know if you don't have that issue of PE in your back catalogue.. 

Anthony

[MIS42N]

Is the PIC firmware for V2 the same as V1?

The V1 firmware will work in V2, with a one line change due to the PWM signal being inverted by the 2N7000/BS250 pair. It actually works without changing the line because the calibration pass can handle both positive slope and negative slope control voltages, but the reporting comes out wrong - reports 5V as 0V and 0V as 5V.

Code: [Select]

MOVLW B'11000000' ; enable PWM2
; 1 1 0 0 0 0 0 0
; | | | | ---|---
; | | | |    +---  x = Unimplemented: Read as ?0?
; | | | +--------  1 = PWM output is active low ### INVERTED ###
; | | | +--------  0 = PWM output is active high ### not inverted ###
; | | +----------  0 = PWM Module Output Value bit
; | +------------  1 = Output to PWMx pin is enabled
; +--------------  1 = PWM module is enabled
MOVWF PWM2CON
However, I have worked on the code a lot, the current discipline algorithm is different, there's a bit more reporting and there's a bootloader so the firmware can be updated via the serial port - convenient if the device is in an enclosure. It's still got some rough edges, but usable. I'll investigate Github, see if I can get the project there in a week or so.

[MIS42N]

Now the project is working I've started a GitHub repository for all the bits and bobs. https://github.com/ajcashin/budget-gpsdo

I will monitor this thread for any discussion, and maybe try some other variations (a Morion MV89 DOCXO and a Ublox LEO-M8T is appealing).

[MIS42N]

I bought a u-blox LEA-M8T on what is termed a Huawei board. You can find them on the usual online sites. The board does nothing special, it has a few spike suppression devices, snubbing resistors. I was able to connect it to the GPSDO board with the addition of a 5V to 3.3V LDO. The aim of the exercise was to see if it made much improvement over a cheap NEO. The antenna is the same as was used with the NEO, located on a window ledge. This is not a good location, it has a limited view of the sky due to being the bottom storey of a 2 storey building, with an adjacent building about a metre away.

The M8T was allowed to survey-in so it operated in timing mode. Survey time was 86400 seconds (a day), the resultant standard deviation was about 6m (I believe in an optimal position should be much better).

After running for a few hours, the results show a huge improvement over the NEO.  The last 2 hours:

Code: [Select]

Time 232744 UTC. Ctrl 1.677427 -0.021 ppb
 Time 233616 UTC. Ctrl 1.677433 0.005 ppb
 Time 234448 UTC. Ctrl 1.677448 0.013 ppb
 Time 235320 UTC. Ctrl 1.677489 0.032 ppb
 Time 000152 UTC. Ctrl 1.677517 0.022 ppb
 Time 001024 UTC. Ctrl 1.677520 0.003 ppb
 Time 001856 UTC. Ctrl 1.677547 0.021 ppb
 Time 002728 UTC. Ctrl 1.677541 -0.005 ppb
 Time 003600 UTC. Ctrl 1.677515 -0.021 ppb
 Time 004432 UTC. Ctrl 1.677513 -0.002 ppb
 Time 005304 UTC. Ctrl 1.677509 -0.003 ppb
 Time 010136 UTC. Ctrl 1.677507 -0.001 ppb
 Time 011008 UTC. Ctrl 1.677512 0.003 ppb
 Time 011840 UTC. Ctrl 1.677537 0.020 ppb
 Time 012712 UTC. Ctrl 1.677558 0.017 ppb
 Time 013544 UTC. Ctrl 1.677553 -0.004 ppb
 Time 014416 UTC. Ctrl 1.677563 0.008 ppb
 Time 015248 UTC. Ctrl 1.677557 -0.005 ppb
 Time 020120 UTC. Ctrl 1.677557 0.000 ppb
 Time 020952 UTC. Ctrl 1.677568 0.008 ppb
 Time 021824 UTC. Ctrl 1.677599 0.025 ppb
 Time 022656 UTC. Ctrl 1.677604 0.004 ppb
 Time 023528 UTC. Ctrl 1.677645 0.032 ppb
This shows a frequency error of less than 0.4mHz (4 parts in 10^-11). That is better than achieved with a NEO with an antenna on the roof (clear sky view).

Is it worth the trouble? it depends on what you want. The Huawei board cost more than the rest of the GPSDO. The GPSDO with this receiver would make a good reference for a transverter working in the 10-100GHz region - 4Hz error at 100GHz might be acceptable.

Next - try this with the MV89 DOXCO. And continue this test to see if it stays as good as it started out.

[MIS42N]

After running the LEA-M8T for a few days, here is the result. It is not quite as good as the first few hours but definitely worth having for more difficult reception situations. It was good enough to show a small deficiency in the disciplining algorithm. It previously aimed to get the 1pps in a 25ns window (an error of zero). As a consequence the phase error drifted from one side of the window to the other. To combat the problem, the algorithm was adjusted by increasing the phase error by 25ns if it is positive. This has the effect of forcing the algorithm to seek a point where +ve and -ve errors balance. An expected behaviour by the cheaper GPS units due to jitter in the 1pps.

The accompanying graph is control voltage and corrections in ppb. for nearly 2 days. The corrections are well under 0.1ppb (implying a frequency error of less than 1mHz). The longer term variation of control voltage of 300uV is almost certainly due to room temperature variation (dropped from around 28C to around 22C).

[MIS42N]

Now the GPSDO using the LEA-M8T as a GPS receiver has been running for a while, its advantage is clear. The measurement period was changed from 512 seconds to 1024 seconds and that almost halved the size of applied corrections. I'm not sure of the significance. If it was the statistical error due to jitter in the 1PPS the reduction would be less. It implies short term variations in the GPS signal itself.

It took more than 2 days from a cold start to reach stability. The first 2 days have been deleted from the accompanying graphs, and it can be seen there was still significant corrections in the first few hours shown. This is data of about 5 days, showing the correction voltage and the correction size in parts per billion. This may be as good as it gets with the OSC5A2B02, the short term stability is quoted at ≤0.05ppb and the corrections are less than 0.04ppb. End of the road?

[MIS42N]

Not quite end of the road. This version was supposed to eliminate any glitches from attaching or detaching anything. The accompanying graph shows the disturbance caused by attaching a 50Ω load to the BNC.  The implied control voltage jumps 500µV. The change in frequency is less than 0.01Hz so didn't trigger the 'out of specification' indication. I hadn't noticed this with the cheaper GPS units as I put it any variations down to changes in the GPS signal. With the M8T it is really obvious.

Since the 5V supply and control voltage for the OCXO are derived from a different regulator to the rest of the circuit, the problem is likely to be earthing. I had hoped an earth fill would have a low enough resistance that this wouldn't happen. Looks like the earth plane needs redesign to isolate the OCXO earth from the other earth. Mr trobbins, I should have taken more notice of your advice.

I have other cosmetic changes to the PCB, time to get a new batch made.

[trobbins]

Assuming the 50 ohm load step is causing a supply rail transient related to 74HC04 U7, then a perturbation of VDD could impact either the GPS or the PIC (as the other circuitry relates to J3, J4, and J5).  Perhaps the PIC's internal derivation of PWM is being perturbed ?

Whatever the mechanism of the disturbance imposing on the control voltage, I'd suggest assessing the 74HC04 environs to avoid a step change in VDD current from egressing to other circuitry.  The pcb layout indicates U7 is quite some distance from the regulator and C14, both for the VDD line and the return 0V plane. 

One option could be to buffer that at U7 perhaps using an RC so that U7 mainly gets its step current from a local reservoir.  Eg. add a series R (and possibly even a ferrite bead over the R lead) in the VDD feed trace from C15 to U4, and replace C15 with an e-cap, and route a trace from pin 14 to near pin 7 (with end pads) so that a smt cap can be soldered to the ground plane side of the pcb at pin 7, with the cap trace going direct to pin 14 - that may mean carving a trace out of the gnd pour.  You could even retrofit that mod to an existing board to gauge the benefit from suppressing the glitch at its source.

Another aspect could be to minimise the J10 gnd disturbance so that it locally goes to just R18 and U7/7 pads, and not into the general gnd pour.

Perhaps of no tangible concern but I see that the ground connection from the GPS J4/4 has quite a long route to the PIC U4/14 and the C14 reservoir - but no apparent easy change is seen.

PS. U6 +5V trace perhaps could go direct to C10, C11, and then to the OXCO.  Also VDDA trace to U3 and U6 could start from C3, rather than from L1 pad.

Ciao, Tim

[MIS42N]

Assuming the 50 ohm load step is causing a supply rail transient related to 74HC04 U7, then a perturbation of VDD could impact either the GPS or the PIC (as the other circuitry relates to J3, J4, and J5).  Perhaps the PIC's internal derivation of PWM is being perturbed ?

Whatever the mechanism of the disturbance imposing on the control voltage, I'd suggest assessing the 74HC04 environs to avoid a step change in VDD current from egressing to other circuitry.  The pcb layout indicates U7 is quite some distance from the regulator and C14, both for the VDD line and the return 0V plane. 

One option could be to buffer that at U7 perhaps using an RC so that U7 mainly gets its step current from a local reservoir.  Eg. add a series R (and possibly even a ferrite bead over the R lead) in the VDD feed trace from C15 to U4, and replace C15 with an e-cap, and route a trace from pin 14 to near pin 7 (with end pads) so that a smt cap can be soldered to the ground plane side of the pcb at pin 7, with the cap trace going direct to pin 14 - that may mean carving a trace out of the gnd pour.  You could even retrofit that mod to an existing board to gauge the benefit from suppressing the glitch at its source.

Another aspect could be to minimise the J10 gnd disturbance so that it locally goes to just R18 and U7/7 pads, and not into the general gnd pour.

Perhaps of no tangible concern but I see that the ground connection from the GPS J4/4 has quite a long route to the PIC U4/14 and the C14 reservoir - but no apparent easy change is seen.

PS. U6 +5V trace perhaps could go direct to C10, C11, and then to the OXCO.  Also VDDA trace to U3 and U6 could start from C3, rather than from L1 pad.

Ciao, Tim

I think rerouting the traces from L1 to U3,U6 has a lot of merit, also the OCXO +5V.

It seems to me the main problem is resistance in the ground plane causing a drop in the wrong place, and that can be fixed by putting in a few exclusion zones. While the 50Ω load was plugged in the system settled to a different voltage and the corrections once that voltage was established were small (similar to no load). The graph is over more than a day. Although it is annoying to see this, it was pleasing to see the algorithm caught it after the phase was out by about 100ns (1 cycle), changed the frequency to pull back the phase error, then changed the frequency to be correct once the phase error was eliminated. Minimum hunting or ringing.