Welcome! Take a look at NavSpark from SkyTraq (http://www.skytraq.com.tw/). They had an Indiegogo (https://www.indiegogo.com/projects/navspark-arduino-compatible-with-gps-gnss-receiver) campaign recently and should deliver real soon now. The NavSpark chip has an trigger pin for time capture, a feature suggested by a fellow time-nut and a 100 MHz clock.
Edésio On Fri, May 02, 2014 at 07:59:14PM -0400, ewkeh...@aol.com wrote: > Welcome to the nuts Tony > You are not specifying exactly how accurate time has to be but in my book > and based on tests the most reasonable priced GPS with 1 pps is a Ublox 6M > that you can get with antenna for less than $ 22 antenna included from > _www.DX.com_ (http://www.DX.com) . They have volume discount. Shipping is > very > slow but included. They seem to be presently out of the 1 pps version but > all ublox units have a 1 pps output and I use with and without and all I do > is > solder a wire to pin 3. > Bert Kehren > > > In a message dated 5/2/2014 7:02:57 P.M. Eastern Daylight Time, > tn...@toneh.demon.co.uk writes: > > 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@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > _______________________________________________ > 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. _______________________________________________ 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.