Hi We are not talking about a system (like GPS) that has junk data coming in. In this case, the phase detector gives you a very good estimate of the delta between input and output in real time. The error trapping / shifting / multi this and that simply isn’t needed in this case. The solution is much easier than the GPSDO.
Let the OCXO warm up for a day or two. Yes it could be a week. Adjust it with a pot to be close to frequency. (This is a basement project). Fire up the loop. Let it settle. Come back in an hour or two and all is well. Confirm this by watching a (good) DVM on the EFC line. It’s a low gain / long time constant loop. It will take a bit to settle. Yes, if code is what gets you excited, put in an array for the coefficients. Then add a timer to step the index. The timer will add about 4 lines. The step process will be on auto-pilot, but that makes it easy. You will settle faster, the net result after settling will be about the same. If a year from now it’s unlocked, re-adjust the pot. Maybe check it with a DVM every so often and adjust it before it unlocks. Not a lot to it. Simple code to write Easy board to build. Does just what it needs to do. Not a commercial system at all. It does not need to be. It’s going to do everything you need to do and be much easier to get running than something far more complex. The idea is to make the simplest system that will do the trick, not make it so hard that nobody ever tries. The target audience is a basement experimenter not NIST. It’s ok in this case to replace a bunch of code with an inquiring mind. Bob > On Oct 25, 2014, at 11:23 AM, Charles Steinmetz <[email protected]> wrote: > > Bob wrote: > >> PHK has a roughly 6 line code snippet that does a basic PLL. Add two more >> lines to check / clamp the integrator if you wish. That's 8 lines. If you >> want a D term (to give it an FLL component) add 2 more lines. We're up to 10 >> lines. >> >> It's just a control loop, not a full GPSDO. There's not a lot to it. > > There's a bit more to it than that. For any loop slow (narrowband) enough to > be useful disciplining a good OCXO, I consider a dual- or triple-rate loop > filter to be essential. There is also always a fair amount of > error-trapping, and other overhead. These can add lines fairly quickly. > > I'm sure I have lots more to learn about writing efficient code. (But note > that there is a difference between coding one's chosen algorithm more > efficiently and choosing a different algorithm that is not really what you > want, just because it is more efficient.) > > Best regards, > > Charles > > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
