Hi You (sort of) have run into two problems:
1) The GPSDO takes forever and ever to lock ( = the gain is to low / the time constant it to long) 2) The GPSDO has to much jitter ( = the gain is to high / the time constant is to short) Obviously, you can’t solve both of these problems by adjusting a single parameter. :) The “common” solution is to run in one mode (high gain) to get things into lock. Then knock the gain down (likely in steps) as the lock settles in. While it may seem like a one way street, it may not be. The same “forever to lock” issue also impacts the ability to deal with a “bump in the road”. If something changes (maybe temperature) you want to deal with that before there is a major impact. Bob > On Oct 23, 2019, at 6:22 AM, Tobias Pluess <tobias.plu...@xwmail.ch> wrote: > > Hi colleagues > > thanks to your inputs I could design the EFC circuit for my new GPSDO and I > think its quite clear how that will work. > So in the past days, I spent my spare time on thinking about the control > algorithm. I used FLL previously, which gave unsatisfactory results, so I > think PLL is the way to go. > Since I will use an STM32F407VG microcontroller, I have plenty of times for > this job, and I had the following idea. > > Assume a timer is clocked with the 10MHz clock. The timer overflows when it > reaches 9999999 (=10e6-1). Further, this timer is used to generate the 1PPS > pulse output: each time when the timer reaches the value of 0, a pulse is > generated on one of the output pins. Since this happens all in hardware, this > should be fine and shouldn't have jitter introduced (e.g. by interrupts or > whatever). > Further, the *same* timer is used also for input capture: each time when the > GPS module outputs a 1PPS pulse, the timer value is copied to some shadow > register, while the timer continues to run. > So what we have now is a very basic TIC which measures the time interval > between the GPS 1PPS and the 1PPS derived from the OCXO! > If the OCXO is slow, the timer will not count up to 10e6 during one second, > i.e. the captured timer value will be a large number, say 9999000 for > instance. On the other hand, if the OCXO is fast, during one second, the > timer will overflow and when the 1PPS pulse from the GPS arrives, the > captured timer value will be some low number, for instance 1000. So this very > basic capture function allows to detect the phase between the two 1PPS > signals, with a basic resolution of 100ns. > Knowing the phase difference, we can now implement a basic PLL which tries to > push this phase difference to zero. And now comes the cool stuff: as soon as > the time interval is low enough, I can enable a TDC7200 which then gives a > higher resolution measurement as the phase difference becomes smaller and > smaller! > > OK I read about this GPSDO simulator which was written by TvB > (http://www.leapsecond.com/pages/gpsdo-sim/). I looked at the sourcecode and > tried to make my own simulation tool using Matlab since I have no data files > available to feed into TvB's program. My Matlab code is attached. > Basically, it simulates an oscillator with 10MHz nominal frequency, and a > 1PPS pulse which can have an adjustable jitter (e.g. +/-50 ns) which can have > a Gaussian distribution or a uniform distribution. > The code then implements a simple PLL which is based on the approach I > outlined above. The PLL locks using a PID controller, similar to the GPSDO > simulator. I made two observations: > a) the PLL does never lock but oscillates as long as the proportional gain is > 0. > b) when the PLL locks and the oscillator frequency is at 10.000000 MHz, the > frequency is somewhat unstable because of the proportional term which feeds > the 1PPS jitter more or less directly to the DAC. The frequency fluctuations > I could observe are up to 20 mHz, which is a terrible performance. > > I think issue a) could be addressed if I made a proper model of the whole > thing, taking the z-transfer functions of the individual blocks into account. > This would perhaps show what properties of the controller are important. I am > familiar with digital filters and their transfer functions and such, but I > have never dealt with a digital PLL so I don't know yet how I should model > the whole thing. (e.g. how would a digital model of the OCXO look like? no > idea.) > Further, I am sure there is a solution to issue b), but I don't know what > that solution is. Or maybe issue b) doesn't really exist but is related to my > code being wrong? > any hints on that? > > I have also attached a screenprint of the charts produced with my simulation > tool. One can see the time between two 1PPS pulses. The time interval between > the GPS 1PPS and the OCXO-derived 1PPS is also plotted and one can see how > the PLL locks nicely after about 45 hours runtime (which is extremely slow, > but having a faster PLL gave me worse noise performance). The EFC voltage and > OCXO frequency are also plotted and if one zooms in one can see that the > frequency is indeed not very stable (and this is related to the proportional > term of the PI controller). > > best > Tobias > HB9FSX > > <gpsim.m><gpsim.png>_______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
