Show by Label

Friday, July 31, 2020

A high precision 10MHz GPS disciplined oscillator (GPSDO)

Note that I will be changing and adding to this post for quite some time. Please revisit often!

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 well into the summer of 2020 and this is one of 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 seperate 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 to too low, you can increase the value of R109 to get a gain of at least 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 C201, 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 C201. 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.

If you have a square wave out OCXO, you can add C105 and change the value of R15 to 100 Ohms to dampen the transitions somewhat.


The importance of the GPS module

Knowing nothing about the required GPS modules, I first purchased two Ublox 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 Ublox versions 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.




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 such as the Bliley and the Oscilloquartz, or even a double enclosure like the Trimble seems to 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 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 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 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, 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. 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. 

I have now taken the isolation for the three OCXO's away as much as possible, so only the bottom part remains, or in the case of the Trimble, I could only remove the top. I'm running a new set of tests since I had to restart the systems after the power-down.
 
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 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 above is the after. There is much less of a temperature effect now.

 
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.
 

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 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 frequency jumps

Although the Bliley only needs a soft feathery touch by 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 the next day.

 

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 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 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:
 
The first graph of the temperature inside the plastic enclosure is only a snap-shot to show the temperature swings. Note that the other two temperatures have a low-pass filter applied to the Lars program. The inside temperature is now regulated within 0.6 degrees and therefore the temperature within the aluminum GPSDO enclosure is also stable. The temperature swings inside the plastic enclosure come from the fact that the fan is stopped when the temperature is below the set-point. It was too difficult to regulate the fan speed to keep the temperature constant. That will require a PID type regulation. For now, this method seems to be sufficient. The temperature inside the GPSDO enclosure is now no longer influenced by the room temperature and hence the DAC will finally show the "real" representation of the GPSDO. This is still with a TC of 500 and a gain of 987. Next step is to remove the DAC temperature compensation from the Lars program.
 
 
 

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.

Stay tuned for more...
 
 

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. I also have one PCB left for sale, send me a pm if you're interested. Over time I will also add the Raspi programs to it. Please note that I made some errors with the layout and could have done a few things better when I designed the PCB. The pitfall's are described in the readme file on the Github site.

The Github for this project can be found here : https://github.com/paulvee/Lars-GPSDO






Sunday, September 1, 2019

Upgrading & Tuning my FY6600 Waveform Generator

For a while, I had contemplated to upgrade my FeelTech FY600-30MHz Dual Channel Waveform Generator.
This is a very interesting instrument that has specifications that would be comparable to instruments hundreds of Euro's more expensive. Unfortunately, the manufacturer of the design took some short-cuts to penny-pinch some more profit out of the device, and that causes some problems.

Initially I didn't care too much, the instrument performed very well for me, but when I started to dig into high precision oscillators and the likes, see my other posts, I needed a higher precision counter function. This can be rather easily done by replacing the main oscillator but I also wanted to see what other people did and what else was possible.

There is a huge number of postings about this instrument on this blog : eevblog.com , after reading through all of them (yes really - it took me three days) I decided to tackle the three most important issues.

These are four main issues reported by the many users on the forum.
  1. A very poor switching power supply with no earth ground. This could put an AC voltage as high as 1/2 of the main voltage on the BNC outputs. The current is very little though, and is caused by the leakage of a capacitor, but still.
  2. Distortion of the waveforms at higher amplitudes. This is caused by the selection of rather inexpensive and older design opamps. Interestingly, there are provisions on the PCB to install much better opamps.
  3. A rather poor main oscillator with poor precision and significant drift. The drift is mainly caused by the fact that the oscillator is way too close to three voltage regulators that get pretty hot.
  4. The attenuation circuit in the output section has an incorrect resistor value.

4. The attenuation issue
At this moment I'm not going to address that problem.

3. The oscillator
The recommended replacement oscillator for the CTS 50MHz 50ppm CB3 version is the model D75J from Connor Winfield. This is a surface mount temperature compensated crystal controller oscillator (TCXO) in the 50Mhz version, calibrated at 25 degrees at 1ppm and a stability of 2ppm. Incredible precision and stability! Because the D75J is a temperature controlled oscillator, the effects of the nearby regulators are pretty much eliminated. This is especially important if you use the FY as a counter.

