GPSDO Version 4

While trying a few new ideas and testing the changes with Version 3, described in another post, and the rather successful results, I started to incorporate everything in a new version 4. This version should be usable as a replacement for my main GPSDO and also to be used for the Reciprocal Counter project also described in another post.

The major addition from the past versions for this version is to use a temperature controlled heater system to keep the components at the same temperature because that is the most critical element that influences a GPSDO. You can eliminate the heater section by simply not populating the parts.

What role does the temperature play?

The temperature generated by parts and the temperature inside the enclosure, influenced by the room temperature, change the relationship of the 16-bit "DAC" output values, actually the DUAL 8-bit PWM, that drives the frequency adjustment of the OCXO and therefore the 10MHz output frequency. Because most of us don't have expensive phase-measurement systems, we use the DAC output values as they are reported by the GPSDO script as a poor-men's alternative method in a program called Timelab to be able to generate ADEV and MDEV charts to look at the long term stability and precision of the GPSDO.

The problem is that when the DAC changes due to temperature effects, it is no longer representing the true 10MHz relationship and therefore renders the ADEV chart method as less precise, to put it mildly.

The challenge is to eliminate any temperature related effects on the DAC settings, so the DAC changes are only caused by the 1PPS from the GPS system, and hence create a 1:1 relationship between the two.

What are the circuits that play a temperature related role? First you have the effect of the temperature on several parts, most notably all the parts that are driving the f-adjust pin of the OCXO. This includes the whole dual 16-bit PWM circuitry, and then the Phase Difference TIC "pulse-to-voltage" circuit between the digital 74HC4046 output and the ADC of the Nano. The Nano ADC is referenced by the internal 1.1V supply and this also will be temperature dependent in some way. Keep in mind that temperature has an influence on all the propagation delays (specified at 25 degrees in the data sheets) of the chips involved.

Second you have the ever changing room temperatures that in my case differ through the seasons. Low at night in the winter, and pretty hot in the afternoon in summer. There are users that literally go through a burial process of their GPSDO in a bucket filled with sand and put it in the basement to reduce these effects. I tried my best by using a fan to try to keep the inside temperature constant for my version 1 GPSDO. That works really well, but unfortunately does not work well with the seasonal changes I have. The temperature difference between night time (not heating) in the winter, and warm summer temperatures during the day is too large for the design I made, so I always have to readjust the settings when the seasons change. I also don't like the noise the fan makes when at close to full speed, and I also want to eliminate the electrical noise it introduces so close to the other critical parts.

To reduce the temperature effects a bit, I already switched to using a Mica capacitor used in the Phase-diff circuit. Mica capacitors are very precise and stable and have extremely low temperature effects on the capacitance. Instead of the 1N5711 Schottky diode that Lars recommended, I'm now switching to a BAV199 (2pF) or a BAV99 (1.5pF) type. They are dual diode packages in the SOT23 form. I will only use one diode of course. The 1N5711 diode is a Schottky type and fine by itself, but I have to mount it upright to save space and that makes it more susceptible to drafts inside the enclosure.

Because these parts are in the controlling loop, I hope that the temperature effects of these new parts reduce the overall effects.

Much more temperature critical is the whole dual PWM DAC circuit all the way to the f-control pin of the OCXO. Minute changes due to temperature in the output of the DAC circuit will change the output of the OCXO. This is exactly what we want to avoid.

To eliminate or as a minimum reduce all these temperature effects, you can make the internal enclosure temperature very stable so there are no changes. You can do that if you can raise the temperature inside the enclosure above the normal seasonal maximum and keep it constant by regulation, and insulate the inside from room temperature changes as much as possible so active temperature regulation can do the rest. 

The alternative that is most commonly used is to use parts that are less susceptible to temperature changes. Unfortunately, anything low tempco is very, very expensive.

So the other solution and challenge is to raise the regulated temperature of the components high enough above the summer temperatures, while making sure that enough heat can be generated in the cooler winter period to keep the temperature at the same level during the seasons and without sudden fluctuations.

A heater design example

A friend of mine, Bud, who unlike me is a real designer, came-up with a heater circuit for his voltage reference. These circuits have exactly the same issues and challenges as I described above.

Here is more information about his design and the process he went through.

https://hackaday.io/project/165139-precision-voltage-and-current-reference

I built that circuit for my own voltage reference and have been monitoring the voltage and the temperature for several months now. It works great, so I was planning on using that heater technique for the GPSDO already quite some time ago.  Now is the time to put it to the test.

To heat-up the circuit, Bud uses a string of resistors and regulates the current through them to keep the temperature constant.

Based on his design, I made some small changes so I can incorporate it with the new GPSDO version. 

The nine sets of resistor strings are each current regulated by MOSFET's. The MOSFET's are driven by an Opamp that measures the PCB temperature and regulates against the desired voltage set by a few resistors. The feed-back components of the Opamp provide a "PID" type regulation.

Using the heater design with my GPSDO

Because I want to stay with the 12V supply I already have, I had to recalculate the values for the heating resistors. Because I want to use the already available 4.096V reference supply, I also had to recalculate the values for the temp setting resistors.

The temperature sensor I selected is a device with an output voltage of 10mV/degree C. I want to keep the temperature of the heater at 38 degrees, which is several degrees above the expected maximum temperature in my office, in the summer. The reference voltage is therefore set to 380mV.

During the cold start, the Opamp output will slam into the rail and may have troubles un-hugging again, so the Zener diode should prevent that and also limit the maximum current. With the 12V supply and the 68R resistor values, the total heat produced should be just over 3W. 

I've added a test pin connected to the temp sensor so that the temperature can be monitored by a DMM, and it also goes to the Nano so the GPSDO script can measure and include it in the report.

The heater resistors will be distributed on the bottom side of the PCB and the most critical GPSDO components are located on the top of the PCB above the heater.

Here are the other circuit elements that make-up version 4 of the GPSDO:

I switched back to using the 74HC4046 again, and I also added the ambient temperature sensor that is sitting close to the TIC parts. This allows me to monitor both the heater and the temperature close to the critical components.

