Budget GPSDO - complete

[MIS42N]

I have been working on this project for a few months, and was not intending to make it public until it was finished. But when is anything 'finished'?

I was posting bits and pieces in the lars GPSDO threadhttps://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/, and was encouraged to start a new thread.

At first I didn't like the idea - half finished - not very professional. Then again someone may find it interesting. The process of preparing a document was constructive, it forced me to consider the choices made and also to solidify ideas for future developments. So here it is [wall] warts and all.

NOTE: *** This project is complete. See message #68 for GitHub link ***

[MIS42N]

Built a second GPSDO based on the circuit published in the .PDF attached to the first post. Two variations:
(1) the power supply is a 7.8V wall wart, the board supply is via a 7805. The 7.8V is also sent to the line driver/receiver system. In V1 the driver/receiver had a separate supply. V2 has one supply for the whole system.
(2) An output to a BNC connector was added. This used a 74HC04 hex inverter, one inverter buffers the OCXO output and feeds it to both the microprocessor and to the other 5 inverters. These are paralleled to drive the BNC output.

The V2 oscillator is still 'burning in'. It is ageing at a calculated 5 ppb/day, about 10 times the rate in the specifications (the specification is after 1 month running). This initially was enough to unsettle the control algorithm. The design target is to maintain 10MHz+-0.01Hz, this was maintained most of the time, interspersed with corrections of up to +-0.5Hz to sync the phase. This is due to the algorithm using a linear interpolation of the data. To detect ageing requires a quadratic interpolation. I didn't implement the quadratic interpolation as it requires higher precision than the arithmetic provides.

Instead a sanity check was added to the algorithm to stop the wild corrections. In the day since it was put in, it was only used once. The ageing has slowed to the point where the control algorithm is working as intended and the +-0.01Hz limit has been achieved. It will be interesting to see how the OCXO behaves after a few days running.

The output is not yet categorised. It should be a square wave of around 2V p-p into 50 ohm. As a crude test it was used as the reference for an SDR, proving that there is some output and as far as we could see it was 10MHz. A search is on to find someone with decent test gear. Anyone in Newcastle NSW following this thread and willing to help?

The validity of using the line driver/receiver was proved. Another driver/receiver pair were constructed and used to drive a 30 meter CAT 6 Ethernet cable. The GPS antenna was placed on a garden shed roof, the GPSDO set up in a lounge room. The GPSDO parses the NMEA data and does the checksum to detect corruption. There were no errors.

There are now (annoyingly) four avenues of investigation:
(1) V3 using the same oscillator and a precision voltage source for the control voltage
(2) V4 using a higher spec oscillator
(3) A different control algorithm. (i) to handle measurement periods > 30 minutes (ii) to calculate more frequently (iii) maybe calculate ageing.
(4) A 10MHz to 49.152MHz converter, suitable to be the reference for an ICOM tranceiver.

At the moment, (4) is the focus until the V2 output is verified as usable.

Modified circuit and picture attached:

The picture shows power input top left, GPS input top, serial output top right.

[spostma]

beautiful work!
Great that you did that all in 100% PIC assembly,
and that you use all PIC resources so efficiently  - I love that too...
Are you willing to share your source code?

[MIS42N]

beautiful work!
Great that you did that all in 100% PIC assembly,
and that you use all PIC resources so efficiently  - I love that too...
Are you willing to share your source code?

Thank you.

I put the current source at http://www.cashin.net/gpsdo.asm. It is a work in progress, so it will probably be out of date next week but I'll leave it there. It is not a 100% reliable web server so if you can't get it first try, wait and try again. You will need MPLAB X IDE v5.35 to see it properly, v5.35 is not the current MPLAB X version. They discontinued support for MPASM (the compiler) after v5.35 and there isn't a good replacement (that I have found). It can still be downloaded from the Microchip website https://www.microchip.com/en-us/development-tools-tools-and-software/mplab-ecosystem-downloads-archive

The source is a bit haphazard and the comments are meant for me so I can get back to it and remember what I did. If you want to rip some of it but not sure what it does, feel free to ask. I am rather pleased with the software UART to receive the 9600baud NMEA, I haven't seen a dropped message yet. It was a devious way of interfacing with a 3.3V device without a level shifter, and also freed up the real RX for user input.

It may seem odd that I chose a PIC processor with USB, but don't use the USB part. I looked at the specification and decided it did all the things I wanted, so bought it. Now I've got a few, no point in researching a different one.

[MIS42N]

Time for an update:

