[time-nuts] Another "atomic" clock question

[Lars Walenius]

Some clarifications on the ADC in the ATmega328 and how it is used in the Arduino GPSDO. 

The resolution is 10 bits but you can select Vref. In my Arduino GPSDO it is set to the internal Vref = 1.1V so 1LSB is 1.1mV. From the beginning I used 5V as Vref but if you plot the response from the RC-net you find that the useful ADC range is only a fraction if you want to have a reasonable linearity. In the beginning I used only 600 out of the 1024 but still the time per bit was more than a factor two different. If somebody want to experiment with other processors for theTIC, a Teensy with 16bit ADC´s is probably a good idea because you can use only part of the range but still have good resolution (noise is another thing that may be both good and bad in a GPSDO).  

According to the datasheet the minimum conversion time is 65uSec for the ATmega328 (ADC clock max 200 kHz and 13 clock cycles).

The discharge of the 1nF is not 1sec but 1mSec. If it was 1sec, 63% of the previous charge should be left and giving errors up to 63%. My assumption when designing the network was to have at least ten time constants of discharge before the next PPS. So a 100mSec time constant would be fine for that. The problem is that with a 1nF capacitor I would need 100Mohm as discharge resistor. To get 1.1mV (1nS) over 100Mohm you only need 11pA for example from the ADC input leakage current.  I decided for 1Mohm that gives 1mv for 1nA. This gives the TIC a drift of about 1ns per nA change. Remember I wished to keep the drift to maybe 1nSs for a couple of degrees room temp change so the drift of the leakage current needs to be below say 0.5nA per degree. My practical testing has showed that I have about 1.2ns drift for 5°C change and it seems consistent between different Arduinos I have.

The 1mSec time constant gives a discharge that directly after the pulse from the HC4046 ends is about 0.1% per uSec.  So for a 65uSec delay the drop is about 65nS for a 1000nS reading and 32uS for a 500ns reading. If the delay is exactly the same every time it should be possible to compensate for.

I have got indication that crosstalk between ADC channels may be a problem in the ATmega328 but with the single TIC and very slowly changing values on the other ADC channels I can´t say it is a problem for me. I also would encourage you to test both the Arduino dual TIC and using both halves of the HC390 whatever I have said about risks. The HC390 is probably not a problem at all for the nS readings as you and Magnus says.

Lars





>Chris wrote:
Let's see what is needed. 
The ADC is 10-bits so it can read to one part in 1024.  It's a 5 volt
full scale so we are only able to measure 5 millivolt increments 

The uP runs about 16 million instructions per second.  What if we wait
1000 instructions to read the ADC what will the error be?  The "1000"
number is conservative by at least a factor of 10.  The discharge
resister has (assume) a one second time constant. 

The read delay would be 1000/16,000,000 or 63 uSec.  in that time the
voltage would have changed about  300 microvolts.  The change is about
15 times less then the DAC is able to measure.    But because of the
conservative estimate it might 150 times to small to measure.   So
randomly delayed reads of the ADC will not matter.  That said I'm sure
we can do 100X better then the 63 uS estimate. 

On the other side, charging the cap.  Let's say I mis-measured a wire
and it is 1cm longer then I though.  The added delay adds a tiny delay
but this is not going to show up in a 10-bit ADC.  Same if the
propagation delay changes through the 74HC390 based variable loading
of other output pins or noise from the 78ls05 voltage regulator.  The
DAC is set up for 5 mV steps.  I just don't need to worry about errors
that are well under 0.5 mV.