Yet another DIY GPSDO - yes, another one

[AndrewBCN]

...
Raison d'etre of GPSDSO is to provide high stability frequency source.

I agree of course, since that's exactly what I wrote. 

And relevant performance parameters are only related to that.
...

That's tautological on your part. You are defining "performance" as stability, and then you are saying that only stability parameters are related to "performance".
 

But cool, that's your personal point of view and of course I am not going to contradict you.

I would just ask you to think about the job of a GPSDO designer. If she/he thinks that the sole definition of performance of a GPSDO is its stability, then she/he has very, very little work to do: just buy the most expensive rubidium oscillator the budget allows, wire it to the most expensive latest generation GPS receiver the budget allows, and slap the same old PID control loop that a retired engineer designed 20 years ago. Pronto, mission accomplished.
However, I would point out that such a "high performance" GPSDO design, if it existed, would not make any sense, since the cost of such a design would easily exceed the cost of a chip scale atomic clock, which has inherently better stability (hence better "performance") than any imaginable rubidium GPSDO.
Equating performance to just and only stability in a GPSDO is a self-defeating proposition.
Wikipedia page for Chip Scale Atomic Clock (CSAC):
https://en.wikipedia.org/wiki/Chip-scale_atomic_clock

EDIT: note that Carsten has posted below a link to a superb lab instrument GPSDO, the SRS FS740, designed in the late 2000's, and offered with a TCXO with optional OCXO or rubidium oscillators. Obviously, the main point of this $3,195 lab instrument GPSDO is not the type of oscillator used, but the amazing functionality provided. https://www.thinksrs.com/products/fs740.html

[thinkfat]

The lure of CSACs is not their stability, actually their performance may well be worse than the typical run-of-the-mill Rb reference. For example, the commercial CSAC from Microsemi mentioned in the Wikipedia article is quoted to have "<1E-11 @1000s ADEV", which not really remarkable. Any cheap surplus Rb can do that, if it's not broken. The big advantage is the size and power consumption, which brings atomic clock type stability to many more applications than what is possible with using the "classic" physics package.

Does it make sense to use a classic Rb (or CSAC) in a GPSDO? Perhaps. But then only if your application absolutely needs it for hold-over performance. But if you're not size constrained, or energy constrained, just use a surplus LPRO-101, hook it up to some control circuit and you have your "ultimate GPSDO" for maybe a couple 100€.

But this type of oscillator brings a whole new set of challenges, it's not enough to hook up a good GPS receiver. A Rb is unbelievably "heavy". It just plows along like a train and you really have to work hard to make it change frequency. It's like driving a truck and only being allowed to turn the steering wheel by 1 degree in each direction. If you want to exploit its stability in a GPSDO, other factors like temperature, air pressure, magnetic fields etc. become much more important than the quality of the GNSS. So in most cases it doesn't make sense. But it sure is fun. I made one once and I was very pleased with the performance. Even while it was locked to GNSS, it was usable as a reference to qualify other, "lesser" GPSDOs.

[AndrewBCN]

Hi,

The next version of the firmware for the STM32 GPSDO (due in mid-May) will come with a new architecture that puts the control loop algorithms in separate files / modules and a new command that allows switching "on the fly" between the different control loops. And the first four control loop algorithms / modules will be:

• The very crude FLL control algorithm that was being used since the early days of the project. It's crude, it does not react well to small disturbances, it reacts very slowly, etc ... but it works (barely, and probably by chance rather than by design).
• A proper PID-based FLL control algorithm.
• A proper PID-based PLL algorithm.
• A "hybrid" PID based FLL+PLL algorithm where each error measurement contributes a weighted response.

And since I am thinking outside the box I would like until the end of the year to work out how a neural network could be used for the STM32 GPSDO control loop, based on this NN library: https://github.com/GiorgosXou/NeuralNetworks

So if you are confident in your C/C++ programming talents and understanding of how GPSDOs work, think about programming your own GPSDO control loop algorithm for the STM32 GPSDO! 

[AndrewBCN]

