[time-nuts] Low cost GPS module for < 100ns timestamping error
attila at kinali.ch
Sun May 4 17:07:20 UTC 2014
On Fri, 02 May 2014 23:54:25 +0100
Tony <tnuts at toneh.demon.co.uk> wrote:
> I'm considering designing and building some dataloggers, probably ARM
> Cortex based (eg. STM32F4xx), which record the time of infrequent
> events, preferably to better than 100ns and if possible better than
> 50nS. The data loggers will be continuously powered, in fixed locations
> and should have reasonably good views of the sky so the use of a low
> cost GPS module should be feasible. I believe it shouldn't be too
> difficult to resolve the PPS timing to +/- 5ns or better with a 100MHz+
> microcontroller clock, but obviously jitter would add to the error
> requiring the GPS to be better than perhaps 90ns or so worst case.
if i'm not mistaken the c/c units of the STM32F4xx run at half main clock,
ie 84MHz max. That would give you a resolution of 12ns.
If you run of a VCXO and can stear the average PPS to lie at the border
between two bins, ie that half of the time the PPS is higher, half of
the time lower, then you should be able to get a bit better than 12ns.
> Inevitably cost and power constraints apply - ideally the GPS would cost
> less than $20 (in quantities of 100), and < $15 would be good, but it
> doesn't seem easy to find very lost cost receivers with timing outputs
> that are properly specified, presumably because of the relative market
> volumes. The power consumption of most timing receivers also seem to be
> higher than navigation units - eg. the Trimble SMT-x spec is 100mA
> compared to the ADAfruit MTK3339-based module which draws 20mA (but they
> are a bit too expensive at $24 apiece).
You can try the LEA modules from u-blox. Single piece they are available
from ebay. You can get them from u-blox directly too. But you have to
buy a couple at once otherwise you pay way too much. IIRC prices get
reasonable from 20 pieces upward.
Even the non-timing modules have usually PPS specified to be better than 100ns.
> This also raises questions about the short term stability of the
> microcontroller oscillator required to maintain sufficient accuracy when
> GPS timing is temporarily lost for some reason - but how long would that
> need to be? 30s? 5 minutes? 30 minutes? An OCXO or a Stratum-3 TXCO
> would be too expensive, but oscillator manufacturers don't seem to
> publish short term frequency stability specifications for low cost/low
> power oscillators, and finding such information isn't easy. Can anyone
> point to figures for a typical non-TXCO low cost oscillator, 10 or 16MHz?
Have a look at John Vig's crystal oscillator tutorial to get an understanding
of the different effects that affect the oscillator. As mentioned already
temperature should be your first concern.
> I did find this study, http://tf.nist.gov/general/pdf/2276.pdf,
> measuring the stability of some low cost quartz wristwatches which gives
> some interesting data of 20 to 65ppb Allan deviation over 100s. That,
> but a 32kHz oscillator might give rise to jitter problems when
> multiplied up to a suitable frequency.
The frequency does not affect the jitter as much as you think. It's more
the Q of the oscillator that determines the close in phase noise.
But as you are using a uC, the phase noise will be dominated by the
PLL and VCO in the uC itself more than the one of the external oscillator.
Also, the phase noise induced jitter is negligible compared to other
effects when you are time stamping (a good oscillator gives you a jitter
of <10ps, much below the ~10ns you can measure).
> Some oscillator datasheets specify Allan deviation values, but I guess
> what I need for estimating worst case timestamp error during holdover
> periods are actually MTIE values. Is there any way to estimate the
> latter from Allan deviations specs? Would an ADev of 65 x 10^-9 over
> 100s imply up to 6.5us of error after 100s?
Under the assumption of no other environmental changes, yes.
But on the order of 100s, temperature becomes significant for the
accuracy you want to acheive. You either have to compensate it in
the oscillator (using a TXCO) or correct it in software by measuring
the temperature yourself. Alternatively, you can try to keep the
quartz temperature within +/-1°C using some heating element.
(it does not need to be a full OCXO)
Also keep in mind that the ADEV values is the statistical variation
of the signal. ie it represents a 1 sigma value. As a normal distribution
is assumed, your error is unbounded (not actually true). If you are
sensitive to maximum error, you should work with a 3 to 6 sigma value
instead of with the ADEV value directly.
Also note: ADEV changes with integration time and its value cannot
easily be extrapolated, in general. You can take certain assumptions
as to what kind of effect takes place in which time scale and apply
its slope, but that's at most a rough guess.
For more information on this topic see "Phase Noise and Frequency Stability
in Oscillators" by Enrico Rubiola.
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl
More information about the Time-nuts_lists.febo.com