Build a DIY DC Dynamic Load Instrument

 

Building a DIY DC Dynamic Load

The conclusion of a very long time investigating the building of a combined AC-DC Dynamic Load (DL) led me to the realization that this is not really possible. At least not without making drastic compromises about accuracy and precision. The AC measurements do not need to be very precise and are, in my case, only occasionally needed, but DC measurements typically need to have the highest precision, stability and accuracy.

The attempts for this combined AC-DC DL are described in another Blog post. There is a lot of information there, so get some fresh Java and have a look. https://www.paulvdiyblogs.net/2022/08/dynamic-acdc-load-cc-cv-cw-batt.html

The above picture shows a stage in the development with the new DC DL prototype as the basis.

To help design this new version of the instrument, I asked for the help of my friend Bud. He is a real designer, and we've done a number of projects together, like the high current RPi UPS, the VBA Curve Tracer and the Differential Probe all described on this Blog.

Bud started a Blog post on Hackaday mostly for the hardware design aspects that can be found here: Dynamic Electronic Load | Hackaday.io I have added that same information here, so it's all together in one place.

At this moment, we have finished the design of the new version and the final board V5.1 has been produced by my sponsor PCBWay.

I'm still working very hard on the software side, because this instrument will do some things a bit different, compared to many other DIY designs.

I'll explain that later in more details but here are some pictures to hopefully wet your appetite from the previous prototype  V5:

The initial target specifications:

Input voltage: 1..100VDC.

Reverse polarity protection to -100V and a 10A fuse.

DUT is disconnect by a relays for reverse polarity protection.

Maximum current of 10A @ 40V (needs to be verified)

Maximum power 180W (tested & verified)

Volt Accuracy: 0.2% (needs to be verified)

Current Accuracy: 0.6% (needs to be verified)

Power input: 12VDC Wall-wart 0.5A with reverse polarity protection to -24V and PTC fuse

CC & CV modes with real-time operation, CP, CR and Battery Mode supported in software.

Pulse/transient mode supported by an external Function Generator.

Current transition monitoring with a DSO.

GUI: 128x128 OLED 1.5' color display and a rotary encoder with a dual button function.

Two temperature controlled fans

Testing the V4 prototype

This earlier version for the AC-DC attempt is still using the Arduino Nano as the processor. It also had provisions for an on-board transformer, but that got too hot so I took it off.

The Nano is not fast enough to process the CP and CR modes, which are regulated in software. At this time, I was planning on implementing the CV mode in software as well, but that did not work at all with this prototype. While looking for a faster processor, I eventually settled on the ESP32. It has all that we need, even though we won't be using the BLE and WiFi capabilities.

This was the first time I really started to work with the ESP32 so I started to experiment with it. This processor is not only much faster than the Arduino Nano, it has a dual core and it has a native RTOS. (real-time operating system) I was hoping that these major features would overcome the Nano limitations.

The next step was to test the ADC that we were planning to use, the 16-bit ADC1115 instead of the on-board 8-bit ADC from the Nano. The on-board ADC for the ESP32 has too many issues, so we can't use it with this application. The ADC1115 has double the resolution, the down side is that the communication with the chip to get the results through i2c is very slow.

In the above picture you can see that I had removed the Arduino Nano from its socket, and used flying leads to put the ESP32 in its place. I also wired-up the ADS1115 ADC. With this prototype, I still used the 16-bit PWM functionality, but we were already planning to use a hardware 16-bit DAC.

So after checking and verifying the changes, this culminated in a new prototype, that we called V5.

Testing the V5 prototype

Version 5 incorporated the ESP32, the 16-bit ADS1115 ADC, the REF5040 4.096 Voltage reference, the 16-bit DAC8571, test hardware for the CV mode and Bud's vastly improved circuitry to drive the MOSFET's.

Unfortunately, we discovered a few layout issues that we needed to fix by jumper wires and Manhattan style additions. We also found that the ADS1115 was happy with 3V3 i2c voltage levels, but the DAC, that we could not test earlier because of its tiny package, did not. That called for two bi-directional 3V3 to 5V level convertors, and I used a 4-channel circuit board connecting Manhattan style to implement that. To be able to increase the i2c clock speed, I changed the 10K pull-ups to 2K2.