The second GPSDO (mentioned in Reply #1), which was ageing quickly at the start, settled down after a week. It was taken to a lab to look at the output, the 74HC04 circuit put out a useful square wave a bit less than 3V p-p into 50 ohm. A spectrum analyzer showed nothing bad, just harmonics as expected from a square wave. So it is classified as a success. Although it reliably held to better than 10MHz +- 0.01Hz (i.e. less than 1ppb error) it didn't perform as well as the first build. It showed more sensitivity to temperature, and since the main difference between the two was the power supply, this is thought to be the cause.

An amateur radio operator mentioned that they liked equipment that ran from a nominal 12V, tolerant enough to run off a charged battery. This presented a problem as the OCXO runs off 5V, so a drop of up to 9V was required. A simple buck converter based on the MP1484EN chip was purchased, sold as the Mini-360 Dc-Dc Buck Converter. It has a pot to adjust the output from 18V to about 1V. This proved very touchy, hard to set within a few % of 5V. This was supplied with 12V from a wall wart.

Since GPSDO #2 was a proven system, GPSDO #1 was modified to use the new power supply. This was not very successful, mostly better than 1ppb but wandering more than GPSDO #2. Since the only change was the power supply, this added more evidence to the idea the power supply is a factor.

I theorised that the main effect of power supply variations was to vary the control voltage. The OCXO is supposed to be tolerant of small supply voltage changes, so a circuit was drawn up to buffer the PWM output of the PIC through a pair of FETs supplied from a MAX6350 precision voltage source. This was an annoying complication, so the current draw of the PIC was tested. It was about 5mA which is well within the supply capacity of the MAX, so in theory the PIC can be supplied by the MAX and the buffer is not required.

So a GPSDO #3 circuit was laid out and about to be constructed when I realised that GPSDO #1 had been set up with a jumper to supply +5 to the PIC. Remove the jumper, supply the output of the MAX (on a breadboard) to the in circuit programming connector and see what happens. So far it looks like a winner. If it proves satisfactory in the long term, GPSDO #3 will be the last prototype using the OSC5A2B02. The circuit is already laid out in KiCad, just need to see if the buck converter does the job. It may be possible to remove the pot and replace it with a fixed resistor, there appears to be pads to do it.

[MIS42N]

The buck converter to drop 12V to 5V (described as Mini-360 DC-DC Buck Converter Step Down Module) proved unworkable. I think it was designed for higher currents than I am drawing (about 200mA). I tested it with a 10Ω resistor and it was quite stable (although very fiddly to set the voltage) at 5V and 500mA. But in the prototype the voltage was jumping around. To continue testing with the processor supplied by a MAX6350 precision voltage supply, a 7805 with heatsink was used to get the 5V for the rest of the circuit from 12V. It generates more heat than the rest of the circuit, very annoying.

The tests were satisfactory, after a few days the frequency errors were less than 1 part in 10E-10. There was still a variation but it didn't seen to be temperature dependent. Part of the circuit was breadboard with leads everywhere, may have been a problem.

On the strength of the success, prototype #3 has been constructed, with the processor supplied by a MAX6350. It was going to use the '7805 on a heatsink' supply for 5V to the rest of the board, but for a trial a cigarette plug to USB adapter is being used to see how it performs. It is more stable than the Mini-360, with lower dissipation solution than the 7805.

It is currently 'burning in' the OCXO (yet another OSC5A2B02) and already better than 1 part in 10E-9.

I had not expected power supply to be an issue. So far the trials have been:
(1) GPSDO running from 5V with GPS module attached to the board - fail, couldn't get enough signal in the house
(2) added an antenna, partial success but inconvenient location
(3) Separate the GPSDO and GPS by using a line driver and receiver to get NMEA and 1pps. GPSDO still using 5V, the rest on another 8V supply. Very successful, stable GPSDO and good GPS signals.
(4) Another GPSDO with a single 8V supply, 5V coming from a 7805 on a heatsink. Not as good as (3)
Decided (maybe foolishly) that the supply should be 12V. From here on, line driver/receiver and GPS unit get 5V from 12V via their own 7805 (not heatsinked).
(5) original GPSDO supplied by buck converter - disaster
(6) original GPSDO with a single 12V supply, 5V coming from a 7805 on a heatsink. About as successful as (4) but needs to get rid of too much heat.
(7) Modify (6) to supply 5V to the processor via a MAX6350, the remainder from the 7805. An improvement over (4) and (6) but still not quite as good as (3)
(8 ) GPSDO #3, single 12V supply, 5V to the processor via a MAX6350, the rest of the circuit from a car to USB converter. Looking good.

I think the 12V to 5V via a buck converter is still the way to go (except for the processor, it needs a very stable voltage). I don't really want to be designing my own (a whole new area of pain) but if the supply is to be a generic 12V (even a car battery at 13.x Volt) then the other option is a hot heatsink, and that will have its own problems (and waste 60% of the supply).

Still a work in progress.

[MIS42N]

I read a bit about buck converters. The problem with the Mini-360 DC-DC Buck Converter Step Down Module is the inductor, it is 10μH. The recommended operation is to have current ripple through the inductor of 30% or less than the current draw. With 10μH and low current the ripple is 100% (i.e. for a portion of the time there is no current through the inductor). I'm guessing that isn't allowing the IC to regulate properly. A hot iron dropped the inductor off, should be able to replace it with a 100μH inductor with a 600mA rating. Just need to order some.

The latest thinking is to have the buck converter output something about 8.5V and a linear regulator (7805) with a heat sink to supply 5V. The MAX6350 should also operate from 8.5V. This will allow input voltage to be anywhere between 10 and 18V, covering the 12V lab supply and 11 to 13.x supply from a car battery. Makes the sizing of a heat sink for the 7805 a bit easier, and the output of the buck converter doesn't have to be down to the nearest 100mV.

[AndrewBCN]

Hello MIS42N,
You may want to investigate the use of an LM317T instead of a switching regulator, to reduce 11V to 13V input to a well-regulated, low-ripple 8V that would then supply your LM7805T and your precision regulator. The LM317T is quite inexpensive but has better dynamic characteristics than the LM78XX series.

[MIS42N]

Hello MIS42N,
You may want to investigate the use of an LM317T instead of a switching regulator, to reduce 11V to 13V input to a well-regulated, low-ripple 8V that would then supply your LM7805T and your precision regulator. The LM317T is quite inexpensive but has better dynamic characteristics than the LM78XX series.

A good idea and I was tempted to go down that path.

I am trying to get away from generating too much waste heat. My test on the buck converter with a 500mA load (5V from 12V into 10Ω) was OK, only slight voltage change over a couple of days. And it was quite cool even though the resistor was too hot to touch (not overloaded though, it is rated 5W). And since I bought 10 of the little things, I want them to work. Just about everything these days uses switch mode supplies of some sort, the best result I have so far was a circuit soldered onto a 5V wall wart. So it should be possible. Even the dodgy USB from cigarette lighter appears to work OK as a 5V source but it is more expensive.

The buck converter was less than $1 and a replacement 100μH inductor a few cents. Now I know what the problem is, I want to give it a go even if it is a failure.

In the meantime, I've started coding a new control algorithm. It is supposed to be adaptive and cater for measurement periods from 3 seconds to days, and do ageing compensation. It is simpler than the one I use currently, but hopefully works better. The current one is only capable of calculating corrections to 5 parts in 10E-11 so I don't know if the OCXO can do better. I also have a DOXCO that, if the algorithm works, can use the same software.

[AndrewBCN]

Hi MIS42N,
If I may, I would suggest these three informative videos:

EEVblog #90 - Linear and LDO regulators and Switch Mode Power Supply Tutorial


EEVblog #594 - How To Measure Power Supply Ripple & Noise


EEVBlog #1116 - How to Remove Power Supply Ripple


A $1 buck converter will likely have several tens to several hundreds millivolts of high-frequency noise on its output, which neither the 7805T nor your precision regulator will be able to remove, as explained in video #1116, here: https://youtu.be/wopmEyZKnYo?t=196

[MIS42N]

I worked my way through this - very interesting https://www.microchip.com/stellent/groups/SiteComm_sg/documents/Training_Tutorials/en528032.pdf

[MIS42N]

This has been on the back burner for a while, made some changes recently so time for another update:
The control algorithm is completely rewritten, nothing like the original. It appears to work well. Although it calculates an ageing compensation, this is not implemented. The OCXO is not stable enough that ageing is significant (I'm trying to figure why).

The algorithm starts trying to discipline the oscillator when OCXO frequency is off by about 10Hz. This only happens during warm up. Once disciplining starts, the OCXO delivers an average of 10 million cycles every second. I think that's equivalent to a PLL lock, and the algorithm won't let go (lose lock?) after that. As described in the pdf (reference in the first post, I should write an update), the OCXO is allowed to 'free run' with a fixed control voltage until the difference between the 1pps arrival and the completion of the last 10 million cycles reaches a limit. A different fixed voltage is applied to bring the difference to zero. Once a voltage has been set, over time the difference limit is reduced. The limits are in a table, currently it is around 150ns at 196 seconds (a frequency error of less than 1E-9 or 0.01Hz) and reduces to about 25ns after 6 hours (a very unlikely 1E-12).

My design criteria was 1E-9, every GPSDO I've built achieves that after about 15 minutes.  I'm trying to push that consistently below 1E-10 but it is proving elusive. The current rig seems to have inherited some quantum DNA, attempts to measure things causes changes. I shall persevere.

Which brings a question? Should I just stop developing more complex solutions to solve smaller problems and commit the original design to PCB?
Pros: It works - 5V and a decent GPS signal in, 10MHz+-0.01Hz square wave 3V p-p into 50Ω out. Visual indication by flashing LED that it is running within spec. Cheap - any GPS that provides a solid 1pps and NMEA data, less than $20 parts, 5V wall wart.
Cons: The requirement for a solid 1pps can be more expensive than the rest of the kit. Could have earthing problems (easily disturbed).

The current rig runs off 12V. I replaced the 10μH with 100μH in the buck converter, added a 2500μF electrolytic to the output, set it to 8.5V and use a 7805 to drop that to 5V for the OCXO. This appears to be quite stable. The 7805 heat sink is warm but not uncomfortable.  I think I have earth loops. The rig is spread over 3 prototyping boards, putting all 3 in a cake tin seemed to make an improvement. I am awaiting a few parts from China, ordered May, expected delivery now August. Slow progress. Maybe time to start the DOXCO version, I have the parts.

[MIS42N]

I decided I should pursue the original concept - a budget GPSDO using minimal parts. A PCB has been designed (with help from Tim - many thanks) and submitted for production. The concept is the user supplies the ancillary components, which may be sufficient for some people. For the more ambitious, the ancillary components may be repurposed and the PCB consigned to the back of a dusty drawer.

The power supply requirements are flexible. The board can be fitted with a micro USB B socket, allowing the use of a phone charger. Alternatively, a barrel connector can be fitted, there is space for a voltage regulator such as a 7805 and some filter components if required. The regulator is at the board edge so various sized heatsinks can be used, or the regulator could be bolted to a case (if the user supplies one).

The circuit requires a GPS module producing 1pps and and NMEA serial data at 9600 baud. The processor can handle either 5V or 3.3V. Optionally the NMEA data can be changed to 4800 baud by changing the software. This should cover most of the modules available.

In theory, this is enough to get a working system. Functionality is indicated by a single LED which provides indication of OCXO failure, satellites in view (prior to getting a fix), fix but not locked. Locked but not in specification (i.e. 1 part in 10E-9) and locked and in spec.

However, this may not be sufficient for setting the system up. A basic user interface is provided through a 9600 baud TTL serial link. This can give more information and can pass through the NMEA data from the GPS module. To use the serial data, the user would need to provide an interface such as a serial to RS232 converter (e.g. using a MAX232 or similar) or a serial to USB (e.g. FT232). Two useful programs are PuTTY and VisualGPS. VisualGPS 'decodes' the NMEA data and shows the number and signal strength of satellites in view, along with other useful data. PuTTY is a terminal emulator and allows keyboard input of the few user option. One option is to switch from the NMEA data and view the second by second deviation of the 1pps from the OCXO.

More when the PCBs arrive.

[MIS42N]

Getting excited. Both the PCB and the additional parts to make multiple kits are in transit. Given Covid delays, ETA is unknown but I figure I'll be populating and testing a PCB within the week.

As detailed earlier, my method of discipline is to let the oscillator run without varying the control voltage, and correct when the oscillator and 1pps diverge by some amount. It appears from reading about other GPSDOs that nobody else does this. This may be because I didn't understand PID control 10 years back and so started down a different track.

After reading about Allan deviation (and finally understanding it), it was clear if the corrections were left too long, the Allan deviation would suffer. So the discipline algorithm has been modified. If no limit correction has occurred, a correction is done after 3*2^9 seconds (1536 seconds or 25 minutes 36 seconds) regardless of the calculated divergence. Most literature indicates a time of about 20 minutes is good, but the way the algorithm works it is locked into periods of 3*2^n.

The trials are encouraging. Here is the result for a day (Local time is UTC+10 hours so starting around 8a.m.):

 Time 215156 UTC. Ctrl 1.9929890 0.026 ppb FFFA
 Time 221732 UTC. Ctrl 1.9927896 -0.186 ppb FD45
 Time 224308 UTC. Ctrl 1.9928470 0.054 ppb 0039
 Time 230844 UTC. Ctrl 1.9927377 -0.102 ppb FF41
 Time 233004 UTC. Ctrl 1.9929316 0.181 ppb 007C
 Time 234141 UTC. Ctrl 1.9928122 -0.111 ppb FFE4
 Time 000301 UTC. Ctrl 1.9929325 0.112 ppb 0006
 Time 002837 UTC. Ctrl 1.9929182 -0.013 ppb 0088
 Time 005413 UTC. Ctrl 1.9929514 0.031 ppb 0065
 Time 010307 UTC. Ctrl 1.9929243 -0.025 ppb FFFD
 Time 012843 UTC. Ctrl 1.9929175 -0.006 ppb 001B
 Time 015419 UTC. Ctrl 1.9929203 0.003 ppb 0050
 Time 021539 UTC. Ctrl 1.9930906 0.159 ppb 0013
 Time 023244 UTC. Ctrl 1.9929929 -0.091 ppb FFCF
 Time 025404 UTC. Ctrl 1.9931175 0.116 ppb 0073
 Time 030205 UTC. Ctrl 1.9930299 -0.082 ppb FFF1
 Time 032741 UTC. Ctrl 1.9930659 0.034 ppb FFFF
 Time 035317 UTC. Ctrl 1.9930683 0.002 ppb FFF7
 Time 041853 UTC. Ctrl 1.9930726 0.004 ppb FFDA
 Time 044429 UTC. Ctrl 1.9931517 0.074 ppb 00EE
 Time 050549 UTC. Ctrl 1.9930177 -0.125 ppb 000C
 Time 051825 UTC. Ctrl 1.9931312 0.106 ppb 0011
 Time 053945 UTC. Ctrl 1.9930854 -0.043 ppb 0057
 Time 055233 UTC. Ctrl 1.9930430 -0.040 ppb 003E
 Time 061419 UTC. Ctrl 1.9930937 0.047 ppb FFF7
 Time 063955 UTC. Ctrl 1.9930552 -0.036 ppb 0047
 Time 070531 UTC. Ctrl 1.9930851 0.028 ppb 0002
 Time 073107 UTC. Ctrl 1.9930393 -0.043 ppb 0024
 Time 075643 UTC. Ctrl 1.9930580 0.017 ppb 0074
 Time 082219 UTC. Ctrl 1.9929936 -0.060 ppb FF63
 Time 084755 UTC. Ctrl 1.9929991 0.005 ppb 002F
 Time 091331 UTC. Ctrl 1.9930119 0.012 ppb FFC7
 Time 093907 UTC. Ctrl 1.9930058 -0.006 ppb FFEE
 Time 100443 UTC. Ctrl 1.9930003 -0.005 ppb 003F
 Time 103019 UTC. Ctrl 1.9929517 -0.045 ppb FF2F
 Time 105555 UTC. Ctrl 1.9929710 0.018 ppb FFFD
 Time 112131 UTC. Ctrl 1.9929276 -0.040 ppb 0060
 Time 114251 UTC. Ctrl 1.9928550 -0.068 ppb FFF2
 Time 120545 UTC. Ctrl 1.9929130 0.054 ppb 0033
 Time 123121 UTC. Ctrl 1.9928443 -0.064 ppb FF84
 Time 125657 UTC. Ctrl 1.9928440 0.000 ppb FF6C
 Time 132233 UTC. Ctrl 1.9928376 -0.006 ppb FFC0
 Time 134809 UTC. Ctrl 1.9928110 -0.025 ppb FEE3
 Time 141345 UTC. Ctrl 1.9928421 0.029 ppb FF94
 Time 143921 UTC. Ctrl 1.9927606 -0.076 ppb FFA6
 Time 150041 UTC. Ctrl 1.9926767 -0.078 ppb 000A
 Time 151830 UTC. Ctrl 1.9927258 0.046 ppb FFEB
 Time 154406 UTC. Ctrl 1.9926865 -0.037 ppb FFF8
 Time 160942 UTC. Ctrl 1.9926660 -0.019 ppb FFF3
 Time 163518 UTC. Ctrl 1.9926037 -0.058 ppb FF96
 Time 170054 UTC. Ctrl 1.9926187 0.014 ppb FF1C
 Time 172630 UTC. Ctrl 1.9926230 0.004 ppb FFF3
 Time 175206 UTC. Ctrl 1.9925515 -0.067 ppb FEE9
 Time 181742 UTC. Ctrl 1.9925549 0.003 ppb FF73
 Time 184318 UTC. Ctrl 1.9924801 -0.070 ppb FF22
 Time 190854 UTC. Ctrl 1.9924627 -0.016 ppb FFF9
 Time 193430 UTC. Ctrl 1.9924227 -0.037 ppb FFF5
 Time 200006 UTC. Ctrl 1.9923839 -0.036 ppb FF95
 Time 202542 UTC. Ctrl 1.9924783 0.088 ppb 0081
 Time 205118 UTC. Ctrl 1.9924581 -0.019 ppb 007E
 Time 211654 UTC. Ctrl 1.9924542 -0.004 ppb 000B
 Time 214230 UTC. Ctrl 1.9924725 0.017 ppb 006B
 Time 220806 UTC. Ctrl 1.9924288 -0.041 ppb FF53

The figures indicate a slow downward movement of the control voltage, presumably to compensate for ageing. The OCXO was turned on less than a week ago. This is overlaid with a rise during the day which is presumably temperature related.

The four characters at the end are for debugging. It is a hexadecimal representation of frequency drift during the measurement period. With a constant control voltage and a perfect oscillator, this should be zero. I am thinking of putting in some compensation for this, but it is not worth it while temperature effects (which are basically unpredictable) are more than ageing effects. Maybe if the software is used in a different hardware platform, it will become relevant.

The design aim was to have an oscillator that delivers 10MHz+-0.01Hz (i.e. 1ppb or less). As can be seen, most of the time it is an order of magnitude better. Cheering .

[MIS42N]

The PCBs and multiple parts arrived. A GPSDO was assembled and connected up to GPS. It worked!! For a while ...

It took nearly 3 hours to assemble. I am not an experienced kit builder, so maybe I should have expected it. Soldering looked good, nothing showing up on the multimeter to worry about, power on. Attached the PICkit 3 and programmed successfully. Sailed through the 3 hour calibration, started to settle into run mode, then serial output stopped. I had noted that serial input from the user wasn't acknowledged, what was wrong?

What was wrong was an oversight on my part. There are no markings on the PCB to show which connector pin does what (should this prove popular, will be fixed in the next run of boards). I had wired the serial input/output incorrectly and it looks like it fried the PIC UART. The system continued to run minus serial output and after a while the LED indicated it had settled to better than 10MHz+-0.01Hz, (the target error of less that 1 part in 10E9). But with no serial output, that was all that could be said. Success of a sort.

Fortunately or unfortunately whichever way you looks at it, it looks like the PIC serial port failed rather than the serial/USB converter. After the disaster, the converter was hooked up to an older GPSDO (carefully, correctly) and is working. Fortunately because I only have one serial/USB converter, but several spare PIC16F1455 processors. Unfortunately as now I have to figure out how to remove and replace a 14 pin part without damaging the PCB.

It looks like a kit can be created for about $16AU+postage (remembering a kit does not include a power supply, a GPS receiver, and the (optional) serial/USB adapter and case). A kit is the PCB, OCXO (OSC5A2B02), PIC16F1455, 74HC04, Panel mount BNC connector, resistors, capacitors, and pin connector strip. I was hoping to include a micro USB connector for power but these are in transit. For testing I supplied power through a barrel connector (the PCB also has provision for it) but I don't have spares of them. A builder could attach wires direct to the board, maybe with a USB A plug. I may include the LED I ordered, it works but not very bright. The LEDs I used before were cannibalised from solar powered Christmas lights and they were much brighter. Maybe one of those can go in, they come in strings of hundreds, just need to remove the wires.

So it's close, folks. I'd like to replace the PIC on the board, test again with serial output working. Report back in a day or two. I've ordered what is claimed to be a NEO-7 module marked BOAR, the O looking like a paw print. I believe these have a preamp for the patch antenna, may get reasonable reception indoors. All in the interests of experimentation.

The system being tested in the last post was turned off to allow this test. That test revealed the system is sensitive to temperature changes. This explains a problem I was having a few weeks back, the system is set up not far from a thermostatically controlled heater. As the heater cycled on and off, it was reflected in the processor raising and lowering the control voltage. I thought at first it was electrical interference but not so. Is it worth doing something about it? probably not. This is a budget build and it meets the specification under normal circumstances (even heaters turning on and off).

[MIS42N]

PIC replaced, system works. I have written up a brief description in the attached pdf.

I have been experimenting with antenna position to determine the difference in performance between good and poor reception. The answer is - huge. With good reception the system often runs the full 25 minutes between adjustments, and all adjustments are frequency changes of less than 0.001Hz. With the antenna positioned on a downstairs window ledge, adjustments were frequent and sometimes more than 0.01Hz.

Is there anybody interested in a kit to construct the GPSDO module? I have several spare PCBs and all the parts to populate the board except for power supply options. That may be a personal preference so best left to the individual. I think this will only be for people in Australia, I haven't done anything like this before so I am assuming I can just post a parcel. I also haven't collected money, I guess PayPal can do that. I am pretty confident the cost including postage will be about $20.

If you are interested, or have questions, you can use the little email symbol to the left of this post to send me an email.

Regarding GPS reception, my solution was to mount the GPS receiver remotely and use a line driver/receiver to bring the signal to the GPSDO via Ethernet cable. This required no changes to the GPSDO. The receiver has an active antenna that is sitting on a roof. This was done because I had the antenna, and the receiver didn't have a patch antenna. I am thinking I'll try a receiver with a patch antenna inside a bit of plastic pipe for weather protection. On paper, a GPS module with patch antenna using the line driver/receiver option is cheaper than buying an active antenna, and can be mounted a lot further away (I've tested it to 30 meters). Is anybody interested in the outcome of this experiment?



 

[intabits]

A bit of a side-track to your project, but may be of interest to you.

Are you aware of this Silicon Chip project from October 2018: "GPS-synched Frequency Reference"?
https://www.siliconchip.com.au/Issue/2018/October/GPS-synched+Frequency+Reference+Pt.1

They made their own ovenized oscillator (40MHz), which I found appealing since its based on all new parts, so multiple units can be made consistently without being bound to whatever used/surplus items are available from ebay and other sources.

But it also uses a PIC (which I don't like - can't even spell it), though I expect that would not be a problem for you, which is why I bring this up.   

I'm working on my version of the project, using just its ovenized oscillator, and an Arduino. I haven't touched it in quite a while, but look forward to getting back into it. I stated a thread on it a while ago:-
https://www.eevblog.com/forum/projects/yep-its-another-gpsdo-early-development-results/msg2129818/#msg2129818

I had to make my own counter and associated bodgery, as the Nano can't count count at 40MHz, but the PIC they used can.
So you might be able to just swap out your oscillator and PWM DAC for the SC oscillator section. (and rewrite most of your code )   

(To handle the 40MHz, I might look into the blue pill STM32-based modules when I revisit my project...)

[MIS42N]

A bit of a side-track to your project, but may be of interest to you.

Are you aware of this Silicon Chip project from October 2018: "GPS-synched Frequency Reference"?
https://www.siliconchip.com.au/Issue/2018/October/GPS-synched+Frequency+Reference+Pt.1

Thanks for the heads up. I subscribe to SC so have seen the article. I think that project was what started me thinking. They published another GPSDO many years ago that used a PIC16F628A to do reporting but had a pile of digital chips to do the disciplining. At the time I decided to make a GPSDO using the PIC16F628A as the controller and I think it was published in circuit ideas a few years ago (long story). It was too complex and the PIC didn't have enough resources to do a good job.

I use the used OSC5A2B02 because they are very cheap for something with respectable specifications. There are plenty of sellers, for various prices. I came across a site where I could buy them in bulk for less than $4 each, but I have enough to build a few kits already. They are also available as a new item but the used ones perform well.

If you look at the specs for the SC project, it talks of an accuracy of +-100 ppb after 30 minutes. I am not happy if I see accuracy worse than 1ppb, usually achieved within 15 minutes. With a good GPS signal long runtime and stable temperatures, 0.1ppb is normal. That's 100 to 1000 times better.

And the philosophy of this project is different. It is more a building block than a complete unit. Just the backpack of the SC project will cost around 4 times this project. There's nothing stopping someone attaching something like a Raspberry Pi to the serial port to drive the user interface. With the NMEA pass through ability, anything in that stream is available. Tack a board to the output 10MHz to do whatever else is needed. Lots of circuits for distribution amps, square to sine filters etc. available.

Good luck with your Nano project. Certainly easier to program than the PIC, but as you are finding out there are reasons I went with the PIC.

[GigaJoe]

I may suggest create a box , from Expanded polystyrene , Styrofoam, and isolate quartz inside. it would be much stable and consume 1/4 of original mA (from over 100 mA in my case was around 20-25 mA).

usually it takes around a week to stabilized , then do adjustment.

[MIS42N]

I may suggest create a box , from Expanded polystyrene , Styrofoam, and isolate quartz inside. it would be much stable and consume 1/4 of original mA (from over 100 mA in my case was around 20-25 mA).

usually it takes around a week to stabilized , then do adjustment.

Good thoughts if you are looking for more accuracy or worried about overheating power supplies. Maybe a bit wasted on this project, it is intended as a 'try before you spend money on an upmarket GPSDO' module. I think most people will find it works just fine if they are using it as the standard for calibrating other instruments, or as the source frequency for a transceiver (1Hz error at 1GHz is not too bad).

[GigaJoe]

your crystal  SC cut - quite stable.
one thing ... you need to be certain that on output "ADC"  there should be very stable output, to avoid jitter.

[MIS42N]

your crystal  SC cut - quite stable.
one thing ... you need to be certain that on output "ADC"  there should be very stable output, to avoid jitter.

It does seem a good crystal. I've now used 4 second hand ones, the quoted control voltage is 0 to 4V with the aim to be correct frequency at 2V. The ones I've used vary between 1.8 and 2.1 so plenty of life in them. They are more sensitive than the expensive crystals at 0.1V/Hz. A Morion MV89 is 1V/Hz which makes it 10 times less sensitive to unwanted control voltage changes. You get what you pay for.

I don't understand your reference to ADC. The circuit uses a PWM (pulse width modulator) with a lot of filtering to remove the artifacts. Is that what you meant?

[GigaJoe]

yes, filtering, maybe increase RC value

one of thing , i did was not only do PWM as voltage source , but also inject pulses for a small correction.
so channel 1 do pwm , a second channel adding pulses (possible to do with lower amplitude ) at lower rate for a fine adjustment, therefore increase precision

[MIS42N]

yes, filtering, maybe increase RC value

I did an LTspice simulation of the filter I use (have you looked at Documentation02.pdf attached to post #15?). It has about 300 microvolt ripple at the first 10uF capacitor, under a microvolt by the second 10uF and too small to measure on the third. No more filtering required.

one of thing , i did was not only do PWM as voltage source , but also inject pulses for a small correction.
so channel 1 do pwm , a second channel adding pulses (possible to do with lower amplitude ) at lower rate for a fine adjustment, therefore increase precision

I dither the PWM to emulate 24-bit DAC. The voltage steps are less than a microvolt. No second output required. This code is executed at 40KHz to vary the PWM pulse width on every pulse.

Code: [Select]

BANKSEL PWM
MOVF    PWM,W   ; Add the least significant
ADDWF   Dithr,F   ; 14 bits of PWM to Dithr
MOVF    PWM+1,W
ANDLW   0x3F ; truncate to top 6 of 14 bits
ADDWFC Dithr+1,W
MOVWF Dithr+1
ANDLW 0x40 ; isolate possible carry out
XORWF Dithr+1,F ; remove it from Dithr
ADDWF PWM+1 ; now the most significant 10 bits
MOVWF   PWM2DCL ; bits 0-5 ignored
CLRW
ADDWFC PWM+2,W
MOVWF   PWM2DCH ; and store it as top 8 bits of next pulse width

[GigaJoe]

but filtering mostly depend on load of filter , would it be make sense to add opamp , between the filter and the control pin ?

[trobbins]

MIS42N, I just received the pcb in the post - much appreciated.  A few more parts to come in and I will be able to start the build and testing 

My incentive was initially to just go for an OCXO, but then reading through the GPSDO options on this forum provided a relatively simple option to go one step beyond in certainty/calibration.  For me this is related to a vintage Systron Donner counter with 0.1/1Hz display resolution, and a venerable HP3325A with control capability to 0.001Hz - both of which have just basic crystal oscillator internal references.  So having a 10MHz GPSDO reference that can directly interface with the HP provides the ability to experience more 'zeroes' than I rightly have a need for (the >7 zeroes club), and for which I would never experience during the calibration of any other type of bench top equipment I'm ever likely to have.

Cheers, Tim

[MIS42N]

but filtering mostly depend on load of filter , would it be make sense to add opamp , between the filter and the control pin ?

Thought of that. That is why there are only 1kΩ resistors between the 10µF capacitors and there are 3 capacitors (most designs I've seen have 2). The source is only 12kΩ (10+1+1), the OSC5A2B02 input impedance is quoted as >100kΩ. An op amp there has to be a good one. Easier to design it out.

[GigaJoe]

curious, why opamp should be good one ?
it basic follower , and approx +2V out , simple OP07 , will do it,  ( i'm wonder , adding opamp together with ocxo  in foam isolated box , eliminated temp and humidity on opamp )
but if  100K then more troubles i guess ...

[MIS42N]

Is it time to rename this project Budget GPSDO - working?

The circuit was run for a day in what I consider a worst case scenario. The GPS receiver was a NEO-6 with an active antenna. The active antenna was placed on a window ledge (inside the window) of a downstairs side window in a two storey residence. The house next door is less than a meter away so the sky view is a narrow strip of sky between the two buildings. The power supply was a 5V charger supplied with a Samsung tablet.

VisualGPS was used to see what the GPS receiver was doing. It took quite a while to get a fix. After getting a fix, the number of usable signals was small, four or five satellited being common with one or two having a reading over 30 (signal to noise? - it's the figure in the NMEA data). In contrast, the antenna on the roof had 8 or 9 satellites over 30, some over 40.

In the 24 hour test period the circuit was able to maintain the desired 1ppb accuracy (10MHz+-0.01Hz) most of the time. There was one wild excursion for about 4 minutes of about 0.2Hz.  Apart from that, there were several minor deviations of less than 0.02Hz.

This demonstrates that the unit is still usable in less than ideal circumstances. If a user was using the unit for calibrating another instrument, they would watch the LED and wait until it indicated the unit was within specification.

[conrad550]

I have a question. Why not just reprogram the Neo-6 with uBlox u-center software to put out a 10MHZ signal?

[thinkfat]

Because it is heavily jittering

[AndrewBCN]

I have a question. Why not just reprogram the Neo-6 with uBlox u-center software to put out a 10MHZ signal?

The whole purpose of a GPS disciplined oscillator (aka GPSDO) is to combine the short term stability of an OCXO with the long term accuracy of the GPS signal.

In the short term, for example over a 1 second interval, most GPS receivers exhibit jitter of around 100ns in their 1PPS signal, and the very same jitter is there when you reprogram them to "put out a 10MHz signal". 100ns is 1 period of a 10MHz signal meaning the Neo-6 10MHz signal would have a precision of +/- 1Hz, whereas the OCXO 10MHz can be adjusted to a precision of +/- 0.01Hz or even 0.001Hz. That's 100 or even 1000 times better.

[iMo]

With Neo 6/7/8 modules the output 1PPS has jitter at 10MHz caused by the internal frequency division mechanism (in order to get 10MHz output you have to divide by 4.8 and 4.8 is not an integer).

The 1PPS output is "clean" when the output frequency is set to:

freq_out = 48MHz/N, where N is integer, N=4, 5, 6, 7, 8..., 98.000.000

Thus 12MHz, 9.6MHz,  8MHz, 6.8571MHz, 6MHz etc. output frequencies are ok.

This issue has nothing to do with GPS.

[MIS42N]

I have a question. Why not just reprogram the Neo-6 with uBlox u-center software to put out a 10MHZ signal?

Because that facility isn't available for Neo 6.

Even if it was available, imo AndrewBCN and thinkfat are all correct. The 10MHz output of a GPS module has limitations. The purpose of a GPSDO is to remove the limitation.

Each project has some starting point. The starting point of this project was to discipline an OCXO with as little extra circuitry as possible. It morphed to being at lowest cost, because less parts usually means less cost. So I am choosing the cheapest readily available components and try to get the best bang for buck. So I try working with the NEO 6.

It seems successful. I created a few kits to populate the PCB (as shown in Documentation02.pdf). I can mail that in Australia for $20AU including the postage. Already dispatched one.

[conrad550]

Thanks for the info. I don't need a 10MHZ ref. Any frequency will work for my calibration needs. Do the clone
GT-U7 and clone NEO 7/8 units have this capability?

[MIS42N]

Thanks for the info. I don't need a 10MHZ ref. Any frequency will work for my calibration needs. Do the clone
GT-U7 and clone NEO 7/8 units have this capability?

I don't know. I know it is talked about in a few other topics on this site, but it wasn't relevant to what I'm doing so I didn't bookmark them. IIRC some clone modules work, most don't retain changes, some don't work at all. You'll have to do your homework.

[MIS42N]

A new challenge. The software is basically finished, I have flashed a few units with a PICkit3 and no problems. However it seems PICkit3 is not that common and people have trouble with that final step of getting the software into the PIC. At first I thought, well that's OK I'll just mail out a loaded PIC, no problem. But what if the software changes?

Looking around, a few quite reputable companies (Bosch, Cisco, etc.) used Tera Term and Xmodem to update their software. Could this work for the PIC? Technically it seems so but I couldn't find an assembler implementation so I am writing one. So far, so good - the Xmodem logic has been implemented - the Tera Term Xmodem sends the PIC a file (which in the final version will be the hex file output by MPLAB X) and the PIC receives it. Tera Term thinks it has completed and so does the PIC. Now all that has to be done is decode the hex file (it is well documented), flash the program. Should keep me going for a week or two.

I sent a unit to Silicon Chip magazine to see what they make of it. Also getting some good feedback on a few PCB improvements. The current version is V0.0, maybe there will be a V0.1 if there's enough interest.

[de_light]

Quick update. I have received one of the trial kits from @MIS4N which came very quickly and well-packaged. After some struggles borrowing a Pickit programmer, I used an Arduino nano to flash the PIC which worked fine. I have installed it in a plastic Jiffy box available locally, but one of the suggestions I made was whether the board layout could be optimised a little and whether the board could fit in some readily available housing (Australia Jaycar jiffy boxes or an extruded aluminum housing or something).

Total current draw is about 450mA when the OCXO is heating and this drops to about 250mA after a few minutes. I created a serial port outlet with a JST connector and this works well with PuTTY. The LED works well and clearly displays the operation. MIS4N has written a very comprehensive manual that is highly useful. I have an active antenna that has arrived today so hopefully can properly fire the device up.

[de_light]

I'm pleased to say that this device works exactly as intended. I had a few hiccups along the way, mainly with supply of recycled NEO-6M devices from Aliexpress (poor soldering/shorted chips, shorted voltage regulators...you name it).

Apart from that, the device works very well. It is sitting, stable, on my desktop. It does lose calibration a few times a day (been running 48 hours) but quickly regains it with the inbuilt algorithm. It also seems sensitive to the activation of other test devices (esp clock-driven) on the bench, so could do with some sort of shielding.

Overall: excellent project. The fact that this is working for the price is mind-boggling. I feel this thread needs some traction.

[HB9EVI]

Thanks for the info. I don't need a 10MHZ ref. Any frequency will work for my calibration needs. Do the clone
GT-U7 and clone NEO 7/8 units have this capability?

neither the clones nor the NEO7 or NEO8 give a jitter-free signal @ 10MHz; and like the others said - a GPSDO is like the 'best of both worlds' - short term stability via OCXO and long term stability by disciplining it to GPS.

the signals from those GPS modules may be accurate in frequency, but also jitter-free frequencies like 12MHz or 2MHz are not clean enough to be used as a reference clock for other devices, while most OCXO have a rather high spectral purity. you just have to watch out to not 'mess up' things when disciplining a OCXO

[cdev]

One can buy a six pack of Navspark Mini, which is a very sensitive Skytraq dual GNSS GPS/Beidou board that has some unique connectivity options and is exceptionally sensitive, more sensitive than Ublox. It runs on  a Leon 32 bit microprocessor some of which is made available to the user via an API. Anyway, when bought in a six pack the cost per GPS is around $6. They are very small, around the size of a dime. (The US's smallest coin.) They are provided in an eight pin DIP board. The current draw is around 35 ma or so (please double check) Its very modest. I have several of these and I use them for NTP timekeeping on my home network. They make excellent cheap timekeeping GPSs in "stationary" mode set via the Skytraq GPS Viewer program. They seem able to maintain time well even in the basement of my house with a amplified or passive antenna. Generally they do much better than he Ublox performance with weak signals. They are not a timing GPS and Sytraq takes care to make it clear that they are not a timing GPS. 

I have two decent GPSDOS and would like to be able to compare them with their 1PPS output. Maybe a PIC would be the best way to do that. They all seem to be well synchronized on my oscilloscope. Unfortunately apart from a PIC eight digit counter I dont own a better frequency counter yet.   I can likely using PICs leverage my existing equipment to make an accurate time and frequency measuring device given as I have a known decent 10 MHz frequency standard GPSDO, a Samsung- also a  TruePosition (which I think is very likely to be as good or perhaps even better than the Samsung. But I dont know. . )

I don't know what the additional older version Beidou sats that the Mini receives add to the mix. Maybe they add some improved accuracy in the vertical plane (altitude) (which is not inaccurate for me, the altitudes they return seems more accurate than the altitudes sometimes returned by other GPSs for me. I have never seen more than one Beidou sat in the sky here in the US using my Mini. But the path as plotted in the GPS Viewer program seems very stable, with very few if any cycle slips once the Sktraq Mini has fully settled down. (which improves over a few hours time, maybe even 24 hours.. for maximum accuracy you should always turn a GPS on as long as you can before you plan to use one. Most importantly, given even  marginal antenna signal they seem to maintain a fix for months without any interruption or significant glitches in the 1PPS output. Also all Skytraq GPSs Ive used Venus 5, 6 and 8  )  are fairly configurable via GPS Viewer, on the Windows platform.. The Mini is Skytraq 6 family GPS it seems.. Which seems ideal for use with a GPSDO. Another person, maybe @jbeale or Dan Drown has written a fair bit on his blog about their PPS characteristics, and I think maybe has some additional code available on his github. A Gogle + github search on the Navspark Mini should find all of it.

Anyway, for $6 they are hard perhaps impossible to match elsewhere. The skytraq is quite a bit more sensitive and its location output seems smoother and more consistently steady than any other low to mid price GPS Ive used. When used with NTP it seems as if I am doing about as accurate as NTP can measure. Very low jitter as reported by ntpq.

[bingo600]

One can buy a six pack of Navspark Mini, which is a very sensitive Skytraq dual GNSS GPS/Beidou board that has some unique connectivity options and is exceptionally sensitive, more sensitive than Ublox.

URL please

/Bingo

[cdev]

http://navspark.mybigcommerce.com

You may have to dig a bit to find it. I suspect that whatever frequencies can be generated using the Arduino like (Navspark is a family of Skytraq Venus GPSs that add additional capabilities that involve the 32 bit Leon CPU are not jitter-free signals. Others here know more about them than I, so I defer to them as to what they can do.  .

Some capabilities of the Leon Sparc-like CPU allow use of it for functionality, for example, MCU-like features,  logging, geofencing, (doing math on the positioning results), RTKlib level accuracy down to a few mm (with other more costly GPS engines)  I sincerely doubt produced time and frequency relevant signals would be free of the problems described above (shown by Ublox) without the use of an external quartz oscillator.  They might be able to reduce the additional parts required to build a GPSDO in some creativge way, butI think the chance one could eliminate that need is likely zero.

They have discussed this! (something other companies would never do, IMHO)

 To state the obvious, They dont want to kill sales of their timing GPS, which is a good one, and a good value for someone looking for  a timing GPS to turn into a GPSDO.   Like most timing GPSs its a bit more expensive, and produces the correction signals needed for building a top notch timing solution. That's quite reasonable.

They are a maker-friendly Taiwanese company that deserves our community's enthusiastic support. 

[bingo600]

I can get Ublox LEA-5T (Timing) for approx 8..9$ on ebay
Older lady but still Timing.

Will have to look at this one

Thanx
Bingo

[cdev]

Where? I'd like to get one if its that cheap.

Although my Samsung GPSDO contains an LEA6T internally.

The fake M8N that I have although its a dual GNSS with both GPS and Glonass is really a fairly crappy GPS.  The RTKKit but older Skytraq GPS I have (S1315F / Venus 8 series based) is superior to the Ublox in positional accuracy by a large margin. Even though it is only a single system (GPS) unit. I dont think its just different Kalman filter settings like some have implied.

Its probably the lack of a TCXO on the (demonstrably counterfeit) Ublox.

This is what I got for trying to save money.

[cdev]

Basically the fake Ublox is useless for what I wanted it for. (RTKlib) I bet timing too. Maybe I will use it for a bedside clock.

I think a few microseconds fast or slow there will make little difference.

[cdev]

The cheaper units typically have just a single "time pulse" output which by default is set for (either) 2 Hz 50% duty cycle (bllinking light) OR 1 PPS. It could also be set to produce a fairly wide range of frequencies at other duty cycles (such as 50%) but its a dirty signal.

The cheap M8N which I have doesn't even break out the 1 PPS properly. It sends a signal to an LED which (from memory) may be 2 Hz or 1 pps. People who want to use it for other stuff have to solder a wire to that pin. Also as I remember the DC supplied to the GPS has to be fairly clean for the GPS to work well. Glitchy DC results in terrible GPS problems.

Thanks for the info. I don't need a 10MHZ ref. Any frequency will work for my calibration needs. Do the clone
GT-U7 and clone NEO 7/8 units have this capability?

I don't know. I know it is talked about in a few other topics on this site, but it wasn't relevant to what I'm doing so I didn't bookmark them. IIRC some clone modules work, most don't retain changes, some don't work at all. You'll have to do your homework.

[HB9EVI]

The fake M8N that I have although its a dual GNSS with both GPS and Glonass is really a fairly crappy GPS. 

cannot confirm that from my experience. I built 2 GPSDOs, one with an NEO-7M and a more recent one with a NEO-M8N. they both work alike, with my measurement possibilities I cannot see a drift between the two. I constantly receive both GPS and GLONASS satellites with the M8N, together always between 12 and 16.

and very likely both are just clones and not genuine Ublox

although I'm not using 1PPS but 1MHz to give on my PLLs as reference, while I divide the OCXOs by 10

[cdev]

my m8n receives a lot of sats too, but the output plot jumps around a lot with lots of cycle slips. It seems to me. I'll have to record the traces and compare it to the aforementioned S1315F or even the mini.

Maybe I'm wrong, this is just a seat of the pants guess.   Something seems broken on the Ublox.

It seems that Ublox doesn't ever completely stop jumping around even when the antenna is in the clear and is totally stationary.  WTF?

I blamed this on the lck of TCXO - but maybe its something else.


With the other GPSs I can lay out say a one meter square in my back yard and then move the GPS around the square and - it looks like a square. The tracks they generate can show you what side of a street you are on, or small turns, it records them. Same with trails and hiking. I record most of my GPS traces while hiking. Still seeking what is the best antenna for hiking.

Whan the GPS is totally still the display becomes fairly stationary, almost.

Yes, they work. Thank you.

[MIS42N]

No updates for a while because the design works. The current test rig has been running for over a month, the OCXO is not ageing much. The program update via Tera Term Xmodem is working in test. The output is usually within 1 part in 10E-10 of 10MHz as far as I can tell. I can't absolutely prove this because I haven't found a local standard better than this for comparison.

I live in Newcastle, Australia - anyone reading this willing to help with calibration?

Based on feedback from several people, there is room for improvement The following are under investigation:

1) Design for an enclosure - I haven't figured what is a standard - UB2, UB3 etc sold by several suppliers but these are plastic. Are these a standard? If the user wants metal because they are putting the device in an electrically noisy situation are there UBx enclosures in metal? More research needed. Any advice?

2) Sensitivity to external influences.
- I notice when the TTL to USB converter is plugged into the PC it causes a glitch - probably an earth loop. I've done some experiments with 4N25 opto couplers, and that fixes the problem for less than $2. The plan is to incorporate them onto the PCB and have the USB TTL converter in the case with a micro USB connector exposed to connect by cable to PC USB.
- power supply variations. I've tried various sources of 5V with "interesting" results. The new plan is to have a somewhat complex system using a buck converter to drop an external source (nominal 12V) to around 7V, then use separate 5V LDRs to feed the OCXO and the rest of the circuitry. Also a boost converter to kick the 7V up to (nominally) 15V to power a precision voltage supply from which the control voltage is derived. The 15V will also be used for 3). Awaiting deliveries of buck/boost from O/S at the moment.

3) Use a line driver/receiver between the GPS module and the GPSDO, connected via Ethernet cable. I have been using this combination to get PPS and NMEA data from a GPS receiver near the roof (antenna on the roof) for over 6 months. It works flawlessly. Heaps of satellites received, HDOP below 1 over 99% of the time. The GPS and line driver to be supplied by a buck converter from the nominal 15V (see 2.). The rig at the moment uses a 5V regulator but this requires the full current between GPS receiver and GPSDO. This results in an offset voltage between driver and receiver due to voltage drop in the earth return. This has not proven to be a problem up to 20 meters, but not all cables are made equal. A buck converter runs cooler and reduces the offset voltage problem.
A variant on this solution is to use one of the GPS modules with patch antenna inside a weatherproof enclosure, eliminating the need for an active antenna. Under construction at the moment.
Provision to be made for those people who are able to mount the receiver inside the GPSDO. It is easy to leave out the line receiver and put the GPS module in its place.

[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.

[trobbins]

Ok I see that level shift now - my initial thoughts were blinkered to the transient disturbances.

I can see that the control voltage level change could result from a change in the U5 regulated rail, and/or the VDD rail, and/or the gnd points. 

The driving change is increased U7 supply current on the VDD supply and its return.  That could be due to the VDD trace resistance from U3 to U7 causing a voltage change on U4 (if the PWM value was sensitive to device supply voltage).  That influence could be checked by cutting the VDD trace near U7 and rerouting U7 directly to U3, then there is just the load regulation of U3 at play.

It seems difficult to know where to start carving up the gnd plane without some indications of where there may be ground current influences.  I'd suggest that static voltage changes in the gnd plane could be assessed by retrofitting direct additional wire links, eg. from U3 to U7, and U3 to J7/4, and U3 to U4/14, such that the gauge of an added link diverts or suppresses gnd related voltage drops that show a net benefit in the frequency ppm deviation with 50 ohm load steps.

If available from the pcb maker, a simple way to suppress static voltage drops in the gnd plane is to increase the copper thickness spec for that plane.

[thinkfat]

Increasing the copper thickness sounds like a pretty drastic method to me. I'd first try to increase decoupling, adding capacitors close to the critical circuits, maybe adding a choke.

[MIS42N]

Further investigation of the reason the errors were halved when the averaging period doubled. A bit of stupidity (typical). The previous algorithm was designed to steer the 1pps so it arrived in the interval 0 to 25ns. As described earlier, this allowed the system to settle anywhere in that 25ns window so tended to wander in that window. My simplistic solution was to add 1 to all +ve deviations so 0-25ns became 1, 25-50ns became 2 etc, with -ve deviations -25to0ns is -1, -50to-25ns is -2 etc. This did force the system to try to settle on the transition from -ve to +ve. What I didn't realise was this gave too much weight to the 0to25ns and the -25to0ns intervals, resulting in corrections which were too large. This can be seen on the graphs, the voltage becomes a sawtooth overshooting every time.

When the measurement period was doubled, the overshoot was the same. But the algorithm now had twice as long to fix it, so the correction was halved.

The perfect solution to this is to measure the arrival time exactly rather than to the nearest 25ns. But this adds more hardware, against the principal of this build. Also it may test the power of an 8 bit processor to deal with the larger numbers involved.

So the algorithm is changed yet again. The solution was to add weight to deviations greater than ±25ns. The actual solution was double the number and add 1. So 0-25ns is still 1, 25-50ns becomes 3, 50-75ns becomes 5 etc, with -ve deviations -25to0ns is still -1, -50to-25ns is -3 etc. Calculations of corrections uses close to 32 bit precision, and shifts (divide by multiples of 2) the final result. It was a simple matter to add 1 to this to remove the effect of doubling the raw deviations.

So does it work. Yes it does. The GPSDO was off for a different reason before changing the software, so it has been running less than a day. Even so, sawtooth is gone and many corrections are less than 0.01 ppb. That's very satisfying. It seems temperature is now the biggest disturbing factor. Always something to think about.

I'll post another graph when I've got more data.

[MIS42N]

Here's the results of further testing with the u-blox LEA-M8T. Each bar on the lower graph is the adjustment after 1024 seconds of averaging so there's about 2 days of data. As can be seen there's a definite up and down wander to this which I originally put down to some error in the disciplining algorithm.  Between X=105 to 140 I tried two modifications to the algorithm. Both seemed to make the situation worse, and as I couldn't see a flaw in the algorithm, the original was reinstated around 140.

Then I looked at the pattern displaced by 84 on the X axis, and it seems to repeat. 84 bars is about a day. Lightbulb moment, this is variations in the 1PPS. It makes sense, when the M8T was surveyed in, it came up with a standard deviation of position of 10 metres. The antenna is in a poor location and it is likely sometimes the calculations are done on a reflected signal.  ±10 meters equates to ±30ns in arrival time.

Best way to prove it is put the antenna in a better position. Maybe in a few day's time.

Even so, happy with this. Some room for improvement but isn't there always.

[trobbins]

I quickly started up your GPSDO earlier today to test and adjust the high stability OCXO option 001 on a HP3325B, which was 0.1Hz high for 10MHz.  It certainly makes the adjustment process easy, especially as I only needed to reach the 0.01 ppb level on the GPSDO for this application.

My other 'budget' based adjustment on the HP3325B was to null the Analog Phase Interpolation 3kHz spur using a PC soundcard and REW spectrum analyser software, rather than use a full-blown spectrum analyser from that vintage.

[enut11]

My introduction to GPSDOs was not a good one.

Oct 2021
I had a HP 10811A crystal oscillator that needed a cal check using a higher authority. The DIY nature and low cost of a GPSDO seemed the way to go so I started building the @AndrewBCN project. https://www.eevblog.com/forum/projects/yet-another-diy-gpsdo-yes-another-one/250/
I am not a programmer so after several failed attempts at programming the STM32 chip using the Arduino IDE, I gave up as I had more pressing things to do.

Jan 2024
Recently I revisited @AndrewBCN project and reread all the posts and downloaded the latest IDE, STM and firmware. This time I got lots of IDE compile errors, so gave up again!

In Reply #143 of the @AndrewBCN thread I saw a short description of a GPSDO by @MIS42N. This one used a preprogrammed PIC to do the disciplining. Fantastic! I chased up all the parts and PCB and here it is. My 'Budget GPSDO' is still in the build phase but it does work and it works well.

Initial tests show my FA-2 counter to be low by about 2Hz. Later I will test the HP 10811A crystal oscillator. I also logged the Vco (OCXO control voltage) for a couple of hours and am still trying to understand the control mechanism.

@MIS42N, I made some changes to the build:
1) I used linear voltage regulators throughout (I prefer them).
2) I did not use the Vco buffer FETs and connected the PWM directly. This does mean a longer wait for stability when connecting to the 10MHz 50R output.
3) I used an Isotemp 143-141 5v OCXO. The two used OSC5A2B02 OCXOs I bought on eBay were faulty.
enut11

EDIT: The note on the Vco plot about hot-plugging the GPS module is a leftover from an old test and should be ignored.

[MIS42N]

@MIS42N, I made some changes to the build:
1) I used linear voltage regulators throughout (I prefer them).
2) I did not use the Vco buffer FETs and connected the PWM directly. This does mean a longer wait for stability when connecting to the 10MHz 50R output.
3) I used an Isotemp 143-141 5v OCXO. The two used OSC5A2B02 OCXOs I bought on eBay were faulty.
enut11

1) - no problem. The SMP was there to lower dissipation in an enclosure, and so it could be used by the Amateur Radio people who like a 13.xV supply. Any supply that works is OK.
2) - connecting the PWM directly leaves you at the mercy of supply variations to the uP and the output buffer. Also, if you connect up to the serial output it will report a -ve control voltage slope and an incorrect Vco. That's an artifact of the reporting, the software was written to handle both +ve (normal) or -ve (inverted) slope. It determines the slope during the calibration run.  The FETs act as an inverter and the reporting software assumes it is there. Neither of those are show stoppers, just "nice to have".
3) - Also the software is written to handle OCXO of different sensitivities, also determined in the calibration. It's good to hear this works in the real world.

