Lars DIY GPSDO with Arduino and 1ns resolution TIC

[thinkfat]

Johnny, I will be interested in hearing how much improvement a Sparkfun ZED9T makes over an M8T. My own Lars build (Murray Greenman, ZL1BPU, display variant), is at the limits of what I can measure in terms of short term stability.

If you're interested in short-term stability of oscillators, you can do a lot with the "tinypfa". For cheap.

https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage

[Johnny B Good]

@Solder_Junkie

 Whilst I'd love to answer your questions in detail and the information is relevant to any design of DIY gpsdo project, I think it would be better to start a separate topic thread rather than completely hijack this one (I can post a link here for anyone interested), However, as a 'teaser', assuming you haven't already seen this YouTube video, have a look here

@thinkfat

 Thanks for the links to the TinyPFA. ISTR Solder_Junkie mentioning this gadget a month or two back. I checked it out but being the cheapskate that I am (says he who blew 250 smackers on that Sparkfun module some 14 months ago ) I was looking for the cheapest option and gave up on making sure of getting the exact right version to convert. However, money isn't everything so, for the sake of my much put upon SDS1202X-E, I'll pick one of those sources in the list whether pre-loaded or not with the SW. I've been hankering after a means to record the data for a while now anyway (you know how it is - not enough round tuits).

[iMo]

..
I haven't experimented with increasing the smoothing caps on the oscillator Voltage control line, I note that Murray used 22uF caps against Lars using 4.7uF. I use 10uF. If you refer back to the James Miller "Simple" GPSDO, James uses a 160K resistor and 100uF cap to smooth the control Voltage line and achieves around +/-5 parts in 10^11 over a 10 second period. Maybe a larger capacitor would work just as well as going to a more expensive GPS module?..

The precise finetuning of the filter is not an easy task, imho. I made an excel tool, trying to ease the filter design for Miller's XOR based GPSDO in past, posted here.
https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070

[Johnny B Good]

Johnny, I will be interested in hearing how much improvement a Sparkfun ZED9T makes over an M8T. My own Lars build (Murray Greenman, ZL1BPU, display variant), is at the limits of what I can measure in terms of short term stability.

If you're interested in short-term stability of oscillators, you can do a lot with the "tinypfa". For cheap.

https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage

 I've just ordered one from Mirfield Electronics in the UK.

[Solder_Junkie]

Martin (G3ZXZ) of Mirfield is really good to deal with.

[bogdanbrudiu]

Can you please help me? I am stuck and don't know what I did wrong...
If I disconnect the TIC from ADC0 and measure the TIC output it looks like this

If I connect it to ADC0 the entire signal goes up 1V and looks like this


When connected the ADC0 reading is 1023 if I disconnect it the reading is ~200 and the console shows 10MHz?

Type f1 <enter> to get help+info
time    ns      dac     temp    status  diff_ns filtX10 tc      filt    timer1  temp1
1       Missing 10MHz?  32768   25.8    WarmUp  1013    10230   32      1       46291   239     Five minute averages: TIC+DAC+temp
1       Missing 10MHz?  32768   25.9    WarmUp  0       10230   32      1       41521   238     Now acquiring value: 0
1       Missing 10MHz?  32768   25.9    WarmUp  0       10230   32      1       6677    237
1       Missing 10MHz?  32768   25.8    WarmUp  0       10230   32      1       41333   240     0       0       0       0.0
1       Missing 10MHz?  32768   25.7    WarmUp  0       10230   32      1       34487   240     1       0       0       0.0
1       Missing 10MHz?  32768   25.9    WarmUp  0       10230   32      1       6018    239     2       0       0       0.0
1       Missing 10MHz?  32768   25.7    WarmUp  0       10230   32      1       27025   241     3       0       0       0.0
1       Missing 10MHz?  32768   25.8    WarmUp  0       10230   32      1       40620   238     4       0       0       0.0


