Warning! This turned out to be the start of a never ending quest for precision so please be warned, you can get hooked too and become a devoted time-nut! (;-))
After I completed this project, I have also created a blog that only deals with the monitoring, measuring and logging of the GPSDO. This blog can be found here.
UPDATE Feb-2023: I'm working on a new method to measure the GPSDO by using a reciprocal counter. There is a specific post on my Blog where I also try out a few improvements for the GPSDO not yet described described in this post. Look here.
UPDATE Dec-2023: During 2023, I worked on improvements to the version 1.0 that I describe below. This resulted in a new blog for the new version 3. That evolved in a version 4 with a few further improvements. They are all described in separate blog posts. Look here
For quite some time, I have been intrigued with a project to obtain a very high precision and long term stable 10MHz oscillator. Not that I really, really need one, it just got my interest and I wanted to learn how to build one.
Most of the interest was triggered when I upgraded my FY6600 function generator, and also when building my dividable pulse generator. Both projects can be found on this blog.
I have been following the projects on YouTube by John Sculley (here), and he designed a precise pulse generator by using a GPS module. The first video of a series can be found here : GPS locked 10MHZ reference
Unfortunately, John has stopped publishing further works which is a real pity. I hope he is OK and has other things to do.
Anyway, this got my attention, and when I started to search the internet for more projects of this kind, I found one that was exactly what I wanted. I looked for a rather simple design, something that I could build and understand, and would not need "time-nut" qualities.
The project I decided to learn more about was that of Lars Wallenius. It can be found here: Lars' EEV blog
Unfortunately, Lars died from cancer shortly after publishing his design.
This was a real loss because he was a very kind and knowledgeable person. Besides, his GPSDO baby got quite some interest, and unfortunately, he did not live long enough to see all the fruits of his work and attention it got.
Even with this deceivingly simple circuit, I knew I had to learn a lot of stuff, because GPS modules, disciplining OCXO's (An OCXO is an Oven Controlled X-tal Oscillator) and measuring the results were all topics I knew little or nothing about. This posed quite a challenge for me, but hey, that's why I like this hobby so much. The good news is that on this particular blog, there were some really helpful and very smart guys that helped me out when I stumbled or fell. I started this project in October from 2019, by ordering the various components. We're now almost closing out 2020 and this is now the longest projects I think I ever embarked on. I'm still far from having satisfied my curiosity or ready to put it aside or to rest.
I will continue to add information here about what I learned and measured so others can benefit from this as well.
First Prototypes
As a first step, I started off by designing a prototype with a first attempt to see if I could actually build this and learn more about it. First I used a protoboard, and that turned out to work OK, but it was quickly apparent that I needed to clean-up that contraption and go to a more permanent setup. By then I already experimented with more OCXO types, which is why I designed two circuits. One with the controller and one with the OCXO circuitry on it. Below is a picture of that prototype using a CTI OCXO.
The separate OCXO board allowed me to swap various OCXO's. In the top of the picture you can also see a Blileyt and a TempTech OCXO. Initially, I had a lot of troubles getting one, that arrived, and worked. It literally took me a few months to collect a few that I could start to work with. Because I had no knowledge of OCXO's I collected a few initially, worked with them, found some issues and then added a few more. I now have 5 OCXO's that are working and that I have been added to my circuits.
The (second hand) OCXO's I have worked with are:
Oscilloquartz 8663-XS 12V DC sine wave out
Bliley NV47M1008 5V DC square wave out
Trimble 65256 5V DC sine wave out
IsoTemp 143-141 5V DC square wave out
CTI OC5SVC25 5V DC square wave out
With this setup, I was able to test some changes to the original design, most notably a different method to discharge the TIC capacitor (C1). However, when I was learning more and more, it was time to create a dedicated PCB to implement all the wisdom and features, put it into a good housing and start to work with that.
Designing a PCB
The PCB that I designed using DipTrace, incorporated everything I knew at the time, and was put together to house different OCXO's. Unfortunately, I did not have the Oscilloquartz and the Trimble versions yet, so I made a footprint error with the layout of the Oscilloquartz one (I could not find a datasheet with a footprint), and since I had no plans to order a Trimble initially, I didn't even consider adding that footprint.
Note that the diagrams that I show below are the result of the many little changes I made on the basis of the PCB's. That's why I call the schematics Version 2. These schematics do NO longer reflect the PCB schematic diagrams 100% anymore, although all changes can be made on these PCB's, like I did as well. I will post the original files that went with the GERBERS on my Github as well as the revised ones.
Component side of the PCB:
Bottom side of the PCB with the modifications required for the Oscilloquartz footprint:
Some of the design and layout decisions
Power Supply
The units I have get fed by an external 12V DC power supply. Initially, I used switching wall-warts. Because I wanted to eliminate possible problems, I switched to a battery that would also provide back-up power during a brown-out.
The battery powered supply is made-up of a 5V DC brick that can supply the required warm-up current for the OCXO's. In my case I happened to have a 7A version, but that's not needed. Using 1.5 to 2A per GPSDO should be enough. Remember that I have to feed three versions at this moment. The next step in the chain is a Boost unit that supplies 12.6V DC to a closed lead-acid battery, salvaged from a burglar system. The battery I have is a YUASA NP7-12, 12V 7.0 Ah version.
I used a Boost regulator for safety reasons. The Boost will most likely fail to the lower input voltage, a Buck unit could fail to the higher input voltage, ruining your electronics.
The 12.6V output level of the Boost regulator will charge the battery while the mains is present. If that would drop out, the battery will supply a steady 12V DC. From the battery, I go through a 1N5822 Schottkey diode to prevent back-powering. From this I directly go to 3 pairs of DC leads with barrel connectors, and they feed the three GPSDO units.
Initially, I used a 15VDC supply and an extra LM7812 to feed the Oscilloquartz OCXO. After I switched to the above setup, I now feed the Oscilloquartz directly with the 12V DC supply.
Power Distribution
To avoid cross-talk or otherwise influences between the various
components, I went as far as I could separating the power sources. The main power entering the GPSDO is 12V DC. In the case of the Oscilloquartz OCXO, it directly feeds that. In the other versions, the 12V goes to an LM7805 that is mounted on the chassis. It gets hot otherwise. This LM7805 is dedicated to power the 5V DC OCXO's only.
Here is that part of the schematic:
The 12V DC also goes to an LM7808 and this supplies power to all the other circuits, some powered by their own 78L05 regulators. One is used for the UBLOX NEO carrier. This carrier actually contains a 3V3 regulator that feeds the NEO chip. The trouble with this unit is that the current fluctuates quite a bit, and more importantly, the 1PPS pulse is pretty powerful and it's difficult to keep that "rumbling" away from the other parts.
The Arduino Nano also gets powered by the LM7808, and it also has it's own on-board 5V and 3V3 regulators. I first used this on-board 5V regulator to also power some other parts, but I found that when the controlling loop is unlocked, there is a pretty dramatic power change that influences the ambient temperature by several degrees. I disconnected the parts so there is nothing connected to the Arduino 5V and 3V3 supplies anymore. The Nano 8V and 5V supplies are only buffered by electrolytes.
The next circuit that is powered from the LM7808 is the DAC circuit. This has it's own power supply based on a 5V REF02 Voltage reference. Following a suggestion from EEV blog member miti, this has been done to isolate the (noisy) Arduino PWM signals from the DAC circuit that is feeding the control voltage for the OCXO. More details can be found on the EEEV blog.
The other 5V components are powered by another 78L05 (U13).
All supplies and components are by-passed with Tantalum electrolytes and 100nF capacitors.
Some of the signals coming from the NEO or the OCXO have fast rise times, and to avoid ringing and cross-talk issues, I used small resistor values in series to dampen the transitions. I did the same with the serial Rx/Tx lines from the NEO and the Arduino Nano.
The controller circuit
Below is the controller portion of the GPSDO. It really follows the design that Lars put forward.
There are a few small additions.
U7 is a 10MHz to 1PPS divider circuit based on a PIC, that I didn't use yet. I used my own synchronous frequency divider instead.
To avoid a reset of the Arduino firmware program when you plug in a mini-USB cable to program or monitor it, I added a 10uF capacitor across the reset pin and ground. Note that when you need to reprogram the firmware, you need to remove this capacitor. I mistakenly located it on the bottom of the PCB, while it should have been located on top, together with a jumper. For now I just soldered a small SMD capacitor across the pins on the Nano circuit board itself.
The oscillator circuit
On the bottom of this diagram you can see the PWM/DAC circuit that drives the OCXO frequency adjustment. The components of this circuit are powered by a 5V reference chip. There are provisions on the PCB to replace the trimmer with actual resistors, to reduce the temperature effects on this very, very sensitive circuit. The two inductors are there to stop the 10MHz signals to back-fire into the rest of the circuits. The PCB also has provisions to accomodate sine wave and square wave out OCXO's, as well as 5V and 12V versions. Look at the schematic below for more details.
Trimming the OCXO output
When you power-up the board with an OCXO of your choice, using a 10K trimmer in the position of R106 makes the frequency adjustments very easy. You can start with the 10K resistor values for R104 and R111, and hopefully adjust the OCXO to a precise 10MHz output with the trimmer in the middle of the range. If it's too much towards either end, you can change the values for R104 or R111 so it is roughly in the middle position. I used the running program with the DAC set to mid-range (h 32676) to adjust the trimmer to get the OCXO towards 10MHZ. While adjusting the trimmer, I looked at the diff_ns column and adjusted the trimmer such that I got an average around 0. Initially, I used a frequency counter for this adjustment, but this is actually much more precise.
Trimming the gain setting
With the mid-range adjustment done, you can now calculate the gain and set and store that into the EEPROM as per the instructions. If the gain is too low, you can increase the value of R109 to get a gain of at least 300, optimum according to Lars is 500. I recommend that you now let the OCXO adjust to it's newer life inside your GPSDO for several days if not weeks. They typically went through a very rough handling dismantling the equipment they were in and then to remove them from the PCB, in addition to the handling and shipping process on their way to you. These OCXO's are very delicate devices. I "aged" mine for a month or more before I replaced the trimmer by fixed resistors in the R105 and R110 positions. Using resistors instead of the trimmer will improve the temperature effects on the very sensitive adjustment circuit.
In the table on the schematic diagram, you can see the values of the trimming resistors I used for the various OCXO's. I found that although Lars recommended a gain of around 500, I got much better results with gains around the 1.000 value for my best OCXO's. It all depends on the quality of the OCXO and the difficulty of the controlling loop adjusting them. If you get wild DAC swings, especially over the +/- 50 ns range, you can reduce the gain and or increase the damping factor.
The OCXO circuit
The circuit diagram below can be used to figure out how to power and tune the various OCXO's. For sine-wave out versions, you need the "squarer" circuit that EEV blog contributor miti proposed. With the values shown, I did not need to tune C202, the amplitudes where large enough to get me very close to an ideal 50% duty cycle. If needed you can add a trimmer in parallel to C202. The trick of the squarer is to amplify the sine wave towards or even beyond the ground and VCC levels. Watch out that you don't exceed the maximum input levels for the 74HC14 or add a clamping diode to 5V. Some sine wave OCXO's need their output terminated to reduce distortion. Use R203 in that case.
If you have a square wave out OCXO, you can add C201 and change the value of R201 to 100 Ohms to dampen the transitions somewhat.
Note: In the diagram above, I messed-up the names of the components that can be use to get a better signal out of square-wave based OCXO's. It says Populate R15 and C105, but they are called R201 and C201 in the diagram.
The importance of the GPS module itself
Knowing nothing about the required GPS modules, I first purchased two U-Blox NEO 6M units and later an M8N version, and started to play with them. In the process, I managed to blow-up one of the 6M units by using the wrong supply voltage for the serial interface. It is 3V3! By then I also learned that the units I had were actually Chinese fakes of the U-Blox versions (they do not have the flash memory) and I also learned more about the timing version. A real M8T is not cheap but I decided to bite the bullet and purchased a genuine M8T chip. I'm very glad I did. I de-soldered the broken 6M chip from the carrier and soldered the M8T in it's place. In the beginning, I did not really know how to select the most optimum settings, but I got a lot of satellites and the results looked good, so I left it at that. Mistake! One other mistake I made was that I didn't save all the settings into the NEO EEPROM and so I lost them after a power cycle. Because I no longer monitored the NEO output, I was unaware of this. These things cost me dearly because I spent a very long time chasing weird events that were actually the result of my not fully understanding the importance of the GPS units.
Because I live in a multi-story apartment building, I only have a partial view of the sky. The active "puck" antenna ( I first used three, one for each GPSDO) is fixed on the window sill just outside the view of the building itself. This view is only East facing and because there is another apartment above me, also only straight up. After months of struggling with my three GPSDO's, swapping OCXO's in and out, and witnessing strange events that I could not explain, I kept on tweaking and changing the hardware. In the process I found several items that I could have done better and I also replaced some components, but I was never really happy with the results. I was also hampered by my lack of understanding and inexperience. After several months of leaving the project alone, and turning my attention to other projects with an attempt to let the OCXO's "age" in the GPSDO hardware, I picked it up again. However, I quickly became pretty frustrated when it turned out that the aging didn't help at all and that I still witnessed the same weird results and significant instability.
By then a lot of it was no longer rocket science for me and I knew a lot more about the whole process. Exasperated, I finally turned my attention to the GPS section. In my three GPSDO's, I used a NEO 6M, an M8N and a M8T GPS receiver. After making some more detailed measurements and observations with the U-center application, it turned out that my NEO versions were not receiving enough satellites with a strong enough signal.
Because my instability of the GPSDO's showed-up over the course of a day, I tracked the GPS modules for at least a day as well. I then noticed that there were serious glitches and drop-outs in the reception over a 24 hour period and this must have been the reason for the weird hick-ups I witnessed in monitoring my three GPSDO's. I also learned that I needed to update the firmware for the M8N and M8T in order to get access to the Galileo constellation, in order to add more satellites to the mix. The 6M cannot received the Galileo constellation al all, so that version became unusable for me.
Updating the NEO firmware was not that easy, but I figured it out. (that process is described on the EEV blog) With the now updated M8N and the M8T, I started to try various settings, and compare the results. It turned out that due to my limited view of the sky, only the M8T in the stationary and timing mode settings provided a stable and reliable 1PPS pulse. I used the survey mode for 24 hours to get a solid fix on my geo positions, and programmed them into the NEO's. The results were dramatically different for the GPSDO's. All the strange effects, except for one (the Bliley, see below), went away. As a matter of fact, it also showed that the hardware additions to the original design were working really well, the results were suddenly and finally outstanding I thought.
Because I only have one M8T, I installed that into the GPSDO with the Bliley, because initially, that showed the most stable results. The 1PPS output signal of the Bliley GPSDO was then used as an input to the Trimble GPSDO, by feeding the signal into the empty NEO connector on the PCB. The 1PPS output of the Trimble was then used as the input for the Oscilloquartz GPSDO, in effect linking all three units to the same M8T. This allowed me to verify the three units and really compare the results.
The lesson to be learned here is that if you don't have a good 360 degrees view of the sky, the GPS module is the weakest link and that can really ruin your day. You will have to optimize the NEO settings to get the best and strongest reception, use it in the stationary mode, filter out the weak satellites and maybe upgrade the firmware to get access to the Galileo constellation and switch to use a timing version if you can.
The completed GPSDO
The picture below shows the GPSDO using the PCB with the CTI OCXO. All in all, I build three working GPSDO units with different OCXO's so I could compare them.
In the bottom right of the picture is the GPS module. I use an adapter cable to connect the board the an SMA connector on the back-panel. It allows for a quick and reliable connection to the GPS antenna. The front-panel you see here is just a quick-and-dirty prototype to test things. I also designed a PCB that functions as a front-panel, but when I made this picture it didn't come in yet.
The three colored wires you see on the top-left side of the picture are leads that go from three pins protruding through the front-panel and connect to the serial pins, Rx, Tx and GND of the Arduino Nano. They further connect to a Raspberry Pi that runs a small program that logs all the activity in a separate file on a USB stick connected to one of the USB ports on the RasPi. The RaspPi also contains a little email program that sends me the results by email at the end of each day. It allows me to collect a whole day worth of second-by-second status outputs by the controlling program running on the Arduino. That data can be imported into an Excel spreadsheet and analyzed, or processed to be analyzed by a program call TimeLab. TimeLab is a special program that can be used to analyze the stability of oscillators. Both programs are available from my Github site, details are further down below.
What I learned
In the process of trying different OCXO's and learning about the controlling software, the GPS module and the overall performance, I noticed that OCXO's with a thick housing (double enclosure?) such as the Bliley, the Oscilloquartz and the Trimble have, were a lot less sensitive to the ambient temperature changes measured within the enclosure, and also the temperatures in my office.
To further take advantage of that knowledge, I created foam boxes around all 6 sides of the OCXO's to further isolate them from outside temperature effects. I tracked the OCXO temperatures, and found them to be a lot less stable than you would anticipate from a device that has a dedicated oven to heat-up the X-tal parts to a temperature significantly higher than the ambient temperature. I measured OCXO temperatures between 40 and 55 degrees C, with an ambient temperature in the enclosure of between 25 and 35 degrees, in an office with temperatures between 18-28 degrees.
Below is a photo of the Bliley where you can see the (10-15mm) bottom isolation between the PCB and the Bliley itself. I extended the leads of the Bliley so it would protrude through the isolation to the PCB. The LM35 temperature sensor that measures the temperature of the OCXO is clearly visible on the right of the OCXO. It is located within the isolation box, and I also stuff some foam between the leads and the TO92 plastic of the LM35 to add some more isolation from the PCB temperatures. On top of this base, I add the rest of the insulation walls and cover. When you add the walls and the top cover, make sure the connections are without heat leaks. I used special glue and double sided sticky foam to build the box, but left the top cover free so I could dismantle if needed. I used some bubble-wrap between the insulation box and the top cover, so it all fits snugly.
Just to the left of the Arduino Nano, you can see the other TO-92 package of the ambient LM35 sensor. This sensor is actually too close to the OCXO, especially with the larger sizes of the Oscilloquartz and the Trimble, so I took it out and extended the leads with 5-8 cm long wires, isolated the connections with some shrink-wrap, while leaving the TO-92 plastic free, and positioned the sensor on top of the D1/C1/R1 circuit, located just to the right of the orange filter capacitor. These components are the most sensitive to temperature changes and will effect the controlling loop of the firmware.
Below is a picture of the Bliley OCXO in it's completed isolation chamber. It still has the ambient LM35 in it's original location, it shows why I wanted to move it out of the way. On the bottom right of the picture you can see the three serial monitor pins:
Temperature effects
Several components, in particular the TIC circuit around R1, D1 and C1 will
influence the controlling loop based on temperature. The other components are that of the
DAC, controlling the frequency adjustment of the OCXO. The voltage
difference between DAC steps can be in the order of microVolts,
especially with higher gains. No wonder that temperature has an effect.
The last one is obviously the OCXO itself, with the oven that puts the
X-tal inside to temperatures as high as 50-60 degrees or more. The sole
purpose of this oven is to create a large differential with the ambient
temperature so the ambient temperature will have little effect on the X-tal itself. In theory...
During my own observations, I found that the temperature of the OCXO oven is influencing the ambient temperature a lot more than the room temperature does. This is why I decided to add an insulation box around the OCXO's. Even then, the oven temperature is dominant for the ambient temperatures. The room temperature only lowers or raises these "linked" temperatures somewhat.
Here is what I mean.
This shows that over a 24 hour period, the room temperature (in red) only varies by 0,5 degrees Celsius (Max - Min) and is fairly flat otherwise.
Here are the graphs following the Oscilloquartz oven and ambient temperatures. Note that these graphs go from mid-night to mid-night.
I think that this proves that the ambient temperature inside the enclosure is heavily influenced by the OCXO oven temperature. This is why I decided to add the insulation in the first place. Note that these graphs were made with the insulation already in place! The effects were much, much larger without the insulation.
This effect was very different with the OCXO's that have the thin casing, such as the IsoTemp and CTI OCXO's. They were much more influenced by the room temperature changes, even when isolated, which prevented me using them in my environment, where the room temperatures change several degrees, especially in winter.
DAC temperature compensation
Although the effect of the room temperature was negligible at first, but when the room temperature increased during our vacation and the following heat-wave, I could see that the DAC curve started to follow the ambient and OCXO temperature curves. tou counter this effect, I implemented the compensation for the Trimble and the Oscilloquartz. The calculated values for the Oscilloquartz were sufficient, but the Trimble needed a few tweaks by hand before the DAC curve flattened out.
The Bliley does not need any temperature compensation. The DAC curve shows no sign of a temperature effect.
Note the very minimal DAC adjustments that are needed to keep the frequency aligned, and this is with a gain of 902!
However, after a few days of monitoring, I noticed a strange phenomenon that started to show up on both the compensated OCXO's , theTrimble and the Oscilloquartz. (I found the root cause, described below)
Here are the graphs for the Trimble, after I set the temperature compensation:
Note the Ambient and OCXO oven temperature graphs on the bottom first and compare that to the Oscilloquartz OCXO graph a little higher up. When the temperature drops a bit around 30.000 seconds, there is a sudden and steep rise in the temperature, until about 64.000 seconds when there is a sudden steep drop. This is unrelated to the room temperature! These transitions can also be observed in the ns and DAC graphs. So despite the fact that the DAC graph is much flatter due to the compensation, there are some pretty serious side effects. The Oscilloquartz has exactly the same behavior.
As a first step, to hunt down the issue, I disabled the temperature compensation again.
The above effect was only showing-up during the current heatwave we have. However, this effect also caused
me to reconsider boxing in the OCXO's with insulation. It looks as if the OCXO cannot
get rid of their generated heat, or they try to maintain a certain delta
with the ambient temperature. Whatever the cause, the stepping-up by 0.5-2.0 degrees is influencing the loop regulation, and
therefore the DAC settings, which is not good, see the next topic.
After running for a few days without the OCXO's in their isolation boxes, I started to loose the lock frequently. This was the major reason why I implemented the extra insulation in the first place. Since the hick-ups only showed-up during the heatwave, with office temperatures around 30 degree C, I decided to go back to the insulated OCXO's and take the hick-ups for granted. We only have these very high temperatures during a few weeks of the year.
Since then, the room temperatures dropped a little bit, and I saw less of the hick-ups.
Temperature compensation results
Consequently, I applied the temperature compensation again. Here are the before and after results:
First is the before, you can clearly see that the DAC follows the OCXO oven temperature.
And here are the Oscilloquartz results, first before then after:
Why is the temperature compensation for the DAC so important?
When you don't have the luxury of an atomic clock to your disposal to
measure (compare) the accuracy and stability of your DIY GPSDO, you can
use TimeLab to characterize your tool. Lars has several examples in his
documents, go read them if this is new to you.
The way to use TimeLab to characterize your GPSDO is to collect the DAC values and import them into the tool, while converting them back to a 10 MHz frequency representation. However, this only works when the DAC values have a 1:1 relation to the differences measured against the 1PPS coming from the GPS.
When the DAC values are influenced by things like temperature, this will skew and distort the TIC relationship and hence the TimeLab representation is of less value because it no longer shows the true disciplined OCXO performance and stability.
The OCXO oven temperature can be monitored by Lars' program to get a handle on the temperature based deviations on the DAC, and his firmware can compensate the DAC settings by taking the OCXO temperatures into account.
The idea behind this is to get a DAC curve that is as much as possible devoid from temperature based deviations.
Below is an example of one of my GPSDO's, with the Trimble OCXO. The graphs show the DAC values, the OCXO temperature, the ambient temperature within the enclosure and the ns value coming from the TIC over a 24 hr period. All temperatures show a dip of several degrees Celsius, and you can clearly see that the DAC follows this curve, which will compromise a TimeLab measurement. Note that the ns graph does not follow the temperature curve, and this is a better representation of what the disciplined OCXO does, and what we would like to see represented in the TimeLab graphs.
The way to use TimeLab to characterize your GPSDO is to collect the DAC values and import them into the tool, while converting them back to a 10 MHz frequency representation. However, this only works when the DAC values have a 1:1 relation to the differences measured against the 1PPS coming from the GPS.
When the DAC values are influenced by things like temperature, this will skew and distort the TIC relationship and hence the TimeLab representation is of less value because it no longer shows the true disciplined OCXO performance and stability.
The OCXO oven temperature can be monitored by Lars' program to get a handle on the temperature based deviations on the DAC, and his firmware can compensate the DAC settings by taking the OCXO temperatures into account.
The idea behind this is to get a DAC curve that is as much as possible devoid from temperature based deviations.
Below is an example of one of my GPSDO's, with the Trimble OCXO. The graphs show the DAC values, the OCXO temperature, the ambient temperature within the enclosure and the ns value coming from the TIC over a 24 hr period. All temperatures show a dip of several degrees Celsius, and you can clearly see that the DAC follows this curve, which will compromise a TimeLab measurement. Note that the ns graph does not follow the temperature curve, and this is a better representation of what the disciplined OCXO does, and what we would like to see represented in the TimeLab graphs.
This shows that it is very important to monitor the OCXO temperature and also find the source of deviations in order to properly compensate the DAC.
Temperature effect when the GPS lock is lost
I noticed a rather strange temperature effect between the locked and unlocked states of the GPSDO controlling loop. When the controlling loop looses lock, The ambient temperature, that I measure close to R1/D1/C1 and the Nano, drops a few degrees. There could be two reasons for this. One is that the lock LED is off, requiring less current. To minimize this effect, I replaced the LED with a high-efficiency version, and increased the series resistor from 200 Ohm to 10K. The other reason can be the Nano itself, because there is less filtering going on when the lock is lost, and therefore the Nano spends less time crunching and more time idling. I have used post #466 on the EEV blog to show this effect. EEV blog post
Bliley OCXO DAC jumps
Although the Bliley only needs a soft feathery touch to the DAC to keep the frequency aligned with the GPS, it's not perfect.
I have noticed very strange "jumps" over the course of several weeks. At first I though that this was a warming-up issue, but even after two weeks, these events still happened. They are different in nature though. Here is a "warming-up" glitch. The DAC values drop and then stay flat.
Here is an event where the DAC values drop or rise, and then come back to the original value. Note that an aberration of about 70 DAC points is only marginally larger than the very common and daily gyrations the other OCXO's need to stay locked. Also note that the ns values stay within the lock margin. It's all very relative, but still. In other words, excellent performance, but not perfect.
The slight aberrations on the DAC after the dip settled and went away after a few days. After monitoring the Bliley for two months after powering-up, the glitches went away and the OCXO was very stable. These jumps from the Bliley are still visible after a cold power-up for a few days though.
I found the root cause of the OCXO temperature jumps!
For several months I have been hunting for the cause of the strange
temperature jumps of the three different OCXO ovens I have. For far too
long, I suspected the temperature jumps to come from the room or ambient temperatures,
or the OCXO oven and this would influence the ns/DAC jumps and so I was
hunting in that direction.
I have finally found the root cause.
Below is an example of what happens with my Oscilloquartz version. It is no longer using the full OCXO isolation, to avoid "over-heating" but the whole GPSDO unit is now in an extra enclosure with isolation to avoid sudden room temperature drifts.
I have finally found the root cause.
Below is an example of what happens with my Oscilloquartz version. It is no longer using the full OCXO isolation, to avoid "over-heating" but the whole GPSDO unit is now in an extra enclosure with isolation to avoid sudden room temperature drifts.
These graphs run from midnight to midnight and are sampled every second as they are coming from the Lars firmware. I collect the output by a Raspberry Pi connected to the Txd/Rxd pins of the Arduino Nano. These daily log files are emailed to me.
To see what is going on during the day, I also use a USB-mini cable connected between the Arduino and my PC. I use the Arduino serial monitor to show the second by second Lars' report on my screen.
The cause of the temperature jumps, that literally changes from one second to the next, is due to my PC waking-up from sleep in the morning or going to sleep in the evening. This going to sleep or waking-up will activate or deactivate the power on the USB port of the PC, and hence will apply 5V to the Arduino through the USB serial link, or not.
This is interesting, because I feed a regulated 8V DC to the VIN power input of the Arduino, and I do not have any other logic connected to the 5V and 3V3 power outputs from the Arduino board. I only have a 100uF cap attached to the 5V output, and nothing to the 3V3 output. You would think that the 8V supply and the on-board voltage regulator would sufficiently power the Arduino, regardless of the presence of 5V coming from the USB connection. The Arduino circuit uses a Schottkey diode (D1) to "OR" the on-board regulated 5V supply with the 5V coming from the USB input.
For a reason I cannot explain yet, the Arduino ADC1 and ADC2 inputs that are used to sample the temperatures are influenced when you apply the USB cable with power. You can also see in the graphs that ADC0, used for the TIC input, gets the same treatment, and this influences the TIC measurement (ns graph) and hence the DAC.
Because of the DAC jumps, we have a "falsifying" event in the TimeLab reports.
The solution would be to use a USB cable with the 5V power removed, or remove D1 on the Arduino board. Unfortunately, this diode is located on the bottom of the PCB and is not easy to get to when you already soldered the Arduino on a main PCB, like I did. I could not easily modify the Arduino board so I connected a male and female USB connector together and did not connect the power pin between them.
UPDATE:
Contrary to what I first believed the root cause for the OCXO temperature jumps was, it is not caused by the USB power connections (+5, GND or shield), but the data lines (D- and D+). I figured this out by using a break-out board contraption after I isolated the +5V line earlier.
If either one or both of the data lines are connected, both LM35 temperature measurements in the Lars report jump by about 0.5 degrees up when connected and down when not.
It may be related to the Arduino Nano internal reference, but I can't explain that yet, can anybody? :-//
If either one or both of the data lines are connected, both LM35 temperature measurements in the Lars report jump by about 0.5 degrees up when connected and down when not.
It may be related to the Arduino Nano internal reference, but I can't explain that yet, can anybody? :-//
Using an additional enclosure to reduce room temperature effects
To reduce the room temperature effects on the GPSDO, I have put the Oscilloquartz GPSDO inside a sturdy plastic enclosure. To improve on the insulation, I de-soldered the BNC connectors from the PCB and replaced them by short shielded wires going to front-panel mounted BNC connectors. The aluminum enclosure of the GPSDO was further insulated from the plastic enclosure by bubble wrap and foam. This enclosure also houses the Raspberry Pi that monitors the Lars' program status outputs. To regulate the temperature inside the plastic enclosure, I installed a small 30 mm 5V DC fan. This fan is controlled by the RPi through a proportional PWM signal that is calculated based on the value of a DS18B20 temperature sensor that is located inside the plastic enclosure. There are a few small ventilation holes in the top front, and the fan is located high-up in the back, creating an air flow just at the top of the enclosure, and not more below where the GPSDO is located. The regulated fan speed will create an inside temperature range that will be small and stable. Right now, after some tuning, the inside temperature is ranging between 32.5 and 33.1 degrees Celsius, several degrees above room temperature, creating a small buffer.
Here are the first results:
I have tuned the fan controller such that the inside temperature is 33 degrees Celsius, and stays within 0.2 degrees. The GPSDO ambient temperature is very stable at 52 degrees, and the OCXO oven stays at 65 degrees, both within a 0.5 degree window. The inside temperature oscillates within a .2 degrees window due to the proportional fan regulation, with an almost constant room temperature. Higher or fluctuating room temperatures will not be handled well enough, that needs an improved controller.
I need to monitor this behavior for a longer period. Next week we'll get higher outside temperatures again, which will be a good test. The next test will be in the winter-time when the room temperature will drop significantly during the night when we don't heat the room.
I have now implemented a PID algorithm to better control the fan. This is actually the first time I put together a PID, so be aware. The first results are actually very good. I'm now running some long-term tests to see how well it works with larger room temperature swings. Luckily, we have unusually high temperatures at the moment. The latest version (run_fanV2_0) with the tweaked PID parameters is located on my Github site.
I have also ordered two more 30mm 5V fans that I'm going to install in the aluminum enclosures of the Bliley and Trimble GPSDO's. I have high hopes that I can control the ambient temperature within the enclosure better, largely eliminating room temperature effects on the DAC.
UPDATE: when the room temperature changed more significantly, the fan
could not keep the Oscilloquartz OCXO temperature flat. There is too much of a delay
due to the double separation between the OCXO and the fan. But, it showed me the right way to go forward.
Temperature controlling the GPSDO enclosure
As a logical next step, I wanted to see if I could control the temperature inside the GPSDO enclosure, and not having to use another, much larger, box surrounding it. The temperature control would be more direct instead of indirect, which would also benefit the temperature critical components of the GPSDO itself.
The whole idea behind this approach is as follows. The OCXO oven, despite sitting in an insulating box, will heat the inside of the enclosure. That heat will eventually leak away through the metal enclosure to the room. This transfer is highly depending on the room temperature itself. If that changes, so will the inside temperature, and so will the OCXO temperature. If we can control the inside temperature, and keep it constant, the OCXO will be presented by en even "outside the insulation box" temperature, and stay constant too. Because the OCXO will always generate heat, we could simply blow-off the excess heat, and keep the temperature stable. To only blow the right amount of excess heat, we can use a temperature controlled fan. The trick is to set the maximum inside temperature level such that there is always a temperature buffer between the inside temperature and the room temperature. If the room temperature drops in the winter when the room is no longer heated, there will be a much larger temperature transfer due to the leakage. The trick is to set the temperature such that it will still run, or very slowly, when this happens. In the summer, when the room temperature can get pretty high, the maximum fan speed should be enough to still keep the inside temperature constant. This may need some tweaking, which is why I modified the firmware to set the controlling parameters for the fan during run-time.
To test that approach, I first modified my Trimble GPSDO. I concocted a simple fan driver circuit, and modified Lars' code to incorporate just the fan controller. Here is a portion of the schematic with the very simple fan driver circuit:
A few things. You cannot use the D9 output from the Arduino, it interferes with the loop, and the result is a stream of "No PPS" messages. Why, I don't know. It took me quite some time to figure out that using D9 was the reason. In any case, D6 works perfectly. I used a small coil and two caps to try to stop PWM pulses from the fan circuit to find it's way back into the OCXO circuits. I used a simple transistor instead of a MOSFET for the same reason. The switching transitions of a transistor are more gradual.
Here is a picture of the fan and the controller board. It only takes a few components.
The 30mm 5VDC fan is installed on the back-panel, and I used two of the mounting screws to also mount the little perf. board with the driver components on it as well. To let fresh air in, I drilled six 6mm holes in the front panel, trying to force the air-flow away from the OCXO. The OCXO itself is still encased in a hard-foam box with about six 10-15mm thick sides. Keep note that the number and size of the input holes are depending on the temperature the OCXO generates. My Bliley has that, so I probably need less, or smaller holes.
The code to extend the Lars' program with this fan drivers is quite simple. I use the ambient temperature sensor as the input, use a low-pass filter to get rid of the notorious jitter of the LM35's and use a text-book PID controller to drive the fan with a PWM signal.
The first results:
The PWM values center around 120 out of a maximum of 255. The amount of air it moves seems sufficient with the intakes that I added. This should give me enough room for higher and lower room temperatures, which are now just shy of 30 degrees during our unusually warm fall temperatures.
The ambient temperature is moving up and down within a 0.6 Celsius window, due to the inertia of the heat transfer system. The OCXO heats-up the inside (ambient) temperature, and the fan tries to regulate it back down to 35 degrees by blowing off the excess. I selected this temperature because it is a few degrees higher than my maximum room temperature together with the surrounding equipment next the the GPSDO's. The regulation takes a bit of time, and so the fan is always a little bit behind, or overshoots. I think this is normal behavior and can be expected of an indirect system. As a result of the now very stable inside ambient temperature, the OCXO temperature is very stable as well. It only varies for 0.3 degrees.
Because I don't have any experience tuning a PID loop, I tried a few gain values, and after I was somewhat satisfied I gave it a try with the above results. My conclusion is that it's good enough for this purpose, so unless any of you can come-up with better gain values, I'll leave it at that. (I'm still continuing to learn more about PID controllers)
It's safe to assume that with this ambient temperature control, the DAC is now mostly devoid of room temperature changes, and therefore shows a direct relationship to the GPS based time difference (TIC) with that of the OCXO. I will be monitoring the results to see if it also works when we have larger room temperature changes during the winter season.
When we now analyze the performance with TimeLab using the DAC settings, we have a true representation of the GPSDO performance.
My version of the Lars' program that incorporates this, Version 3.52, is on my Github, the link is below.
After a few days looking at the results, I decided to now also convert my Bliley GPSDO, although it hardly shows any room temperature effects. And I will also modify my Oscilloquartz version again, and take the GPSDO out of the plastic container. The regulation inside this container is even more indirect, so I think I can get better performance with regulating the inside temperature like I do now with the Trimble. It will also remove the requirement of needing a Raspberry Pi and a third sensor, although I'll keep using the RPi for logging purposes.
I have modified my Bliley and Trimble GPSDO's with the fan and the controller. In the meantime, I also sold my Oscilloquartz GPSDO to an interested user. This allowed me to recoup some of my out-of-pocket investments in this project.
New version for the Lars code, V3.60.
While continuing to tune the fan controller, I needed to recompile and restart the units when I changed values. That is very tiresome, and extremely lengthy process because of the restart, so I extended the already existing method that Lars used to now also set the fan controller parameters at run-time. The "info and help" display (f1) incorporates these changes, and so does the display of variables (f2).
What you can now change on the fly is the minimum PWM setting (u) with an integer value between 0 and 255.
You can also set the maximum ambient temperature (cool_baseline) with the "v" command and use an integer value of degrees in Celsius.
The PID gain settings can bet set with: x for Kp, add an integer that is 10x of what you want, to get one decimal. So use x6 to get 0.6. Use y for Ki and z for Kd with the same x10 values.
Note that these new values are not set in the Nano EEPROM, there is no space left and I didn't want to rearrange the current storage of values that Lars intended. As a consequence, after a reset or reboot, these values will revert back to what is programmed in the code.
Below are the cold startup graphs of the Bliley using the version 3.6 of the software with the standard PID parameters, PWM and temperature settings.
After the PID regulation has stabilized, the Ambient temperature within the enclosure stays at 36.0 degrees, even during the next 24 hours. This is a function of the room temperature regulation, as you can see from the PWM graph, but also of the OCXO temperature stability. After the regulation stabilized, the OCXO now only varied 0.3 degrees initially and after almost 7 hours is now very stable at 50.2 +/- 0.1 degrees during the next 24 hours after this graph. BTW, my Bliley still has the DAC values jumping down a few 100 DAC points every now and then for a few days while warming up.
And here are the results of the Trimble after a cold startup:
Note the snap-shot of the more detailed PWM temperature regulation after the initial startup of about 2 hrs. The resulting ambient temperature stays at 36 +/- 0.1 degrees. The OCXO temperature stabilizes at 48.1 degrees +/- 0.1 degrees. A day later, it centered at 48 +/- .2 degrees. Not as good as the Bliley but still very satisfactory.
After a few weeks into the heating season, I wanted to post the following results because it shows the fan regulation at work even better. This data is collected from my Trimble based GPSDO.
The following data is from my Bliley based GPSDO.
By looking at the PWM graphs, you can clearly see the reaction to the heating of the room in the morning, and the gradual decline in the evening. The ambient temperature, measured on top of R1, D1 and C1, is kept stable at 35 degrees, and this is an approximation of the temperature inside the enclosure. As you know, my OCXO's are in isolation boxes, so the OCXO oven regulation is not much influenced by the temperature on the outside of that insulation box. What you see in the OCXO graph is the temperature regulation of the OCXO oven itself. It seems that there could be a correlation to the room temperature, but even if so, the effect is within 0.5 and 0.6 degrees. I doubt that has a noticeable effect on the OCXO frequency output. Lastly, the DAC graphs shows the "real" response to the GPS 1PPS deviation, and that data can now be used to plot the charts in TimeLab without external "pollution". The Trimble has a TC of 1,000 and the Bliley a TC of 1,500.
Conclusion
With the explanation for the temperature jumps when the USB cable is connected, and the fan regulation, I think I've now solved all the DAC temperature related problems.
With this out of the way, I can now revisit some of the settings and make some more measurements.
Finding the optimum TC setting
Here
are the TimeLab results of running both GPSDO's with a TC of 4, using
method #2 from Lars to determine the optimum TC (page 12 in his
document).
The optimum or what Lars calls a "reasonable" TC can be found at the intersecting slopes from the PPS jitter (down going slope) and the oscillator drift and noise (the part of the slope going flat or back up).
Note that the slopes of both curves are just about identical up to 200 seconds. I suspect this is because the Trimble gets its 1PPS from the same NEO M8T located in the Bliley GPSDO and so the PPS jitter is the same. With the TC of 4 seconds, both DAC's follow the GPS and the OCXO deviations precisely, because there is no filtering.
In any case the optimum TC is approx. 4,000 seconds for the Bliley and approx. 2,500 seconds for the Trimble. I selected a TC of 2,000 for both which should allow me to better compare them.
After running the GPSDO's with a TC of 2,000, here are the results of the second day. It took about 6 hours to get a lock, and even after that, the loop needed some more time to get really stable again.
This seems to suggest that a TC of 2,000 for the Bliley is only a little too high, because you can see small drifting patterns in the ns figures. It is otherwise very stable, and this is with a gain of 902! For the Trimble the TC is definitely too high. The ns numbers start to oscillate and the DAC needs to follow suit.
I'm now going to set the TC to 1,500 for both.
Update, a TC of 1,500 was still too high for the Trimble, I gradually brought it down to 800.
Here is the result of optimizing the TC's for both GPSDO's.
The ns curve for the Trimble is no longer "oscillating" because of the OCXO drift anymore, and so the DAC has less swings to correct it.
So despite the fact that the optimum TC in the TimeLab chart shows a value of around 2,500, the reality is different.
The Bliley based GPSDO is now tuned with a TC of 1,500 and is very stable, apart from some anomalies (outliers) as you can see in the middle of the graph. After running with a TC of 800 for the Trimble, I raised it to 1,000 again.
Setting the ADC linearization parameters
Lars describes a method to set the ADC linerarization of the TIC readings on page 12 of his pdf documentation. Unfortunately, he was not very clear or specific enough for mere mortals on how to derive the min-max values. On the forum, we have collectively struggled to figure this out. This process is described on the EEVblog starting with a question at post 724.
While trying to figure it out, I found a procedure that will give you the numbers.
Set
the Time Constant to 4 (with t4), and wait for a lock. It may take a few minutes. When you have a lock again, set the TIC_offset to 1,000 (with o1000) and wait until the
numbers in the ns column stabilize about around zero again. When you set the offset from the default of 500 to 1,000, the ns values will jump the additional 500 and the loop will try to bring it back to zero. This will only take a
minute or so but this time there will be no lock indication. In my software, this is
shown as "****" in the sample below.
This setting will results in a set of numbers in the filtx10 column that are about evenly spread to numbers above and below 10,000 (see the example below). What you need to do with them before you could add them into the system however was the big question. After a hint from a blog user, I modified the monitoring program to also log the "raw" TIC_ADC values. They are in the second column of the example below, and Eureka!, they show the minimum and maximum numbers you could add into the system.
The big question left is how figure out what to do with the filtx10 values to derive at appropriate min and max values, as Lars wanted you to do? In his documents, he writes: "The filtx10 values will get you the min and max." Well, maybe, but what is max and what is min, and either way, you can't enter them into the system as they are. According to the software, and the f1 info, the accepted values are 1-500 for min, to get you 0.1-50, and 800-1023 for max.
Unraveling the mystery
Remember that when there
is no lock, the data in the filtx10 column shows the data multiplied by 10. So the new offset of 1,000
becomes 10,000 in the filtx10 column.If you now look at the data in the filtx10 column, and also at the data in the ADC column, it's easy to see that all values above 10,000 "represent" the minimum ADC value. To get that value so you can enter it into the system, you need to subtract 10,000 from the filtx10 data. So as an example, if the value is 10,120, take off 10,000 to get 120. When you enter this value into the system, it will be divided by 10 automatically to become 12 which is the intended value.
All values below 10,000 are the maximum values, but need to be divided by 10. So as an example, if the value is 9,950, the maximum value you need to enter is 995.
I would capture at least a page or so of data in a spreadsheet and then use Excel to first sort the values by value, and then use Excel to calculate the average of the values < 10,000 and also of the values > 10,000 to get the min and the max average values you can enter into the software.
These average values can now be added into the system with (small L) l 120 for min and (small L) l 995 for max. Set the TICoffset back to 500 with o500 and then save the settings with s1 into the EEPROM.
The numbers in the added column with the ADC TIC values are spot on to those calculated numbers above, so that must be it!
Here is a small abbreviated sample of my modified log from the Bliley:
Timestamp ADC pwm time ns dac temp status diff_ns filtx10
15:31:20.015 -> 995 134 4283 -6 35478 50.4 **** 10 9950
15:31:20.994 -> 997 135 4284 -3 35873 50.4 **** 2 9970
15:31:21.977 -> 995 138 4285 -6 35328 50.4 **** -2 9950
15:31:23.007 -> 994 141 4286 -7 34990 50.4 **** -1 9940
15:31:23.989 -> 12 132 4287 14 39274 50.4 **** 21 10120
15:31:25.018 -> 992 138 4288 -9 34614 50.4 **** -23 9920
15:31:26.006 -> 989 141 4289 -13 33731 50.4 **** -3 9890
15:31:26.987 -> 32 132 4290 31 44028 50.4 **** 44 10320
15:31:27.973 -> 16 142 4291 17 40721 50.4 **** -14 10160
15:31:29.002 -> 10 139 4292 12 39556 50.3 **** -5 10100
15:31:29.984 -> 991 130 4293 -10 35102 50.3 **** -23 9910
Mystery solved !
New MDEV & Frequency plots
Here are the latest TimeLab plots of both GPSDO's. The Bliley with a TC of 1,500 and the Trimble with a TC of 1,000.
The Trimble is good, but the Bliley is very good.
This plot shows even clearer how good the Bliley is in relation to the Trimble.
Isolated outputs for the GPSDO
After
having seen yet another situation where the GPSDO lost lock due to a
glitch after I connected something to the 10MHz output BNC connectors, I
decided to fix this once and for all by adding isolated outputs. My
GPSDO is floating from earth ground, and so are most of my instruments.
The only exception is my scope. Due to this floating behavior, you can
have ground voltage potential differences in the tens of Volt, up to half the mains voltage, and this
can cause glitches when you connect these floating grounds together. I
am planning to have two instruments that are going to be fed from my
GPSDO, my FY6600 Function Generator, and my Fast Rise Frequency
Generator. Both are floating from earth ground. This means that I will
need two separate isolated outputs. The most sensible method is to add
these outputs to the back-panel of the GPSDO, because the inputs for
both other instruments are on the back also. My Fast Rise Frequency
Generator is already prepared for the 10MHz GPSDO clock input and it has
a BNC on the back. The FY6600 needed a modification to do the clock generation and distribution. That project description is on my FY6600 blog post.
I designed a circuit based on the rather well known TADD-1 6-channel RF Distribution Amplifier.
The pdf document can be found here : TADD-1
Because the circuit is inside the GPSDO, I didn't need the input isolation transformer, and I only needed 2 outputs. I also added the fan controller circuit to it. Here is my circuit:
I
decided to power the OpAmps with their own dedicated supply. I used an LM78L08 to generate the VCC for the Op Amps. I found that 8V is sufficient. You can bridge the 78L08 socket if you don't want to do that and use the available 8V that I already have available on the main board.
I also used inexpensive transformers that I ordered some time ago. I have added components to tie the isolated ground connection to the ground connection of the connecting instrument by a 10nF capacitor and a 1M Ohm resistor. They will make sure the output ground is not floating. In my situation, the outputs are always connected to the instruments, such that there can be no build-up of the ground potential, which is why I think I can get away with what I did. Officially, the capacitor should be a 500VAC type, and you should use two 1M Ohm resistor in series to create a spark gap and avoid a short if one of the resistors fuses.
Below is the top view of the PCB.
This
is how the board will be mounted. The board will slide into the top
cover of the enclosure so the components are "hanging down". The SMA
connectors are mounted on the back-panel. To keep them isolated from the ground of the main board, I went through some work to make sure that there is no connection from the main ground to the metal enclosure. The gain trimmer will be accessible through a hole
in the back-panel as well, Although I decided that I won't not need it.
The PCB looks like this with the 3D rendering tool from DipTrace:
This
is a 3D rendering of the bottom side of the board. I don't have all the
3D models for the parts I used, but you get the idea. The trimmer shown
is the wrong kind, I'm using a simple one turn trimmer with the
adjustment on the front.
When the boards arrived, I build one up for one channel and started some measurements. It quickly turned out that the gain section is not needed. The influence ( for a square wave input signal) is very small, and since the input signal is coming from within the GPSDO enclosure, I will be able to feed-in the 5V p-p square waveform. What also became apparent is that I don't need the second amplifier stage. Nice, because that saves two op Amps. Not needing the gain adjustment also saves one additional hole in the back panel.
It's very easy to modify the PCB for these changes. I took out R8 and the trimmer and replaced R7 with a 0R resistor, putting the Op Amp in a unity gain buffer configuration. I used a thin (wire-wrap) wire to connect the top of R1 to the top of R9 and used a solder blob to shorten pins 2 and 3 of one of the second stage Op Amps. Both isolation transformers are now connected to the first Op Amp, but I changed the 100R series resistors R1 and R9 to 50 Ohm ones to keep the output impedance the same.
Below are the two outputs from both isolated channels, using SMA to BNC connectors and connecting the channels to my oscilloscope, terminated by the 1M Ohm scope inputs. Here I'm using my bench supply to feed the board with the 12V DC, and I use my function generator with a floating 10 MHz 5V p-p square wave input. The fidelity of the signals are good to at least to 4V p-p, below that level, the wave forms start to deteriorate.
Looks good to me.
I have added the board to my Bliley GPSDO, and I'm feeding my DIY Frequency Generator instrument now with it. With this last step, I think I'm done for the moment with this project. There may be some software tweaking required, but I don't see the need to add anything to the hardware. Both my GPSDO's are stable and performing very, very well.
I have also designed a small PCB that will go into the FY6600 function generator that will use the GPSDO 10 MHz for the clock generation circuits to feed the required 50 MHz master clock. The description for that portion is on my FY6600 blog post.
Additional developments
To keep this blog is clean and focused as much as possible on the GPSDO, I have created another blog post that deals with the monitoring, measuring and logging of the GPSDO.
This blog, with it's own Github project can be found here.
Using my PCB
If you are interested in obtaining this PCB, I added the required files on my Github site, together with my version of the controlling firmware for the Arduino. Please note that I made some errors with the PCB layout and could have done a few things better when I designed the PCB. The pitfalls are described in the readme file on the Github site.
Updated firmware to version 3.7.0
During the summer period, I noticed that the temperature regulation inside the enclosure was not working properly anymore. The PWM slammed to the 255 "rails" too often, and it did not regulate anymore. I was very busy with another project so I just left it.
I knew I had to spend more time learning about tuning the PID regulation loop, which I never did well.
I started reading on that and also implemented a few other PID libraries just to see what they did differently from what I concocted myself. In then end, they were more complicated or troublesome than I wanted or needed. I did make an update and improved some things and then started to tune the PID parameters while following the recommended procedure, start with Kp, then Ki and followed by Kd.
While watching the effects closely, I realized that because of the inertia of the system, the reaction of the temperature inside the enclosure by the little fan, it was clear that my Kp gain was far too low, and the Ki gain was barely needed. The system itself already provides a lot of damping. I also don't have sudden jumps, so also the Kd gain is barely needed.
In the meantime, I was still unhappy with the performance. The simpel little fan (30x30mm) I was using was not able to cover a wider span of ambient temperatures. I decided to replace it with a larger fan, this time a 40x40mm Noctua NF-A4x10 5V version with a PWM input. This meant that I no longer needed the transistor based switching of the negative lead of the fan, because the signal is inverted. I am now driving the PWM input from the fan directly from D6 of the Arduino. The Noctua fans like a PWM frequency of around 25KHz, unfortunately, the standard Arduino PWM frequency is only 976 Hz. I applied a register change to get it up to 7.8KHz, but that's it.
Instead of using the ambient temperature sensor as the input to the PID regulator, I'm now using the sensor attached to the OCXO. To make that more effective, I removed the insulation cover of the OCXO. This will also ensure a bit more heat into the enclosure which will give me more room to maneuver the temperature. The regulation value is set just about the temperature that the OCXO generates by itself, 47.5 degrees C, so I only remove the excess amount.
I also improved some comments in the code and now arrived at version 3.7.1 which is on the Github.
Here are the results of a 24 Hr period with the updated regulation:
The PWM activity is a result of the changing room temperature during the day (heating) and night, which is reflected by the Ambient temperature measured inside the enclosure. The OCXO oven is now kept at a stable temperature and this results in a better frequency stability, here represented by the DAC. The fan always runs at a minimum PWM of 25 to keep a constant air flow.
All this shows how critical the temperature regulation is, because I can see the OCXO reacting to it in a negative way. I strongly believe that the temperature regulation is the key to a stable GPSDO system.
The Github for this project can be found here : https://github.com/paulvee/Lars-GPSDO
If you like what you see, please support me by buying me a coffee: https://www.buymeacoffee.com/M9ouLVXBdw