The control mechanism is written up in Software.pdf in the GitHub repository. It's a bit weird as there's no accurate timer of the 1PPS, just to the nearest 25ns. It relies on the sawtooth jitter of low end GPS modules to randomize arrival times which (perhaps counterintuitively) improve accuracy. So collecting lots of data and averaging, unlike a normal PID control.

I still can't understand GitHub and might shift to SourceForge which seems more user friendly.

GitHub repository https://github.com/ajcashin/budget-gpsdo

[enut11]

Thanks @MIS42N for a fantastic GPSDO project that just works and is great for non-programmers.
I bought some of the hard-to-get parts from Silicon Chip Magazine and the rest from Jaycar Electronics Australia.

https://www.siliconchip.com.au/Issue/2023/May
https://www.jaycar.com.au/

You might have noticed that I mounted the OCXO on stand-offs. After the failure of two used units from eBay, I needed a way to easily change the OCXO.

To finish the project I am building an analog power supply and I also have a nice case to mount it in. You might say it was made by HP for this project
In case you were wondering, the box at present is just an empty shell. I know not what happened to the original internals.
enut11

[enut11]

All the bits mounted inside the HP box. I am currently monitoring the OCXO Vco from a cold start to see how it tracks by the time the 1PPS signal stabilises.
The 'GPS Lock' LED appears to be off but is in fact flashing once every second. The designer, @MIS42N, tells us that this is when the best performance is available.

Apart from measuring the Vco, how else can I check the circuit for performance? I am a novice wrt precision frequency/time references and my main interest at this stage is a way to check my frequency counters and 10MHz distribution box.
enut11

[trobbins]

As I was an early adopter (so to speak), and MIS42N kindly gave me two of his Rev1 pcbs, I built a second of these GPSDO's to 'confirm' performance of the first built unit.  To satisfy any further doubt, I luckily had access to a HP5065A Rubidium standard that gave a reference that was independent from GPS.  As I recall, I didn't have tools (or incentive) to push the comparisons below 0.01Hz, or do statistics or further design tweaking that MIS42N has since done.  Since then I have happily tweaked a HP 10811-60159 10MHz OCXO, as this budget GPSDO was easy and convenient to turn on and quickly stabilise.

[MIS42N]

The 'GPS Lock' LED appears to be off but is in fact flashing once every second. The designer, @MIS42N, tells us that this is when the best performance is available.

The LED has a variety of flash patterns. They are documented in GPSDOnotesV1.pdf in the repository. A design aim was to minimise the hardware to get a functioning system, the LED flashes try to convey useful information at all stages (e.g satellites in view before the GPS module reports a lock).

A single flash (50ms) once a second indicates the software thinks the frequency is within 1ppb (i.e. 10MHz±0.01Hz). This was a design aim and considered 'good enough' for most hobbyist uses as it is better than most standalone frequency references. The GPSDO frequency may be more accurate but that doesn't change the LED. The actual estimate is reported via the 9600 baud user interface. The output frequency is locked long term to the GPS 1pps, guaranteed (10M * period in seconds) cycles ±1.25 cycles if the LED is single flashing. So can be used to compare a rubidium standard (which is very stable but can have a small frequency error) using a phase comparison over a long period (e.g an hour).

