Whilst trying to see how well my GPSDO (look at another posting) was doing, I used a design with a traditional counter, with a very loooooong gate time to get a few decimal digits of the 10MHz output. This counter was designed by Yannick Turcotte and together we made it work with my GPSDO. This is also described on this Blog and can be found here.
This counter was more for play & study than really usefull, but at the time, I could not find any DIY projects that would give me a higher resolution. In the meantime, Yannik built another version specifically for a GPSDO, and this project is described here: GPSDO-YT-10-Mhz
I don't think it has the oomph to get down to 12 digits of resolution, so I discounted his project for now.
A viewer of my Blog pointed out that a Reciprocal Counter would be "easy to build" to measure a GPSDO, but he did not offer any proof if it could do 10-12 digits nor did he build one. Typical armchair critic leaning back to let others do the work. However, the back-and-forth with him actually resulted in the find of a DIY reciprocal counter that promised a minimum 10 digits of resolution already. Now we're talking.
I studied the website (http://www.mino-elektronik.de/ ) and was impressed with what Michael Nowak has built over the years. It turns out that he became a real expert and has developed several implementations with all the required information to build one.
What peaked my interest was that he recently converted his software to run on a Raspberry Pico. I had an unused one, so I wanted to build that version as a proof of concept.
This was the beginning for me to plunge head first into a dark rat hole with new techniques, processors, debuggers and the likes to get to grips with, all the while sucking you deeper and deeper while money flies out of your wallet. But hé, as I always repeat at nausium to whoever cares to listen, that's the beauty of this hobby, right?
Raspberry Pico Fmeter2
Because I wanted to use the counter predominantly on my GPSDO, I could forego most of the input circuitry because my 1PPS and the 10MHz are already producing square waves. It should be easy I thought.
Here is the project described on Michael's website : Pico-Fmeter2
Look for the link to the project that is also described on the EEVblog here : pico-frequency-counter-using-rp2040/
Because I never really used the Pico after I got the LED blinking on it, and Michael uses the IAR Embedded Workbench to program and debug the code, I decided to invest in this toolchain. The IAR EW for Arm processors is free with a code size limitation, but that was no limiting factor.
It took me some time to install Michael's software structure on my PC because there were some weird dependencies in the EW that plagued the installation. I started by uploading the hex code the traditional Pico way, and that worked fine and the counter became alive.
With Michael's help and a little detective work I figured out what to do to re-create his structure, using an older EW, in my EW (V9.32.1) on my PC and eventually I could build the code myself and download it to the Pico using the IAR EW. In the meantime, my educational version of the Segger J-link probe arrived so I could use that to download the code and debug it as well. Nice! I had not used a debugger like that since my early career days with microprocessor development systems, in-circuit emulators and Logic Analyzers in the 70's and early 80's. These debugging tools came a long way!
As an aside, in those days I found and contracted IAR, which at the time was a small start-up company in Uppsala, Sweden, to have them write some disassemblers for the logic state analyzer of the company I worked for. We worked together for a few years providing support for a number of processors our customers wanted to use the LA with. Some of them had pipe-line archtectures or internal memory and they figured out ways to get enough information to provide a cycle by cycle assembly code trace. I was really impressed with their capabilities. At the time they were already developing what must have been the early version of the EW and I even visited them in Sweden. Small world...
I still have a lot of learning to do but I'm already impressed with the integrated and complete environment the IAR EW provides.
Back to the Pico...
Here is a picture of the setup I was using as a first proof of concept test.
Besides the Pico and the LCD, there is only a single capacitor to couple the GPSDO 10MHz to the Pico input pin, a trimmer to adjust the contrast and a single resistor to set the backlight of the LCD. Cannot get much more simple and the results are very good! Astonishingly good actually.
This is with the software as it comes "out of the box" without any configuration and it is gratifying to see this reassuring display.
Next step was to lengthen the Gate time and make it display more digits.
The last two digits are not really useful with this flying leads setup on a breadboard, but it was the needed kick in the proverbial behind to see if I could get it any better, and look for more.
The next step was to feed the counter with the GPS 1PPS pulse, because the counter can use it to fine-tune the internal clock to get better precision, and that resulted in an improved precision. Really nice!
The Pico solution was Michael's way to see how far he could go with the new Pico, but the software was really a port from his STM32 based solutions.
I was impressed enough to now take the next step, and that is to hunt for a higher resolution.
STM32 Fmeter-431G
Michael was so kind as to send me a PCB for the FMeter-G431, so I ordered the parts needed to build it. Several were not available anywhere due to the current chip shortage, but eventually I was able to find what I needed, or used what I already had. Unfortunately, I ran into a few snags and ordered the incorrect parts, so had to go through the whole process again. I was able to give Michael some feed-back about his BOM so others will hopefully not fall into the same trap.
One of the traps is that when you use the MAX232 convertor, it inverts the STM outputs and that limits the connection to the PC to only true RS-232 to USB adapters. I'm typically use a TTL serial to USB convertor (get one that supports 3V3 and 5V levels) but you can't use that with the MAX232. The signals are inverted. In the end, I took the chip off the board and bridged the two input to the outputs with two 1/8 W 100R resistors to keep the polarity the same. The resistors also "kind of" protect the STM chip.
The Fmeter-G431 project can be found here on his website: Fmeter-G431
Michael also described it on another EEVblog here: EEVblog
Again I used the IAR WB to re-create Michael's software environment, and this time I was fairly quickly able to build the code myself. I needed to build a new Jlink probe cable, and had to order a few parts, but eventually I was up-and-running for this chipset as well. I never used the STM32 family so again I had to learn a lot from scratch. I'm not complaining, it's keeping my grey matter active.
Here is a picture of my setup, again straight after download, no options set yet:
Looks exactly the same as with the Pico. Remember, almost the same software.
Here it still has the MAX232 in place, so I could not change the parameters yet.
Michael intended to have the counter board piggy-back on the LCD display, but I wanted an easier way to test and debug, so I concocted a two socket deal that would allow me to see the display while working on the counter.
As I already noticed on the Pico version, the processor clock is very critical when you start to increase the number of digits in resolution. This counter has it's own simple VCXO that had pretty good specifications, but when I tested it against my GPSDO, I was amazed how poor it performed, at least lying on my desk the way it is.
In any case, I already knew that the counter has provisions for an external clock, preferably an OCXO, and that was what I wanted to use next.
External Clock
As it so happens, I was already experimenting with the two OCXO's that were left-overs from my GPSDO project, and I already had plans to build a little PCB with a reference IC to better tune the frequency.
I have a CTI OC5SC25, 5V, square wave output and an ISOTEMP 5V square wave output version as well.
I build the schematic, finished the layouts, produced the Gerber files and uploaded them to JLPCB, my to-go-to board house. Unfortunately, while I was waiting for the boards to arrive, I discovered that I did not actually order them. Bummer!
That left me with the Manhatten style setup, but I had too much difficulty to precisely tune the frequency to that of my GPSDO. Plus it was "flapping in the breeze"which did not help either.
To improve the connections between my GPSDO and the external OCXO, I modified the three frequency input connectors on the counter PCB to SMA adapters.
I use my DSO to monitor both signals, and with a 20 seconds high persistance I could easily see the drift from one compared to the other. I'm triggering on the GPSDO and the OCXO is tuned with the trimmer to have a still display with no movement. Drifting to the left means it's too slow, and to the right means it's too fast. Simple.
Unfortunately, even though the oscillator is ovenized, temperature plays a huge role on the stability, and the trimmer adjustment is too finicky and simply not good enough.
However, using this setup is already a significant improvement over the local VCXO on the counter board. I now need to see how much precision I can wring out of this system, also by using the 1PPS to tune the clock, but to go to 10 digits of resolution, even this is not good enough, unless you calibrate the clock against the GPSDO before you make a measurement.
In the meantime, my OCXO board arrived and I played around with it a bit. I'm not dissapointed actually!
First of all, as I knew and already alluded to, it is very difficult to tune the OCXO frequency with that of the GPSDO. The full trimmer adjustment is only +/- 1mHz, but even a fraction of a trimmer turn will change the frequency a lot.
This plus temperature changes, or rather the sensitivity for it, like drafts or even waving your hand makes it very difficult to exactly tune.
To better use the OCXO board as the external clock input for the counter, I put it in a little plastic container so the temperature inside the box will be a lot more constant that is, when everything has properly warmed-up by the oven of the OCXO.
This is the black box (no pun intended) on the right of the picture.
At the same time, I'm using the trend measurement feature of my 6-1/2 digit DMM to track the adjustment voltage for the OCXO. Obviously, if that drifts or is noisy, so will the output frequency be.
When I had the board outside the container, the voltage would move a lot.
However, in the box, after a sufficient warm-up, it is rock-stable!
Note the voltage scale on the left.
I'm also using my DSO to track the alignment of the OCXO with the GPSDO output to keep en eye on the drift. I can see it drift a little bit with the 20 seconds persistent setting, but I can't tune it now that it is in the box.
From now on, I'm using the 1PPS compensation that the counter provides, so that will help with the drift of the OCXO relative to the GPSDO.
The counter display is now very stable at 10.000,000,000,X MHz but has the last 1-3 digits flipping after each 10s gate time, which I think is also a function of the 1PPS adjustment the counter uses.
On the DSO, I can see the OCXO frequency drift to the left on the DSO, so it's a little slow, but the 1PPS compensation does a good job adjusting the internal clock to be able to show this kind of resolution and precision.
Here is a trace of the report the counter puts out. I capture it with a time stamp to show the gate time.
I think that this is already quite remarkable, with a display of 10 digits, we're already looking at a 100uHz resolution! I'm impressed. Well done Michael!
Looking at a larger sample of the above report and looking at the deviations from the GPSDO 10MHz, we see quite a number of values that are outside of what we are hoping to see:
It means that with the current setup a steady 100uHz resolution is still too much to ask for, but it is already better than a 10mHz resolution, so it's pretty good already.
Initially, I used my Lab Power Supply to power the counter with one channel, and the OCXO with the second channel. While running a trendplot for the frequency-adjust voltage, the second channel op my Siglent SDM3065X switched off, stopping the mesurement after aboyt 2 hours. This spontanously switched off happened before, after about a day, but never when I was present. This time I was there. It switches off, just like it would be when the front panel switch is used. Bummer, that's not an easy problem to track down.
As a second step, I used a 5.1VDC Wallwart, but the voltage dropped too much to my liking during the oven startup. The OCXO draws about 600mA for about 2 minutes, and this is on top of the counter. I tried a trend plot for the f-adjust again, but was not impressed. I did not want to further occupy my Lab Supply so I concocted a small power supply that is going to be fed by a transformer based 15VDC wallwart. This is one I use for special occasions, because it is not a typical switching supply, hence a lot cleaner.
I'm using an LM317 based voltage regulator to create a 5.1V supply, because these regulators are more quiet than a standard LM7805 type regulator.
At this moment, I'm feeding both the counter and the OCXO supply from this supply now.
Here is the schematic.
The LM317 type regulators have a pretty large tolerance for the voltage setting, but I did not want to add a trimmer because of the poor tempco. I tried the calculated 680R, and that resulted in a desired 5.1V. Be prepared to tweak the R1 and R2 values to get the desired output voltage.
I'll add a picture of the protoboard later. I actually had to progressively use larger heatsinks for the 317, because it got too hot. It has to dissipate about 10V at up to 800mA for a short period when the oven heats up, but even during the stable period, it got too hot.
I'm now running another trendplot to see how stable the f-adjust for the OCXO really is. I'm also looking at my DSP to see the drift. It is surprisingly stable and it reaches that situation within about a minute or two after power-up. Not bad.
Here is the tendplot of the frequency adjust voltage over a longer period:
Note that the voltage reference still needs to "burn-in". It only has had power for several days in total, not even continously. You can see the startup effect that looks huge, but consider the voltage level. We're talking about a swing of less than 200uV. You can also see the temperature effect of the heating in my office being turned low during the night. When I took the snap-shot, it was 9 in the morning, and the heater came on at 8. It turned off at 17:00 the previous day. So a warmer temperature results in a very slightly higher voltage. The GPSDO controlling loop must be able to handle this with ease.
Other than that, it is rock stable enough for controlling the OCXO.
I have now added another section to the power supply, because I want to separate the power for all three boards to minimize cross-influences. Experience with my GPSDO has learned that there are benefits to seperate all the supplies to minimize adverse effects.
The part of the schematic that I did not implement in hardware on the Veroboard at the moment yet is for the GPSDO. That will get 8V so the Arduino Nano regulator on the board itself is used to create the 5V, adding one more layer of separation. That LM317 does not need a heatsink.
Realize that this drifting and the difference with the GPSDO is only really an issue when you try to measure something as stable as a GPSDO. For most other applications, this is an already excellent counter! As a general purpose counter, it really only needs a front-end to accept different signal shapes and voltages, but Michael has a solution for such a front-end on his site as well.
But, I believe that there is still some more room for improvement and I want to see if I can get more precision and resolution!
Using a GPS 1PPS to adjust the external OCXO
Michael implemented a method in software to tune the internal clock of his counter with a GPS generated 1PPS signal. As far as I understand it, the software only nudges the internal clock (derived from the external OCXO) when it has detected a small difference. Also realize that the 1PPS signal can have a jitter somewhere between 20 to 40nS depending on the GPS module, the antenna, your place on the globe and of course the constellation that is available to you. That's a seperate chapter all by itself.
To test the stability of the hardware as it is, I connected the same 10MHz from my GPSDO to the input of the counter, and also used the same 10MHz as the external OCXO input. The two signals are then in sync, so the display should only show residual noise and other self induced artifacts. The result was very good I thought. I will do it again when I have more of the building blocks ready.
Using a GPSDO as the external clock
To see if we can further improve the current setup, I think that the best possible solution is of course, to try a true GPS disciplined external OCXO for the counter.
Yes, this means I'm going to be using a GPSDO clocked counter to measure a GPSDO. Sounds funny, but that's what I'm going to try to do.
There are many ways to create a GPSDO circuit, and I can easily use the one I already have to start with or I can try a very different approach, of which I've found a few that are worth trying as well.
To reduce the amount of variables, I'm going to try a mini version of the Lars Walenius GPSDO for this counter first. I know it well enough by now to get up to speed quickly. Over the years since I've had my GPSDO, I kept scanning for improvements and developments every now and then.
Here is the link to my (long) posting for that project: GPSDO
While going through this counter adventure, I want to try out a few interesting possible improvements. These improvements will most likely not make it in the really minimalistic-version of the Lars GPSDO that I want to build for the counter.
One of the interesting improvements I came across is a design that caught my interest. In my GPSDO, Lars designed the OCXO frequency adjustment by using a 16-bit DAC constructed out of two 8-bit PWM channels, one hi, one lo. In my own version of his design, I used an improvement that a user recommended for this circuit. The idea is to use a couple of 74HC14 Schmitt Triggers that are powered by a stable reference voltage, with the goal to seperate the noisy Arduino environment from the DAC output and create a very clean and stable DC voltage to tune (disipline) the OCXO.
This newer find also used the same 74HC14's but in a very special way. I wanted to try and test this circuit for a possible later implementation into a new GPSDO circuit, so I build it on a breadboard, and used it to tune the OCXO for the counter.
Here is the website where I found the information: dual-pwm-circuit
Initially, to test the new DAC circuit, and drive the 16-bit "DAC" on the breadboard, I use an Arduino Nano and stripped most of the code from the GPSDO out and only used the minimum code to allow me to set the 16-bit counter value by hand and send it to the new DAC circuit. This worked very well, but is too sensitive for stable use while still in the breadboard version and without a voltage reference, but the new circuit has a lot of promise.
Here is the test setup I was working with to try it all out:
From top to bottom, you see the Fmeter-G431 counter board with the LCD. On the top side of the board is the interface to the Segger J-link. It goes to a little adapter board that connects to the big ribbon cable that goes to the probe. On the left of the board is the connector that supplies power, coming from my Lab supply. It also has the Rx/Tx signals that go to a Serial TTL to USB convertor (3.3V!) that goes to my Laptop. I took the MAX232 out as I mentioned earlier. I use PuTTY to look at the reports and program the options for the counter.
I modified the counter board with SMA connectors so I could feed it with clean signals from my GPSDO supply the 1PPS and also the external OCXO. To the left is the 1PPS input coming from my GPSDO. Top right is the OCXO input, and below it the 10MHz from my GPSDO, which is what we measure. Below it is the LCD display, this time showing 11 decimal digits when it shows 9.999 MHz etc. and 10 digits when it shows 10.0000 etc. MHz.
The breadboard below it has the Arduino Nano and more to the right is the new 74HC14 based DAC construction. At the high-impedance output is an Opamp buffer circuit and that goes to the f-adjust pin of the dead-bug CTI OCXO. The trimmer you see on top of the OCXO is not used at the moment.
When I took the picture, the OCXO was not exactly tuned to that of the GPSDO, which is why you see a few milliHerz of difference.
The new "DAC" circuit on my breadboard is not powered from a reference quality voltage, but is fed by the same 5V supply that powers the Nano and the OCXO. The 5V is pretty clean because it's coming from a second channel of my Lab supply, but it is not the same. (that has changed now)
While testing the DAC setting with the new circuit, I was amazed how easy it was to precisely tune the OCXO to the GPSDO. The granularity of the DAC is in steps of 60 microVolts (4V/65535) and it is so much easier to adjust than by using the mechanical trimmer. Even with a 20 turn trimmer range of +/- 1mHz it is way too sensitive. Merely touching it already has an effect. I could make that adjustment better, but I'm not going to use it anyway, it's only there for testing.
GPSDO Controller
The missing part is the controller board for the OCXO.
I decided to use the GPSDO I already know pretty well, the Lars Walenius version, with some of my modifications. The original project is described on my Blog. This particular circuit only has the essentials, but I also wanted to try another new feature.
Instead of the 74HC4046 that Lars used to create the pulse that is representing the difference in the two phases of the 1PPS and the 10MHz (Actually a divided down 1MHz), I am using a dual 74HC74 flip-flop, that supposedly does the same thing. In the schematic, this is U1A and U1B.
This idea comes from a country fellow, Erik Kaashoek. More information on his github
When the board came in, I tried the 7474 idea from Erik, and I tried all the 7474 technologies I had. The 7474, the 74F74, the 74LS74, the 74AHC74, and the 74HC74 also from a few different manufactures and they all worked flawlessly. I decided to use the 74HC74.
The only notable omissions from the Lars' design are the two temperature sensors, I don't plan to use them, and if I do need one or the other, they are easily added.
Note that when you want to use this schematic, you have to apply the modification that I made to Lars' sketch, that uses the D10 port to drop the voltage from the C7 capacitor, after reading it with ADC0, through R7 to GND. He used a 10M resistor to GND to bleed the voltage, but I wanted to eliminate the 10M value due to its inherent Johnson noise and make sure the ADC measures at the real top of the voltage, not already loaded by the 10M. As a quick and easy elimination, you can replace R7 with a 10M, and set port D10 to a low during start-up, or solder it to GND.
UPDATE & WARNING:
The 7474 circuit is NOT working the same as a 4046. While experimenting with another method to do a phase difference measurement, I prototyped both the 4046 and the 7474 circuit on a breadboard, and fed them with my main GPSDO 10Mhz and the 1PPS signals. Now granted, the 10MHz is not used in the GPSDO, only a 1MHz signal, but still.
Above is a normal situation. CH2 (blue) is the output from a regular 74AC4046. CH1 (yellow) is the output from the SN74AHC74 circuit. The signal from the 4046 is lagging 10ns behind that of the 4046 (must be a propagation delay), but that is not an issue. The point is that the pulse durations, which reflect the phase difference should be the same, and they basically are.
While making some measurements I saw that there are sometimes weird results. Have a look here:
Most of the time, the two circuits are in agreement, but every once in a while (several times per minute), there is one, sometimes up to several pulses where we have an incorrect measurement. Someone on the EEVblog, where I reported this behavior, commented that this is probably due to the 10MHz=50ns pulse width. If it's a tad more, the pulse shifts, and causes the glitch. The original designer I asked reported that he has no clue.
Due to the saw-tooth behavior of the 1PPS from the NEO, there are actually about 4 to 9 steps (one per second) of drift within the saw-tooth cycle. Both circuits behave the same. However, when the 7474 circuit is off, and produces the glitch of a few ns, it can be from one to several succesive cycles within the saw-tooth cycle and then it resets and is the same as the 4046 again.
I tried all technologies I have, and even from different manufacturers, like the SN74HC74, the 74LS74 and even a 74F74, and lastly even a "normal and old" SN7474NV. All have this bad behavior at 10MHz signals.
Here is the SN74F74 also showing the problem.
This F (although F=fast) technology is still much slower than the modern AHC and HC technologies and shows a glitch with a lower amplitude, which is why I missed it earlier when my trigger was set higher-up.
The 74ACH74 circuit seems to work fine with 1MHz inputs, and others have not reported any issues with those speeds, so it's safe to use this circuit as a replavement.
The controller PCB has arrived and I populated it and verified the various signals. I then loaded the Arduino sketch and hooked up the PWM connections from the controller to the breadboard circuit I build earlier.
After verifying that everything functioned, I calculated the gain (28) and saved that and the TC setting (4) to the EEPROM and started to Run. It didn't take long, only a few minutes, to get a Lock because the OCXO was already warmed-up and a TC of 4 is the lowest setting. The Lock is also shown by the red LED trhat floating on the left side of the PCB. Success!
Now I need to build the OCXO PCB version that you see in the foreground and add that.
Using the OCXO and new DAC controller
Here is my design using the new DAC circuit:
The output of the dual PWM DAC, is taken from C7 but that point has a very high impedance. So high that when I clip my 10 GOhm input impedance DMM to the output, the voltage drops. This is why I use an Opamp to buffer the DAC output and drive the OCXO. The two resistors on the output, R12 and R13 are there so I can reduce the full 4V swing of the DAC to a much smaller voltage change for the OCXO. This increases the sensitivity and gain for the PID loop and is what I already do on my "real" GPSDO. It reduces the V/bit resolution of the DAC. R9 and R10 need to be tuned for the OCXO you're going to use. They need to set the center of the trimmer to the sweet spot of the OCXO, and that voltage is different for every one of them. After tuning the circuit and when the OCXO is stable, you can replace the trimmer circuit with low tempco resistors for R12 and R13, and only use the jumper on positions 3 and 2. At a minimum a tempco of 50, better is 20 or even lower, unless you can keep the temperature of the whole setup very stable.
Due to an omission from my part, I did not include SMD pads for R15 on the PCB. This resistor can be added in the circuit by soldering it between pin 3 and 2 of the J3 jumper connections, and bridge 2 and 1 together. Start out without this resistor though.
The jumper is there so I can easily switch from a trimmer adjustment and back to the Arduino controlled DAC or all three positions during the burn-in and tuning phase. This is basically the same design I show for the other OCXO adjustment a little above.
Here is a picture of the controller and the OCXO/DAC board together.
Note that as a first power-up, I did not populate the trimmer section on the OCXO board.
Nest step is to connect it all to the counter and start to use the new circuit as the external clock.
Hooked it all up and tried from a cold start. It took 91 seconds for a lock with a TC of 4. The counter no longer needs the 1PPS signal so it's now running from the GPSDO generated clock. To remind you, the 1PPS that I use for the counter GPSDO is the same as is used for the "big" GPSDO that I'm measuring the 10MHz output from. This is a NEO 8MT, which should have better stationary stability for Timing measurements.
Now I need to track the counter output for a longer period.
First of all, I noticed that the counter was reading about 160ppb too high. When I wanted to compensate for that in the counter software, I saw that there was already a factor of 160 in. Duh! After some experimenting I found that with zero compendation, the counter was about 10ppb too high, so I entered a -10ppb compensation.
This is the result still with a TC of 4, meaning that the OCXO is adjusted with an unfiltered correction. The correction is jittering due to the up to 20nS (sawtooth) jitter of the 1PPS. In effect, this is the short-term GPS performance. To get the best out of the OCXO, we need to filter (dampen) the 1PPS jitter with a longer time factor.
Here is the counter output at a GPSDO TC of 256. This is a kind of middle of the road value, that is OK to use when there are no other GPSDO software compensations active, and the OCXO is "flapping in the breeze".
The counter is now reading the 10MHz of the "real" GPSDO with a resolution of +20/-10ppb or 9 stable decimal digits.
The following two graphs show the correction of the OCXO frequency when the difference between that and the 1PPS is deemed too large by the software.
Here is the deviation in a nsec graph:
And here is the compensation for the OCXO:
The DAC value was dropped by one count to bring the difference back in check. Important is the granularity of this adjustment, which is called Gain in the Lars' software. Right now, the DAC output ranges from a few mV to the full 4V reference, which means that we have 4V/16-bit = 60 microVolt resolution. That's still way too high, so we need to lower that.
To increase the resolution, you can loosely fix the f-adjustment pin of the OCXO to the sweet spot by using clamping resistors, and then let the DAC control the sweetspot. The fighting against the sweetspot clamping will reduce the voltage swing of the DAC output, in return increasing the resolution, and that means a higher Gain for the controlling loop of the sketch.
Here is a screenshot of the DSO that is measuring both GPSDO 10MHz clocks. Blue is the "real" GPSDO, and is used to trigger. Yellow shows the counter GPSDO. There is some drift of about 40nS, the result of the different TC values of both GPSDO's and of course the temperature effects.
I'll try to see if I can improve on that differential drift.
The power supply board came in an I populated and tested it. Works fine with one, already known caveat, the LM317 that feeds the OCXO will get pretty warm during the initial warmup of the oven. After that it's fine. To keep the heat down, use a 12VDC input and do not go beyond 15VDC. This board can be used inside a metal enclosure, in which case the LM317's can be mounted (isolated) on the enclosure itself, eliminating the heatsinks for the standalone unit as I have it here.
Here is a picture of the board.
The outputs are on the bottom. From left to right, +5.1V for the counter, +5.1V for the OCXO and +8V for the Arduino/controller.
I actually made a small mistake on the layout. The mounting holes for the heatsinks are grounded, which means that I have to insulate the LM317's from the heatsink. Something I overlooked. When I publish the Gerber files, I'll fix that.
Initial setup for the OCXO/DAC
After the first functional tetst, it is time to get down to business and start to work on the DAC resolution. To start with the DAC/OCXO circuit, do not populate R12 and R13, and start without R15. Put a jumper on the 1 and 2 positions of J3 and now select the proper resistor values for R9 and R10 to make sure you can set the OCXO output to 10MHz with the trimmer about in the middle. You can now use this setting to burn-in the OCXO. When that is stable enough, you can now add the GPSDO controller and connect the DAC by putting a jumper on pin 3 and 2 of J3.
When that works to your satisfaction, you can now start to reduce the DAC swing from 0..4V to a lower range around the sweet-spot by adding R15. R15 is used to reduce the Volt/bit range of the DAC and increase the gain for the PID loop. The goal for the counter version is to get the gain in the 300-400 range. (Lars recommends 500 for the GPSDO but that's too high for the counter version. I tried it.) I actually first used a trimmer instead of R15 to try it out and when I was satisfied, I switched to using a resistor. Don't select a gain that is too high, it will hamper the startup period. I ended up using a 82K value for R15 and that resulted in a gain of 387.
With this setting you can fully tune the software and do the first runs to determine the gain and try to get a lock. Make sure that before you do that, the systems has warmed-up sufficiently.
With that done, you can now linearize the DAC range. Go to my main GPSDO blog here to see how that is done. Search for "Setting the ADC linearization parameters". In my case that resulted in a Min of 985 and a Max of 227.
Now you're ready for more testing and tuning.
After a serious amount of burn-in, and when you're happy with the setup, you can now populate R12 and R13 with low tempco resistors. To calculate the values, use the R9, RV1 and R10 values. You can now use R15 on position 3 and 2, and remove the connection to pin 1 to keep the high tempco trimmer section out of circuit. After you placed the R12 and R13 resistors, you need to go through the gain setting and linearize the DAC once more to tweak it.
Testing the Counter Version of the GPSDO
For the last several days, I have been playing with the settings of the GPSDO to make it more of a reciprocal counter version, rather than a long term frequency standard.
To that extend, I have modified the sketch to make the GPSDO get a lock faster and maintain a stable frequency output after the warm-up period for the oven. The idea is that when you want to use the counter for general purpose measurements, you power it on, and want to make a measurement fairly quickly, and do not want for several hours to get a traditional GPS lock.
I also wrote a function that would automatically increase the time constant (TC) while keeping a lock. When the difference between the 1PPS is drifting too far away, the TC is automatically reduced to keep the lock. If the lock is lost all together, the TC is reduced more dramatically and the process starts again. To get a lock quickly, I start with a TC of 4, which is the unfiltered setting and progressively increase the TC while trying to keep the lock. Lars used a lock formula that would only give a lock when the difference with the 1PPS is less than +/- 100 ns for a period of 5 x the TC. The 5 is the lockPPSfactor. I changed that to a value of 2 because we're less interested in a long term result.
Here is a run while using the automatic TC setting where I disturbed the system:
As you can see, the TC is rapidly and progressively increasing from 4 to the maximum I set at 250. (the horizontal scale is in seconds) I then disturbed the system. It looks dramatic but it actually never lost the lock but started the process to first rapidly lower the TC and then to increase the TC again. It then was about to loose the lock at 250 again, so it once more lowered the TC in steps, and then recovered back to the maximum at 250. I did this for TC settings between 100 and 800. That takes a lot of time...
After running many tests, I also decided to dynamically change the lockPPSfactor. I now start with 3 and progessively reduce it to 1 with higher TC values and go down when the ns is drifting out of control or when the lock has been lost.
During the testing, I tried several TC setting that would give me the fastest lock results, and the most optimum filtering/damping, which is depending on the TC value. A low TC adjusts the OCXO rapidly, but it will show signs of the 1PPS drift and saw-tooth effects. A larger TC will increase the filtering and dampens the swings, but then the PID loop will be more sluggish to react.
Right now I'm using a TC of 250. With that, the DSO shows a drift between both GPSDO's of about 20-30ns over quite a long period and I have counter readings of the main GPSDO with stable 10+ digits.
The sketch will be posted on my Github when I'm done.
Finding the optimum TC
After I replaced the 7474 with the 4046, I ran a test to find the optimum TC for the OCXO.
Here is that result in a Timelab plot:
This shows that the OCXO can be used with a TC of about 300 maximum. This point is at the bottom of the curve, where the down going graph intersects with the going back up graph. After trying a few higher TC's, my wet-finger hunch to select a TC of 250 was right.
A dedicated GPSDO for the Counter
The next step was to design a dedicated minimum GPSDO board that will be specifically designed for this reciprocal counter use. It is also time to put everything in an enclosure to reduce the temperature/draf effects. It may also help to pre-heat the inside of the enclosure to get a faster stabilization after a cold start. We'll see...
Here is the schematic diagram that I ended-up with:
This is really a minimum GPSDO circuit based on the Lars Walenius design with some of my own and other contributor enhancements. This is a simplified combination of the other two boards that I used to experiment with. The idea is that this design can be used as the external clock for any counter. All it needs is a 1PPS input from a GPS system. I have used THT components just because I have them in stock. If a smaller size board is required, you can easily change the components to all SMD.
The board needs two power inputs, an 8V-100mA for the Ardjuino Nano, and a 5V-700mA for the OCXO. The 8V supply goes straight to the Nano, and I let it use it's own 5V regulator to supply the Nano board. The 8V is also used with a separate 5V regulator, to supply the other components with power and create some power and noise separation. I decided to eliminate the 4V reference chip, for this purpose, it is not really needed. We'll see.
Because I need at least three 74HC14 gates to clean the 1PPS signal and also to elevate the OCXO output to drive the 10MHz signal, I decided to use two more gates and use them to seperate the PWM outputs from the Nano. Again to create some more noise separation. This will mean a change to the script because the DAC outputs are now inverted. I have not posted the script, but for this hardware I'm using gpsdo_ctr_V365.ino.
Here are the board layouts (taken from the KiCad 3D viewer):
There is again no copper underneath the OCXO, so the board does not suck the heat away from the OCXO metal can. You can use a number of different OCXO's, because many have the same footprint. Check it out before you solder them in place though! I made the pin-holes a little larger so it's easier to fit them, and also remove them.
I have used the footprints for SMA adapters for the 1PPS and the 10MHz signals, but you can easily use a braided cable soldered to the pads to connect the board.
Here is the board in action:
I tweaked the DAC output range by populating the three resistors to get as close to a 500 gain as possible. At this little adjustment range, it is more difficult to get the sweet spot set by a DAC value of 32767 (the mid range) and also the linerarization values that will be accepted by the script.
This circuit works well, and can be used as a general purpose GPSDO or as an external clock for a (reciprocal) counter that needs high stability and precision.
Is there another even more simple GPSDO circuit we can use?
I recently found an interesting approach that I'm investigating now. It uses a more modern version of the 4046, unfortunately, apperantly the best one they use in this design, a Nexperia 74HCT7046 is discontinued and hard to get and the even more advanced 74HCT9046 is obsolete and I cannot find any stock at my prefered suppliers. I wanted to try one, but that no longer makes sense. You can still get them from a few sources, but make sure you can trust them. I ordered two of the 74HC7046, we'll see if they are genuine.
I bread-boarded the circuit that I found here:
http://www.knietzsch.com/amateur_radio/ham_index_s-GPSDO.htmhttps://www.dl4zao.de/projekte/index.html#a1968
I tried a couple of things and I'm impressed with how this works, especially on a bread-board.
Here is what you see: The left circuit on the bread-board is a 74HC4046, to the right of it, the equivalent circuit based on a 74AHC74, and the two chips to the right are two 74AHC390 decade counters. I'm only using one of the counters at the moment to use the 100KHz. Just above the bread-board is the Isotemp OCXO.
Mini GPSDO
And here is the schematic of this very simple circuit:
Let me explain. The idea is that you use a NEO GPS receiver and program it to output a 1KHz, 10KHz or 100KHz signal, instead of the 1PPS. The 1PPS has the well known jitter of up to 30ns, and that is due to the division of the 48MHz OCXO on the NEO board. When you divide by a factor that is divisible by 48, you get clean signals. The 1, 10 and 100KHz is used for that reason.
Testing it without a NEO
While I was waiting for an additional GPS antenna, I wanted to test it out without a NEO first. I used my frequency generator that is fed by my GPSDO, and I have set it to a 1, 10 or 100KHz output.
I tried both the 1KHz and the 100KHz option and settled on the 100KHz because I did not see a lot of change. Using 100KHz saves one 390 counter.
The Isotemp OCXO 10 Mhz output is divided down to 100KHz by the 390 counter, and both signals are fed into the 4046 to do the phase comparison. The result is taken from the PC1 output, and that produces the well known phase difference that is used in all the GPSDO circuits I have worked with. This pulse is filtered to get a DC voltage that goes to the frequency adjust pin of the OCXO. The DC voltage goes up and down with the phase pulse and will eventually setttle when both signals are equal in phase, hence a lock.
This is the resulting phase drift of my GPSDO 10MHz and the Isotech OCXO in the above circuit setting over about an hour:
If you look up a bit in the blog, you see that the "real" GPSDO has about 20ns drift, this one about 30ns. Still very respectable.
NOTE
My DSO was a little confused and does not display a correct frequency in the upper right corner, but rest assured, it is a precision 10MHz down to the microHz. I saw more frequency errors so I ended-up rebooting the DSO and that fixed it. Go figure.
I build a bit more permanent circuit on protoboard to see if I can get even better results.
BTW, the designers used the 7046 or the 9046 variants because they use the "lock" pin this variants have. This is not a very good indicator for a lock, so they use software to make it a more reliable indicator. They also use the Arduino Nano to setup the NEO, and read the NMEA messages.
I also experimented with using the PC2 output of the 4046, but the system kept hunting and did not settle soon enough. The PC1 output settles much faster.
Unfortunately, the protoboard version did not bring the improvements I was hoping for. After a cold-start, the system is very quickly getting close to a lock, but then hunts around the phase lock point a while.
Here you can see the relatively fast ramping up to the phase lock point, but then it starts to hunt. Every once in a while, there is a large glitch on the frequency control voltage, the lock is lost and the process starts again. This may be due to the fact that this OCXO has not been used a lot, since I used the CTI in the other tests.
The Bliley OCXO I'm using in my main GPSDO has a tendency to create glitches on the output as well. It is extremely stable, by far the best of all the OCXO's I've tried and used, but still there are jumps in the DAC value, the result of a frequency output glitch in the OCXO.
I'm unsure at the moment which is which, so I need to spend a little bit more time watching this circuit behave.
The good news is that the controlling loop is pretty quickly responding and eventually, everything is stable again. As with the other circuit, this circuit is also flopping in the breeze, and seems to be sensitive to room temperature changes, as all the other circuits I tried. No change there..
The regulating voltage swings are in the microvolts so could benefit from some power enhancements, and it needs to be in an enclosure of sorts. I think it could also benefit from a seperate power supply for the controlling chips, apart from the OCXO like I have on the other GPSDO. I think I'm going to try that even though it will mean a few additions to the circuit.
Testing it with a NEO
The two NEO versions I have, a M8N and a 6M do not work with the supplied antennas. When the NEO's are on my desk, I don't have a good enough reception to see any satellites.
I had to order an additional antenna, so I could try my NEO M8N. Unfortunately, I found out that I cannot update the firmware on this fake NEO so it cannot support the Galileo constellation. More importantly, I also discovered that although I can change the 1PPS output setting in u-center, the output does not change.
I have another NEO 6M based board, but that does not have a micro-USB, nor a SMA antenna adapter. I had to modify the board by soldering a small shielded cable with an SMA adapter to the antenna connection on the board so I could connect my antenna. And that works. I can also adjust the timing pulse to 100KHz, 10KHz, or 1KHz.
The other good news is that when I save the configuration to the on-board i2c-EEPROM, (a 24C32) it actually stores the settings. Powering the NEO off, and turning it back on works. It started up with the configuration I set it to, and the 100KHz pulse was there. That is very good news, because I will not need an Arduino Nano to set it up after it is powered on. I wonder why the original designers didn't use this feature? Well, they also want access to the NMEA messages, but there is no need to set it up at every power-on.
So how does this contraption finally work in the "real" configuration:
First of all, the GPS unit had been on for a while, so it already had a stable sattelite lock.
However, as you can see, the mini-GPSDO only needed a few minutes after power-up to get a stable lock, although with a tiny bit of hunting around. Mind you, this was still during the warm-up period of the OCXO! The DMM display did not start at the very beginning, because that would have ruined the resolution on the display. I waited until is was in the ball park before I started to record.
On my DSO, where I look at the big-GPSDO and the output of the mini-GPSDO, I can visually see the waveform drift a little, somewhere around 20ns for several minutes. Sometimes there is a glitch.
But it quickly gets back to a stable display as you can see. The controlling voltage level changes around the sweet-spot to adjust the OCXO are very small, and also depend on the supply voltage. Right now I'm tapping the 5V for the two IC's directly from the OCXO where I connect to my lab PS. I will change that and use my dedicated power supply that has two different regulators for the OCXO and the GPSDO.
I'm now using my special GPSDO supply so we have better seperation between the OCXO and the GPSDO logic. The NEO is still powered through a USB serial convertor that provides the 3V3 supply for the NEO. This is also not the most stable supply. To see how far I can take this further, I ordered a new NEO-6M board that has an SMA adapter for the antenna, and it also has a regulator that allows you to supply 5V to it. The resulting signals are still at the 3V3 level, but I think that the 74HC4046 can easily handle that.
The jitter/drift of the OCXO output over a long time is still up to 40ns, compared to my main GPSDO, but the source of the jitter is still unclear to me. The 100KHz signal from the NEO should not have any master clock related adjustment jitter, but the adjustment voltage is changing too.
I am ageing an Oscilloquartz OCXO already for a few days that I just liberated from the PCB it came with. The PCB was pretty much a piece hacked out of the instrument it was in, so it needs some tender loving care. This double-ovenized OCXO should have a very stable output, maybe not at a precise 10MHz, but it should not jitter. I'll see if I can use that so investigate what the real source of the jitter/drift is. (I did, but I need to do some more work)
I'm intrigued by this simpel solution, so I also started to design a PCB. Here is the circuit diagram I'm going to use.
Before I continue, I want to play with the 74HC4046 some more and see if I can concoct the equivalent of the lock detector circuit that is on the 74HC7046 chip. If that works, I'll continue with this circuit, otherwise I'm going to try to switch back to the 74HC74 circuit.
We'll when testing this lock indicator circuit, I discovered something else. Because I am using the Isotemp OCXO in the dedicated counter GPSDO, I switched to the CTI for this mini GPSDO. When I powered it up, it would not lock at all, it kept searching (voltage swings from minimum to maximum) without stabilizing. The original designers used a jumper to select between the PC1 output, that I had been using, and the PC2. When I switched to using the PC2 output, it locked almost right away, meaning that the hunting for a mid-point is very gradual
When I looked at the so called Lock Indicator on pin 1, it is apperant why the designers had to use software to make sense of this indicator. For this application, it is pretty much useless because the resulting output signal is almost immidiately stable showing a lock, but the lock indicator cannot show small variations.
I will test it some more when the 74HC7046 arrives, but I don't have very high expectations.
The next step was to see if we can use the 74AHC74 circuit for both OCXO's. Well, that answer is a resounding no. The circuit is very unruly around the sweet spot and never settles down. I tried the positive and negative outputs to no avail. The problem is that around the sweetspot, the output of the FF is at exactly at the half point of the 100KHz cycle and collapses to either a high or a low and that causes the frequency adjustment to swing without settling down. The output of the 4046 stays a 100KHz pulse so the integrator does not get janked as much. My explanation that it works in Lars' GPSDO is because I think it has so much filtering that this effect does not show up. Well, at least I tried.
Here's another start-up sequence, looking at the frequency adjustment voltage. It only takes about 3 minutes for the OCXO to get tuned to the GPS signal.
Nice and very promising...
There is still more to come...
Is that it?
This counter design has quite a bit of potential, but it will still not be good enough to approach 12 digits. For that kind of resolution and precision, you'll need an even faster processor and timers and also an even better phase measurement system. There are dedicated chips that can help you do that, the TDC7200 and the even better AS6501. Michael has build counters with these chips, one that is even using two of them in tandem, but details are sparse and he has not divulged all the details at this moment.
One of those, the FMeter-407-TDC is a potential candidate. Unfortunately, the STM32 chips that are needed for this counter are completely unavailable at the moment. That project will have to wait.
That leaves me with trying to get the most out of the current version, and learn more about it.
Enough to do and learn...
Enjoy!
If you like what you see, please support me by buying me a coffee: https://www.buymeacoffee.com/M9ouLVXBdw