To reduce some heat hot-spots from the three on-board regulators near the oscillator, I added two small "sticky tape" heat-sinks (Raspberry Pi type) on top of the three regulators. The temperature of the heatsinks after more than two hours is now about 46 degrees C, and more evenly spread.

After I installed the new TCXO, I measured the precision against a calibrated oscillator.  I measured the frequency of this oscillator to be 5,000,001.7 Hz. This is very close to the calibrated value of 5,000,002.1 Hz, but that factory calibration was eons ago, although the oscillator was never used until very recently (see my other post: Frequency Generator with Fast Edges). Either way, that is a remarkable precision and the reading over a few hours only changed 0.1Hz. The heating of the temperature inside the FY enclosure no longer seems to have an effect. The next step is to measure the result with a GPS Disciplined Oscillator (GPSDO), a project I'm currently working on.

2. The opamps
I replaced the single dual output amplifier with two single THS3095 opamps. I also increased the +/1 12V to +/- 15V to give them more room. The performance at higher output voltages and at higher frequencies is now much improved. Still not great, but much better, at least worth the small investment and trouble to do this. The best performance is still with 5V p-p and lower output voltages. I wonder what the higher frequency models actually deliver, if mine at 30MHz is already very poor.

1. The power supply
The power supply has been talked about many times on the forum, with several options offered, but there are only a few examples for a replacement.  I decided to design a completely new supply, that would let me adjust the +/- 12V outputs to +/-15V as well. The new output opamps need this voltage to display the waveforms without distortion.

Going through my parts collection, I picked a 24VA block transformer that could be mounted on a protoboard. The transformer is a little too heavy (in VA) with 2 separate winding's of 12VA each, and an output of 15VAC. Both secondary winding's are fused with 0.8AT PTC fuses. The primary has two separate 115V winding's. Because there are seperate windings, I took advantage of that feature, and created two separate supplies. The advantage is that you can use full bridges on either one, saving on the size of the buffer cap, and you can avoid ground problems, especially easy to do when you are using perf- or protoboard instead of  a real pcb layout. I tied the supplies together at the connector going to the main board, not anywhere else. I also wanted to avoid the inevitable switching noise coming from the DC-DC regulator going to the -12V supply as much as possible. Any noise on the 12V rails can/will make it to the output signal. After measuring the final results, I added another 330nH inductor to the plus input of the DC-DC convertor, to prevent more switch noise from being injected back into the 12V supply. This added inductor is not shown on the circuit diagram below.

The weight of the transformer will prevent the instrument from sliding as much, because the instrument was so light before, a bonus.

I decided to use the LM318 and LM338 voltage regulators for both the +/- 12..15V analog supplies. The only specialty in this circuit  is around the 10-turn trimmers, because they are China quality, and therefore cannot really be relied upon. The worst case is when the runner looses contact, creating a much higher output voltage then you intended, and this could potentially blow up the output amplifiers of the FY6600. The way I selected the adjustment components is such that you can get just below 12V and just above 15V. Depending on the toleration's of your parts, you may have to adjust a resistor value here and there. I bread-boarded the circuits before I mounted them, just to be sure.

For the +5V supply used for the digital circuits, I selected a simple DC-DC Buck convertor because doing that with normal linear regulators would create too much heat (burning off the difference between 20V and 5V at 500mA). I specifically did not want to add a fan, with all it's generated high frequency switching noise inside the box. I also reused some parts from the old supply, specifically the line filter and the 5V choke.

My unit is intentionally still floating. This can be fixed easily with a BNC/USB connection to another earth grounded instrument. If I change my mind, I can still add a 4mm connector to the back, tie that to the power ground and make a connection to earth ground with a test lead that way.

Here is my design:



And here is the unit with the supply installed:



Just above the upper left hand corner of the transformer, you can see the two little heatsinks I used on top of the three regulators to disperse their heat. Just above it you can see the metal can oscillator that I'm going to replace. The person that did the layout of the board had no clue as to the heat effect of the regulators on the stability and precision of the oscillator. 👿

I did not have room on the protoboard for the DC-DC convertor, so I used double sided sticky tape to put it on top of the transformer and moved it away from the analog section of the main board. These DC-DC devices are notorious for their switching noise superimposed on the output voltage. Using the 10uH inductor from the old supply and a few capacitors on the output reduced the 25mV ripple at about 1MHz to about 7mV, which should be OK.

When I started the testing, I had to resort to a little kludge because the heatsink I used was too small. In hindsight, I should have used two separate and larger heatsinks. Doing that now would cause some major and ugly surgery. Bolting another one on it is now better with the supplies at +/- 12V, it will be significantly cooler when I change them to +/- 15V. (less of a voltage drop over the regulators) At +/- 12V, the heatsink is now just below 50 degrees C. After more than two hours, the temperature inside the case is about 35 degrees C, at a room temperature of 27 degrees C, which is a bit warmer than I like but fine for now.

After I raised the +/- 12V supplies to +/ 15V to give the output amps more headroom, the reduced voltage drop over the regulators decreased so much that the extra heatsink kludge is no longer needed.

With all the mods done, I'm happy with the results.

I am actually most impressed with the precision of the counter function now. With my GPSDO now fully operating, I could finally measure the actual precision. When I measure the 10MHz output of the GPSDO, the counter with a gate of 10 sec. gives a result that is exactly 1 Hz too low. (9.999.999.00 MHz) Not a bad result at all for these modifications. It takes about 15-30 minutes of warm-up time to reach the highest precision.

Enjoy!


Friday, August 23, 2019

Frequency Generator with fast edges

This post describes the building of a 20MHz frequency generator with a 1-2-5 frequency selection down to 1 Hz through a rotary decoder. The frequency generator is a stable high precision 5MHz oscillator. The device also has fast rise (<=1ns) output edges that are generated through a Fast Rise assembly taken from a Tektronix PG506 Calibrator. The PG506 was used by Tektronix engineers to calibrate instruments. I used it extensively in my period at Tek.

The reason for this design
When I started to investigate the DIY build of a differential probe, see one of my other posts, I needed a fast edge pulse to measure the bandwidth in lieu of using much better equipment that I don't have. I also wanted to have a precise pulse generator with many frequencies, analog to the PG506, to measure and calibrate instruments or help in prototyping circuits.

For about 40 years, I held on to a Fast Rise Board assembly from a PG506 dating back to my time at Tektronix. The unit was defective coming out of a unit that was still under warranty (actually blown up by the user) and could not be repaired without some significant surgery. With some help I was able to fix it. For a long time I wanted to reproduce part of the PG506 Calibrator to test and adjust DMM's and oscilloscopes and although I even had a prototype for the Standard Amplitude amplifier up and running, I never saw the real need to spend some significant money on the required precision parts to finish it.

During this time I already built a PIC-AXE program to control the frequency selection so the time was right to put it all together. The main controller for the instrument is a PIC-AXE 14M2, and I use a second 18M2 controller to serially drive the LCD display. The PIC-AXE chips are very easy to use and are programmed in BASIC. PIX-AXE has a great Software Development Environment (SDE), which I think is even better than the Arduino SDE. http://www.picaxe.com/

Please keep in mind that this is a quick-and-dirty "put together". Dealing with fast pulses with frequencies at 20MHz on proto-board are typically not very forgiving for glitches due to the fast switching of devices, and this is no exception. When (if) I decide to build a final version, I will have to make a proper PCB with power and ground planes and do a much, much better job at decoupling.

The building process
In any case, if you're interested, here is the design that I put together.

Clock generator

Above is the circuit diagram. Below is a picture of the oscillator I'm using. It's an old unit that was in my parts collection for 40 odd years as well. It was calibrated and measured to deliver 5,000.0021 KHz at 27 degrees Celsius. That's only 2.1ppm by the way.

A clock of 5MHz does not really work well in a 1-2-5 divider sequence, so I used a PLL chip to multiply the 5MHz oscillator output to a 20MHz clock. The output of the 5MHz oscillator also goes to the front panel through a few buffers.


Because of the constraints of the enclosure, I mounted it upside on the top cover so it's still in the proper position. It's not "ovenized" but encased well to prevent wild ambient temperature fluctuations. The designers must have designed it with certain temperature parameters in mind, so I didn't want to mount it on its side or upside down.



Frequency Selection
The 20Mhz oscillator signal comes in at the top left of this diagram. It is divided by 7 74LS390 decade counters (two per package) into the main frequencies. All the outputs go to an 8-input multiplexer, a 74LS151. The selection of the 8 inputs goes through 3 inputs (A, B and C) and are driven by the controller. The output of the multiplexer then goes through a divider section of two 74LS109 flip-flops that divide the selected frequency through 2 or 4 to get the intended 1-2-5 frequency selection sequence. The divider outputs are selected through three OR-gates, who are also driven by the controller through NOR gates. The output of the OR-section is buffered and goes to the Fast Rise board, and also the the output BNC connector. (one still to-do is to replace U11.6 with the spare F02 and add that F04 gate in parallel to the output buffer section to get a bit more diving capability)

The controller also drives transistor Q1, which is used to activate a small relay. The relay switches the positive and negative power to the Fast Rise board. The Fast Rise board gets very warm when used, and that does not work well with a precision oscillator, so I decided to switch it off when not used, similar to the operation in the PG506. The zener diode is used to lower the 16.5V to the 12V DC for the relay.


CPU Circuit
The main controller circuit is quite simple. On the top left is a stereo connector that is used to program the device in-circuit, through the PIC-AXE USB to serial cable. The main 14M2 controller sends out a serial stream to the display controller, which is an other PIC-AXE controller, a 18M2 version. The main outputs of the 14M2 controller are the ports that drive the mux frequency selection and the /1 /2 and /4 step selection, in addition to driving the power for the Fast Rise board.
The selected settings are transmitted over a serial interface to another PIC-AXE controller on the LCD board section, and that drives the LCD display.
Lastly, the controller also deals with the rotary encoder. Pushing the rotary encoder button toggles the Fast Rise board power. Turning it left or right will select the output frequency.

Display Circuit
The display circuit consists of a PIC-AXE 18M2 controller that takes the serial input data from the main processor and multiplexes that to a typical LCD display. Due to space requirements, I selected an 8x2 LCD display. The code for this controller is a standard program that can be downloaded from the PIC-AXE site (Serial LCD). I used a ribbon cable to connect the display controller to the LCD display on the front panel.


DC Power Circuit
Due to space and noise considerations, I used an external 15-0-15VAC 2x300mA transformer. I have a number of these transformers in various voltages and housings and use them to power several of my tools. They all have 4mm test lead connectors, and I use a 3-pole DIN connector to connect the AC voltages to the power board.

For this instrument, I need three different voltages, +5V for all the logic, and +16.5 and -16.5 in addition to +5V for the Fast rise board.

NOTE:
With the 1.000uF capacitor (C4) in the positive supply side, there was a mains ripple on the +16.5V output when the Fast Rise board was activated. The Fast Rise board consumes a lot of power from the +16.5V and the +5V supply. The raw AC supply sagged to just below the headroom of the LM317, creating a hum on the positive High Rise pulse. Using Schottkey diodes to create more headroom just didn't do it, so I added a 3.300uF in parallel to C4 and that fixed that problem. When (if) I decide to turn this circuit into a real PCB, I will redesign the power section and use high efficiency/low drop regulators and do a better job decoupling.


PG506 Fast Rise Board
The design of this circuit is a typical testament to the skills of the Tektronix analog designers, that were among the best in the industry in those days.

 
The code
The code for the main controller and the serial LCD driver can be found on my Github site: Frequency-Generator

The various parts as I built them look like this:

This is the power board. The little black square is the switching 5V regulator. I don't show the extra 3.300uF cap here, that was added later.


The Fast Rise board is at the very top. To the left is the front panel with the 8x2 LCD.
On the bottom of the case (in the middle here) is the main board. On the top left of that board is the PLL on an SMD carrier and the 4 LS390 decade counters. Next to them the 74LS151 mux and the LS109 flip-flops. Top right is the programming connector for the main controller. In the middle to the left is the 18M2 display controller and the adjustment for the display contrast. Next to that the 3 pins for the oscillator connection. To the right are the F32 OR gates and F02 NOR gates.
On the bottom row from left are the 14M2 main controller, the 74F04 buffers and in yellow the relay.


The standard Power-up screen after de device has booted up, displaying the version number of the software.