...
Does it make sense to use a classic Rb (or CSAC) in a GPSDO? Perhaps. But then only if your application absolutely needs it for hold-over performance. But if you're not size constrained, or energy constrained, just use a surplus LPRO-101, hook it up to some control circuit and you have your "ultimate GPSDO" for maybe a couple 100€.
...

Apparently GPSDO manufacturers think it does not make sense to use a rubidium oscillator in any new GPSDO design. And obviously they can't rely on surplus LPRO-101s. Btw Microsemi has a single GPSDO in their current product line (not sure whether they think it's an "ultimate GPSDO") and it is based on their CSAC. They also bought the Vectron line of GPSDOs, and these are all based on OCXOs.
https://www.microsemi.com/product-directory/timing-synchronization/3826-gnss-disciplined-oscillators-gnssdo

Disclaimer: I have zero ties of any kind with Microsemi or any other GPSDO manufacturer.

With all this we are getting very much off-topic in this thread,  something I will try to avoid in all my future posts.

[Carsten]

Apparently GPSDO manufacturers think it does not make sense to use a rubidium oscillator in any new GPSDO design.

Sorry for another off-topic comment Stanford Research Systems (SRS) sells the FS740, which is a GNSSDO with an optional Rubidium standard (SRS PRS10) as integrated high-stability source. I use these at work. While bulky, heavy, power hungry, and slow to settle after power on, they work like a charm in a lab environment. However, these are about two orders of magnitude more expensive than your entire BOM cost. Surely not a tool for a hobby project, but an example of a relatively new GNSSDO using a Rubidium timebase.

[AndrewBCN]

Actually there is a very interesting chart on the SRS website that demonstrates exactly some of my points above. 



One can notice that whatever type of oscillator is used, the stability of the GPSDO is bound by the intrinsic stability of the oscillator used until it intersects the GPS PPS Allan deviation, and by the GPS PPS stability after that point - just like any other GPSDO, including the Lars' DIY GPSDO or the STM32 GPSDO.

Also note that the design of the SRS FS740 (late 2000's) predates the commercialization of the CSAC (2011).

[AndrewBCN]

Hi,

So we have seen in some of my previous recent posts that GPSDOs work by "disciplining" a local oscillator using a GPS PPS (which is in fact a "proxy" for the atomic clocks on GNSS satellites). The "disciplining" is done by a closed (feedback) control loop, which can be analog or digital, and implemented in hardware or software. In the STM32 GPSDO the control loop is obviously implemented in software. If the control loop is properly programmed, it should "discipline" the oscillator as "gently" as possible until the Allan deviation curve for the oscillator intersects the GPS PPS Allan deviation slope, and then carefully synchronize the oscillator to the GPS PPS for any larger taus. For the $10 OCXOs we are using, this "intersection" usually occurs before or at around the tau=1,000s point.

As mentioned before, future versions of the firmware will allow changing the control loop algorithm "on the fly", and I will be moving the control algorithms into a separate file to make it simpler to focus on their programming. And anybody can write their own code for the control loop algorithm(s) and test it(them) on the STM32 GPSDO hardware. The STM32 GPSDO "experimentation platform" is 100% Open Source hardware and software, so you can take it in any direction you want. When testing the STM32 GPSDO and new control loop algorithms, the firmware already supports reporting in tab-delimited format, suitable for input into e.g. spreadsheet programs for further processing and charting.

For example:
a) You can program a "random walk" algorithm that will "disturb" the Vctl value at random intervals and see how that affects the OCXO stability, as measured on an Allan Deviation vs tau chart.
b) You can program a genetic algorithm to determine near-optimal parameters for a PID controller. See for example the video on YouTube by Steve Brunton about this.
c) etc.

For PID control loops, I strongly suggest avoiding "reinventing the wheel" and using this Arduino PID library by Brett Beauregard: https://www.arduino.cc/reference/en/libraries/pid/

Likewise for neural network / machine learning algorithms there is this Arduino NeuralNetwork library by George Chousos: https://www.arduino.cc/reference/en/libraries/neuralnetwork/

With this post I am concluding my "Back to the basics" or "GPSDO principles" ramblings and I will now focus on matters directly related to the STM32 GPSDO hardware and software.

[cdev]

