Re: [time-nuts] Low cost GPS module for < 100ns timestamping error
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,
tnuts@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.
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, EWKehren@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,
tnuts@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.
On 03/05/2014 00:59, EWKehren@aol.com wrote:
Welcome to the nuts Tony
Thanks, Bert.
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
As I said in my first post I'd like to achieve an accuracy of better
than 100ns - or 50ns if possible at reasonable cost.
I had come across the Ublox 6M when I was looking earlier, but I
misunderstood the data sheet and thought it was only the expensive
($135) LEA/NEO-6T versions which provided timing. Definitely worth a
closer look - the NEO-6M is specced at 30ns RMS which is good enough.
The power consumption is a little higher than I would have liked at
37mA/3V, but still rather less than others.
Thanks,
Tony
On 03/05/2014 02:07, Edesio Costa e Silva wrote:
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
Wow, that is very interesting - especially at under $18 including a
powerful micro. Looks hard to beat, but would have preferred an ARM chip
rather than SPARK. Can't have everything I guess!
Tony
On Sat, 03 May 2014 02:38:07 +0100
Tony tnuts@toneh.demon.co.uk wrote:
On 03/05/2014 00:59, EWKehren@aol.com wrote:
Welcome to the nuts Tony
Thanks, Bert.
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
As I said in my first post I'd like to achieve an accuracy of better
than 100ns - or 50ns if possible at reasonable cost.
I had come across the Ublox 6M when I was looking earlier, but I
misunderstood the data sheet and thought it was only the expensive
($135) LEA/NEO-6T versions which provided timing. Definitely worth a
closer look - the NEO-6M is specced at 30ns RMS which is good enough.
The power consumption is a little higher than I would have liked at
37mA/3V, but still rather less than others.
Thanks,
Tony
I hope I'm not getting to philosophical here, but isn't the time stamp
accuracy measured between receivers? That is, if I have two GPSDO, they
are guarenteed to be within X amount of time from each other.
Or do you consider a time stamp to be absolute?
Looks like this is all you'd need for most timing projects. Just add your
favorite OCXO and some wire.
The SPARC (not Spark) is actually a step up from ARM. It was developed by
Sun Microsystems (now Oracle) it is optimized for things like fast context
switching, multi tasking and so on, all the things done by operating
systems. The Sparc V8 does 128 bit floating point, (quad precision) I
wonder if 200Kb RAM is enough to run an older version of SunOS? (a BSD
variant.)
Are these shipping yet?
On Fri, May 2, 2014 at 7:07 PM, Tony tnuts@toneh.demon.co.uk wrote:
On 03/05/2014 02:07, Edesio Costa e Silva wrote:
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
Wow, that is very interesting - especially at under $18 including a
powerful micro. Looks hard to beat, but would have preferred an ARM chip
rather than SPARK. Can't have everything I guess!
Tony
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.
--
Chris Albertson
Redondo Beach, California
On 5/2/14, 7:07 PM, Tony wrote:
On 03/05/2014 02:07, Edesio Costa e Silva wrote:
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
Wow, that is very interesting - especially at under $18 including a
powerful micro. Looks hard to beat, but would have preferred an ARM chip
rather than SPARK. Can't have everything I guess!
THey probably did that because the LEON3 SPARC core is free (developed
by Jiri Gaisler and Sandi Habinc for ESTEC, originally).
I've done a lot with that SPARC: in fact I have one flying in space on
the ISS right now as a software radio (which can do GPS, as a matter of
interest). As soon as the GPS receiver software has the 1pps output,
I'll be building a sort of GPSDO (TCXO driving an NCO, with NCO phase
increment driven by corrections derived from GPS).
There's a good tool chain for the SPARC (GCC), and Aeroflex Gaisler AB
has a mailing list that provides support for questions (even if you're
using the free open source cores). Gaisler also has a huge library of
open source peripherals that you can integrate with the LEON core.
If you want FPGA testbed code and real support, beyond the bare sources
and documentation, you do need to pay for a license, but it's fairly
reasonable ($5-10k, as I recall) if you're developing a "product".
There's also a good open source RTOS available (RTEMS) if you need that;
THere's a variety of Linuxes also available for the SPARC V8, although
it's definitely not a plug and play.
It would be interesting to know what options on the LEON3 the NavSpark
implements (e.g. FPU, etc.). The LEON3 (at least in some flavors) has a
very cool debug support unit (DSU) which can do things like breakpoints
on memory access to specific locations, instruction logging on a
trigger, etc. The DSU can be accessed via serial port and/or JTAG
and/or other interfaces. It's all GDB compatible, of course.
I'd guess that writing C code for the SPARC is not much different than
writing C code for the ARM. Ditto for ASM code.
On Sun, May 4, 2014 at 5:40 PM, Chris Albertson
albertson.chris@gmail.com wrote:
Looks like this is all you'd need for most timing projects. Just add your
favorite OCXO and some wire.
The SPARC (not Spark) is actually a step up from ARM. It was developed by
Sun Microsystems (now Oracle) it is optimized for things like fast context
switching, multi tasking and so on, all the things done by operating
systems. The Sparc V8 does 128 bit floating point, (quad precision) I
wonder if 200Kb RAM is enough to run an older version of SunOS? (a BSD
variant.)
In a previous life, I worked as Unix sysadmin at university. We had
several old Sun3 (motorola 68020 based) and a few Sparcstation based
on Sparc. The first SunOS I worked with was 4.1.1U1 and the last
4.1.4.
I remember even the 68020 were a bit unhappy with 4Mbytes of RAM but
I can't recall if it was a kernel requirement or just the userland
stuff we needed to run on them.
Probably NetBSD can be a more recent and configurable option for
embedded sparcs.
best regards
Frank
On 5/4/14, 8:40 AM, Chris Albertson wrote:
Looks like this is all you'd need for most timing projects. Just add your
favorite OCXO and some wire.
The SPARC (not Spark) is actually a step up from ARM. It was developed by
Sun Microsystems (now Oracle) it is optimized for things like fast context
switching, multi tasking and so on, all the things done by operating
systems. The Sparc V8 does 128 bit floating point, (quad precision) I
wonder if 200Kb RAM is enough to run an older version of SunOS? (a BSD
variant.)
Not all SPARC V8s have FPU: the SPARC spec has a lot of flexibilty in
implmentation: a lot of "if you want X, then it has to do the following
things in the following way, but it's optional"
http://www.gaisler.com/index.php/products/processors/leon3
There's multiprocessor versions. Versions with and without cache,
versions with and without FPU, etc.
If you want a POSIX compliant OS, then RTEMS will definitely fit in
200kbytes. Don't know about all the other options. I've never heard of
a SunOS implementation on LEON, but there's a lot of weird stuff out
there. You do want to make sure that whatever you use is reasonably
complete and of a reasonably recent version (or at least one you're real
familiar with).
There are a fair number of "one-off" ports of some OS or another to the
LEON, but which don't have any continuing support, bug fixes, or users
to contribute. Imagine a grad student doing their thesis on "An
implementation of RSX-11M supervisor mode on the LEON3-MP"... they get
enough done to demonstrate that it works, and they graduate, and who has
a bunch of RSX-11M software anyway.
Are these shipping yet?
Hi
Well some of us still have RSX-11M (and RSTS/E) code floating around …..
Bob
On May 4, 2014, at 12:30 PM, Jim Lux jimlux@earthlink.net wrote:
On 5/4/14, 8:40 AM, Chris Albertson wrote:
Looks like this is all you'd need for most timing projects. Just add your
favorite OCXO and some wire.
The SPARC (not Spark) is actually a step up from ARM. It was developed by
Sun Microsystems (now Oracle) it is optimized for things like fast context
switching, multi tasking and so on, all the things done by operating
systems. The Sparc V8 does 128 bit floating point, (quad precision) I
wonder if 200Kb RAM is enough to run an older version of SunOS? (a BSD
variant.)
Not all SPARC V8s have FPU: the SPARC spec has a lot of flexibilty in implmentation: a lot of "if you want X, then it has to do the following things in the following way, but it's optional"
http://www.gaisler.com/index.php/products/processors/leon3
There's multiprocessor versions. Versions with and without cache, versions with and without FPU, etc.
If you want a POSIX compliant OS, then RTEMS will definitely fit in 200kbytes. Don't know about all the other options. I've never heard of a SunOS implementation on LEON, but there's a lot of weird stuff out there. You do want to make sure that whatever you use is reasonably complete and of a reasonably recent version (or at least one you're real familiar with).
There are a fair number of "one-off" ports of some OS or another to the LEON, but which don't have any continuing support, bug fixes, or users to contribute. Imagine a grad student doing their thesis on "An implementation of RSX-11M supervisor mode on the LEON3-MP"... they get enough done to demonstrate that it works, and they graduate, and who has a bunch of RSX-11M software anyway.
Are these shipping yet?
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.