This is the largely unchanged dual 8-bit PWM DAC circuit I have been using in the version 3 tests. These parts will sit on the top side of the board, above the heater components. Here is a link that explains this circuit :EDN article

This is the power rail section. The 12V is used by the heater section and also feeds all voltage regulators.

There is a regulator for the 5V supply and it feeds the Reciprocal Counter, the optional fan and also the OCXO.

There are two other separate 5V supplies for the logic section and for the NEO board. Especially the NEO supply is fluctuating due to the 1PPS pulse and that effect I want to isolate as much as possible.

The 8V supply goes to the Arduino Nano, and I'll let it use it's own 5V regulator to supply the parts on the Nano board itself.

To the right hand side, you see an 8-pin connector. This is the interconnect that will go to the output board. This board is only used for the GPSDO version to provide isolated 10MHZ and 1PPS outputs for other instruments. 

The layout

This is the top side, with the most critical components sitting on top of the heater section. The heater temperature measurement sensor sits also on this side of the board.

Because this board will sit inside an insulated chamber made from foam, it has to be as small as possible to fit. It took me quite some time to get all the parts on the board. Unfortunately, the Oscilloquartz is no longer an option. It's too large, but I already have other plans for that OCXO.

And here is the bottom side (flipped horizontally) with the heater element resistor pads.

This is the most complex layout I've made, with quite a number of parts. It wasn't easy to get everything laid out with a 2-layer board. For this first version, I wanted access to everything so I can measure and make changes by cutting traces. 

How it will fit together.

To keep the heat trapped inside the enclosure, and minimize the effect of room temperature changes, the board needs to be encapsulated by a foam box. The 4 plastic stand-offs mounted in the mounting holes will raise the PCB a cm or so from the bottom insulation.

There are several additional steps I need to make to keep the heat inside and reduce leakage. Much to try and test, so time will tell.

I've ordered some 6mm and 8mm Styrodur foam sheets to be used as the insulation for the inside of the enclosure. I also ordered a special foam cutter that will allow me to cut precise sizes of the foam to reduce heat leaks. The foam cutter works great so I'm more confident that I can get my chamber made without too many leaks.

[Update June 8 2023]

 

The PCB's arrived and I have built one up. I had some problems getting it all to work. It turned out that I copied an earlier version of the schematic into this version, but forgot to include some of the changes I already made. I also lost quite a bit of time hunting an error in the heater circuit that turned out to be caused by a bad Opamp. In any case, it's working and I'm running the very first test of the whole system. After setting the loop parameters and turning it on, I got a lock pretty quickly and the automatic TC increased without issues to 500.

Here is a graph where I monitor the heater temperature sensor output (mV/degree C)  during the start-up period.

It takes quite some time to get the inside temperature to settle down. Although my initial goal was to have the heater settle on 39 degrees, the oven of the OCXO and the 5V regulator add to the inside temperature.

After the ramp-up, I started to track the sensor anew, to see what is going on in more detail.

Note the voltage scale.  We're looking at 46 degrees C with 1/10th of a degree or less resolution. The temperature is measured on the top of the PCB and is a function of the heater and the OCXO oven. I may need to raise the heater temperature a bit to get it closer or even above the OCXO oven temperature, or let some of the heat escape from the OCXO itself by adding a hole in the insulation right on top of the package. 

Right now, it seems that the OCXO oven is controlling the inside temperature and the heater may only function during the start-up. Either way, the temperature is nicely regulated for now. I'm letting the Lars' sketch track the temperature of the PCB in two places, so I can plot them over large time periods without using my DMM.

I will let the system run for 24 hours to give the OCXO some more time to settle. Right now you can see that the DAC values are still very slowly going down while the temperature has been stable. 

Note that the first 500 seconds of the run were left out when I plotted the above graphs.

After 22 Hrs, the DAC is now starting to settle down:

Just showing the last 1 Hr snap shot of the above data shows the tracking of the DAC to the NS data and is basically devoid of temperature changes (although we have a heat-wave at the moment):

The TC setting of 500 is probably a little too high for this CTI OCXO, but I'll continue this run with it.

After everything has stabilized, I'll do a new parameter setting exercise and then do a run to try to figure out what the TC should be by using an ADEV chart.

After 24 hrs, the OCXO seems to be happy and stable again in it's new home.

I broke-off this run, and redid the parameter selection of the gain and the DAC linearity. I also disconnected the power to the OCXO and changed the temp setting resistors to have a heater temp of 44 degrees, same as the OCXO seems to produce to the inside of the isolation box. Obviously, the OCXO metal can itself is a lot hotter. I then profiled the heater start-up again. 

I'm tracking the output voltage of the heater Opamp (U5) here. As you can see, it slams into the rail (I took the 6.2V zener (D1) out of circuit that's supposed to prevent that because I'm having some issues with it) and than gradually reduces the voltage/heater current while the temperature is still ramping up. The final temperature the sensor is reporting is now 449mV so 44.9 degrees C. Close enough, time for a next run.

While using my IR camera, I can see that the heater on the bottom of the PCB provides a very nice looking uniform temperature on the top side above it. I use a lot of strings with resistors, but that really helps to get a uniform heat pattern, without heating-up the individual resistors too much.

I really think we may have a very good solution to the issue, but time will tell. Right now we have a heat-wave and the temperatures at night hardly drop at all. So I will not declare victory yet.

I'm a little concerned about the temperature of the 5V regulator for the OCXO (U6), it reaches just above 60 degrees, and the electrolyte next to it (C21) gets too warm. The heatsink I use for the regulator is too small, unfortunately, it's all I have and I don't have enough room on the PCB to try something else. Initially, I wanted to use the extra heat from the regulator, especially during the warm-up period for the OCXO oven, but I now found that it is not really needed. I will relocate the regulator back to the enclosure again (on the back panel?), and simply use wires to connect to the original pin holes.

With things they are now, I'm glad that I will not need a fan so I'm going to remove all that from the next revision onwards.