A neural network that incorporates inputs from environmental sensors, such as temperature and pressure and humidity  would be helpful.

[Carsten]

Also note that the design of the SRS FS740 (late 2000's) predates the commercialization of the CSAC (2011).

Where'd you get that number? The user manual was released early 2017 according to its revision history. And when I was first playing around with the James Miller GPSDO and SRS FS725 in early 2016 the FS740 was not around, as far as I recall.

Also, just like thinkfat pointed out above, in terms of ADEV neither the SA.45s CSAC nor the MAC-SA5X can compete with full-blown Rubidium standards like the PRS10 or the LPRO-101. For relevant tau > 1000 s the PRS and LPRO are putting the CSAC and MAC to shame. If you go for a GNSS-locked Rubidium, you likely do that for holdover performance, and tau < 1000 s is irrelevant regarding holdover.

A neural network that incorporates inputs from environmental sensors, such as temperature and pressure and humidity  would be helpful.

Presumably, hermetically sealed OCXOs are supposed to be indifferent to atmospheric pressure and humidity. However, I'm curious whether you could still correlate such environmental sensor values with OCXO drift.

[AndrewBCN]

...
Where'd you get that number?
...

Check the schematic on page 222 of the User Manual. It is dated February 15, 2005 ; similarly, the power supply schematic on page 217 is dated February 9, 2011. This is user documentation that usually follows the initial product design by at least 2 to 3 years, if not longer. So clearly, the SRS FS740 is a superb lab instrument, but its design and development predate the commercial availability of the first CSACs in 2011.

And please... could we get back on topic?

[Carsten]

Check the schematic on page 222 of the User Manual. It is dated February 15, 2005 ; similarly, the power supply schematic on page 217 is dated February 9, 2011. This is user documentation that usually follows the initial product design by at least 2 to 3 years, if not longer. So clearly, the SRS FS740 is a superb lab instrument, but its design and development predate the commercial availability of the first CSACs in 2011.

The February 2005 date is the schematic of the interface for the PRS10 Rubidium standard. The PRS10 is pretty old, so the interface schematic was likely copied from sth. that predates the FS740. Note that the page layout differs from the remaing schematics. The power supply schematic (date February 2011) was likely also duplicated from another product (why redesign sth. that has proven to work). The remaining schematics' dates (everything that would have to be designed from scratch for a new product) are from July 2014 or later. I highly doubt it took them 12+ years from beginning of development to release.
The CSAC was likely available when the FS740 was designed, but why would SRS
a) pick a part with inferior long-term stability and
b) pick a part from an external supplier if they manufacture an alternative in-house.

And please... could we get back on topic?

Sorry. Absolutely. Getting back on topic now:

How have you measured the resolution of your hardware implementation of Lars' TIC?

I'm actually curious about that. You wrote that instead of the 1 ns resolution claimed by Lars it is actually only 25~30 ns. How did you come to that conclusion?

[nealix]

GPSDO working fine with 1.8 inch ST7735 LCD display module, SPI interface.
Thanks to help from Badwater Frank, I was able to refine the display to my choices,
and add more comments to Andre's v0.06b code, and PM email it back to him.

Please don't bother AndrewBCN for help with this, since he does not yet have one of these displays.
I am happy to share if anyone else has trouble getting it going.   Here is the screen after ~3 hours of up-time;



This was a China eBay special, but is essentially the same as the Adafruit 1.8 inch ST7735 color LCD with SPI interface.
Regardless of where you buy it, you just want one with the 8-pin interface and the ST7735 controller chip.

Even though the current V0.06b codebase is a simple FLL based GPSDO, and not yet a PLL design, I must say that for casual home lab
and home radio use, this is more than good enough, and has a LOT fewer parts that the more complicated GPSDO's out there.
Anyway, when the PLL code and phase detector schematic changes happen later this year, it is easy enough to modify at that time.

Neal

[AndrewBCN]

Neal, that looks very, very good.  

Thanks for the improved and well commented ST7735 display code, I'll make sure to merge it by v0.06c. 

