[time-nuts] Low cost GPS module for < 100ns timestamping error

[Chris Albertson]

here is what I'd do....

Get a decent OCXO (ovenized crystal oscillator and control it with your
GPS.   Don't worry if the GPS's PPS is 50ns or 5ns.  You are going to be
averaging these for a while.    Basically you build a GPSDO.    These have
become very easy to make.   I have one I made for about $8 and it has not
gained or lost 100ns in weeks.

Next get a second uP, not the one controlling the GPSDO.   let your GPSDO
10MHz output drive this uP's counter and have the thing your are timing
connect to the pin that will capture the counter.   This is done in
HARDWARE.    The pin can cause the hardware counter to be captured  to a
register.  So the software need not be "real time"   The counter is ALSO
captured by the 1 PPS from the gps.    This way you capture both the one
second "tick" and your event.   You log the number of "counts" past the
second.

You can use ARM processors but I'm doing this with an Arduino cone I got on
eBay for under $4.  You do not need much CPU power as all the real time
stuff is done in the uP's peripheral hardware.  The uP only has to send the
data over a link or log it so an SD memory card.   even the 8-bit AVR is
faster than I need for that.




On Fri, May 2, 2014 at 3:54 PM, Tony <tnuts at toneh.demon.co.uk> wrote:

> Hi, I'm new here so please be gentle!
>
> 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.
>
> 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).
>
> There are several cheap modules that have PPS outputs but no accuracy
> specification; it's possible that these could be used with sufficient
> averaging/filtering of the PPS output. Actually repeatability is the
> important requirement rather than accuracy as they could be calibrated.
> Perhaps even a PPS o/p is not absolutely necessary - could the NEMA output
> timing be used given enough averaging and a sufficiently stable oscillator?
> Compromising the timing accuracy requirement a bit to say 150ns may be
> acceptable if the GPS device is cheap enough.
>
> I understand that the PPS outputs of some cheap modules sometimes become
> ill-behaved, but in this application the time stamp can be adjusted (or
> anomalous clocks ignored) post-event if necessary to correct for temporary
> disturbances.
>
> 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?
>
> 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.
>
> 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?
>
> Any thoughts? Thanks,
>            Tony H
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California