I moved the main LM317 (U6) to the back panel and I'm running another test with all the changes. Apart from the missing front panel, everything is inside the foam box inside the enclosure as it will be eventually.

Judging from the temperature reporting, I don't need the two sensors at the two locations above the heater anymore. With the next revision I will move the one close to U14 and place it underneath the OCXO to keep track of that temperature.

Also judging from the heater Opamp output voltage, it takes about 45 minutes before it reaches a steady state. It takes that long to gradually get everything warmed-up to the set temperature of 45 degrees. The controlling loop works really well. Kudos Bud!

BTW, when everything is on temperature, the GPSDO draws an overall current of about 220mA at 12VDC. That's not too bad.

[update 10-07-2023]

I found another item of interest. 

Below is the current run with the new 44 degree PCB heater temperature setting. Luckily, I was pre-occupied with something else so I left it running for a longer period. When I looked at the latest data, I saw a disturbance I cannot really explain yet. I may have bumped the GPSDO when I moved it a bit.

After the glitch (bump?) everything went smooth again for several more hours.

After more than two days, the DAC seems to be slowly settling again...

Below are the same plots just with added data. For some reason, there are larger swings in the NS numbers. Why I don't know yet. Here is a new plot after another night, luckily no more disturbances, but the DAC is still going down :

I'm going to stop this run now and do a run with TC 4 to find the optimum time constant (TC) by selecting the fixed TC mode (x0) and then t4. The resulting trace can then be analyzed in TimeLab. It will need about 28 hrs (TAU of 100.000) to get enough data to reduce the uncertainty and see the cross-over point between the OCXO and the GPS.

Here are the results of 1 day and 12 hrs worth of data collection to determine the optimum TC.

There was a little bit of extra hash, most likely due to my less than ideal GPS reception, but after that, everything went back to normal. The extra hash will probably make the ADEV plot a little worse, but so be it. The PCB temperature is rock stable.

Here are the TimeLab ADEV plots. First the unfiltered plot (the vertical bars show the uncertainty):

Lars recommends to use the "subtract global linear frequency trend (drift line)", and that results in this plot:

Up until 4 seconds (TC = 4), we see the OCXO stability by itself, and after that the GPS takes over and the stability (not the absolute accuracy!) increases to about 1.66E-11 at 2,000 seconds.

This graph suggests that we can raise the TC to 1,200 (20 minutes) of averaging. This is the point where the downward going slope transitions into a flat or going up part.  A value of 1,200 is way better than I could expect from this quite simple OCXO. 

Lars reports that the TC range for an OCXO can be between 100-1,000 a rubidium between 2,000-10,000. Maybe the version 4 hardware is really making a big difference...

So the next run will be with a TC of 1,000 instead of 500 and we'll see what that does. 

[Update 13-07-2023]

Well, that didn't have the hoped for results...

Notice the wild swings in the NS plot. There must be something wrong with the hardware. I now see swings way beyond +/- 20ns. Maybe that glitch I saw earlier was a sign of something going bad.

Due to the increased filtering with the TC of 1,000, the NS gyrations got beyond 80, a value which I selected to cause a reset in the automatic TC code. The system could not recover quickly enough so it lowered the TC to start at a beginning of 4 again. The original code from Lars uses an NS value of 100 to determine the loss of a lock. Either way, a TC of 1,000 seems to be too aggressive with my less than ideal GPS reception.

The good news is that the temperature regulation does it's job. I now also need to plot the room temperature and figure out at what higher room temperature, the heater looses control.

I've started a new run with a TC of 800, which is still very respectable. I also switched from my Lab Supply to a good 12VDC wall-wart to supply the power to the GPSDO.

Running these very long term runs will allow me to start to work on the connections of the GPSDO to the outside world and a new revision (4.1) for the PCB with the changes/corrections and the aim to make it smaller so it can be used for the reciprocal counter as well. That's next on my list.

Although I was monitoring the results over several days, the performance got worse and worse due to the wild swings in the NS numbers. I even set the damping from 3 to 2 to no avail. The GPSDO is loosing the lock all the time due to NS numbers getting out of range.

[31-July-2023]

To get an idea of where the regular wild swings from the NS come from, I switched out the NEO and applied the 1PPS signal from my main GPSDO. It has a NEO M8T and should be better. Unfortunately, that did not improve anything. For some reason my setup has developed an issue that I need to further examine. The GPS reception itself is fine with plenty of satellites and good reception. PDOP is 1.5 and HDOP is 1.0. Hmmmm.

[1-Aug-2023]

I spent just about the whole day on the NEO issues. In the end, I found an issue with my M8T. It seems that it's not a real genuine chip, or something went bad. The hardware report no longer shows the version anymore, and I can't use the survey mode because of that. It may have been partially bricked. Luckily, I found a used M8T from a reliable source I used many times before so I will have a new chip somewhere in the early part of September. This is not a major problem because I'm going on vacation for two weeks anyway.

GPSDO Version 4.1

[ 27-July-2023]

After all the findings and improvements based on V4.0, I decided to update the design to new version. I also needed to reduce the size of the PCB so it would fit inside an isolated chamber, and do double duty for my main GPSDO and also use it for the Reciprocal Counter. The counter assembly needs more room than what the 4.0 PCB provides.

On top of that, the main GPSDO will also need an interface board to bring out the required signals, and electrically isolate all of it to avoid connection glitches and grounding issues.

Here are the circuit diagrams for this new revision.

The major changes are that a DS18B20 room temperature sensor is added. This sensor will be located outside of the enclosure and is monitored by the sketch. The other temperature sensor is now an LM45 SOT-3 version and is now located underneath the OCXO. The connectors that go to the interface board have changed and are now added here. I have broken them up to make the layout easier. Also note that I replaced the 1nF TIC capacitor from a Mica THT to an SMD NPO version. With the heater, the Mica version is no longer needed. I also changed the TIC diode back to a BAT 54C Schottky version to reduce the voltage drop. The few extra pF's (from 1.5 to 10pF) dwarf in relation to the 1.000pF capacitor value.