[enut11]

As I was an early adopter (so to speak), and MIS42N kindly gave me two of his Rev1 pcbs, I built a second of these GPSDO's to 'confirm' performance of the first built unit.  To satisfy any further doubt, I luckily had access to a HP5065A Rubidium standard that gave a reference that was independent from GPS.  As I recall, I didn't have tools (or incentive) to push the comparisons below 0.01Hz, or do statistics or further design tweaking that MIS42N has since done.  Since then I have happily tweaked a HP 10811-60159 10MHz OCXO, as this budget GPSDO was easy and convenient to turn on and quickly stabilise.

@trobbins, I too have a HP 10811 reference and, compared to this GPSDO, it was running approx 2Hz low. This may have been just an ageing phenomenon as the HP specs say something like '10 to the -11' which is very good indeed. Anyway, I adjusted my 10811 and it is now better than '0.02Hz' as read on my FA-2 counter. See Reply #83.
enut11

[enut11]

This is a plot of the Vco (OCXO trim voltage controlled by the PIC) over a period of 2 hours from a cold start. This was an open box test.

The sudden Vco variations near the start are part of the software OCXO voltage/frequency sensitivity calibration.

The 1PPS GPS Lock signal happened around 30 min. From then on the plot is very flat suggesting only minor frequency control changes were required.