Is this the way the signal should look like? somehow I would expect it would slowly charge and based on how much it charged you know the delta... And since the TIC offset is between 200 and 1020ns I would expect the slope would be over this period....

[Solder_Junkie]

Check that you have connected the TIC (4046) correctly, I think one of the diagrams I saw had the pins wrongly marked.

See, including the "as built" pdf: https://www.qsl.net/g4aon/gpsdo/

SJ

[Miti]

Check your ground, see my posts starting at reply #44, I had a similar issue. Check the offset voltage at the ADC input. My first logs are very similar to yours.

Cheers,
Miti

[Solder_Junkie]

As per the reply from Miti, I added a braid from the Arduino ground to the TIC ground. I cannot remember if it made a difference or not.

SJ

[Clemgill]

Hi,

I am trying to understand Lars's code and needs confirmation of my findings related to the TIC measurement section.

The code says that conversion ADC acquisition starts at rise of PPS:
  ISR (TIMER1_CAPT_vect)
{
  timer1CounterValue = ICR1;        // read the captured timer1 200ns counter value
  TIC_Value = analogRead(A0);        // ns value
  PPS_ReadFlag = true;
}

Time needs to be given for the voltage to build-up on the 1nf capacitance. at least 500ns and max 1000ns
The RC time constant is 3,9E3*1E-9 = 3,8E-6s = 3,6 microseconds (= time to reach to 63% of the maximum of 5volts)
Lars limits the full range to 1,1volts (22% of 5volt), so roughly consistent with the 1000ns max ?

According top the ATmega328P datasheet :
The interrupt execution response for all the enabled AVR® interrupts is four clock cycles minimum. After four clock cycles the program vector address for the actual interrupt handling routine is executed. During this four clock cycle period, the program counter is pushed onto the stack. The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles

Which sums up to 7 cycles before starting to execute the Interrupt vector code (when acquisition of the timer1CounterValue takes place).
ADC measurement start after 9 cycles from PPS (two more read cycle to capture timer1).
With a clock at 16Mhz (62,5ns) the corresponding latency would be 562ns => Not enough...
The ADC conversion time is said to take 13 conversion cycles (Table 23-1.), but the sample and hold takes place only after the first two conversion cycles (Figure 23-6).
With an ADC clock of 200kHz, one conversion cycle = 500ns... so time lag to charge the capacitance is mostly found in the conversion process.

Does that make sense ?
Thx,
Gilles.

[PCB.Wiz]

According top the ATmega328P datasheet :
The interrupt execution response for all the enabled AVR® interrupts is four clock cycles minimum. After four clock cycles the program vector address for the actual interrupt handling routine is executed. During this four clock cycle period, the program counter is pushed onto the stack. The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles

Which sums up to 7 cycles before starting to execute the Interrupt vector code (when acquisition of the timer1CounterValue takes place).
ADC measurement start after 9 cycles from PPS (two more read cycle to capture timer1).
With a clock at 16Mhz (62,5ns) the corresponding latency would be 562ns => Not enough...
The ADC conversion time is said to take 13 conversion cycles (Table 23-1.), but the sample and hold takes place only after the first two conversion cycles (Figure 23-6).
With an ADC clock of 200kHz, one conversion cycle = 500ns... so time lag to charge the capacitance is mostly found in the conversion process.

You would need to check the assembler to get the exact timing. There could be calls and parameter loads and possible register saves in the interrupt preamble.
If you wanted to check you could toggle a pin right at the analog-start line.

[MIS42N]

With an ADC clock of 200kHz, one conversion cycle = 500ns... so time lag to charge the capacitance is mostly found in the conversion process.

Does that make sense ?
Thx,
Gilles.

The ADC has very little to do with the charging of the 1nF capacitor. It starts charging when the 1PPS edge triggers the HC4046 on and finishes charging when the 1MHz from HC390 turns it off. So the charging time is all hardware controlled. It then slowly discharges through the 10M resistor until the next 1PPS. I am working from the circuit posted at the start of the thread. I haven't looked further, I'm assuming this is still the circuit people use.