I've added the 100nF decoupling for the U3 Opamp and changed the VCC voltage to the 8V rail, same as for the Reference. The U2 reference can be switched out for a 5V (REF5050) or even a 10V (REF5010) version. Keep in mind that when you do, several resistors values have to be recalculated.

Note that I show a 4.7uF capacitor (C32) on the f-adjustment input of the OCXO. That value may be too high for the Opamp to drive, so you can reduce the value to as low as 10nF.

I've decided to no longer buffer the output from the OCXO's with a 74HC14 gate, but I did add the optional termination resistor R91, in case the OCXO needs it. And I've also isolated the OCXO signal with C35, and added two mid-rail setting resistors R81 and R82. 

I've added another SMD package for the Zener diode, the rest is largely unchanged.

The temperature sensor is now used to monitor the actual PCB temperature close to the TIC circuit and is recorded by the sketch.

The major change here is the move of the main LM317 for the 5V OCXO rail to the back panel. I also moved the interconnects to the Processor board. The Fan circuit elements are all removed.

The layout was quite a challenge to reduce the size and accommodate all of the additions and changes.

Note that I made a small error with the silkscreen for the 74HC390. It is shown as a 74LS390 because KiCad does not have a symbol for the HC version, and I forgot the change the name. The 4046 is a 74HC4046 version.

Version 4.1 Interconnect board

I started working in this additional board quite some time ago, but kept making changes based on different ideas.

The goal behind the circuits for this board is to fully isolated all signals coming from and going to the GPSDO circuits. Ideally, I want nothing to disturb the fragile operation of the GPSDO. This board will only be used for the main GPSDO, the counter version does not need it, unless I want to feed it with the 1PPS from the main GPSDO. In that case, many components are not needed and can be left out.

In the end, I decided on having two isolated 10MHz outputs on the front panel, and one on the back panel.

The isolation for the 1PPS pulse provided on the back panel is a little differed because these low frequency signals cannot use a simple transformer so I decided to use an optical isolation switch. This configuration needs some power on the secondary output side so I use a small isolated DC-DC package. I prototyped this circuit and it works really well. The downside of this circuit is that there is a significant added propagation delay. Keep that in mind.

What I also wanted to add is a 1PPS input to the GPSDO. My main GPSDO has a genuine NEO M8T, which is the timing version that is supposed to be much better than the fake normal NEO's like the 6 or 8 that I'm using now. The idea is that the GPSDO for the Reciprocal Counter can use the 1PPS from my main GPSDO.

The serial interfaces for the Nano and the NEO also need to be fully isolated. In this case, I'm only optically isolating the TxD signals from the Nano and the NEO, because they go to the Raspberry Pi monitor. The RPi will supply the 3V3 power rail to the optical interfaces and create 3V3 levels for the RPi. Right now I'm only logging the Nano, but I want to also start logging some data from the NEO as I did before with the "simple" counter.

If I have a need to re-program the Nano or use u-center for the NEO, I can use an isolated USB TTL interface adapter that connects to the Nano USB serial or the NEO USB serial connectors. This will alleviate the glitch/jump issue when connecting a USB cable directly from my Laptop to the USB connector on the Nano. I reported about this weird glitch in the previous GPSDO blog post.

The interface board will slide upside down in the top slot of the enclosure, with the larger parts "hanging down" from the bottom of the PCB. What you see here is the Top side that is facing the top cover from the enclosure. There is only about 3.5 mm of space between the PCB and the top of the enclosure.

The two interconnects to the GPSDO board are on the left hand side, together with two 10MHz connectors that will use a braided cable to go to the connectors on front panel.

On the right hand side are the connectors that go to the outside of the enclosure via holes in the back panel. The 10MHz and 1PPS signals will have an SMA connector sticking through the back panel. 

This is the bottom side of the PCB with all the taller components.

Both the GPSDO and this board have been uploaded to PCBWAY by means of the added "button" in KiCad, which makes this process super easy. PCBWAY sponsor the production, shipping & handling for me of which I'm very grateful.

[1-Aug-2023]

Both the boards will arrive tomorrow, but I have a busy week because I'm going on vacation at the end of this week. I will most likely not have enough time to build them up and test them. 

[4-Aug-2023]

After a delay, the boards came in yesterday, and again I'm impressed with the quality. I did manage to find some time to solder the heating resistors on the GPSDO board. The rest will have to wait until I'm back from vacation.

[21-Aug-2023]

I'm back from vacation and started the population of the GPSDO board. It's done and running the first test. I changed the PCB temperature from 44C to 51C to isolate the board a bit more from the room temperature, which is pretty high at the moment. We have warm summer weather.  There is no ground plane underneath the OCXO anymore so there is a reduced heat transfer, which is better for the heater regulation.

During the building process, I noticed a few silkscreen hick-ups and I found that the 8V regulator is a bit too close to other parts so it's now moved a little sideways. My current version with the above corrections and changes is now V4.1a.

My genuine but used M8T also arrived so I have plenty of things to do...

[24-Aug-2023]

Replacing the fake M8N with the 8MT has not solved a strange glitch issue I'm having already for a long time. There is an example in the data below where the lock is in jeopardy and the TC needs to back-pedal to keep the lock. I'm now suspecting the 74HC4046 I'm using. I have moved it from prototype to prototype and it could be the root cause. When I power-down the unit, I will replace it. (It did not solve the issue)

I will still need a longer test period, but after almost 46 hours, everything seems to be OK and shows an improvement over V4.0. We're getting there at last...

I'm tracking the room temperature, the PCB temperature and the OCXO temperature. The OCXO temperature is measured by an LM45 SOT-23 placed underneath the OCXO and is connected by heat-sink paste to the metal can. After warm-up, that temperature stays within a small window while the room temperature fluctuated between 28.5 and 25.5 degrees. The PCB temperature is rock solid at 52.9 degrees without any fluctuations. The DAC has settled down after about 16 hours and is still fluctuating, as it seems only from the phase errors (NS), but now devoid of temperature related changes it seems. 

NB This is still without the top of the metal enclosure installed, so the OCXO can is still subject to the room temperature changes.