[enut11]

A close up of the last 20 min shows the Vco varies by about 300uV PP short term. Larger cyclic variations are also visible. Sample rate for this test was 4 sec. Ambient temp was 30C.

[enut11]

My GPSDO locked up a couple of times and had to be rebooted. Discussions with @MIS42N ultimately showed that I inadvertently created the problem.

The HP box that I used to house the GPSDO had some front panel LEDs that I re-used. These 'last century' LEDs were very inefficient, requiring up to 10mA drive. This current was upsetting the PIC and ultimately the Vco stability. While the exact nature of the problem was not fully understood, it appears to have been solved when I installed a very efficient modern PIC LED.

I also skimped and left off the 2 FETs that buffer the Vco and would recommend that they be used as per the circuit.

In any case, the PIC based GPSDO is working well now and holding 10MHz to within 0.01Hz or better.

A great project. Thanks @MIS42N
enut11

[trobbins]

enut11, did you use a 10k series resistor for your LED, or lower that value for better visibility ?

I had surreptitiously located various smt caps directly from various device pads to local gnd plane as a pro-active way of hopefully avoiding such disturbances, given the 10MHz operation and the nuanced manner of deriving the OCXO control voltage.

[enut11]

Hi @trobbins. I had previously lowered the 10K resistor to 270R (ouch) to get sufficient visibility from those very old LEDs. Anyway, I found a green LED that needed only 0.1mA (x100 less current) and it was still bright! Installed an additional series 18K for a total of 28K so minimal loading now on the PIC.