It is only required that the ADC starts after the 1nF charging, and not long after so very little discharge has occurred. The start time is estimated as you outlined, except with a 200kHz ADC clock the sample and hold will take place a minimum of 5µs after requested, not 500ns.

So the delay in the interrupt routine is not a worry.

FYI the time to acknowledge an interrupt is 4 to 7 CPU cycles (unless there are other interrupts being processed in which case it will take longer). The reason is the CPU will complete whatever instruction is in progress. Many instructions complete in 1 cycle so the delay is 4 cycles. Some instructions (call, return for example) take 4 cycles so dependent on what part of the instruction the CPU is working on, the delay can be 4 to 7 cycles.

[Clemgill]

Thanks PCB.Wiz and PIS42N for your answers,

Sorry for the mistake with wrighting 500ns, I meant 5000ns. The conversion time is indeed dominating.
Moreover I converted the compiled HEX file to assembly code and found the start of the interrupt vector  (TIMER1_CAPT_vect)
There are many instruction taking place before the actual "analogRead(A0)" (including 15 "push", and other 2 cycles instructions) summing up to 45 cycles = 2812ns..... even before taking into account the conversion clocks.

[Clemgill]

Another question regarding the "TIC_value" moving average filter.
from the code :
TIC_ValueFiltered = TIC_ValueFiltered + ((timer_us*1000 + TIC_Value) * filterConst - TIC_ValueFiltered + (filterConst/2)) / filterConst; 
I understand that this is setting the "TIC_ValueFiltered" to  the mean of "TIC_Value * filterConst" (when timer_us = 0)
But why is the term (filterConst/2) added ?

[Clemgill]

But why is the term (filterConst/2) added ?

I guess I found the answer to my question: this is to enhance the rounding
Integer computation rounds by cutting the fractional part of the result (INT function in excel)
Better rounding can be achieved by rounding to the closest integer.
This is what adding 0,5K does :
A   A+0,5   INT(A)   INT(A+0,5)
2,4       2,9       2            2
2,6       3,1       2            3

[Clemgill]

Hi,
Can someone help me with the maths explaining why "diff_ns = Frequency in ppb" ?

From LARS code :
    diff_ns = (timer_us - timer_us_old)*1000 + long (TIC_ValueCorr - TIC_ValueCorrOld + 0.5); // = Frequency in ppb if updated every second!

Thanks

[metrologist]

1 ns = one billionth of a second (1/1,000,000,000)

1 us = 1000 ns

[thinkfat]

"diff_ns" is the phase drift of the signal against the reference. phase drift equals frequency offset. it's not phase difference, mind you, but the change in phase difference since the last measurement.

[Clemgill]

Thanks for the replies, I think I got it.

This is my way to understand :
If T0 is the period of the reference signal and T the period of the measured signal
Time Interval is measured at each second on the rising edge of T0, hence:
Diff = Delta(TIC) = TIC(at ((k+1)*T0) - TIC(at k*T0) = (k+1)(T-T0) - k(T-T0) = T - T0
notice that TIC drifts if T#T0 (seen on oscilloscope), but Delta(TIC) stays constant if T is still (constant rate of change)
As frequency offset (also called fractional frequency or frequency deviation by Lars) = (T - T0)/T0 = (F - F0)/F0
then (T - T0)/T0 = Diff/T0

Is this OK ?

[Clemgill]

Hi,

I noticed a significant difference in TIMELAB for fractional frequency ADEV between DAC curve and diff_ns curve.
There is a factor a 100 difference (shape of the curves are parralel but diff_ns curve is 1E2 above DAC curve)
I measured 35ppb for the DAC range so using 5.4E-13 scale factor for the DAC input (gain = 65535/35 = 1852 => scale factor = 1/gain * 1E-9)
And 1E-9 scale factor for the diff_ns input.

Could this be explained by the averaging effect of DAC provided by the PLL loop ?