( I removed the first 1.000 seconds after the start-up from the graphs below to zoom in on the actual fluctuations)

Extracting the NEO 6/7/8 qErr data

The qErr is a prediction for the internal clock difference to the next 1PPS misalignment error, and produced by the NEO chips. The qErr number can be subtracted from the next NS value already used in the sketch, and thereby eliminate the clock errors due to the misalignments of the GPS 1PPS signal and the NEO internal 26MHz clock. In my setup, these "errors" are shown to be in the +/-10nS range. 

Be aware that I've heard that the qErr output is no longer available starting with the NEO 10-series, so stick to the 6/7/8 series.

Information about that interesting new feature can be found here: https://www.eevblog.com look for post #1065 from contributor UR8US.

UR8US provided the Lars' sketch he is using, but I wanted to experiment with a simple test program using a bare Nano and an M8N NEO to learn how to do it. I have now figured out how I can extract the qErr information from the NEO.  

Hardware details can be found here : NEO interface and here for the qErr report : Protocol 

Look for the UBX protocol section 32 starting on page 168 and for the report details on pages 432-433

This is what needs to be done hardware wise:

The SDA signal is available on pin 18 of the NEO chip, and goes to A4 on the Nano.

The SCL signal is available on pin 19 of the NEO chip, and goes to A5 on the Nano.

The NEO already provides the pull-ups, and the i2c/DDS interface is activated by default.

The A4 and A5 inputs on the Nano are currently not used so that's a simple modification.

I used two thin wires that I soldered directly to the NEO chip and then extended them to the Nano inputs.

After a bit of fiddling, my test sketch runs fine and I can extract the qErr result. Below is a sample of the output of the test sketch.

 

The next step is to make the hardware modifications to the V4.1 GPSDO and also make the changes to the main sketch. 

[26-Aug-2023]

The hardware changes are easy. All you have to do is to solder two thin wires to the NEO chip pins 18 and 19 and connect them to the A4 and A5 pins on the Nano board itself. The wires are floating in the air, so no PCB changes are required. That's it. The NEO already provides the pull-ups for the i2c bus and the bus is activated by default.

I had to make a few small changes to the sketch that UR8US provided because the initial "mValue" delay (he calls it Kounter) of 300 causes the loop timer not to increment anymore. This is likely due to the added code I have in my sketch. My assumption is that he uses this as a "delay" to fill out the 1 second loop time so there is enough time between the polling of the NEO and collecting the qErr data. In my case, a value of 250 was borderline so I used 200, but even 0 seems to work well for me.

Lastly, I found that the qErr results were alternating with a zero value every 1s loop, so I added a small fix to his code to eliminate that. Some of his code was not used by me, mostly the plotter code.

Here is a small sample of the result:

The qErr results are simply subtracted or added to/from the "raw" NS data, resulting in a "new" NS number that should be devoid of the NEO internal clock and the 1PPS alignment issues. These error numbers for my setup are in the +/-10nS range.

I also replaced the HC8046 chip to see if that will eliminate the strange glitches I'm having. These glitches are not due to the GPS antenna or GNSS constellation, because my main GPSDO, that uses the same antenna does not show any of the glitches. It is rock solid. (it did not)

[27-Aug-2023]

I've now started a long run with these changes. After a run of almost 21 hours, there was only one glitch, that I'm now suspecting is coming from the CTI OCXO. Other than that, the system is behaving very well. It seems I'm now well into the quality issue area of the used OCXO.

Addressing the Sawtooth effect

Now that I've been able to address the clock alignment errors, the next step will be to figure out a way to eliminate or reduce the sawtooth effect. The trick is to find the correct place in Lars's code on where to do it so it does not mess with his code and functionality. I also need to better understand more of the various filtering (IIR technique) he already uses.

Before I will embark on that adventure, I need to start a separate project to better understand his code.

[09/09/2023]

I did start on a better understanding of Lars' code and improved the comments in my sketch, but I have decided to not do the sawtooth "correction". There is already quite a bit of dampening in the original code and I don't want to disturb that at the moment. If it worked for Lars, it will have to do for me. There are other things I believe I can improve a bit.

It took a while before I could get back to the Blog. I was experimenting with a number of things, and I also got a few health issues that I'm slowly putting behind me. Nothing serious, just bothersome.

I started to build-up a second GPSDO 4.1 PCB so I could do some experimentation while I could leave the other one alone. In the meantime, I also got delivery of my second Bliley OCXO. At first when unwrapping the package, I got a scare because there is a large dent on one of the corners. However, it works fine despite that issue, so I put it in my second circuit and I'm running more tests.

One of the circuits that I looked into a bit more was the heater circuit. Long term analysis showed that the regulation was not as good as I had it earlier on the 4.0 build. After a large number of tests, I decided to swap the TL071 Opamp with a OPA1641 and that improved things pretty dramatically. I now need to run some longer tests with this new board, and will leave the first one alone for the moment.

One of the other circuits I was not overly impressed with, when starting to look at the seemingly unstable performance, was the 16-bit dual PWM DAC circuit. It turned out that the voltage going in to the Opamp was not very stable, and the output of the Opamp was pretty dismal. Here is what I found with the DAC set on hold with the value set around the sweetspot:

This is the output of the 16-bit PWM DAC circuit, taking from C8:

It seems that the minimal loading of the Opamp inputs is already enough to cause these changes. 

This is the output of the Opamp after the compression circuit, taken from the f-adjustment test point:

This is pretty bad because the noise and swings are larger than several DAC steps. This will effect the OCXO output and will work against the controlling loop resulting a an unstable output.

I replaced the TL071 Opamp with an OPA1641 and the changes are pretty dramatic:

The DAC output at C8 is no longer jumping around although there is quite a bit of noise. However, this is in the low micro-Volt range now. 

The output of the Opamp and the compression circuit is now also a lot cleaner, although could be better.

I'm now starting a new run with the second Bliley and see what it will do with the two improvements.

This second Bliley will need to be nursed back to a stable situation so this could take a few weeks.

[update 18-Sept-2023]

I have also been busy finishing the Reciprocal Counter.