We then figured out a slightly different circuit for the CV mode, eliminating an extra DAC that we were planning to use. Using that earlier method would actually be cumbersome to drive with the planned user interface so the new method uses two CMOS switches to automatically change the configuration to use the DAC for the CC mode and for the CV mode.

Unfortunately, we also found out that the heatsink I was planning to use, that would fit nicely in the enclosure I also wanted to us, could not handle the heat transfer. Not only did things got really hot, we were far away from the specifications! I measured the NFET package temperature at well over 160 degrees C, and the heatsink temperature rose to almost 100 degrees, and that at a mere 90W for only a few minutes. Bummer!

The obvious solution is to use a different heatsink with a significantly larger surface. 

Unfortunately, larger heatsinks are very hard to find, unless you go for the typical PC CPU coolers. The ones that are available literally tower above the NFET, and it's not easy to use them for two NFET's or find an enclosure for this construction. 

We found two that looked promising and I ordered both of them. Luckily, the most promising arrived early, so we could start to test with it. This is the one on the left. It has the largest amount of contact surface. 

The one on the right relies on a fan at the end (or even both ends) to blow the air through. Unfortunately, that calls for a small diameter fan and they have difficulty getting enough air displacement, unless they rotate faster, making a lot more of a whining noise. Which is another reason why it is not my favorite. 

The one on the bottom is the one I had been using. I purchased a number of them for other projects many years ago. I did an extensive search, but I could not find anybody offering them anymore. 

The different heatsink called for drastically different construction because the length of the leads to the NFET's and the critical components on the PCB are very critical. We did not want to split the NFET's and give them each their own heatsink, or their own heatsink side.

This is why we ended-up with the contraption below. It does not need many PCB changes, so was relatively easy to setup and test. The original fan is now moved from the top to the bottom, getting its air from underneath the enclosure. The fan is blowing directly to the fins of the heatsink. We will use a second fan to suck the hot air out of the enclosure, which has ventilation slots.

 

The first test already showed that we could now easily handle 90W for quite some time, which was not possible with the previous setup. The enclosure we selected later required us to rotate the heatsink 90 degrees horizontally, so a fan mounted on the back panel can suck the hot air out.

A longer-term test at 150W showed that we were on the right track. Everything stayed at manageable temperatures.

Let me explain what you see on the above OLED display.

On the top, you see the actual DUT (Device Under Test) voltage ibn blue and below it, the actual current value in green.

Below that it shows the mode (CC = Constant Current) the NFET's are driving the DUT (ON)  and the actually calculated DUT power in Watt. The display is in red because the power approaches the maximum value and is there to warn the user.

Underneath the horizontal line is the parameter you set with the rotary encoder. The mA suffix changes with every mode. The last line shows the actual 16-bit DAC value (while testing) and the heatsink temperature in degrees Celsius. The color is orange to warn the user that the temperature is above 60, it turns to red above 90.

The colors are used to warn the user for conditions like over temperature (90), over-power (150), negative DUT (wrong polarity) Voltage too high (>100V), voltage too low (<1V), over current (>10A), etc.

The discrepancies in the display values for set/actual current are caused by the fact that I don't use the sense inputs yet so the drop in resistance due to the high power and long leads is not accounted for. Yet.

The User Interface to drive the instrument is kept as simple as possible, and I let the software do most of the setup underneath the hood.

The rotary encoder that you see mounted on the PCB is there so I can more easily test the setup with this prototype. It will later be placed on the front panel. In the CC mode, as you see above, you set the current by turning the knob. The knob currently has two speeds. If you turn it fast, the resolution goes to 10x so you get to your destination rather quickly. Short pressing the rotary encode button switches the DUT output to on and off, by turning off the drive to the NFET's. A long press switches to the next mode. You simply cycle through the modes in a loop, so from CC to CV, to CP, to CR and from the BT mode back to CC. When you switch to another mode, the output is automatically disconnected, and the instrument is prepared for the next measurement. The mA suffix you see in the Set line, changes with the modes, so from mA, to V, to W, to R and in the BT mode back to mA. There is no separate transient or "pulse" mode, because this feature can be used in all modes. That may not be very practical in all modes but the pulse functionality is as versatile as your function generator supports. (amplitude, frequency, pulse form, pulse width, rise/fall times and offset)