Just a few remarks about the "10,000,000.001Hz" reading on Neal's attractive STM32 GPSDO LCD color display. That translates into a peak-to-peak stability in the +/- 1E-10 range in the tau=1000s range which is more or less where one can expect a $10 (used) OCXO to be, and right around the point where the control loop "gently" regulates this stability using the PPS from the GPS receiver (pay attention to the "uf-" in the display). In other words, despite the very simple and primitive control loop algorithm, Neal's STM32 GPSDO build is behaving exactly as it should. 

No "magic trick" exists that would make an STM32 GPSDO have any better stability (or "performance" as some would call it) with the same choice of oscillator and GPS receiver, and spending $250 on a "better" GPS receiver module (e.g. the u-blox ZED-F9T) or $500 on a used rubidium oscillator - if you can find one that actually works for around that price - would bring only marginal improvements in stability. 

So at this stage we can definitely answer Neal's question from two weeks ago when he still didn't have his STM32 GPSDO up and running, about whether he would need a $300,000 caesium atomic clock to measure the performance of his $50 STM32 GPSDO:

- Neal, no you don't, you can save that money for a nice dinner with your family! 

[AndrewBCN]

A code snippet listing the various GPSDO control loop algorithms. Right now the selection is done by using a switch statement that calls one of the 10 possible algorithms. This is not elegant at all, an elegant solution would be to put each control algorithm in an object of class "control loop algorithm" and select the object, but again: too many ideas, too little time. 

Code: [Select]

  // algorithm selector function
  uint16_t adjustVctlPWM(uint16_t previous_PWM_output, uint32_t timer, uint8_t algorithm_no);
  // up to 10 different control loop algorithms, in order from 0 to 9
  // 0 - primitive, very simple control loop
  uint16_t primitive_ctl_loop(uint16_t adjusted_PWM_output, uint32_t lclppscount);
  // 1 - not a control loop, we force the OCXO to drift slowly and regularly
  uint16_t forced_drift_Vctl(uint16_t adjusted_PWM_output, uint32_t lclppscount);
  // 2 - not a control loop, we force the OCXO to "jitter" randomly
  uint16_t random_walk_Vctl(uint16_t adjusted_PWM_output, uint32_t lclppscount);
  // 3 - FLL PID control loop, coefficients set manually
  // 4 - PLL PI (not PID) control loop, coefficients set manually (similar to Lars')
  // 5 - PLL PID control loop, coefficients set manually
  // 6 - FLL PID control loop, genetic algorithm used to find near-optimal coefficients
  // 7 - PLL PID control loop, genetic algorithm used to find near-optimal coefficients
  // 8 - FLL + PLL "hybrid" PID control loop, weights and coefficients set manually
  // 9 - Neural network MLP driven control loop
I ended up already writing the "forced drift" and "random walk" algorithms, these are just out of curiosity and for testing purposes, and can be replaced with more useful control loop algorithms at any time. The "primitive, very simple" control loop algorithm is the one we have now, unchanged.

[AndrewBCN]

Not a release yet, this is strictly for the adventurous. Read the WARNING.txt file!

Anyway, this new firmware has the control loop algorithms split in a separate .cpp file, so when you open the main file in the Arduino IDE, you will have three tabs: one for the main .ino file, one for the .cpp file, and one for the .h file.

If you want to write a new GPSDO control loop algorithm, you only need to include the new algorithm code in the .cpp file and add a few lines in the .h file. In other words, you (almost) don't have to worry about the 2,000 lines of code in the main .ino file! 

To try the different control loop algorithms: use the command LA number where number is 0 to 9. If an algorithm is not yet programmed, then trying to switch to it will return to the default algorithm (0).

Now about the control loop algorithms:
0. The primitive_ctl_loop algorithm is what I programmed months ago, and has been the only control loop algorithm until now. It somehow works. It only updates Vctl every 429 seconds. And if you suddenly open the window in a cold winter day, this might be enough to "disturb" the OCXO by + or - 0.01Hz, and you'll notice that the control algorithm reacts a bit too slowly to sudden "jumps" in frequency. The periodicity of the updates can now be changed in the source code, so if you want to try the same algorithm with updates every 100 seconds, go ahead. This is the default control loop algorithm.

