Linux PPS clues?
Hi all,
I need some clues on the Linux PPS subsystem.
I am trying to take some timestamps of events on a GPIO using an ARM
SBC, and noticed that the kernel linux can be interfaced to a PPS
signal, wanted to sync another GPIO to a GPS receiver for time
reference. I need to know how much precise this system can be. How much
resolution can I obtain with a cheap receiver (maximum quantization
frequency)?
Formulas are well accepted.
Thanks,
Ilia.
Yo Ilia!
On Thu, 20 Oct 2016 06:15:39 +0000
Ilia Platone info@iliaplatone.com wrote:
I am trying to take some timestamps of events on a GPIO using an ARM
SBC, and noticed that the kernel linux can be interfaced to a PPS
signal, wanted to sync another GPIO to a GPS receiver for time
reference.
You should check out the gpsd time howto, and ntpsec.
I need to know how much precise this system can be. How
much resolution can I obtain with a cheap receiver (maximum
quantization frequency)?
On average, on a RasPi 3, you can expect about
Formulas are well accepted.
How about a graph, or two? See attached. From the histogram, I suspect the
granularity is about 200 nano sec. From the offset graph you can
see how the offset jumps.
Here is the offset data on PPS v. the system clock:
Percentiles......
Min 1% 5% 50% 95% 99% Max
-21.645 -2.587 -0.834 -0.020 0.991 0.991 13.557 µs
Ranges......
90% 95% StdDev Mean Units
1.825 5.318 0.850 -0.006 µs
Or see a lot more live graphs here: https://pi4.rellim.com/day/
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
On Thu, 20 Oct 2016 06:15:39 +0000
Ilia Platone info@iliaplatone.com wrote:
I need some clues on the Linux PPS subsystem.
I am trying to take some timestamps of events on a GPIO using an ARM
SBC, and noticed that the kernel linux can be interfaced to a PPS
signal, wanted to sync another GPIO to a GPS receiver for time
reference. I need to know how much precise this system can be. How much
resolution can I obtain with a cheap receiver (maximum quantization
frequency)?
Using GPIO for precision timing is the wrong approach. If you are
already using an ARM processor, it is much better to use the time/capture
unit to time events. These are counters which run usually with 50-200MHz
giving you a resolution of 5ns to 20ns. Their advantage is that you are
not limited by the interrupt latency and (mis)behaviour of the software,
but handle everything in hardware.
Attila Kinali
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
Thank you.
I quickly read the gpsd howto and it explains what I want to do using
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but
the informations of the live graphs page are precise down to the ns: are
these averaged?
What do you intend for granularity? Consider that I'm a newbie in
frequency/time specific terms.
Regards,
Ilia.
On 10/20/16 07:02, Gary E. Miller wrote:
Yo Ilia!
On Thu, 20 Oct 2016 06:15:39 +0000
Ilia Platone info@iliaplatone.com wrote:
I am trying to take some timestamps of events on a GPIO using an ARM
SBC, and noticed that the kernel linux can be interfaced to a PPS
signal, wanted to sync another GPIO to a GPS receiver for time
reference.
You should check out the gpsd time howto, and ntpsec.
I need to know how much precise this system can be. How
much resolution can I obtain with a cheap receiver (maximum
quantization frequency)?
On average, on a RasPi 3, you can expect about
Formulas are well accepted.
How about a graph, or two? See attached. From the histogram, I suspect the
granularity is about 200 nano sec. From the offset graph you can
see how the offset jumps.
Here is the offset data on PPS v. the system clock:
Percentiles......
Min 1% 5% 50% 95% 99% Max
-21.645 -2.587 -0.834 -0.020 0.991 0.991 13.557 µs
Ranges......
90% 95% StdDev Mean Units
1.825 5.318 0.850 -0.006 µs
Or see a lot more live graphs here: https://pi4.rellim.com/day/
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
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.
--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999
On Thu, 20 Oct 2016 07:52:10 +0000
Ilia Platone info@iliaplatone.com wrote:
I quickly read the gpsd howto and it explains what I want to do using
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but
the informations of the live graphs page are precise down to the ns: are
these averaged?
What do you intend for granularity? Consider that I'm a newbie in
frequency/time specific terms.
If you are still going for the synchronization of telescopes, then
you definitly don't want a rpi. Go for one of the more industrial
oriented boards (the original rpi is basically just a graphics card with
an attached arm processor as USB controller). Like the beaglebone,
or probably even better for the Vybrid based boards (Colibry family)
from Toradex (has less EMI noise than the BBB).
Attila Kinali
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
Thank you Attila :)
Actually the system for timestamping is at design stage yet.
I expect an event rate of about 100kcps, but I found little infos about
the bandwidth variable for the receivers.
Since I don't want to fill in the list with off-topic posts, just limit
in time-related quests.
There's not any problem for the board I'll use, I referenced the
raspberry because it's well known. My questions are for the software
side and relative efficiency of the system.
Best Regards,
Ilia.
On 10/20/16 08:01, Attila Kinali wrote:
On Thu, 20 Oct 2016 07:52:10 +0000
Ilia Platone info@iliaplatone.com wrote:
I quickly read the gpsd howto and it explains what I want to do using
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but
the informations of the live graphs page are precise down to the ns: are
these averaged?
What do you intend for granularity? Consider that I'm a newbie in
frequency/time specific terms.
If you are still going for the synchronization of telescopes, then
you definitly don't want a rpi. Go for one of the more industrial
oriented boards (the original rpi is basically just a graphics card with
an attached arm processor as USB controller). Like the beaglebone,
or probably even better for the Vybrid based boards (Colibry family)
from Toradex (has less EMI noise than the BBB).
Attila Kinali
--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999
On Thu, 20 Oct 2016 08:15:03 +0000
Ilia Platone info@iliaplatone.com wrote:
Actually the system for timestamping is at design stage yet.
I expect an event rate of about 100kcps, but I found little infos about
the bandwidth variable for the receivers.
100kHz event rate is quite a bit. You will need a relatively fast
processor to handle that. 200MHz would be probably the minimum
with a uC, I guess 400MHz with a linux based system.
Since I don't want to fill in the list with off-topic posts, just limit
in time-related quests.
There's not any problem for the board I'll use, I referenced the
raspberry because it's well known.
Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O
My questions are for the software
side and relative efficiency of the system.
The software side varies with the CPU and the subsystem used.
I don't know what linux offers as facility to use the timer
units. A quick glance at the code didnt reveal anything.
Worst case you would have to write a small driver (probably
100-200 lines of code) for it.
If you want, I can ask some of my friends to see what is available for
this kind of stuff.
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
From: Attila Kinali
[]
Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O
[]
Attila Kinali
Actually, of the 15 Raspberry Pi cards I have only one is used in a graphics
application.
On the positive side they work very well with external devices for control
and measurement, and have a huge amount of software and hardware support for
a vast range of devices which makes for fast and easy development. On the
negative side, certainly they are not the fastest of devices, although the
current quad-core RPi3 is capable of handling thousands of messages per
second, and having Ethernet over USB won't give the lowest jitter if
sub-millisecond timing is important.
I will be interested to see what is recommended for a 100 kHz event rate.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
the only essential task is sampling and logging into an usb drive. the
timestamps must be as accurate as possible with the GPS reference clock.
This for an undefined number of devices.
Since this 100KHz is a starting point, I must know how fast can be the
event rate. Linux Clock tick on some boards should be 100ns for example,
giving a maximum event rate of 5MHz.
I must only ensure if the kpps/gpsd system can have a good accuracy for
5-8 hours. I own a dozen of the Glomation sbc3130s boards (100MHz /
12MHz GPIO speed / NXP3130 uC). If these boards can do this work, I'd be
happy.
Best regards,
Ilia.
On 10/20/16 09:59, David J Taylor wrote:
From: Attila Kinali
[]
Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O
[]
Attila Kinali
Actually, of the 15 Raspberry Pi cards I have only one is used in a
graphics application.
On the positive side they work very well with external devices for
control and measurement, and have a huge amount of software and
hardware support for a vast range of devices which makes for fast and
easy development. On the negative side, certainly they are not the
fastest of devices, although the current quad-core RPi3 is capable of
handling thousands of messages per second, and having Ethernet over
USB won't give the lowest jitter if sub-millisecond timing is important.
I will be interested to see what is recommended for a 100 kHz event rate.
Cheers,
David
--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999
Yo Ilia!
On Thu, 20 Oct 2016 07:52:10 +0000
Ilia Platone info@iliaplatone.com wrote:
I quickly read the gpsd howto and it explains what I want to do using
kpps on a raspberry. From there I can see a typical accuracy of 1uS,
but the informations of the live graphs page are precise down to the
ns: are these averaged?
Well, that is a complicated question. The graphs are directly from the
ntpd logs. No modification to the data except scaling. But ntpd
itself is sort of a big PLL. Also the way ntpd handles PPS is somewhat
complicated. There is an algorithm for ignoring outlier pulses, and the
accepted puless are averaged in the mipoll interval before being
logged or input into the PLL
But, bottom line, you can pretty much expect the RasPi sysclock to be
stable and accurate, to one standard deviation of better than 1 µs. 90%
of the time, to better than 2 µs. Better than 5.5 µs for 98% of the
time.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588