Tell me more about your ground plane and how you use it to improve circuit performance.
enut11

[trobbins]

'Improving' circuit performance may be a step too far, but the photo shows where I located local bypass caps on the PIC, 740AC04, J1, J2, OCXO, and power input (I used 5V plugpack and an on board LC for buffering).  The pcb is V0.0.

Ciao, Tim

[enut11]

A close up of the last 20 min shows the Vco varies by about 300uV PP short term. Larger cyclic variations are also visible. Sample rate for this test was 4 sec. Ambient temp was 30C.

I was curious about the short term Vco variations shown in Reply #88. @MIS42N had indicated that they were too large and that something was affecting the PIC supply.

The only other significant load on the PIC supply was the GPS receiver so I powered it with its own 5v regulator directly from the 12v input. This made a noticeable improvement to Vco stability.

The first chart is a 9hr plot of Vco. The large sudden variations are under software control as the program uses the Rx 1PPS to lock in the 10MHz.
The second chart is zoomed in to show the smaller variations. These are now around 10uV. Compare this to the 300uV in Reply #88.

The Budget GPSDO is now boxed and ready to use. Very happy with this DIY 10MHz reference. I have used it to calibrate a Racal Dana frequency meter, a 10MHz Oscilloquartz reference and a HP 10811 OCXO.