The counter is now measuring my main GPSDO. 

The picture was taken at the beginning of the first run, it is now showing a stable 10.000,000,000,00 MHz with only an average of 26 measurements. Quite impressive.

The white box on top of the counter is a Raspberry Pi that I use to monitor the GPSDO report inside the counter.

I also put together all parts for the new version main GPSDO and finished populating the interface board. 

After verifying the correct operation, I created a front panel and back panel for the GPSDO, and they are in production at PCBWAY at the moment.

The interface boards came in and I build one up. The main GPSDO is lying open on my desk so I can still run some tests.

You can see the two grey and purple wires that go from the Nano pins to the NEO so I can use the qErr data. The interface board lies on top in the position it will eventually slide in the top half of the enclosure. The three wires on the output side (on the right side) go to the Raspberry Pi that supplies the 3V3 for the interface and monitors the Nano sketch output. Above that is the cable that supplies the isolated 10MHz signal to the Reciprocal Counter.

Because the enclosure is still open, there are some temperature related changes that will be eliminated when the enclosure is closed.

The sponsored by PCBWay front panel and back panel came in so I could finally go to the next step and finish-up and close the enclosure.

Here are a few (low quality) pictures taken with my phone. Better ones will come when everything is finished and I can use my lightbox and DLR camera.

The thick cable coming out from the back is the connection to the DS18B20 temperature sensor. I will probably change that to an LM35 that I still have. It saves on the code volume. I also may need the extra space because I committed a cardinal sin. Read on...

[Update 30-09-2023]

While testing the complete setup of the main GPSDO and the Reciprocal Counter, I continued to have poor results that I finally tracked down to the performance of first one the NEO M8T's, later both. I spend quite a bit of time fiddling with u-center to adjust the NEO M8T parameters, because I never really understood it all, but things got gradually worse. On top of that struggle, my laptop started to protest every time I plugged in the USB serial interface to the M8T carrier, using the micro-USB or the individual pins. I have been re-installing USB drivers for the two different chips that are used in my USB serial adapters, to no avail. The only remedy was to power down my laptop, and start it back up to a really fresh setup (don't use restart!). Eventually I removed u-center after I found a newer version was available and started with a fresh installation. 

This time, things started to come together. Eventually, I even got the M8T to produce a Timing fix, something that I never saw before. I still can't figure out how to do the survey, but a while ago, I collected the GEO data from running the M8T for a few days, and collected the average parameters. 

I also programmed the other M8T and presto, also the Timing fix appeared after a while. With the stationary/fixed parameters, the resulting 1PPS signal is a lot cleaner because the NEO chip no longer has to figure out what the position is all the time.

After putting it all back together, I'm running another test to see how things look over a longer period. 

More later!

Using a "real" DAC

For the past years ever since I started with this project, I followed the principle design that Lars put together and documented. I deviated here and there with improvements, but kept following the original design. However, one of the crucial circuits still does not meet my expectations, the dual PWM DAC. 

Even with the new design I'm using now (if it's good enough to go up in space), I was disappointed with the drift and jumps. I measured that by fixing the DAC to the mid-point and used my 6.5 digit DMM to track the output changes in a graph. My hope was that with everything at a fixed temperature, there would only be a minimum amount of drift and jumps. That's true, but I'm not impressed.

So, for a long time, I resisted the urge to use a "real" DAC, until last week, when I got weak in the knees. So sorry Lars. I looked for a 16-bit plus DAC, settled on the 18-bit AD5860, thought I ordered it, but  discovered late in the process that I got a 16-bit DAC8531 instead. This is what I got from the supplier:

Confusion all over. The writing on the package is not mine, but inside are two DAC8531 chips. After reclamation, they insisted that they never even carried the AD5860 and that I could not have ordered it. It's not my handwriting, but theirs. Go figure.

Long story. While I was still unaware of this mishap, I continued. However, the AD5680 did not have a library so I contacted the Arduino library Guru Rob Tillaard and persuaded him to create one.

He did, very quickly, but there was something not quite right when I tested it, with what I still thought was an AD5860. When I finally figured out that I got the wrong part, I used the proper library for the DAC8531 and presto, it worked. Unfortunately, that chip is a mere 16-bit version, although the AD5680 is in reality also an 16-bit DAC, but they use a special technique (trick) to make it look like 18-bits.

In any case, I soldered the ADC8531 to a carrier and quickly put together a test circuit.

What you see below is the Arduino Nano on the left, the DAC on the carrier, the REF02 5V reference and the "range reduction" circuit.

After I got the right library working, I then fixed the DAC output to the mid-point and did the same measurement as before. The results were terrible with drift and jumps all over the place. Now, granted, I'm looking at microVolts so this setup is not ideal.

In order to see if I could improve it, I put together a little test board that I can use instead of the dual PWM DAC 

With this board, the SPI signals come in from the right, and the Vref voltage coming from the GPSDO and the output (fAdj) going to the OCXO. It should be simple to disable the 16-bit PWM on the GPSDO and use this circuit instead. But first I need this board to better test the operation.

The boards arrived and I populated one. I first tried it with just an Arduino on a bread board to see what this new circuit does. I was pleasantly surprised. The noise and stability issues I saw when everything was on the bread board (picture above) were gone, although I still saw quite a bit of drift.

I then modified the SPI interface from hardware to software in the Sketch, so I had freedom of the SPI ports, because several of them are already used in the GPSDO version. Looking at the library source showed me how to do it.

I then wired-it all up so I could put it inside the GPSDO, using double-sided sticky foam tape to mount it on the main PCB. I wanted the maximum heat transfer from the oven for this board, to see if I could eliminate the drift. The firmware of my Sketch was upgraded to V4.0 and that eliminates the dual 16-bit PWM code, and is replaced by the quite simple DAC8531 code. 

Here are a few measurements:

.

This is a measurement of the f-adjust pin of the OCXO with the previous 16-bit PWM circuit in the working GPSDO. Note the vertical size of the individual "steps" in the waveform. They show the resolution in microVolts of the changes in the DAC.

