NTP PPS

[peterwillcn]

Hi,
my apologies. I am using the GPS from SureElectronics.
http://www.sureelectronics.net/goods.php?id=99

It is pretty easy to get up and running, but I am starting to find some limitations, specifically with the control of NMEA sentences. It looks like I cannot configure the sentences. All I need is ZDA, but I presently receive everything but ZDA.

hey Pual
support for nanosecond accurate clock signal output level, need to let the the pps signal instead of linux kernel PLL RTC signal, so that when the lost satellite signal, but also keep the time accurate.
This is HARDPPS Modehttp://www.ntp.org/ntpfaq/NTP-s-algo-kernel.htm.
my ntp web page: http://www.openxid.com/posts/timing-services
best wish

[Paul Kennedy]

Hi,

Good idea to publish my web pages on github. I will certainly do this. I just need to complete the work on PPS then I will get back to the web pages sub-project.

I really like your idea for hardpps. I think breaking it out into a kernel discipline away from the NMEA driver is the correct original approach from Dave Mills. Well thought of!

I guess the hardpps needs a kernel modification for raspi / GPIO? Would you know what that is? Maybe I can use this instead of the good work from chrisprt

regards
pk

[Paul Kennedy]

Hi, Peter,
I started fooling around with github this evening. Looks pretty simple.
https://github.com/secondthoughts

I will push my code there in the near future. Just need to sort out a reliable flow between my pi<-->mac<-->github

I am intrigued with your idea for the hardpps driver. Can you please let me know what kernel mods are required to make this work?

cheers
pk

[joew]

I am hoping to build something similar to what you guys have been working on. Anyone have suggestions on what GPS to get? Accuracy (PPS is a must) and it actually working are the most important things to me FWIW. Thoughts? Caveats to certain units?

[Paul Kennedy]

Hi joew,
I am using a unit from sure: http://www.sureelectronics.net/goods.php?id=99

I chose it because it has a 3.3v output for both NMEA and PPS, which means I can make a direct connection to the pi, rather than a level shifter between. I am not completely 100% happy with the unit, but it seems to be doing the job it is intended to do. My preference would be for a unit with ZDA, but alas, this has RMC, GGA,GLL,GSV. It was a little fiddly getting pps up and running with npt, but the info from the good folks in this forum got me there.

regards pk

[Paul Kennedy]

Joew,
Here is a link to my pi with the above gps. Hopefully the link is self explanatory and you can see for yourself what you would get.

http://secondthoughts.no-ip.org/

[joew]

Paul Kennedy,

Did you need to do anything special to get PPS working over the serial port? I assume you are using a serial <-> usb converter?

[Paul Kennedy]

Hi Joew,
I am no longer using the USB interface as it does not support pps. I made a custom cable for serial + PPS. My offset and jitter errors reduced from 1-5 millisecs to 1-5 microsecs. If a few millisecs is sufficient for you, then USB would be fine. It is certainly easier. Getting microsecs is a much greateer task (recompile the linux kernel etc)

[peterwillcn]

hey chrisprt, Thanks.

[peterwillcn]

Hi, Peter,
I started fooling around with github this evening. Looks pretty simple.
https://github.com/secondthoughts

I will push my code there in the near future. Just need to sort out a reliable flow between my pi<-->mac<-->github

I am intrigued with your idea for the hardpps driver. Can you please let me know what kernel mods are required to make this work?

cheers
pk

hey paul
You real time monitoring very cool....
Support HARDPPS the patch to support 2.6.36 Unfortunately, only research code to modify into 3.1.9-pps + reference file here http://github.com/downloads/ago/linux-2 ... 6-ts17.bz2 I merge the code, and compile the kernel, also without success.
If you are interested, please join http://www.pool.ntp.org/en/join.html to share time,Finally
:thank you very much for sharing code to github https://github.com/secondthoughts.

best wish

[Paul Kennedy]

Hey Peter,
My initial results of the kernel pps suggest microsecond level synchronisation. Do you believe hard pps will be even better? Can you outline the benefits of hardpps over kernel pps?