Is it finished? Not yet. I want to add a 10MHz output to the front panel and maybe even a buffered 1PPS. Also, I think a 240AC line filter will help clean up the power supplies even more.
enut11

[enut11]

With the metal cover on, the Budget GPSDO seems to have stabilised to the third decimal place. It has been running for about 8 hours in a room with an ambient temperature of 26-29C. Counter settings were 1s gate and HP 10811A external reference. Not sure if the GPSDO was checking the 10811 or vice versa

[ddosegov]

Í´d say I´m good.
Half of the sky shaded by building, in non-heated room, no enclosure...

>h Time 204314 UTC. Ctrl 1.760273 -0.049 ppb
 Time 204730 UTC. Ctrl 1.760203 -0.070 ppb
 Time 205146 UTC. Ctrl 1.760194 -0.008 ppb
 Time 205602 UTC. Ctrl 1.760196 0.002 ppb
 Time 210018 UTC. Ctrl 1.760378 0.182 ppb
 Time 210434 UTC. Ctrl 1.760338 -0.040 ppb
 Time 210850 UTC. Ctrl 1.760435 0.097 ppb
 Time 211306 UTC. Ctrl 1.760323 -0.112 ppb
 Time 211722 UTC. Ctrl 1.760218 -0.105 ppb
 Time 212138 UTC. Ctrl 1.760233 0.014 ppb
 Time 212554 UTC. Ctrl 1.760255 0.022 ppb
 Time 213010 UTC. Ctrl 1.760339 0.085 ppb
 Time 213426 UTC. Ctrl 1.760386 0.047 ppb
 Time 213842 UTC. Ctrl 1.760370 -0.016 ppb
 Time 214258 UTC. Ctrl 1.760319 -0.051 ppb
 Time 214714 UTC. Ctrl 1.760295 -0.023 ppb
 Time 215130 UTC. Ctrl 1.760288 -0.008 ppb
 Time 215546 UTC. Ctrl 1.760330 0.042 ppb
 Time 220002 UTC. Ctrl 1.760366 0.036 ppb
 Time 220418 UTC. Ctrl 1.760416 0.049 ppb
 Time 220834 UTC. Ctrl 1.760378 -0.038 ppb
 Time 221250 UTC. Ctrl 1.760322 -0.056 ppb
 Time 221706 UTC. Ctrl 1.760216 -0.106 ppb
 Time 222122 UTC. Ctrl 1.760214 -0.002 ppb

[MIS42N]

Í´d say I´m good.

Excellent.

I (and maybe others) are interested to know where you got your info and parts from. Version 1 or Version 2? And is it a part or full build. [enut11 did a partial build with his own variations].

[ddosegov]

Excellent.

I (and maybe others) are interested to know where you got your info and parts from. Version 1 or Version 2? And is it a part or full build. [enut11 did a partial build with his own variations].

Huh... Parts source: Aliexpress, PCB from JLPCB, I used design published here, modified power supply part and added LC filter to the output, repoured copper pour...

[ddosegov]

Is it finished? Not yet. I want to add a 10MHz output to the front panel and maybe even a buffered 1PPS. Also, I think a 240AC line filter will help clean up the power supplies even more.

Try this trick i used when I was chasing microvolts of variations on 5V line in another GPSDO - use 12v power supply and add 7808 in front of 5V regulators. 
For 1pps use PICDIV from leapsecond.com for generating 1pps from 10MHz, in that way you´ll still have 1pps if gps looses signal, and if something goes wrong with 1pps out, you´ll replace 1€ PIC, not gps.

[enut11]

Is it finished? Not yet. I want to add a 10MHz output to the front panel and maybe even a buffered 1PPS. Also, I think a 240AC line filter will help clean up the power supplies even more.

Try this trick i used when I was chasing microvolts of variations on 5V line in another GPSDO - use 12v power supply and add 7808 in front of 5V regulators. 
For 1pps use PICDIV from leapsecond.com for generating 1pps from 10MHz, in that way you´ll still have 1pps if gps looses signal, and if something goes wrong with 1pps out, you´ll replace 1€ PIC, not gps.

Hi @ddosegov. Yes, I already use a 7808 in front of the 7805 supply to the PIC. That is part of the original design by @MIS42N.

Tell me more about PICDIV.
Thanks
enut11

[MIS42N]

Tell me more about PICDIV.
Thanks
enut11

Uses assembler program for a pic12f675 or similar to create pulses from the OCXO 10MHz input. The processor runs without interrupts so relies on accurate loops to produce the desired output.

There are a few different 1PPS programs. The simple ones produce the 1PPS with no synchronisation so are not aligned with an external time source. More complex programs allow alignment to within ±200ns of another source with suitable external input. Due to the instruction time being a quarter of the clock, it would be difficult to adjust that last 200ns.

I don't know it is worth implementing. You want 1PPS, take it from the GPS module. As long as there is a reasonable sky view, they will continue to output 1PPS. The PIC in the GPSDO keeps stats on lost signal, rarely happens.

However, if 100% reliable (but not necessarily 100% accurate) 1PPS is required, for example to run a wall clock, then maybe PICDIV has a place. The OCXO is always running but with an extended loss of input there will be a CPU reboot and there may be a loss or gain of cycles before discipline is reestablished.

The GPSDO program could be written to give extended holdover (if input is lost then restored, the OCXO frequency is changed to compensate for any lost/gained cycles then discipline reestablished). However, that seemed like more complexity that a simple GPSDO was expected to deliver. Currently if signal is lost for around a minute, the CPU is rebooted and runs with the Vco established during calibration (unless the user interface is used to update the default Vco) until the signal returns.

http://www.leapsecond.com/pic/picdiv.htm