1. The forced_drift_Vctl algorithm increments the PWM DAC by 1 bit every 1000 seconds. So in theory the OCXO should slowly and regularly drift up in frequency. What is the use of this? I have no idea, but it was simple and amusing to program.

2. The random_walk_Vctl algorithm randomly increments or decrements or leaves unchanged the PWM DAC every 5 seconds, with equal probabilities. This in mathematical terms is called a "random walk" (see the article on Wikipedia) and I am curious to see how it will affect the ADEV curve of the STM32 GPSDO - when I get around to plotting anything. Again, not particularly useful but it's there as a curiosity.

3 to 9: I'll program these when I have some time.  Now I need some 

[Carsten]

The display does look cool

So at this stage we can definitely answer Neal's question from two weeks ago when he still didn't have his STM32 GPSDO up and running, about whether he would need a $300,000 caesium atomic clock to measure the performance of his $50 STM32 GPSDO:

All you can do is measure the stability between two time sources, which you do for OCXO vs. NEO-M8N. The accuracy of the measurement is therefore constrained by the stability of both clock sources. Even if the resolution of your measurement may be 0.001 Hz this doesn't automatically imply that its accuracy is also 0.001 Hz.

Code: [Select]

  // 3 - FLL PID control loop, coefficients set manually
  // 4 - PLL PI (not PID) control loop, coefficients set manually (similar to Lars')
  // 5 - PLL PID control loop, coefficients set manually
  // 6 - FLL PID control loop, genetic algorithm used to find near-optimal coefficients
  // 7 - PLL PID control loop, genetic algorithm used to find near-optimal coefficients
  // 8 - FLL + PLL "hybrid" PID control loop, weights and coefficients set manually


A word of caution regarding PID control: Derivative control is not typically used for disciplining XOs. Both the NTP reference implementation (see RFC5905 Sec. 11.3 and Appendix A.5.5.6) and PTPd use PI, only. The reason behind this is that without special pre-processing derivation behaves like a high-pass filter and therefore amplifies noise, i.e., the 1PPS jitter. Also, derivative control is typically only required for inert processes that are prone to overshoot, but OCXOs typically have EFC modulation bandwidths that enable instantaneous response to EFC voltage changes.

No "magic trick" exists that would make an STM32 GPSDO have any better stability (or "performance" as some would call it) with the same choice of oscillator and GPS receiver, and spending $100 on a "better" GPS receiver module or $500 on a used rubidium oscillator - if you can find one that actually works for around that price - would bring only marginal improvements in stability. 

0. The primitive_ctl_loop algorithm is what I programmed months ago, and has been the only control loop algorithm until now. It somehow works. It only updates Vctl every 429 seconds. And if you suddenly open the window in a cold winter day, this might be enough to "disturb" the OCXO by + or - 0.01Hz, and you'll notice that the control algorithm reacts a bit too slowly to sudden "jumps" in frequency. The periodicity of the updates can now be changed in the source code, so if you want to try the same algorithm with updates every 100 seconds, go ahead. This is the default control loop algorithm.

Your example is precisely a case where a better GNSS receiver will bring more than marginal improvements. An order of magnitude decrease of 1PPS ADEV, e.g., NEO-M8N vs. ZED-F9T, will enable picking significantly shorter PLL time constants, therefore enabling faster response to external disturbances (like sudden temperature changes).

Update: Added RFC5905 and PTPd source code links as PI controller examples.

[AndrewBCN]

Hi,
So just a few among the latest developments in the firmware:

1. The source code now includes a long comment explaining how to calibrate the BMP280 sensor using the PO and AO commands:

Code: [Select]

/**********************************************************************************************************
 * A quick note about calibrating the BMP pressure / altitude sensor in two simple steps:
 * 1. Get the atmospheric pressure in hPa from the nearest weather station. Then use the PO command to
 *    adjust the reported value from the BMP280 until it matches that from the weather station.
 * 2. Get the altitude for your location from Google Maps or similar service (or the GPS value). Then use
 *    the AO command to adjust the reported value from the BMP280 until it matches that from Google Maps.
**********************************************************************************************************/
This only works with firmware version 0.06c Alpha. 

