GPS module recommendation for Pi timing
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
Is this application for a product that you will be selling in quantity and
producing over time, or a one-off or low volume application?
On Fri, Mar 13, 2020 at 10:07 AM Brian Lloyd brian@lloyd.aero wrote:
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
--
--Jim Harman
Hi Brian,
We published this back in 2016 but it provides an analysis on the stability of the STC on the first three generations of Raspberry Pi as well as the stability profile of the uBlox M8Q:
https://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
Hopefully it will give you a starting point if nothing else :)
Kind Regards,
Peter Membrey
----- Original Message -----
From: "Brian Lloyd" brian@lloyd.aero
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Sent: Friday, 13 March, 2020 22:06:07
Subject: [time-nuts] GPS module recommendation for Pi timing
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On Fri, Mar 13, 2020 at 9:20 AM Jim Harman j99harman@gmail.com wrote:
Is this application for a product that you will be selling in quantity and
producing over time, or a one-off or low volume application?
It will have a run of at least 100 units, maybe more. I would like it to
have a decent lifetime in case we need to make more.
On Fri, Mar 13, 2020 at 10:07 AM Brian Lloyd brian@lloyd.aero wrote:
I have an application where I need to synchronize the internal TOD RTC
in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via
GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the
M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like
this?
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
Hi
Pretty much any generic GPS module will get you to 1 ms without a lot
of effort. There is certainly no need for the M9F or M9T sort of parts.
A typical module will deliver a pps signal that is better than 100 ns as
far as timing.
How good you can do via serial on a Pi depends a bit on how loaded it
is. “Microsecond" level performance is possible.
I’d target low cost over performance in this case …..
Are you laying out a board for your gizmo? If so, there are a number of
drop in solutions for not a whole lot of money.
Bob
On Mar 13, 2020, at 10:06 AM, Brian Lloyd brian@lloyd.aero wrote:
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On Fri, Mar 13, 2020 at 2:07 PM Brian Lloyd brian@lloyd.aero wrote:
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
If you are using a Pi, then you are limited to the Pi onboard crystal,
however as long as the GPS signal is "good", and the temperature is
stable, <1ms should be easily acheivable (my logs show ~20us is) while
GPS is running, however without GPS, the drift can be significant.
Although you might not need external NTP, the "simple" stack would be
ue gpsd to listen to the GPS and PPS, and then ntp/ntpsec/chrony to
set the time.
If you wanted a "plug and play" solution, the uptronics board is the
probably simplest.
https://store.uputronics.com/index.php?route=product/product&product_id=81,
otherwise for 1ms, there are many suppliers of uBlox modules.
Cheers
Arne
On Fri, Mar 13, 2020 at 9:59 AM Peter Membrey peter@membrey.hk wrote:
Hi Brian,
We published this back in 2016 but it provides an analysis on the
stability of the STC on the first three generations of Raspberry Pi as well
as the stability profile of the uBlox M8Q:
https://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
Thank you. Perfect. Reading now.
Bob KB8TQ: We are laying out our own board as it will be doing other things
besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
will go directly to a GPIO pin, assuming that will provide the best
performance.
Hal Murray: Yes, I am trying to discipline the system clock.
Arne: Yes, I was considering using gpsd.
Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
programmable output from the Ublox.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
Hi
If you are laying out a board and building quite a few, shop for one of the
< $10 modules. What’s out there changes almost month to month so
research is needed. As long as you get a PPS out, and a fairly rational
serial i/o, mating them up should not be to crazy.
You might spend the money you save on the GPS buying a “real” RTC
chip ….. They aren’t crazy expensive and mate into the Pi environment
pretty easily. GPS can come and go unless the antenna is in a really
good location.
Bob
On Mar 13, 2020, at 11:17 AM, Brian Lloyd brian@lloyd.aero wrote:
On Fri, Mar 13, 2020 at 9:59 AM Peter Membrey peter@membrey.hk wrote:
Hi Brian,
We published this back in 2016 but it provides an analysis on the
stability of the STC on the first three generations of Raspberry Pi as well
as the stability profile of the uBlox M8Q:
https://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
Thank you. Perfect. Reading now.
Bob KB8TQ: We are laying out our own board as it will be doing other things
besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
will go directly to a GPIO pin, assuming that will provide the best
performance.
Hal Murray: Yes, I am trying to discipline the system clock.
Arne: Yes, I was considering using gpsd.
Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
programmable output from the Ublox.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
If your product depends on monotonic times, there are a lot of good reasons
for using NTPD. It will slew the clock rather than jump it which can be
hugely important for many applications if there is some need for data to be
accumulated with monotonic timestamps. It will also apply good drift
correction for times when sky and satellites might not be visible (which in
terms of real world products is very common.
You prominently mention both milliseconds and TOD RTC. Note that all common
RTC chips (e.g. DS1307) only directly read out time to the previous second.
They do not read out directly for milliseconds although you can try to
interpolate based on seconds edge.
Tim N3QE
On Fri, Mar 13, 2020 at 10:07 AM Brian Lloyd brian@lloyd.aero wrote:
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On 3/13/20 8:50 AM, Tim Shoppa wrote:
If your product depends on monotonic times, there are a lot of good reasons
for using NTPD. It will slew the clock rather than jump it which can be
hugely important for many applications if there is some need for data to be
accumulated with monotonic timestamps. It will also apply good drift
correction for times when sky and satellites might not be visible (which in
terms of real world products is very common.
You prominently mention both milliseconds and TOD RTC. Note that all common
RTC chips (e.g. DS1307) only directly read out time to the previous second.
They do not read out directly for milliseconds although you can try to
interpolate based on seconds edge.
Tim N3QE
On Fri, Mar 13, 2020 at 10:07 AM Brian Lloyd brian@lloyd.aero wrote:
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
I've been working on a similar project - using a battery powered
beaglebone and a GPS with an RTL-SDR to build an interferometer.
I was able to get a NEO-7 hooked up, chrony installed and running, etc.
on 4 nodes. Attached are screen shots running pdsh to see all 4 nodes
what I have not been able to do is figure out how to sync the RTL-SDR
(or, at least, get a 1pps hack into the data stream) - I might just go
to a fancier RF interface like a Lime mini.
Hi,
For your application and 1 ms accuracy ,the problem, this is a long time that i have made that, it is in the output and the information on a serial link or GPIO on a no Real Time OS. Even if you don't want using USB in an internal the PI use an USB serial port. There are some parameter in the USB driver to manage the answer.
For the GPIO it is also a driver to manage.
To have a good accuracy the best way is to use RTOS or best a metal OS to manage the GPIO.
Or allow some slope accepted modular time.
Thierry M
-----Message d'origine-----
De : time-nuts [mailto:time-nuts-bounces@lists.febo.com] De la part de Brian Lloyd
Envoyé : vendredi 13 mars 2020 15:06
À : Discussion of precise time and frequency measurement
Objet : [time-nuts] GPS module recommendation for Pi timing
I have an application where I need to synchronize the internal TOD RTC in a
raspberry pi and need to pick a GPS module. We are building our own
hardware but still using the Pi so interconnection will be via GPIO/serial.
We won't try to use USB.
This is not an NTP application. These units will be in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.
The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.
Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?
Thanks.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hi
One as yet un-asked question:
Is this a dynamic or a static application? If static, is there time to do a
proper survey of the location? Normally that all matters for accuracy.
In this case it mostly matters in terms of dropouts / code slips. A
code slip would indeed nuke your “one ms” budget.
Bob
On Mar 13, 2020, at 11:17 AM, Brian Lloyd brian@lloyd.aero wrote:
On Fri, Mar 13, 2020 at 9:59 AM Peter Membrey peter@membrey.hk wrote:
Hi Brian,
We published this back in 2016 but it provides an analysis on the
stability of the STC on the first three generations of Raspberry Pi as well
as the stability profile of the uBlox M8Q:
https://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
Thank you. Perfect. Reading now.
Bob KB8TQ: We are laying out our own board as it will be doing other things
besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
will go directly to a GPIO pin, assuming that will provide the best
performance.
Hal Murray: Yes, I am trying to discipline the system clock.
Arne: Yes, I was considering using gpsd.
Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
programmable output from the Ublox.
--
Brian Lloyd
706 Flightline
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On 3/13/20 8:17 AM, Brian Lloyd wrote:
On Fri, Mar 13, 2020 at 9:59 AM Peter Membrey peter@membrey.hk wrote:
Hi Brian,
We published this back in 2016 but it provides an analysis on the
stability of the STC on the first three generations of Raspberry Pi as well
as the stability profile of the uBlox M8Q:
https://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
Thank you. Perfect. Reading now.
Bob KB8TQ: We are laying out our own board as it will be doing other things
besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
will go directly to a GPIO pin, assuming that will provide the best
performance.
Hal Murray: Yes, I am trying to discipline the system clock.
Arne: Yes, I was considering using gpsd.
Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
programmable output from the Ublox.
I've been working on a similar project - using a battery powered
beaglebone and a GPS with an RTL-SDR to build an interferometer.
I was able to get a NEO-7 hooked up, chrony installed and running, etc.
on 4 nodes.
what I have not been able to do is figure out how to sync the RTL-SDR
(or, at least, get a 1pps hack into the data stream) - I might just go
to a fancier RF interface like a Lime mini.