On the front panel, in addition to the rotary encoder and the OLED display, there will be two toggle switches, one for selecting the sense input terminals, and one to select power. There are two BNC connectors, one for the transient/pulse input and one for the DSO output. There will be an USB-C connector to the ESP32 that is required in the Battery Mode and also allows for updating of the firmware. And finally, two 4mm connectors for the power connections and two 4mm connectors for the sense inputs. Simple and efficient. And no, there is no keypad. It is not needed and I dislike keypads.

A suitable enclosure

The heatsink has been tested and verified that we can now easily get to 150W, but that is still outside of the enclosure. Because of the height of the contraption, we also had to find another enclosure that would accommodate this construction. There are not many compact enclosures that answered our requirements.

We prefer a plastic enclosure, because the heatsink is connected to the DUT  through the non-isolated NFET's and that can get up to 100V DC.

We also need to modify the enclosure to get enough air in and out. And we want to be able to make a PCB-based front and back panel.

The height of at least 9cm dictates that you will get enclosures that are very wide, and not very deep. They are unsuitable for our requirements, but it's up to the other makers to select what they want.

The enclosure we selected is the TEKO AUS33.5. The top one in the picture below is the one I already have and was planning to use, but it is not deep and high enough. We settled on the bottom one. TEKO is a German manufacturer but with a little Google-action, you can find them all over the world, or there are suppliers that send them all over the place. I use www.tme.eu a lot for my purchases, and they carry these enclosures.

So with this version of the prototype, I have been very busy with the testing, implementing and again testing the changes we needed/wanted to make, and all the while further developing the software.

Final Version 5.1 PCB

Based on the now fully working V5 prototype, we have redesigned the board for the new heatsink and made several other changes and corrections. The PCB has been produced again by my sponsor PCBWAY. They financially sponsor this project by producing the boards and sending them to me for free.

The small TO220 heatsinks you see on top of the NFET's help to disperse their heat better, because they are not in the forced airflow. Instead of one 4-pin fan, we now have two connectors so the second fan that sucks the hot air out of the enclosure is also temperature speed regulated by the sensor on the heatsink.

We also switched to another OLED display source, because the one I purchased many years ago was no longer available. We selected a good quality and commonly available version but that has a different pin-out so we fixed that on the PCB as well.

Here is a quick sneak preview of the completed instrument . Note that I switched to larger TO220 heatsinks for the NFET's to get rid of even more heat now that these fins are in the airflow of the second fan.

Here is some detail about the construction. They are all iPhone pics, with a low resolution. Better ones will come later.

The unit has been stress tested with a 180W 15 minute test while using an IR-camera to keep an eye on the temperatures. I believe we can support 200W, but I don't have a large enough current source to test it out. Bud has some high capacity battery cells that he can use, but his stuff is all boxed-up for his house move so we have to wait.

Above is a picture of the completed instrument. The sheet metal front panel that came with the enclosure was used to experiment and try out the connections. It will eventually be replaced with a PCB that will have the silkscreen indicating the functions and connections.

Top left is the 12V DC power switch. The larger empty hole to the lower right of the power switch was a mistake. The power switch was in that position earlier, but it was too close to the ESP32 board so I had to moved it away.

The black oval next to it is the USB-C to USB-micro adapter providing access to the ESP32. The USB connection to a PC is required in the Battery Mode, and can also be used to debug the firmware or upload newer versions.

The four empty holes around the OLED display stem from an earlier attempt to fasten it to the front panel. At this moment, I use sticky tape to mount it. I have an idea that I will try when I design a PCB as the front panel that will not show holes or screws.

To the right is the rotary encoder switch that controls the setup and the measurements.

Lower left is the pulse/transient input BNC connector. It can connect to a Function Generator. The input voltage is 5V for a DUT current of 10A.

Below it are the two 4mm sense input connectors.

To the right is the sense toggle switch, switching the voltage measurement to the sense inputs or the main inputs. 

To the right are the main 4mm DUT power connections.

Slightly above that is the DUT current monitor BNC connector. The output is 1V for 10A of the DUT current.

The back panel has the 90mm fan mounted and also the 12V DC input connector.

Here is an example of the Battery Test mode. This is a Lithium 3.7V 14500 cell. The cell is several years old and had not been used. The specification is 650mAh and I tested it with a discharge current of 2500mA. The cut-off voltage was set to 3V.