2. I have been working with Neal (nealix) to improve the integration of the ST7735 color LCD display into the hardware and software. Neal has been kind enough to repeatedly test and debug the code and the SPI bus connection to the ST7735 display, and we are reaching the point where I would say this is a fully supported feature. As usual, many thanks to badwater-Frank for pioneering this very neat feature! Check the amazing ST7735 color LCD display pictures posted above!

3. There are many changes coming in version v0.06c, but now the tentative release date is end of May / beginning of June.

Code: [Select]

// Version v0.06c:
//  - The frequency measurement algorithm now uses 8-bit information about frequency offset in a single unified
//    ring buffer rather than 64-bit counter data in multiple separate ring buffers. For the 10,000s data set,
//    this saves 70kB of RAM, and allows using the STM32F401CCU6 Black Pill variant without any firmware changes.
//  - Holdover Mode / Disciplined Mode commands implemented
//    Note that in Holdover Mode the PWM DAC value can still be set manually using the SP command
//  - Pressure Offset (PO) and Altitude Offset (AO) commands implemented
//  - picDIV synchronization control and AP (arm picDIV) command
//  - Reading TIC measuring phase difference between GPS PPS and picDIV PPS and discharge capacitor
//  - STM32F401CCU6 Black Pill (lower cost version with less RAM and flash) now fully supported
//  - TM1637 clock module can show UTC or local time. Local time to UTC time offset can be configured using TO command.
//  - Control loop algorithms in separate file and LA (Loop Algorithm) command to choose active control loop algorithm.
For the adventurous, there is an Alpha quality (very preliminary, not fully tested and possibly incomplete) v0.06c source on GitHub, not as a release, but in a separate folder under /software.

I'll be away from the project until end of May / beginning of June, but iannez can push any urgent code fixes to the repository and I feel I can count on those of you that have built the STM32 GPSDO to answer most questions related to e.g. the new ST7735 display and/or other parts of the schematic.

So, let's keep this project going full steam ahead! Thank you all for your enthusiastic support and patience!       

[THDplusN_bad]

Good day,

wow - a lot of progress on this project over the past week - thanks.   

I will set some time aside for this and I am looking forward to building a 1st bread board build over the next 10 days or so...

Cheers,

THDplusN_bad

[AndrewBCN]

Hi,
I am already planning for a few changes in the source code for firmware versions v0.07 (August / September ?) and later:
1. The various display support options and the corresponding code to be moved out of the main source file, into TFT_display.cpp and Mono_display.cpp and respective header files.
2. Monochrome (OLED) display support code will continue to use the u8g2 library.
3. TFT color display support will use the TFT_eSPI library which is optimized for STM32, instead of the rather slow Adafruit GFX library. See https://github.com/Bodmer/TFT_eSPI
4. OCXO auto-calibration will change to two increasing precision steps, with the second step optional. The first step is the one implemented right now, which uses a simple interpolation to find a Vctl that results in an OCXO frequency of 10MHz +/- 0.1Hz. This rough calibration lasts a minute or two. The second optional calibration step will last some 3 to 5 minutes and will find a Vctl that results in an OCXO frequency of 10MHz +/- 0.01Hz (i.e. +/- 1ppb). Note this corresponds to the PLL "lock acquisition" phase in classic PLL designs such as Lars' DIY GPSDO.
5. Control loop algorithms implemented as C++ objects rather than functions. I promise this will make the code simpler and easier to understand and maintain!

[trrriple]

Hey Andrew -

I've been working on a project on and off for a little bit. Essentially it's a Teensy 4.0 based GPSDO that "i think" has a similar design approach to yours. I started mine without knowing yours was there, but found it today and wanted to ask you some questions!

Here's my code, be warned it's very primitive still. https://github.com/trrriple/teensyGPSDO/blob/master/src/main.cpp

I wanted to ask you about the tuning strategy and see if it made sense to you. _tuneOsc() is my current algorithm in the code.

I am using a DAC8550 (16 bit) DAC to handle the control signal to the OXCO, with a LT1086CT-5 providing the 5v for the OXCO, and DAC vref. The Teensy 4.0 is powered from some random 3v3 LDO.