Good call on the kernel compile process. I bashed away with in on a mac over the weekend, but gave up. Too many errors were being thrown by xcode. Next on my list is to compile natively.

I need the kernel to consume pps on a different GPIO port to the one baked into the existing kernel as I need the GPIO port 16 for a different purpose. A project for the weekend (I think it takes a weekend to compile it

[joew]

Paul Kennedy,

I just received my Sure GPS board, pretty neat. Things seem to be working nicely over the USB. One thing I am curious about is if it is possible to get PPS over the serial via a serial to USB. Also, what sort of custom serial cable did you build? I would really like to give getting PPS working a shot via serial.

-Joe

[Paul Kennedy]

Hi Joe,
it is not possible to get pps via USB (physically not possible - no wires), therefore you must use the pps 'test' pins on the sure card, and connect them to the GPIO.

have a look at this plot. It shows my pi settling after a reboot (I had it off for the weekend)

http://secondthoughts.no-ip.org/www/

it is now at the microsecond level.

If you look at the advanced page, you can see the actual serial + pps pulse data arriving. It lets you know all is really well

Getting the pps hooked up is a little tricky, but if you are persistent it is possible. I will make a cable diagram, but there is a lot more than that (you need a special linux kernel)

[joew]

Paul,

Sorry perhaps I am misunderstanding something. Is it possible to get PPS over serial (with a customized serial cable or something) rather than GPIO? If so, would that still need kernel changes? Additionally if NMEA and PPS are then going over serial would it be possible to use a serial <-> USB converter and get NMEA and PPS from that?

I know that USB has the downside of having a 1ms polling cycle but I am just trying to explore all the options before picking one.

-Joe

[Paul Kennedy]

Hi, serial data is serial data. PPS is merely a low voltage pulse at regular intervals. On a regular PC, it is feasible to hook up a PPS pulse to the DCD handshake lines (typically pin1) of COM port, but a pi does not have a regular serial port, so the answer to your question is a clear no.

And in relation to USB, the answer is also no. Check out the USB specifications on wikipedia, and you will see there are no handshake lines.

so if you really want better than a couple of millisecs, your best option (as far as I know) is to recompile the linux kernel.

[joew]

Thanks for clearing that up for me Paul.

[Paul Kennedy]

No problem. I suspect for most situations, millisecond timekeeping is sufficient. The nice thing about ntp is it will prevent your clock jumping about, and slew rather than step your clock. This is really useful for downstream apps which typically expect time to march forwards.
Pk

[chrisprt]

All,

I've been working on a hardware solution for this for the past month (I'm terrible at electrical engineering), and I've finally got it working. For those interested, I've attached the last 3 days' loopstats in graph form.

I think stability could be a lot better, but the pi is currently housed in a room that fluctuates quite a bit in temperature. It moves from around 70F to 90F or more throughout the day. I also have various other processes running on the pi. I've had quite a few days that stayed within 20 microseconds of perfect.

[chrisprt]

And for people interested in my build, Here's a screenshot displaying the major parts:

http://i.imgur.com/aWV8Q.png
It's composed of an Adafruit raspberry pi prototyping plate, a simple DB9 breadboard connector, an LD33V voltage regulator, and a MAX3232 SMD chip.

The hardest part was soldering the MAX3232 chip in and dealing with the 5 0.1uF capacitors on the board. The voltage regulator is regrettably large and stuck there, but I didn't have anything smaller to do the job and I didn't want to wait another week for a smaller one to arrive.

[chrisprt]

All,

I saw the posts asking for a new kernel image and realized that I went through the arduous process a few weeks ago. I've compiled the newest kernel as of about 3 weeks ago:

Code: Select all

pi@raspberrypi /lib/modules $ uname -a
Linux raspberrypi 3.2.27-pps-g965b922-dirty #1 PREEMPT Sat Sep 22 16:30:50 EDT 2012 armv6l GNU/Linux

The GPIO pin that accepts the pulses is GPIO 24.