These values are entered into the Battery Test PC program below on the bottom left hand side.

The test is started from this program, and it sends the parameters to the Dynamic Load and starts the measurement. 

During the measurement, the display is refreshed with the parameters coming from the Dynamic Load, such as the voltage, the current, the time and the calculated mAh value, shown on the bottom right. The graph is dynamically updated during the measurement.

As soon as the Dynamic Load measures that the cell voltage has dropped below the cutoff voltage of 3V, the measurement stops and removes the load. 

Just above the green Test Ended message, the Controller Message shows a Serial Time-out, instead of the Cutoff Voltage, because it was waiting for another measurement that took too long to send the data. The DL terminates the waiting loop and restarts the reception of the setup parameters or a mode change automatically.

This is a test of an EFEST 14500 IMR cell of 650mAh. These IMR cells can deliver up to 9.75A for short periods, or up to 6.5A continuous. Bud and I used these cells in the Raspberry Pi 3 UPS, to supply enough voltage to let the RPi ride out a power glitch or let it power down safely. I had not used these cells for many years and just charged them again for a few times to run this test. 

With just over 550mAh, the test shows that the cell is no longer meeting the specifications of 650mAh, but is still usable.  

In order to test at higher currents, you really need to use the sense inputs, which I did. I also used a metal battery holder, plastic ones would melt.

 

Note that I faked the Rated Capacity of the cell in mAh from 650mAh to to 2000, to overcome the calculated  time limitation in the software (rated mAh/current), which would terminate the measurement prematurely. You can save the details including the graph, and when you do, you can enter more information about the cell and also add the weight, which is a good give-away indication for poorly "specified" or plane fake cells.

When the measurement is terminated or ended, you can restart the measurement in the PC software and test another cell. Long-pressing the rotary switch on the DL brings you back to the CC mode. The original hardware that was intended for this PC program would also re-start the Arduino Nano controller. We don't need to do that, the DL load automatically takes care of all that.

Transformer snubber design using Quasimodo test-jig

This is a little post about the transformer snubber design tool using the Quasimodo test-jig, designed by Mark Johnson.

The link to the overall post is here and the pcb's can be ordered here.

I've had this jig for almost 10 years and used it every time I need to add a transformer to my designs.

The test-jig helps you to create an optimum snubber configuration for transformer windings having critical damping, without requiring any calculations and without measuring the transformer's inductance or capacitance.

From the website: 
A power transformer snubber is a wonderful thing for reducing or eliminating RFI from rectifier-induced LCR ringing. Unfortunately it's a huge pain to design and optimize a snubber. First you have to measure the transformer's leakage inductance and secondary capacitance, at about 100 kHz, which is not especially easy. Then you have to estimate the capacitance of your rectifier(s), which does not always appear in datasheets. Finally you plug these numbers into a formula that spits out snubber values -- and then you hope it's all correct.


Here is the schematic of the Quasimodo test-jig:


The name Quasimodo is used because it was the bell ringer of the Notre Dame. I like that name, it rings a bell! In essence the test-jig creates a 555 generated frequency and a fast MOSFET to create a pulse with a very sharp edge, ringing the transformer winding. The snubber is used to limit the ringing.

Here is how you need to connect the transformer winding connections/shorts for various transformers. Make sure you short all windings except the one you want to measure:

Some real results on a Triad PP28-180 transformer with two independent primary and two independent secondary windings. See the first picture of the post for the setup.

First, banging one of the secondary windings without a snubber:

With a 10nF and 1K resistor snubber:

After tuning the snubber to 680 Ohm with 10nF:

No more ringing, the bell is silent now. 

An additional 150nF across the winding results in more damping:




Here is the result in my application (AC/DC Load):


An observant user pointed out that the two electrolyte capacitors in the negative supply (C30 and C36) are upside down in the schematic.😕 
Thank you Kirstin!



Highly recommended!

Building a 10MHz Master Clock

Even though I have a GPSDO, and in the process to upgrade it, I still would like to build a 10MHz reference clock.

I have a spare Oscilloquartz 8663-XS OCXO that I wanted to use for my GPSDO, but the lack of room on the PCB stopped me in my tracks.