Fundamentally though, I modified the teensy freqCount library to allow an external interrupt (in this case the 1pps from the GPS) to flag the counter as ready to be read. This counter is connected to the 10 MHz output from a CTI 10 MHz OXCO. So essentially every PPS from the GPS, I read the counter and get the count value. Once stable, it is between 9999999 Hz and 10000001 Hz. I feel like though my frequency is bouncing between these too often, as is shown in the attached picture. Perhaps though I have unrealistic expectations.

Basically I was hoping you could point me in the right direction on what I need to start tweaking next! I'm out of ideas 

[thinkfat]

From the graphs I would say you are correcting too often and too heavily.

[S57UUU]

Hello Trrriple!

Seeing that designing GPSDOs is a quite popular sport here, I also started work on a couple of GPSDO designs.

My first design is very similar to yours. I'm using a MSP430 uC and PWM output, everything still in very embryonic state. I guess, you will probably beat me to the finish line with this one :-)

The problem, when using the captured value as the error signal in the PLL loop is, that with the counter running at 10MHz, we get a 100ns "blind zone". One solution I thought of, was to keep the loop on the edge between two values, the quantization error (the "sawtooth") providing the necessary dither. For example, set the VCXO so, that in 100 consecutive captures, half of the captured values will be N, and the other half N+1.  Not really sure that would work, haven't yet tried.

Marko Cebokli

[trrriple]

From the graphs I would say you are correcting too often and too heavily.

Hmm it could be! I'm currently correcting every 100 seconds. My current lowest possible correction (besides zero correction when the average over the last 100 samples is exactly 10 MHz) is

Code: [Select]

    else if (abs(error) <= .02)
    {
        adjVal = .0001;
    }

And .0001 V I think is about as low as I can get with a 16 bit DAC. Maybe when I'm within that bound or .01 I correct even less often?

Hello Trrriple!

Seeing that designing GPSDOs is a quite popular sport here, I also started work on a couple of GPSDO designs.

My first design is very similar to yours. I'm using a MSP430 uC and PWM output, everything still in very embryonic state. I guess, you will probably beat me to the finish line with this one :-)

The problem, when using the captured value as the error signal in the PLL loop is, that with the counter running at 10MHz, we get a 100ns "blind zone". One solution I thought of, was to keep the loop on the edge between two values, the quantization error (the "sawtooth") providing the necessary dither. For example, set the VCXO so, that in 100 consecutive captures, half of the captured values will be N, and the other half N+1.  Not really sure that would work, haven't yet tried.

Marko Cebokli

Hey Marko! I'm pretty new to designing electronics, that's why I trying to force this as much as possible to be a software project hah. But to your point, yeah essentially we end up in the middle of the last pulse... it seems to follow pretty consistently when it's +1, the next one will be -1 and vice versa (but sometimes not). I'm a visual learner so I'd have to see your idea in action.

I appreciate the feedback everyone.

[S57UUU]

I will publish my designs in full detail, once I (hopefully) get them halfway working (which probably won't be very soon :-)

As thinkfat noted, maybe you could reduce your loop gain. For example, use a 32 bit accumulator, top 16 bits go to the DAC, the bottom 16 bits providing a "fractional" part, that would allow you to use very small loop gains in a very simple way.

Marko Cebokli

[thinkfat]

Hello Trrriple!

Seeing that designing GPSDOs is a quite popular sport here, I also started work on a couple of GPSDO designs.

My first design is very similar to yours. I'm using a MSP430 uC and PWM output, everything still in very embryonic state. I guess, you will probably beat me to the finish line with this one :-)

The problem, when using the captured value as the error signal in the PLL loop is, that with the counter running at 10MHz, we get a 100ns "blind zone". One solution I thought of, was to keep the loop on the edge between two values, the quantization error (the "sawtooth") providing the necessary dither. For example, set the VCXO so, that in 100 consecutive captures, half of the captured values will be N, and the other half N+1.  Not really sure that would work, haven't yet tried.

Marko Cebokli

The "dithering" through the quantization error is not gaussian noise, though. That means it will not average out completely.