Taking aquarat's lead, I've hosted the kernel and modules on google drive:
kernel: https://docs.google.com/open?id=0BznvtP ... HEtUDRpUEU
modules: https://docs.google.com/open?id=0BznvtP ... mxFTktYM0E

It seems like people are interested in recompiling the kernel, so when I get home from work today I'll modify this post and add a diff patch file so that people can just download the latest kernel and run the patch to have PPS support for the pi kernel.

[Paul Kennedy]

Hi Chris,
Thanks for your plots. Mine can be found at http://secondthoughts.no-ip.org/ntp/index.php

I rarely see my pi drift off more than a couple of microsecs, and I have pretty much followed your guide, so am interested why we see a difference. I am using the suregps which has a 3.3v pps so no need for Caps or level shifters. Just a cable.
I thought you also had the suregps? Maybe I got lucky

It was a bit fiddly getting it going, but has run perfectly the past few weeks. I am now testing how stable client computers behave consuming ntp on my pi. So far so good. My Mac seems to sync up just fine and I get well under a millisecond even via wifi.

Next step is to split my cable so I can simultaneously run an LCD panel so I can find the ip with ease

[chrisprt]

Hi Chris,
Thanks for your plots. Mine can be found at http://secondthoughts.no-ip.org/ntp/index.php

I rarely see my pi drift off more than a couple of microsecs, and I have pretty much followed your guide, so am interested why we see a difference. I am using the suregps which has a 3.3v pps so no need for Caps or level shifters. Just a cable.
I thought you also had the suregps? Maybe I got lucky

It was a bit fiddly getting it going, but has run perfectly the past few weeks. I am now testing how stable client computers behave consuming ntp on my pi. So far so good. My Mac seems to sync up just fine and I get well under a millisecond even via wifi.

Next step is to split my cable so I can simultaneously run an LCD panel so I can find the ip with ease

Paul,
that's pretty impressive. What version of linux are you using? Before using the pi, I found that most of the jitter was caused by the OS I was using. Debian has usually matched what I'm seeing (20usec), while FreeBSD (unfortunately not available on the pi currently) was rock solid - usually only off by 1usec max. I'm also surprised that you're able to maintain sub millisecond accuracy for remote machines since the ethernet port for the pi is synced at 1 millisecond per poll, as far as I know.

I'm using the Garmn GPS 18x LVC. You may have made the better choice if using the suregps allows you to avoid all the circuitry I'm using. I see that it's a popular model. Is there anywhere cheap to pick them up? I'd be tempted to try it to see if I get any better results.

I'm also wondering if the non-hf kernel is causing some jitter. I'm running raspbian hard-float, but the kernel was compiled using armel (soft-float). I couldn't find the needed hf compiler when I was compiling the most recent kernel.

[Paul Kennedy]

Hi,
I am using the kernel you built

I purchased the suregps direct from the manufacturer at: http://www.sureelectronics.net/goods.php?id=99

I was not aware the network stack has a 1 millisec limitation. Where did you come across that?

Maybe NTP on the client PC is taking it into account via the round trip delay algorithm.

thanks for the tip.

[chrisprt]

As promised, I've attached the pps.patch file which should aid anyone who plans to recompile the kernel with PPS support. Download the latest raspberry pi kernel, apply this patch from the linux directory, and then go through the normal compilation process. Make sure to enable all the relevant PPS driver modules in the menuconfig pre-build.

Also, this patch targets GPIO pin 24 for pulse syncing. If you'd like to change that to a different pin, just search the patch for "gpio_pin" and change it accordingly.

[peterwillcn]

http://www.ntp.org/ntpfaq/NTP-s-algo-kernel.htm

hardpps() is called with two parameters, the absolute time of the event, and the time relative to the last pulse. Both times are measured by the system clock.

The first value is used to minimize the difference between the system clock's start of a second and the external event, while the second value is used to minimize the difference in clock frequency. Normally hardpps() just monitors (e.g. STA_PPSSIGNAL, PPS frequency, stability and jitter) the external events, but does not apply corrections to the system clock.