This is the output of the new DAC circuit while using the Arduino on the bread board, and my Lab supply functioning as the 5V reference voltage. After a bit of output swinging, it stabilized. This already looks a lot better. Every step "size" is 10uV, compare that to the screenshot of the original dual PWM output. I think that this could show a 5-10x improvement. Is that worth a device with a price of 9.50 Euro's that in all fairness will replace quite a number of parts? Time will tell...

I took a measurement of the DAC circuit wired in the GPSDO, but forgot to store it. Sorry. In order to get the output voltage range better centered around the sweet-spot, I had to replace the 12K R4 value with 8K2.  That resulted in a Gain of 260 which is a little on the low side. The DAC output results were again much better so after setting the parameters for the GPSDO again, my guess is that there could be a 10x improvement. I'm now letting it run for a few days to see if the reports are in agreement.

Here are a few Excel charts showing the results after letting the GPSDO run for a few days. The OCXO is still settling as you can see. The charts below show a full 24 hours of data every second, starting at mid-night. The room temperature goes up during the day due to the central heating of the room. The PCB temperature regulated oven is kept at 52.9 degrees Celsius and does not change at all. The temperature of the OCXO casing goes up by a mere 0.4 degrees. This small temperature change is not reflected in the DAC output and will all critical components kept at a constant temperature, we can safely assume that there are no temperature related issues in the regulation.

The report from the Lars sketch shows that the NS measurement, which is a function of the relative difference between the GNSS 1PPS signal and the OCXO frequency, has about +10/-10NS swings and an additional drift around the mid-point of about 20nS over a 24-hour period. The DAC compensation for the OCXO frequency changes with small steps and is still moving down a little while it is settling.

The lower graph represents a 10 minute window, where the DAC only compensates +/- 1 step every now and then.

There are two things we can do to further improve the sensitivity or enhance the resolution. We can use a DAC with a higher resolution, but the only one I found that have a buffered output is the 18 bit AD5680. This is not even a "real" 18 bit version. The more simple method is to further enhance the compression circuit to reduce the adjustment span.

The "real" DAC I'm using now seems to be more quiet and has less noise. This should not be surprising, due to the significant number of components that the improved dual 16-bit PWM has, in addition to the required Opamp that has to boost the output. 

The DAC8531 chip has all the components on a single die and on top of that, has a built-in buffer. I have decided to switch to that chip and see what I can improve further.

[Update 24-11-2023]

The tests with the "real" DAC were very positive, so I started on a new revision of the circuits (V4.2) and incorporate the DAC and while at it, also make a few smaller changes I wanted to do.

So, first of all I eliminated the dual 8-bit PWM circuitry, and added the DAC circuitry. I also changed the room temperature sensor from a DS18B20 to an LM35. I first tried a TO-252 version but found that it is not suitable due to the large heatsink, even mounted it isolated on the enclosure. I then switched to use a TO-92 version that will be suspended in free air. 

I also rearranged the DAC output compression circuitry for the OCXO. While trying to get better results (higher gain), I found that it was too difficult to select the right clamping resistor values to get the mid-point of the DAC range (32767) to match the sweet-spot of the OCXO. Because all the parts are located on top of the oven regulated PCB, adding a trimmer is now less of an issue. I did select an SMD trimmer so I could locate it right in the middle of the heater section. The "burn-in" circuit is now eliminated. I found that you don't need that anymore since we have the PCB temperature regulated and it's easy to set the DAC at any value you want, or let it free-run during the burn-in period.

The new Version 4.2 has been designed and sent to PCBWay for manufacturing. As soon as I have the boards, I will build one up and show the results.

Here are the two changed schematic diagrams. The rest has not changed.

[update 27-11-2023]

In order to explain the DAC output compression section of the circuit, I will use an LTSpice simulation. 

The 16-bit DAC output will vary between GND and V-ref, which is 4.096V.  This will result in 4.096/16-bit or a 62.5 uV per bit resolution. Adjusting the f-adjust pin of the OCXO with 62.5uV steps will be way too course for the 10MHz precision we're after and this will result in an unruly DAC output when one value is deemed too low and the next value is too high.

In order to reduce the DAC output steps to get a finer frequency adjustment of the OCXO,  I'm using a simple "compression circuit" that uses three resistors and a trimmer. The 100K series resistor is there to separate the very low impedance of the DAC8531 output from the two clamping resistors and also reduces the loading of the DAC amplifier to keep it linear. It helps in the voltage divider/clamping circuit setting.

The impedance of the f-adjust input pin of the OCXO is so high, that it has no effect on the voltage divider/clamping circuit. The two voltage divider/clamping resistors have two functions. One is a voltage divider function to center the f-adjust voltage to the 10MHz sweet spot of the OCXO. The other function is to reduce the voltage swing of the DAC centered around that mid-point. Lower resistor  values increase the clamping and reduce the voltage swing.

The LTSpice simulation above varies V2 with a ramp between GND and 4.096V. V2 is simulating the output of the DAC. As you can see from the simulation diagram, the 0 to 4.096V span is reduced to a span of only 160mV, or +/-80mV at the mid-point (the OCXO 10MHz sweet-spot). It's not easy to select E96 resistor values that will center the sweet-spot, so I added a trimmer. Note that all these components will be at a fixed temperature, due to the PCB oven, so there are virtually no temp effects.

This circuit provides an actual reduction of about 25.5 times. So instead of 4.096/16-bit, which is 62.5uV/bit, we reduce that to 2.4uV/bit. That results in a frequency change that is about 25 times smaller. The actual resulting frequency change is depending on the sensitivity of the f-adjust input of the OCXO your using. 

The reduced voltage span will also result in a higher gain, in my case 414, which is just below the maximum of the 300-500 value Lars recommends. 

Set the parameters for the sketch

Here is what I do to obtain and set the most critical parameters for the sketch. You need access to the Arduino serial port and the trimmer. You can wire-up the main board and make it functional. It does not need to be inside the enclosure for this procedure.

