Hi Bruce

You are absolute right that it is wise to put some time in the estimation of such effects as asynchronous Clocks. An iteration between  thinking and building seems always to be necessary but we all have different capabilities for that. For the Arduino I came to an end with the interrupts as I am not good at uP´s.

The Arduino GPSDO has two interrupts. One is synchronous with the 10MHz and comes from timer1 overflows. The other is synchronous with the 1PPS. So it is three asynchronous clocks right now in the GPSDO controller.

As I understand my problem it is that an interrupt takes some time to execute and if you get the two interrupts to close you will have a problem with timing as you can´t execute both at the same time?

Of course the easy solution could be to have the needed resoulution higher than the time it takes to execute the interrupts but in the GPSDO I want a resolution of 200ns (5MHz Clock) and the shortest interrupt is 3us.

I would be glad if somebody (Chris?) could have a look in the Aduino GPSDO code to see if it possible to get rid of the uncertainty due to the interrupts from the timer1 overflow.

Another question: Does a PIC not need overflow interrupts to count say 5000000 counts as I do in the Arduino?

Lars

From: Bruce Griffiths
Sent: ‎söndag‎ den ‎16‎ ‎februari‎ ‎2014 ‎20‎:‎14
To: time-nuts@febo.com

The response time to an external asynchronous interrupt is never
deterministic.
The external interrupt has to be synchronous with the uP clock to avoid
the non deterministic synchronisation delay.
Even when the external event is synchronous with the clock input to the
uP and the uP uses a divider to produce its internal clock then there is
the issue of divider phase shift.
This phase shift can lead to sampling the waveform before the peak
across the sampling cap. This is far from ideal, its better to sample at
or slightly after the peak when the sensitivity to timing variations is
far smaller.
To complicate the issue further the time of occurrence of the peak is
temperature dependent and the sampling switch on resistance is nonlinear
so that peak delay varies with temperature and input signal amplitude.

Its generally quicker and cheaper to estimate the magnitude of such
effects and make appropriate choices than just build a sequence of
breadboards each of  which then needs to be extensively characterised.

Bruce

Chris Albertson wrote:

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Lars,

For precision work you must avoid having more than one interrupt. Otherwise there is the chance both will occur at or too near the same time and introduce unexpected latency. There are a couple of solutions.

1. Use a chip with capture h/w so you don't need an interrupt for critical time measurements.
2. Handle timer rollover in software (as in polling) to avoid timer interrupts.
3. Keep track of time with instruction counting instead of an overflowing and interrupting timer.
4. Avoid overflows and interrupts by using time intervals instead of elapsed time.
5. Use a chip with multiple cores with at most one interrupt per core (or a propeller chip with no interrupts at all).

The other point to make is interrupt latency. Aside from the sub-cycle h/w synchronization jitter (which is always present) each microcontroller family has a certain number of instruction cycles of latency before your interrupt code executes. In the case of the PIC, this is a fixed number, which is why something like the picPET can be accurate to one cycle. From what I've read the AVR does not have fixed latency, due to its variable- or multi-cycle instructions. Consequently your interrupt handler has both h/w jitter and s/w jitter. To most people this is who-cares. But when you're counting nanoseconds these details matter a lot.

Many uC these days have CCP (capture/compare) in h/w, which pushes the problem of timing to bare hardware instead of being tied to instruction timing or interrupts. So if the chip you're using has CCP, by all means use that. That way your 1PPS timing is done in h/w and your s/w only has one timer interrupt to deal with.

/tvb

Another variation is to use a single 125 style buffer device (eg
74LVC1G125) to charge and discharge a capacitor (in reality an RC
network when the ADC input is taken into account) via a series resistor.
The input to the buffer is driven by the input to a conventional
synchroniser whilst the buffer output enable is driven by the
synchroniser output.
The buffer output being enabled whilst the synchroniser output is low
(for a 0-> 1 PPS input transition) and disabled whenever the
synchroniser output is high.
This ensures that the capacitor network is discharged to zero between
PPS events without requiring an additional device (or a resistor) to
discharge the RC network.

The capcitor reset level sensitivity to leakage currents is greatly
reduced over that when a 1M discharge resistor is used.

The nonlinearity can be calibrated by using a statistical fill the
buckets technique.
This requires a relatively noisy test signal generator (RC oscillator??)
to drive the synchroniser input.
However its essential to ensure that this oscillator isnt injection
locked to the synchroniser clock.

Bruce

Lars Walenius wrote:

The attached circuit schematic illustrates how this might be implemented.
Faster logic devices can be substituted.

R2, C2 approximate the equivalent input circuit of the ADC.
R2, C2 values will vary for each ADC.

The Shift register which acts as a synchroniser and produces various
trigger signals is clocked at 10MHz (assumed to be the uP instruction
cycle clock rate)

The RC network charge time varies between 1 and 2 shift register clock
periods ( ie a charge time from 100ns to 200ns).
Sampling a time stamp counter clocked at the same frequency as the shift
register is only required if the GPSDO local oscillator has a potential
initial offset of  100ppb or more.
If missing PPS detection is required then a PPS time stamp counter with
a range of several seconds is desirable.

Bruce

Bruce Griffiths wrote:

Hi Bruce,

What are the tradeoffs with using different values for R1?  I have no practical experience at this, so all I can do is rely on the models.  Does the fact that R2 is in the PIC, and C1 is so tiny, make the value of R1 of less importance?  On my PIC, they list C1 as 5pf, R2 as effectively about 7K, and C2 120pf.

Bob

R2 is dominated by the adc sample switch on resistance and thus has a
relatively high  tempco (~4000ppm/C).
C2 has a relatively low tempco (~100ppm/C or so)

To reduce the effect of the sample switch on resistance tempco on the
gain tempco of the TIC R1 C1 need to be proportioned so that R2 has
little effect on the gain temcpo.
R1 = 470 ohm, C1 = 1nF (NPO) appears to be about right for a 2.5MHz
synchroniser clock and the PIC you intend to use.

This should reduce the effect of the sample switch on resistance tempco
by a factor of 10 or more.

The minimum value of R1 is governed by the output resistance of the
tristate buffer and its tempco.

Bruce

Bob Stewart wrote:

Now you've lost me.  What 2.5 MHz synchronizer clock?  Everything I have external to the PIC is 10MHz.  The PIC is running HSPLL at 40MHz, though I don't think that makes any difference to this.

Bob

For a 10MHz synchroniser clock  A C1 value of around 220pF or so should
be appropriate.
The exact value depends on the ADC reference voltage.
A n ADC reference less than 5V may be useful.
I'll run some simulations to check the sensitivity to R2's tempco.

Bruce

Bob Stewart wrote: