Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-22 Thread folkert
Hello,

The last 25 hours I measured the jitter of my RPi-with-userspace PPS
processing. In the following graph you'll see those measurements. Each
row is an hour:
http://vps001.vanheusden.com/~folkert/jitter-hm.png
There's some kind of wave in it which I cannot explain: everything not
related to timekeeping (apart from sshd) is disabled on that device. No
cron, no at, not even the processes that monitor the state of the
network port.
Allan deviation: http://vps001.vanheusden.com/~folkert/allandev.png


Folkert van Heusden

-- 
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread David J Taylor

I've now add Folkert's user-mode method to my NTP/Raspberry Pi notes here:

 http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode

Comments and corrections welcomed.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread paul swed
Though I have been tied up with the wwvb stuff this is also on my list of
"to do's".
I have had the RPI up and running and am looking forward to making a small
low power time server.
Thanks
Paul
WB8TSL


On Mon, Jun 17, 2013 at 5:31 PM,  wrote:

>
> ___
> 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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread lists

___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread Dan Drown

Quoting folkert :
:
+127.127.28.1.PPS.0 l48  3770.000 
2.231   0.005

:

I'm surprised that the jitter goes down to 0.005 as I'm now measuring
the PPS from userspace. My program runs with "real time" scheduling and
maximum priority but still the kernel needs to do a context switch etc.
when it receives the pps pulse.



I got similiar results with measuring the PPS timestamp in a userland  
real-time (SCHED_RR) process.  All my hardware is different from  
yours, but it sounds like our software is close in architecture.   
Here's the graph of jitter over two days:   
http://dan.drown.org/stm32/run5/time-variance.png


I'm using the setting "minpoll 4 maxpoll 4" for a 16 second cycle and  
sending the median of those 16 offsets to ntpd.  I'm also collecting  
the max and min offsets, and graphed them here:  
http://dan.drown.org/stm32/run5/usb.png


As a comparison, I tried timestamping in the kernel and put the  
min/max graphs for kernel vs userland side by side:  
http://dan.drown.org/stm32/run6/usb-compare.png


The jitter for the kernel timestamping run is improved as well:  
http://dan.drown.org/stm32/run6/time-variance-compare.png


More info on the userland/kernel comparison:  
http://dan.drown.org/stm32/run6.html


___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread David J Taylor

David,
[]
Ah!
Is the serial over usb working stable on your rpi?
I have lots of problems with usb devices dropping from the usb bus. Also
with a powered hub.
[]

The software compiled and installed without any issues.  I've yet to
figure out how to get it to auto-start - you might like to add that
to your instructions.  I may add a section to my Web page with a
step-by-step guide, as this is so much easier than have to use a
non-standard kernel.


Will do.

For now:

edit /etc/rc.local and add the following (BEFORE the exit 0 statement
and AFTER the #!/bin/sh line):

/usr/local/rpi_gpio_ntp -N 1 -g 8

(replace '8' by the gpio pin)


Folkert van Heusden
===

I'm using the USB GPS right off the USB port, no hub.  I've had no stability 
problems (the GPS stops working after some number of days, 25 typically, but 
maybe that's why it was cheap in any case!  RasPi-3 here has a Wi-Fi dongle 
and DVB-T TV receiver stick connected, and that appears to be stable as 
well.  I'm using a 5.25V 2A PSU as supplied by ModMyPi.com


Thanks for the auto-start information.  I'd previously seen more complicated 
ways of doing this - scripts involving the ability to stop and restart the 
software.  BTW: it's /user/local/bin/rpi_gpio_ntp, for the executable, I 
think.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread folkert

David,

> Fine, Folkert.  The GPIO pins are numbered in your program exactly
> as I would expect, and the diagram just confirms that.  Yes, the
> patched kernel can remain, and PPS operation should be unaffected.
> I was able to drive the two pins (GPIO 18 and GPIO 8) in parallel,
> and I have a signal level of about 2.5 V from a resistive divider.
> I'm actually driving it from a Trimble SMT module where the serial
> is over the USB, and gpsd see the GPS data perfectly.

Ah!
Is the serial over usb working stable on your rpi?
I have lots of problems with usb devices dropping from the usb bus. Also
with a powered hub.

> Thanks for the monitoring output.  The tie delay between the PPS
> leading edge and the change of the monitoring line varies between
> 270 to 390 microseconds, so despite the jitter being reported in the
> 3-5 microsecond range, the "internal clock" is perhaps running about
> 1/3 millisecond behind "real" time.  You will be able to see the
> performance compared to kernel-PPS here:
> 
>  http://www.satsignal.eu/mrtg/performance_raspi-2.php

cool!

> and a comparison with other stratum-1 Raspberry Pi cards here:
> 
>  http://www.satsignal.eu/mrtg/performance_ntp.php
> 
> The software compiled and installed without any issues.  I've yet to
> figure out how to get it to auto-start - you might like to add that
> to your instructions.  I may add a section to my Web page with a
> step-by-step guide, as this is so much easier than have to use a
> non-standard kernel.

Will do.

For now:

edit /etc/rc.local and add the following (BEFORE the exit 0 statement
and AFTER the #!/bin/sh line):

/usr/local/rpi_gpio_ntp -N 1 -g 8

(replace '8' by the gpio pin)


Folkert van Heusden

-- 
Curious about the inner workings of your car? Then check O2OO: it'll
tell you all that there is to know about your car's engine!
http://www.vanheusden.com/O2OO/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread David J Taylor

Check this picture:
http://jeffskinnerbox.files.wordpress.com/2012/11/raspberry-pi-rev-1-gpio-pin-out1.jpg

GPIO pin 8 is in the upper right block with SPI in it.
GPIO 8 (CE0) is written above it. By the numbering on that diagram it is
physical pin 24.
[]
If I remember correctly, the kernel patch uses GPIO 18 (PCM_CLK), so
using GPIO 8 will work fine with the patched kernel.
[]
Maybe, but I'm not an electronics expert (not at all in fact) you can
feed both pins?
[]
Ok, I've uploaded version 0.2 which can do so.
This version can also, in debug mode, show the offset of the local clock
to the PPS timestamp.


Folkert van Heusden


Fine, Folkert.  The GPIO pins are numbered in your program exactly as I 
would expect, and the diagram just confirms that.  Yes, the patched kernel 
can remain, and PPS operation should be unaffected.  I was able to drive the 
two pins (GPIO 18 and GPIO 8) in parallel, and I have a signal level of 
about 2.5 V from a resistive divider.  I'm actually driving it from a 
Trimble SMT module where the serial is over the USB, and gpsd see the GPS 
data perfectly.


Thanks for the monitoring output.  The tie delay between the PPS leading 
edge and the change of the monitoring line varies between 270 to 390 
microseconds, so despite the jitter being reported in the 3-5 microsecond 
range, the "internal clock" is perhaps running about 1/3 millisecond behind 
"real" time.  You will be able to see the performance compared to kernel-PPS 
here:


 http://www.satsignal.eu/mrtg/performance_raspi-2.php

and a comparison with other stratum-1 Raspberry Pi cards here:

 http://www.satsignal.eu/mrtg/performance_ntp.php

The software compiled and installed without any issues.  I've yet to figure 
out how to get it to auto-start - you might like to add that to your 
instructions.  I may add a section to my Web page with a step-by-step guide, 
as this is so much easier than have to use a non-standard kernel.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread folkert
> Thanks, Folkert, that's most helpful!  One thing which is unclear to
> me is what do you mean by pin 8?  Is that a programming number, or
> does it refer to the GPIO header?  I did try and find this in the
> RPi documentation, but it's not clear.

Check this picture:
http://jeffskinnerbox.files.wordpress.com/2012/11/raspberry-pi-rev-1-gpio-pin-out1.jpg

GPIO pin 8 is in the upper right block with SPI in it.
GPIO 8 (CE0) is written above it. By the numbering on that diagram it is
physical pin 24.

> I'm currently using NTP driver type 22 on the RPi I would like to
> test with. If I move to the type 28 driver it doesn't matter that
> PPS is left supported in the Linux kernel.  Please confirm there is
> no need to revert to a kernel without PPS support.  Is there a
> simple way of stopping the OS stealing that GPIO pin - turning off
> PPS support with a simple edit?

If I remember correctly, the kernel patch uses GPIO 18 (PCM_CLK), so
using GPIO 8 will work fine with the patched kernel.

> What might matter, of course, is that I would need to move the
> actual PPS signal to a different pin as kernel-PPS and your program
> would not live together, as both would want to grab that pin.  So it
> may mean making a small hardware change as well if I can't turn off
> PPS support.

Maybe, but I'm not an electronics expert (not at all in fact) you can
feed both pins?

> One thing you might want to try is to pulse one of the GPIO pins in
> response to the rising-edge interrupt you get, to see what the delay
> is when measured by a 'scope.

Ok, I've uploaded version 0.2 which can do so.
This version can also, in debug mode, show the offset of the local clock
to the PPS timestamp.


Folkert van Heusden

-- 
Nagios user? Check out CoffeeSaint - the versatile Nagios status
viewer! http://www.vanheusden.com/java/CoffeeSaint/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread David J Taylor

Hi David,


That sounds good, Folkert - perhaps you might publish the details
somewhere? I'd like to try it myself, but my Linux and C knowledge
is limited.


Here it is:
http://vanheusden.com/time/rpi_gpio_ntp/

Please let me know if anything is unclear: I'll then enhance e.g. the
readme.txt and such.


For comparison, on three RPi cards here with modified kernels to get
PPS from a GPIO pin, using ntpq -pn I see jitter values of 0.002,
0.002 and 0.002/0.004.  The 0.002 seems to be near the sys_jitter
limit as reported from ntpq -c rv.


That's indeed better. The results I see are probably also influenced by
the fact that this RPI also does other things (software defined radio,
camera and measuring the light intensity outside).


Cards 1 and 2 are just doing NTP, the third card is running a data
collector processing signals from a DVB receiver stick, and sending
the derived data over a Wi-Fi link to a PC running Plane Plotter
using the dump1090 program. This gives a CPU load around 35%.  It
would be interesting to know how your version handles a busy RPi.


Hmmm, I'll see if I can setup an RPI which only does the time keeping
and see if that gives better results.


Folkert van Heusden
===

Thanks, Folkert, that's most helpful!  One thing which is unclear to me is 
what do you mean by pin 8?  Is that a programming number, or does it refer 
to the GPIO header?  I did try and find this in the RPi documentation, but 
it's not clear.


I'm currently using NTP driver type 22 on the RPi I would like to test with. 
If I move to the type 28 driver it doesn't matter that PPS is left supported 
in the Linux kernel.  Please confirm there is no need to revert to a kernel 
without PPS support.  Is there a simple way of stopping the OS stealing that 
GPIO pin - turning off PPS support with a simple edit?


What might matter, of course, is that I would need to move the actual PPS 
signal to a different pin as kernel-PPS and your program would not live 
together, as both would want to grab that pin.  So it may mean making a 
small hardware change as well if I can't turn off PPS support.


One thing you might want to try is to pulse one of the GPIO pins in response 
to the rising-edge interrupt you get, to see what the delay is when measured 
by a 'scope.


Many thanks for making this available.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread folkert
Hi David,

> That sounds good, Folkert - perhaps you might publish the details
> somewhere? I'd like to try it myself, but my Linux and C knowledge
> is limited.

Here it is:
http://vanheusden.com/time/rpi_gpio_ntp/

Please let me know if anything is unclear: I'll then enhance e.g. the
readme.txt and such.

> For comparison, on three RPi cards here with modified kernels to get
> PPS from a GPIO pin, using ntpq -pn I see jitter values of 0.002,
> 0.002 and 0.002/0.004.  The 0.002 seems to be near the sys_jitter
> limit as reported from ntpq -c rv.

That's indeed better. The results I see are probably also influenced by
the fact that this RPI also does other things (software defined radio,
camera and measuring the light intensity outside).

> Cards 1 and 2 are just doing NTP, the third card is running a data
> collector processing signals from a DVB receiver stick, and sending
> the derived data over a Wi-Fi link to a PC running Plane Plotter
> using the dump1090 program. This gives a CPU load around 35%.  It
> would be interesting to know how your version handles a busy RPi.

Hmmm, I'll see if I can setup an RPI which only does the time keeping
and see if that gives better results.


Folkert van Heusden

-- 
MultiTail na wan makriki wrokosani fu tan luku den logfile nanga san
den commando spiti puru. Piki puru spesrutu sani, wroko nanga difrenti
kroru, tya kon makandra, nanga wan lo moro.
http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread David J Taylor

From: folkert
[]
I'm surprised that the jitter goes down to 0.005 as I'm now measuring
the PPS from userspace. My program runs with "real time" scheduling and
maximum priority but still the kernel needs to do a context switch etc.
when it receives the pps pulse.

Folkert van Heusden


That sounds good, Folkert - perhaps you might publish the details somewhere? 
I'd like to try it myself, but my Linux and C knowledge is limited.


For comparison, on three RPi cards here with modified kernels to get PPS 
from a GPIO pin, using ntpq -pn I see jitter values of 0.002, 0.002 and 
0.002/0.004.  The 0.002 seems to be near the sys_jitter limit as reported 
from ntpq -c rv.


Cards 1 and 2 are just doing NTP, the third card is running a data collector 
processing signals from a DVB receiver stick, and sending the derived data 
over a Wi-Fi link to a PC running Plane Plotter using the dump1090 program. 
This gives a CPU load around 35%.  It would be interesting to know how your 
version handles a busy RPi.


 http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
 http://www.satsignal.eu/Radio/dump1090.html
 http://www.satsignal.eu/mrtg/performance_raspi-3.php

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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.


Re: [time-nuts] raspberry pi, adafruit gps & ntp

2013-06-17 Thread folkert
> After 51 minutes of ntpd run-time this gives:
> 
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *firewall.intran 192.168.64.2 3 u7   64  3770.560   -0.506   0.493
> -belle.intranet. 192.168.64.2 3 u   58   64  3770.560   -0.470   0.405
> -time2.intranet. 194.109.20.183 u   56   64  3771.034   -1.282   1.392
> +auth1.xs4all.nl 193.67.79.2022 u   28   64  377   17.580   -0.160   0.490
> xSHM(0)  .NMEA.   0 l1   16  3770.000  -359.47  10.670
> +SHM(1)  .PPS.0 l18  3770.0002.964   0.061

After 12,5 hours:

 remote   refid  st t when poll reach   delay   offset  jitter
==
*192.168.64.1192.168.64.2 3 u  280 1024  3770.534   -0.924   0.579
-192.168.64.100  192.168.64.2 3 u  451 1024  3770.625   -0.920   0.560
-192.168.62.129  194.109.22.183 u  278 1024  3771.661   -2.347   0.665
+194.109.22.18   193.67.79.2022 u  295 1024  377   17.719   -0.357   0.978
x127.127.28.0.NMEA.   0 l5   16  3770.000  -309.57  40.640
+127.127.28.1.PPS.0 l48  3770.0002.231   0.005

Looking good!
It is probably selecting 192.168.64.1 due to an accidental "prefer"
keyword for that server in the configuration.
I'm surprised that the jitter goes down to 0.005 as I'm now measuring
the PPS from userspace. My program runs with "real time" scheduling and
maximum priority but still the kernel needs to do a context switch etc.
when it receives the pps pulse.


Folkert van Heusden

-- 
MultiTail er et flexible tool for å kontrolere Logfiles og commandoer.
Med filtrer, farger, sammenføringer, forskeliger ansikter etc.
http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
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] raspberry pi, adafruit gps & ntp

2013-06-16 Thread folkert
Hi,

Ok today my friend Henk (Henk are you still subscribed here?) soldered
the raspberry pi on my adafruit ultimate gps breakout v3. Apart from the
soldering things were totally easy to get to work: only a few tweaks to
cmdline.txt and inittab and the serial data streamed in.
I decided _not_ to patch the kernel after a couple of issues with
missing include files and such. But as only "watching" the nmea stream
gives bad results, I needed to find an alternative for the PPS signal.
So I wrote a little program which watches the GPIO port using poll
(which waits for an interrupt) and then pokes in the shared memory
segment of ntpd.

After 51 minutes of ntpd run-time this gives:

 remote   refid  st t when poll reach   delay   offset  jitter
==
*firewall.intran 192.168.64.2 3 u7   64  3770.560   -0.506   0.493
-belle.intranet. 192.168.64.2 3 u   58   64  3770.560   -0.470   0.405
-time2.intranet. 194.109.20.183 u   56   64  3771.034   -1.282   1.392
+auth1.xs4all.nl 193.67.79.2022 u   28   64  377   17.580   -0.160   0.490
xSHM(0)  .NMEA.   0 l1   16  3770.000  -359.47  10.670
+SHM(1)  .PPS.0 l18  3770.0002.964   0.061

I started the program with statistics logging enabled so I will produce
some nice graphs after a day or so.


Folkert van Heusden

-- 
Feeling generous? -> http://www.vanheusden.com/wishlist.php
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
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.