This OCXO is too good to not use, so I embarked on a little side project to put it to good use.

For a very long time, I already collected information from another user (Gertjan Miedema) that built a frequency reference with that same OCXO, so I borrowed some of his ideas.

Here is the link to that design : https://www.circuitsonline.net/forum/view/126987/1

It's a Dutch forum but I take it you can either follow it, or use Google translate.

There are three areas where I'm going to deviate from that original design. First of all, I'm not going to create a separate power supply for it. The unit will be on 24x7 and I did not want a normal transformer to power the unit. I have a nice 15VDC 1A wall-wart, so I'm going to use that. The stability and precision of the 15V is not that important for this design.

The other area I'm deviating is by using different output transformers. There was a large effort to create very special hand-made transformers, but I did not want to go that far. I'm going to use the commercially available transformers that I already use for several other projects.

Lastly, I'm not going to use the Oscilloquartz reference voltage to power the frequency setting circuit. It seems the logical thing to do, but this so called reference voltage is anything but a stable reference voltage. They are typically created by using a Zener (reference) diode like the TL431 inside the OCXO, but that is simply not good enough as you will see.

During my work with the Reciprocal Counter, described in another post here, I found to my dismay how poor that reference voltage really is. Have a look at that post and search for the following update: "Testing the counter (11-05-2023)" towards the end.

Here is a display of the Vref output that shows what I mean:

This OCXO has been powered for many weeks 24x7 and is in a plastic container isolating it from drafts, but not the room temperature of course. It's easy to see that using the Vref of the OCXO will fall short when you really want a very stable 10MHz, because any variation in the Vref output, as little as micro Volts,  will show-up as a change in the output frequency.

The Oscilloquartz is currently running while using the following circuit, put together after my "discovery". Here it is using a 10V reference I had in my stash already. This prototype is built on protoboard.

My plan is to use the above frequency setting circuit, but with a REF5050, which is a 5V reference.

Here is the schematic I decided on, with values corrected/tuned during the testing.

Another deviation is that I only need two isolated 10MHz sine wave outputs, not 4.

Most of the resistor values are taken from the original design and they work perfectly.

My intent is to put the circuit in a metal enclosure, but put all the electronics in an isolated foam box inside the enclosure so the OCXO will warm-up the inside far enough above the maximum room temperature, hopefully reducing the temperature dependencies of the components.

This is a side-project so may not get a lot of attention while I'm working on the GPSDO version 4 and the Reciprocal Counter.

[update July 2023]

I did manage to create a PCB layout.

The two long multi-turn trimmers top left are from my old part stash, even through they date back to the 70's, they are genuine and of very good quality. The adjustments of these course and fine trimmers will protrude through the front panel, the same as the two SMA output connectors. The length is 125mm and the width of the board is 99.5mm so it will slide in the typical enclosures I use.

[Update November 2023]

I got the PCB's and populated them. I found some issues with the silk screen and some footprint errors that I corrected in a V1a you see below. That is the actual version you can find in the Shared Project section of PCBWay. Later I will add all the files on my Github site.

Based on the specification for the Oscilloquartz 8663, I made a change to the supply. The voltage specification for the OCXO is 12V +/-5%. Originally, I wanted to use a 12V supply but the Schottky protection diode and the series resistor will bring that too much below that specification. The series resistor can be omitted, I left it in there because Gertjan measures the voltage drop and has a circuit that will show the oven activity. I decided to omit that for the moment, because I don't see the practical use when the nit is powered-on all the time. It makes more sense to indicate a stable output after the oven has finished the warm-up period. The additional circuit can be easily added by using a small separate PCB. 

I now changed the raw DC voltage input to 15V and added an LM340 12V regulator that is mounted (isolated) on the side of the enclosure.

There are some footprint refinements and silk screen errors on this V1a that are not reflected on the real PCB V1 below. This PCB was manufactured by PCBWay and as usual, has an excellent quality. One of the giveaway's is to look for holes that are drilled in pads. The hole should be exactly in the center, which they are. The gold plating of the pads makes it very easy to solder the components.

I also designed a Face plate for the enclosure. Make sure you order the black color.

Below is the actual PCB from PCBWay. The black finish with the white silkscreen makes it very professionally looking.

After putting it all together and trying to calibrate the output with my GPSDO, I'm pretty impressed.