On the left side are the two Fast Rise output BNC's. On the top the positive edge, and below it the negative edge.
Below the LCD display are the main output BNC and to the right the 5MHz output of the oscillator. Top right is the rotary encoder with push button, and below it the output voltage adjust for the Fast Rise pulses.


Performance
How does it perform?

I'm using a 74F04 as the output drivers for my clock signals, and use two gates with a series resistor of 50Ohm. They produce a nice and steady 4ns rise time, using a 1mtr coax terminated in 50Ohm at the scope input.

I think I can improve on the cross talk and glitches, but that will be when (if) I design a proper PCB.


Above is the 5MHz oscillator signal taken from the BNC connector on the front panel. Note that the end of the BNC cable is terminated into a 50 Ohm coax terminator before it goes to the scope input. Because of the poor decoupling on the main circuit board, the switching transitions of the various gates and the PLL are clearly visible. I don't care too much at the moment, more important for me right now is the frequency selection, the timing precision and the Fast Rise outputs.



Above is the 20MHz pulse, again terminated into 50Ohm.



Above is the 100KHz signal terminated into 50Ohm. The two gates of the 74F04 driver for the output are doing a good job, note the rise-time of 3.7ns.


Pushing the rotary encoder toggles the Fast Rise board power.




And here is the beautiful positive edge of the Fast Rise board. According to the PG506 specification, the Fast Rise edge should be <=1ns. This is at the limit of my RIGOL DS2072A (with the 300MHz hack - it reports that it is now a DS2302A).
The rise-time is not a steady 1.250ns, it varies a little. I was lucky when I pressed the print button on the scope to get this picture.



The pulse of the Fast Rise at 100KHz looks like this:



Calculating bandwidth from rise time
The "rule of thumb" calculation to infer bandwidth from rise time is BW = 0.35 / rise time for (Gaussian type) analog scopes and for DSO's it should be BW = 0.40  / rise time.

The RIGOL specifications for the DS2302A list a 300MHz bandwidth (@ 3dB) with a typical rise time of 1.2ns.
If we use the rise time specification of 1.2ns for the RIGOL with the factor of 0.40, we get 333MHz, on paper...

In the above actually measured case, the calculated bandwidth is 0.40 / 1.3ns (max) = approx. 307MHz. Spot on!

Master clock precision
After I upgraded my FY6600 Function Generator & Counter with a 1ppm precision TCXO oscillator, I measured the frequency of the master oscillator to be 5,000,001.7 Hz. This seems to be a little better that the part got after calibration (5,000,002.1 Hz). Either way, that is a remarkable precision for such an old and never used part.

The next step is to measure it again as soon as I have my GPS disciplined oscillator ready, which is a project I'm starting right now. If all goes as planned, this should allow me to verify the clock precision of my counter within 1ppm, and also allow me to calibrate the master clock again. The now up and running GPSDO was used to measure the precision of the FY6600. It is exactly 1Hz too low at 10 MHz. This means that the precision of the 5MHz oscillator is even better than I first anticipated.

Todo's?
As mentioned earlier, there are some things I could do to get rid of the noise, glitches and cross talk, but right now, I'm very happy with the results.

Update [may 2020]
I used this unit extensively while testing the 100 MHz differential probe design that my friend and I designed recently. Look at our blogs that details this project. We could only really characterize the diff probe with the fast edges. That alone was worth the trouble to build this unit.

In addition, after having now completed three working Global Positioning System Disciplined Oscillator (GPSDO) units on another project, not described on my blog yet, I wanted to test a couple of things. For this test I needed a very stable and precise 1 second clock signal, to replace the jittery but very precise 1s pulse coming from the GPS unit that drives the GPSDO. This is a perfect task for this unit, but it needed a "final" modification.

To feed the unit with the extremely precise GPSDO 10MHz output, I added a BNC connector to the back panel, and wired that to the oscillator input pins on the main board. From now on, I will connect the 10MHz square wave output of one of the GPSDO units to this input to create a very precise 10MHz base clock. In order to get the master 20MHz clock back, I needed to change the configuration of the PLL multiplier chip from 4x to 2x. I also no longer needed the 5MHz oscillator, so I took it out.

Needless to say, this change in the setup works very well. So well actually, that I'm now seriously considering making a decent PCB layout and get rid of the nasty glitches and wiggles on the output pulses.

Stay tuned!

Enjoy!