Turn-on the system and let it go through the warm-up period. Observe the report of the sketch through the serial interface. Clear the EEPROM with e22. Set the parameter type for the temperature sensors with j11 (two times an LM35). The room temp sensor type is fixed in the sketch. Select r for Run.

With a running system, you should now freeze the DAC to the 16-bit mid-point with h32767. If you now observe the filtx10 column in the report, you can tune the trimmer such that the average of the  numbers in that column are near zero. This will ensure that the DAC range will be kind of equal below and above the sweet spot. When that is done, you can now calculate the gain for the PID controller.

 

The Gain of the system is obtained as follows. Freeze the DAC with h1 to the minimum and collect about a page of the report and load it in Excel. Select the filtx10 column and let Excel calculate the average. Note that number, it will be positive. Now set the DAC to the maximum with h65535 and again observe the fitlx10 column. Collect a page full of data again, and take note of the average of the values in the filtx10 column. It will be a negative number this time. These two numbers will give you the maximum range effect of the DAC output to the OCXO frequency. To determine the sensitivity, that Lars calls Gain, you divide 65535 by the sum of the two numbers, but do not use the negative sign. This will give you the Gain for the controlling loop. Input that Gain with gxxx. Save it in the EEPROM with s1.

You will have noted that although we adjusted the mid-point of the DAC close to a zero result in the filtx10 report, the min and max DAC numbers you obtained are not equal. To address that, Lars created two parameters that will linearize the gain in his sketch. This procedure is hard to follow in his description, but this is what I figured out you need to do. Switch the system to normal running by inputting r for Run. Observe that the TC is 4 or use t4 to set it. Let the system run and obtain a lock. This may take a minute or so. Now skew the offset of the software with o1000. The system will loose the lock but wait for the ns column to get back to about zero (+/- 25 or so) again. A lock is not required. Look at the filtx10 column, it will have values above 10,000 and below 10,000.  Wgen there are a number of each showing-up, you can collect about a page of the report and input it in Excel. Sort the filtx10 column to group all the values above and below 10,000. Obtain the average of each group of numbers. For the average of the values below 10,000, divide the result by 10, and input that into the system with lxxx.

For the average of the values above 10,000, subtract 10,000 and input that number also with lxxx. This will set the min and max linearization parameters. Save them into the EEPROM with S1. Set the offset back with o500, and switch back to run (r). The system should get a lock after a few minutes and the TC value should start to increase automatically. Initially, it may reset the TC number again and restart the process.

That's basically all you need to do. Now you can finish building up the system, put it inside the enclosure and do some long-term testing. Remember that it can take several days for the OCXO to become stable, meaning no large drift or jumps in the DAC column of the report.

[update 08-12-2023]

After running the system for a few days, the OCXO has settled and I can't see much of any room temperature influences. The DAC and the compression circuit is behaving really well such that I'm going to finalize this project.

I also build the V4.2 for the reciprocal counter and that is also running very well. Time to wrap it up.

All the files are now added to my GitHub site and I also updated the entry in the PCBWay Shared Project section so it has replaced the GPSDO V4.1 entry with the updated V4.2.

I will run a few measurements soon and show the results here for completeness.

After several days of operating in it's final place on my bench, I collected the following report from the GPSDO:

I don't show the PCB temperature here, it is rock solid at 52.6 degrees C over the 24 hr period. This removes just about all temperature related component value changes and propagation delay changes out of the circuits. The room temperature sensor only moves about 0.4 degrees (no room heating that day) and the sensor underneath the OCXO reports a change of a mere 0.2 degrees. I will show another measurement when the outside temperature is at or below freezing level, so the differential is larger. Right now it is too warm for this time of the year.

The ns chart looks pretty good, no drift or spikes and is typical for my GNSS setup. The DAC report shows a delta of about 12 DAC steps over the 24 hr period. Every DAC step is about 2.4 micro Volt and that is equal to only a few micro Hz nudging for the output frequency to stay aligned meaning that is is very stable and precise. Pretty good results I think, so I'm happy!

For completeness, I monitor the Lars sketch output that is produced every second by a Raspberry Pi. I'm actually using the original Classic version B for that. There are a few scripts that run on the RPi to collect the data over a serial pin, log it in a file, and at the end of the day, another script compresses the log file and sends it to me by e-mail. That allows me to analyze the results in Excel and create the graphs that I show in this Blog.

The scripts can be found on my GitHub here.

The enclosure that I used

Here is some information about the enclosure that I use for several of my instruments, this one included.

The enclosure I use has partnumber bi0002562 and is described as a "high quality aluminum project box/enclosure case" with the sizes 150x105x55mm. Here is a link that hopefully stays up for a while:

https://www.aliexpress.com/item/32766709803.html

Be aware when building this version:

When I design a circuit, I do not really spend a lot of time on the manufacturing issue. As you may know, designing is bliss compared to the manufacturing hell. Issues with part availability, part numbers, obsolescence of parts etc, etc, are not taken into account by me in most cases. My assumption is that you should have enough DIY wisdom to copy or reconstruct what I did. It's not an IKEA product is what I'm saying.

On the Github, I uploaded an interactive BOM as it is produced by KiCad. And I also included a CSV version. A few users that were in the process of building this version had questions. Also PCBway had a customer that wanted them to populate the board, and presto, manufacturing hell reared its ugly face. They need to have every part painstakingly specified to use their pick&place machines.

I was not careful or precise enough for some of the parts. I normally use parts that I already have in stock, and I don't always keep the exact specifications. That's why the part numbers are not entered in KiCad to show up on the BOM. I also create or use foot prints that accommodate a few different parts, even though soldering them can be a little adventures. That cannot be allowed with pick&place machines of course.

I have created a Q&A file based on these questions so be aware of these issues when ordering parts.

[Update Sept-16-2024]

Another Maker, Greg Kasprowicz build 5 of the instruments. He also build the Reciprocal Counter, also described on this Blog. He is not happy about the NEO6 he used, so be aware. I recommend the NEO8.

Enjoy!

Paul

If you like what you see, please support me by buying me a coffee: 

https://www.buymeacoffee.com/M9ouLVXBdw