It seems to be for PC2 output but Lars was using PC3 (pin 15) which, afaiaa, does not have such a dead zone.
BTW, when you mentioned that ten hours wait for the ocxo's EFC pin to rise a mere 500mV, my first thought had been, "Jeez! I thought hanging in for the two and a half hours it took for my own version of the G3RUH gpsdo to finally establish lock with a 5000s TC was bad enough!!
I'd only stuck it out because unlike an earlier version with a 1000s TC PLL filter that had refused to get past a sticking point, this looked like it just might eventually reach its goal and I was curious enough to let it continue unmolested. I'd aborted the earlier run and added a 20M ohm 'helper resistor' between the output of the PLL filter and Vcc to brute force its way past its sticking point. This had done the trick, albeit at a slight reduction of the filter's time constant, and was retained as a permanent fix.
I'm pretty sure I'd used the same 470uF cap, tested for sub nA leakage at 5 volts, so the puzzle of the stickiness of the earlier test build remains an unsolved puzzle - possibly a leakage issue in the cheap paxolin stripboard I'd built it on.
Since I didn't want to be left hanging in the breeze for two and a half hours waiting for it to resume GPS lock every time I had to power it up (I was still tinkering with it), I came up with a two diode plus trimpot helper circuit to do the initial 'heavy lifting' of the EFC voltage to just shy of the 2.3570 on tune volts by about 150mV, relying on the forward bias current at sub 100mV dropping to less than a nA (12 and 15 volt zenners proving to the best choice over standard silicon diodes like the 1N4000 series for this job). This measure reduced the time to lock from a cold start to
only half an hour.
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
The 5000s TC proved a bit too long for the oxco's short term stability so I reverted to a 1200s TC, keeping my speed up circuit in place where it now reduces the time to lock from cold to a mere 10 to 12 minutes, matching the time it takes for the ocxo's oven temperature to stabilise enough for the PLL to finally catch up with the resulting wild frequency swings (tens of mHz).
Looking at the circuit diagram of the Lars gpsdo you posted, I noticed the use of two pwm pins to create a 16 bit DAC. Presumably the 10 bit ADC is being oversampled to gain an extra 5 to 6 bits to match the effective PWM resolution? I haven't examined the code in detail (or at all, tbh).
==============================================================================================
[EDIT] Whilst scanning Lars's code to get a clue on whether he'd used oversampling, I realised why he'd ganged two pwm pins to create a 16 bit pwm - to make full use of the ADC's 10 bit resolution of course! Mind you, I'm surprised he didn't oversample by 16 and decimate by two to add a couple of extra bits resolution. Perhaps a lack of code space?
![Undecided :-\](https://www.eevblog.com/forum/Smileys/default/undecided.gif.pagespeed.ce.cCZ6w-jWpR.gif)
==============================================================================================
At the time when I first download Lars' documentation, I'd not had any experience in using the Arduino IDE with any of these AVR based SoC boards. However, since spending the past 50 weeks (and counting), programming a Nano to control the base plate temperature of an LPRO-101 in my ongoing RFS project of the last two years, I now have a renewed interest in making a micro controller based alternative to my current gpsdo work horse lab reference and this looks a better bet than Andrew's pet project (for starters, at least).
I've attached a couple of screen shots of the ruby versus the gpsdo covering a 25 hour and a half interval. The infinite persistence includes the 5 or 6 ns gpsdo disciplining wobble (mostly ionospheric effect) and the leisurely 33ns phase wander of the ruby which appears to be in part, a diurnal artifact.