I first tuned the output frequency to that of my GPSDO with the course adjustment, and then switched to the finer adjustment over longer times.

Here I'm measuring the drift by using the maximum persistency of the DSO, while correcting the drift with the "fine" adjustment.

It's a little hard to see on this screen shot, but the sine wave output is exactly 2Vpp into 50 Ohm as measured by the DSO.

Here are some more pictures on how the inside of the enclosure looks and what I did to insulate the components as much as possible from room temperatures. It does not show the later added LM340 12 V regulator.

Below is the insulation "box" or rather a cover, that I made out of 6mm Styropor. The box rests on top of the PCB. The bottom of the PCB is not insulated, but that is much less affected by drafts etc.

I mounted the OCXO about 1-2 mm above the PCB so that there is minimal heat transfer to the PCB itself. There is also no ground plane below the OCXO again to reduce the heat transfer to the PCB. Obviously, the inside of the box will be heated by the temperature of the OCXO oven, but that will happen pretty uniformly.

There are some holes in the insulation cover, but that is not a major deal I hope. It also prevents overheating of the OCXO as well.

I use a small trip of Styropor on top of the insulation box such that the cover of the enclosure presses the insulation box on top of the PCB.

Initially, I hooked the reference to my DSO, together with the GPSDO, to calibrate it. It's still drifting a bit after having been powered off for a month or so.

At this moment I'm now feeding the output to my counter and will attempt to adjust the frequency, and also register the min-max and avg values.

Running the tests and tune the calibration is a matter of a lot of patience watching the deviation on the counter and making small adjustments to fine-tuning the frequency (;-)).

The latest Gerber files can be downloaded from the PCBWay site here: 

https://www.pcbway.com/project/shareproject/10MHz_OCXO_frequency_reference_1_of_2_ba8a8ef2.html

And from my Github site here:

https://github.com/paulvee/10MHz-frequency-reference/tree/main

Purchasing various parts

I was advised by the support people at PCBWay that my BOM is not complete enough for them to automatically populate the PCB, so I added some more information. The trouble is that I have not figured out how to add this information to the BOM I get out of KiCad.

For FB1, 4 and 5 I used this Digikey partnumber: 240-2551-1-ND
For FB3 I used Digikey pn 240-2391-1-ND 
This is a 2A part, but you cal also use the 1Amp version I used for FB1. 
For FB2 I used Digikey pn 1934-1411-ND
For U1, the REF02, I used Digikey pn 505-REF02CSZ-ND 
For R4, you can use pn CSR1206FKR500CT-ND this is an optional resistor that you can also bridge.

It’s is OK to use a 2.2uF capacitor for C14 and C16, this is not a critical value at all.
For D1 I used general purpose Schottky diodes I have in stock. You can use the S1G with Digikey pn 1655-S1GCT-ND
The Oscilloquartz OCXO is a used version I typically buy from vendors that advertise on eBay or Aliexpress. Just Google for “Oscilloquartz 8663-XS” to get the right version and then select the price. Here is one: https://www.ebay.com/itm/204065244750 
I have very good experiences with seller Queen*s_land https://www.ebay.com/str/bluegirl5

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

Some assembly tips

Before you solder the two SMA connectors in place, slide them into position on the PCB, they have a pretty tight fit. Then slide the PCB in the bottom enclosure and also mount the front panel to the bottom part of the enclosure. Move the SMA connectors so they are centered and protruding through the holes of the front panel. Tack them in place to the PCB with your solder iron. Now add the two trimmers and make sure they are aligned in front of the two adjustment holes in the front panel. Use some tape to secure them in position, slide the PCB out of the enclosure and solder one of the leads of the trimmers and check the alignment again. Only then solder all connections of the SMA connectors and the trimmers. With these four parts in place and the PCB in position, mark the place for the 3.5mm mounting hole in the bottom enclosure such that the PCB will always be in the right place.

The red power LED will slide in the 3mm hole of the front panel, I use some glue on the back side to keep it there and use leads and a connector to mount it to the PCB.

The four mounting holes on the front panel need to be counter-sinked on the outside to use the screws that come with the enclosure.

Stay tuned for more...

Paul

If you like what you see, please support me by buying me a coffee: https://www.buymeacoffee.com/M9ouLVXBdw

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.