Raspberry Pi Forums

Posted: **Fri Dec 30, 2011 5:06 pm**

My first project for the Rpi will be to implement a stratum 1 NTP server for the house using a low cost gps from spark fun.

My question is, can the gpio pins be used for the pps signal?

It may be a matter of recompiling the ntp source to look at a different pin, which doesnt really scare me.

all I can say is gimme gimme gimme some pi.

Posted: **Fri Dec 30, 2011 6:03 pm**

k.elliott said:

My question is, can the gpio pins be used for the pps signal?

I see no reason why not – and good idea for a project, I may just do that as well!

- Always wanted to try playing around with GPS a bit.

The thing to watch out for is the voltage of the PPS signal the GPS module provides.

The RPi GPIO is 3.3V only – it is not 5V tolerant.

- Don't forget that you will need a 3.3V serial port as well, unless you go for a USB version.

A lot of the modules seem to be 3.3V CMOS for both UART and PPS anyway, which is good.

Posted: **Fri Dec 30, 2011 6:31 pm**

Thanks, I have been doing some research and there seems to be several implementations of the "LinuxPPS" daemon which works directly with the kernel. Then fire up an ntp server and you are good to go. I wish I had the components so that I could bash on it this weekend.

Posted: **Sat Dec 31, 2011 12:09 am**

To get PPS working, one needs to add PPS support into a driver that receives an interrupt. Adding PPS code to a driver that is already interrupt driven, such as a PC parallel port, is about an hour's work. I'm slow. I test.

The question will be whether there already is pin-change interrupt in the GPIO driver (I'm pessimistic), or if the interrupt controller must be configured for external interrupt. In that case it's likely a dead end.

Until release, it's purely guesswork whether it is doable.

Posted: **Sat Dec 31, 2011 12:23 am**

Wiki page says "Each GPIO can interrupt, high/low/rise/fall/change.", so it should be fairly easy to do, though it may require a little kernel hacking. USB serial should be good enough to get the time, with an interrupt setting the start of second.

Even better would be if you can start a timer on interrupt (http://www.febo.com/time-freq/.....index.html).

Depending on the stability of the chosen crystal (and your level of obsession) you might want to investigate splicing a better oscillator (TCXO, OCXO, GPSDO, Rb, etc).

Posted: **Wed Feb 08, 2012 7:33 pm**

Hi there, I found this thread while searching for related info on google. There is indeed a PPS-GPIO client, see http://groups.google.com/group.....53fa14c298. It has been in mainline kernel since 3.2. You need to select PPS and PPS-GPIO client while doing menuconfig. I was able to register gpio1_31 (I hard-coded it as gpio_pin=63) on another ARM machine with an appropriate level shifter.

I don't have a RPI to play with. You would need to add the following to your board support package (probably in arch/arm/ to register the gpio pin that will be used for PPS:

add
#include <linux/pps-gpio.h>

add
/* PPS-GPIO platform data */
static struct pps_gpio_platform_data pps_gpio_info = {
.assert_falling_edge = false,
.capture_clear= false,
.gpio_pin=63,
.gpio_label="PPS",
};

static struct platform_device pps_gpio_device = {
.name = "pps-gpio",
.id = -1,
.dev = {
.platform_data = &pps_gpio_info
},
};

static void pps_init(int evm_id, int profile)
{
int err;

err = platform_device_register(&pps_gpio_device);
if (err) {
pr_warning("Could not register PPS_GPIO device");
}
}

You will need to call pps_init in the configuration routine along with the calls to init other devices on the board.

dmesg will show the pps registration during boot up and show the pps capture events if you have pps debugging turned on.

[ 0.080893] pps_core: LinuxPPS API ver. 1 registered
[ 0.080906] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 2.030757] pps_core: source pps-gpio.-1 got cdev (253:0)
[ 2.030773] pps pps0: new PPS source pps-gpio.-1
[ 2.035711] pps pps0: Registered IRQ 223 as PPS source

..... later, after attaching the pps line from GPS

[ 8524.440161] pps pps0: capture assert seq #1531
[ 8525.439891] pps pps0: PPS event at 1328721600.905551895
[ 8525.439913] pps pps0: capture assert seq #1532
[ 8526.440188] pps pps0: PPS event at 1328721601.905827102
[ 8526.440232] pps pps0: capture assert seq #1533

Posted: **Thu Jul 05, 2012 1:37 pm**

When you have configured the pps_gpio in your desired GPIO, you can see the signal values using the ppstest application.

But I'm having some problem to configure ntp (ntp.conf) to detect it. Have you get it?

Thanks.

Posted: **Fri Jul 13, 2012 6:12 pm**

I merged the drivers/pps section from the linux mainline into the raspberry pi kernel and recompiled the kernel successfully. I loaded the module by running sudo modprobe pps-gpio, but I unfortunately received this error:

Code: Select all

pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
pps-gpio: failed to request GPIO 63
pps-gpio: probe of pps-gpio failed with error -22

Any idea why that would happen? I haven't done any other GPIO work, and I haven't hooked anything up to it yet. Is there something that I need to do to make sure the GPIO is functional?

Posted: **Fri Jul 13, 2012 7:24 pm**

I guess I can't edit existing posts unfortunately. I figured out the solution for this.

I noticed that goodx's code, while working, referenced a pin 63. I'm not sure why this was done, but for the pi there are only 26 pins. I tried pin 26, and received the following in dmesg:

Code: Select all

pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
pps_core: source pps-gpio.-1 got cdev (252:0)
pps pps0: new PPS source pps-gpio.-1
pps pps0: Registered IRQ 111 as PPS source

Posted: **Wed Jul 18, 2012 9:18 pm**

I'm interested in getting a PPS input to RPi going, not sure exactly how to start with building a new R-Pi kernel. Is there a tutorial on this process somewhere?

I do know that the R-Pi GPIO pin numbers can be counted three or four different ways. There are only 26 GPIO pins on the R-Pi board (some of which are no-connects) but the numbering on the Broadcom SOC is very different; the SoC has a large number of GPIO pins, not all of them are in use on the R-Pi. See for example http://elinux.org/RPi_BCM2835_GPIOs
That table has the BCM2835 chipset numbering going from GPIO0 to GPIO53.

Posted: **Fri Jul 20, 2012 5:53 pm**

jbeale wrote:I'm interested in getting a PPS input to RPi going, not sure exactly how to start with building a new R-Pi kernel. Is there a tutorial on this process somewhere?

As far as I know, there is none.
Here's what I did (huge thanks to goodx for the help in doing this):
Prepare to compile the raspberry pi's kernel as instructed by this page:
http://elinux.org/RPi_Kernel_Compilation

Once you have the pi's kernel downloaded locally, merge everything under the drivers/pps section of the main linux branch (https://github.com/mirrors/linux/tree/m ... rivers/pps) into the pi's kernel. You'll also need include/linux/pps-gpio.h from the main kernel, copy it into pikernel/include/linux. Overwrite files as needed.

I can't attach .c files, so I'm guessing there is a rule against it, so you'll unfortunately have to modify the architecture code yourself.

Head over to pikernel/arch/arm/mach-bcm3807 and modify bcm3807.c. For this you'll want to include the pps-gpio.h file that you copied over earlier (#include <linux/pps-gpio.h>), and also add

Code: Select all

/* PPS-GPIO platform data */
static struct pps_gpio_platform_data pps_gpio_info = {
.assert_falling_edge = false,
.capture_clear= false,
.gpio_pin=9,
.gpio_label="PPS",
};

static struct platform_device pps_gpio_device = {
.name = "pps-gpio",
.id = -1,
.dev = {
.platform_data = &pps_gpio_info
},
};

to the file. I added it right in the #ifdef CONFIG_BCM2708_GPIO section.
Finally, search for

Code: Select all

bcm_register_device(&bcm2708_gpio_device);

and right after that put

Code: Select all

bcm_register_device(&pps_gpio_device);

Take note at all of the options in this struct, because they do matter. I've already confirmed that .gpio_pin represents the actual GPIO pin on the pi, not the pin numbering. so, in the example above, I chose to use GPIO 9, which is P1-21.

After you're done, save the file and exit. Configure the kernel appropriately, making sure that you're including the PPS GPIO drivers as well as PPS support (modules), and build the kernel normally. At this point you can follow all the normal procedures for building the Pi.

Once you've copied over the kernel, firmware, and drivers, and then are able to boot the pi, run

Code: Select all

sudo modprobe pps-gpio

to load the module. Check dmesg, and if your pulse is setup already, try using the pps-tools available at http://www.linuxpps.org/gitweb/?p=pps-tools;a=summary to test the pulse.

If this all sounds like an awful amount of work, I could potentially share my already compiled kernel. It's only 4MB, so if you're interested, I can pop it on a file sharing site.

Eventually I hope to make a more readable guide, but since I don't have it completely working, I haven't got that far yet.

Posted: **Sat Jul 21, 2012 12:16 am**

Thank you very much for that post on making the kernel. Everything there seems clear (although I haven't yet tried to actually compile a new RPi kernel). What part is not yet working for you? I thought from your previous post, you had got past the non-existent GPIO pin 63 problem?

Posted: **Sat Jul 21, 2012 1:00 am**

jbeale wrote:Thank you very much for that post on making the kernel. Everything there seems clear (although I haven't yet tried to actually compile a new RPi kernel). What part is not yet working for you? I thought from your previous post, you had got past the non-existent GPIO pin 63 problem?

I have. I detail my current status in http://www.raspberrypi.org/phpBB3/viewt ... 8&p=129224.

At the moment I am detecting the pulse, but as the ATOM driver it's being marked as a false ticker (it drops 1 out of every 20 seconds or so), and I can't get the serial UART to work. I'm also using simple resistors, so I'm thinking about upgrading to a better level converter for the UART/pulse.

If I can make one more suggestion, when compiling bcm2708.c,

Code: Select all

.capture_clear= false,

Make that true;

I believe it helps the system maintain the pulse a little better.

Posted: **Tue Jul 31, 2012 8:23 am**

Hi Chrisprt

Would it be possible for you to post your kernel to a file-sharing site ? I have a Trimble Thunderbolt-E GPS/OCXO which currently runs into a an x86 machine and forms part of the NTP Pool project... it would be great to hand this duty off to a Pi

.

Side note... my Raspberry Pis automatically detected the presence of my NTP server the first time I turned them on, which made me very happy.

Posted: **Thu Aug 02, 2012 2:07 am**

aquarat wrote:Hi Chrisprt

Would it be possible for you to post your kernel to a file-sharing site ? I have a Trimble Thunderbolt-E GPS/OCXO which currently runs into a an x86 machine and forms part of the NTP Pool project... it would be great to hand this duty off to a Pi .

Side note... my Raspberry Pis automatically detected the presence of my NTP server the first time I turned them on, which made me very happy.

Sounds great. I'd love to get someone else working on this.

The following kernel and modules are based from the raspbian install image provided by raspberrypi.org. If you aren't running raspbian (debian wheezy I believe), then you need to install that first.

Here's a tar of the current kernel that I'm working with:
http://www.4shared.com/archive/kXRVBttE/kerneltar.html

Here's the modules
http://www.4shared.com/archive/d9KtErm_/modulestar.html

Instructions:
First, boot into the regular raspbian image. Download the modules that I listed above, and unzip them into the /lib/modules directory on the install. Once you're done, if you list /lib/modules, you should see something like 3.1.9, and then 3.1.9-pps+ in the same directory.
The intention here is to avoid overwriting your modules for your default install, so that you can roll back if needed.

After those are in place, pop the SD card into a reader, and find the boot partition. It's in FAT32, so in windows, it will be the only files shown on the SD card. rename the kernel.img file to something like kernel-backup.img. unzip the kernel.tar.gz file provided above into the partition and rename it from "Image" to kernel.img.

At this point, plug it back into your pi and attempt to boot.
If everything was setup correctly, you should see something like this on boot:

Code: Select all

pi@raspberrypi's password:
Linux raspberrypi 3.1.9-pps+ #6 PREEMPT Wed Aug 1 19:44:18 EDT 2012 armv6l

If you're this far, then you should be able to load the necessary modules by typing "sudo modprobe pps-gpio"

After this, type "dmesg" and you should hopefully see an output similar to this:

Code: Select all

[  773.164041] pps_core: LinuxPPS API ver. 1 registered
[  773.164080] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[  773.172256] pps_core: source pps-gpio.-1 got cdev (252:0)
[  773.172288] pps pps0: new PPS source pps-gpio.-1
[  773.172359] pps pps0: Registered IRQ 108 as PPS source

At this point, your pps device is at /dev/pps0, and you can use the LinuxPPS testing suite (pps-test) to test your device. The quickest way to test I found is to take a wire and connect it to the pin (GPIO 23 for the kernel list above), and then lightly close the connection on the 3.3v pin. The 3.3v pin is the one w/ the P1 on the board next to it. Warning: accidentally connecting it to the 5v could fry your pi, so be careful doing this.

if everything is setup correctly, you should see something like this:

Code: Select all

pi@raspberrypi /usr/src/pps-tools $ sudo ./ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
source 0 - assert 1343872739.754885657, sequence: 1 - clear  0.000000000, sequence: 0
source 0 - assert 1343872739.854118652, sequence: 3 - clear  0.000000000, sequence: 0
source 0 - assert 1343872740.377387067, sequence: 4 - clear  0.000000000, sequence: 0
source 0 - assert 1343872740.420147201, sequence: 6 - clear  0.000000000, sequence: 0
source 0 - assert 1343872740.472563140, sequence: 7 - clear  0.000000000, sequence: 0

If you've got this far, it's probably time to try to run a wire from your clocking device to the pi pin.

Remember, the Pi only takes 3.3v, so you might need to get a level shifter or make a voltage divider if you're pushing 5 or 12v.

Once that's connected, you'll have to download and compile the ntpd source, since the refclocks aren't included in the version on the pi. Finally, after that's done, you should be able to add

Code: Select all

#PPS Source /dev/pps0 using assert
server 127.127.22.0 minpoll 4 maxpoll 4

to the ntp.conf file which will register the ATOM driver. If all is well, you'll sync appropriately. If you're like me, you might encounter the atom driver being marked as a false ticker, which sucks. I haven't found a fix for that yet.

One last thing: I've read from some time nerds (I use the term lovingly) that the Ethernet on the pi is controlled by the USB controller, which is poll rather than push. Because of that, they worry that the pi will never be able to be more accurate than 1 millisecond, since that's the rate that the USB controller polls. I'm not sure if that's too imprecise to be part of the pool project or not.

Posted: **Thu Aug 02, 2012 9:44 am**

/me starts downloading

I need to try and work out what the PPS voltage is... I can't find it anywhere in the manual.

I've also got a Motorocola OnCore UT+ which is just a GPS (as opposed to a GPS +OCXO). It has TTL pins which would work nicely with the UART on the Pi.

The UT+ has a 5V PPS : http://www.tapr.org/pdf/UT_Eng_Notes.pdf

Posted: **Thu Aug 02, 2012 2:35 pm**

Thanks for the detailed setup info! Looking forward to getting some time to try this. I have some stable OCXOs, also a GPS but reception here is bad so it probably does skip some pulses.

> they worry that the pi will never be able to be more accurate than 1 millisecond

If you see < 1 ms jitter over your internet connections from any computer, I'd be surprised. LAN might well be more stable than that though.

...also, given the R-Pi USB2 subsystem generates 8000 interrupts per second whether it is active or not, would expect the time resolution is more like 1/8 msec (?)

Posted: **Thu Aug 02, 2012 5:56 pm**

Even if the granularity of Ethernet transactions is 1 msec on R-Pi USB connected devices, there might be ways around that. For example, $10 will buy you http://www.sureelectronics.net/goods.php?id=1180 a ENC28J60 ethernet module which communicates via SPI, for 10 Mbps transfer. This is only 10baseT, but it still might give you lower jitter and better timing resolution. I have one of these, so it might be worth a try. The ENC28J60 has two separate interrupt outputs and it can generate interrupts upon packet-receive-complete and packet-transmit-complete[1], so your timing can be as good as you can time interrupts. In fact, I don't see why you couldn't even use external hardware to time packets with ns precision, if desired.

[1] Section 12 in http://ww1.microchip.com/downloads/en/d ... 39662a.pdf

Posted: **Thu Aug 02, 2012 10:04 pm**

aquarat wrote:/me starts downloading

I need to try and work out what the PPS voltage is... I can't find it anywhere in the manual.

I've also got a Motorocola OnCore UT+ which is just a GPS (as opposed to a GPS +OCXO). It has TTL pins which would work nicely with the UART on the Pi.

The UT+ has a 5V PPS : http://www.tapr.org/pdf/UT_Eng_Notes.pdf

The voltage on the GPIO pins, which is what you'll be routing the PPS signal to, is NOT 5v tolerant. It must be shifted down to 3.3v.

Posted: **Fri Aug 03, 2012 2:39 am**

jbeale wrote: If you see < 1 ms jitter over your internet connections from any computer, I'd be surprised. LAN might well be more stable than that though.

Yep, agree! I hope to sync certain time-sensitive machines on my LAN though

jbeale wrote: ...also, given the R-Pi USB2 subsystem generates 8000 interrupts per second whether it is active or not, would expect the time resolution is more like 1/8 msec (?)

I admit that I don't really know the internals of the pi's USB system. I just remember reading in a thread on some time post that it polls at 1ms. If that's false, and it's interrupting, then they may have just been misinformed (good for us).

Posted: **Fri Aug 03, 2012 2:54 am**

Well I'm no expert, the only agreement I've heard about the USB subsystem is that it's a big mess code-wise. But it does apparently generate interrupts at fixed 8 kHz rate matching a USB2 sub-frame size (?). For all I know it could be polled somehow despite all the interrupts- at any rate the only thing that matters is the actual performance, which I look forward to testing.

Posted: **Fri Aug 03, 2012 6:26 am**

Ok, I've followed the instructions to get this far (having connected my 3V3 PPS signal as indicated)

Code: Select all

pi@raspberrypi:~$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1343974960.571134559, sequence: 1755 - clear  0.000000000, sequence: 0
source 0 - assert 1343974961.571134802, sequence: 1756 - clear  0.000000000, sequence: 0
source 0 - assert 1343974962.571134035, sequence: 1757 - clear  0.000000000, sequence: 0
source 0 - assert 1343974963.571134260, sequence: 1758 - clear  0.000000000, sequence: 0
source 0 - assert 1343974964.571136477, sequence: 1759 - clear  0.000000000, sequence: 0
source 0 - assert 1343974965.571135685, sequence: 1760 - clear  0.000000000, sequence: 0
source 0 - assert 1343974966.571134884, sequence: 1761 - clear  0.000000000, sequence: 0
source 0 - assert 1343974967.571136074, sequence: 1762 - clear  0.000000000, sequence: 0
source 0 - assert 1343974968.571136255, sequence: 1763 - clear  0.000000000, sequence: 0
source 0 - assert 1343974969.571136427, sequence: 1764 - clear  0.000000000, sequence: 0
source 0 - assert 1343974970.571136592, sequence: 1765 - clear  0.000000000, sequence: 0

Looks very promising! Now I'm not sure how to compile NTP from sources. Tried to follow below plan, but 'apt-get update' has error about NO_PUBKEY

...from http://packages.ntp.org/debian/
Add the following lines to your /etc/apt/sources to use the packages in this repository:
Code: Select all
    deb http://packages.ntp.org/debian stable main
    deb-src http://packages.ntp.org/debian stable main
Then run apt-get update; apt-get install ntp-dev to switch over to the current NTP-Dev snapshot.

sudo apt-get update
[...]
Err http://packages.ntp.org stable/main armhf Packages
404 Not found
Ign http://packages.ntp.org stable/main Translation-en_US
Ign http://packages.ntp.org stable/main Translation-en
Fetched 2,332 B in 3min 5s (12 B/s)
W: GPG error: http://packages.ntp.org stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BBBEE20C7C23860F
W: Failed to fetch http://packages.ntp.org/debian/dists/st ... f/Packages 404 Not found

pi@raspberrypi:~sudo apt-get install ntp-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package ntp-dev

Posted: **Fri Aug 03, 2012 1:38 pm**

Just get it and compile it from http://www.ntp.org/downloads.html/

Posted: **Sat Aug 04, 2012 12:27 am**

Thanks, got the source and I'll try a compile. By the way, after running the (Raspbian stock, non-PPS) ntpd process for a while, the ntp statistics log for frequency offset ranges between -37 to -38 ppm for my particular R-Pi. If I simply kill the ntpd process, does the Linux kernel still maintain that -37 ppm correction for the system time, or does it revert to an uncorrected clock?

Posted: **Sat Aug 04, 2012 5:44 am**

Another question: with the 3.1.9-pps+ kernel and the pps_gpio module installed and the PPS signal connected, I am getting two lines added to the 'dmesg' log file every second, as below. How can I turn this off? I want to use dmesg to see other things like USB device connections, etc. and a lot of megabytes are accumulating in the /var/log directory.

Code: Select all

[ 3607.338808] pps pps0: PPS event at 1344057999.574615408
[ 3607.338836] pps pps0: capture assert seq #84794
[ 3608.338792] pps pps0: PPS event at 1344058000.574558873
[ 3608.338813] pps pps0: capture assert seq #84795
[ 3609.338802] pps pps0: PPS event at 1344058001.574535336
[ 3609.338830] pps pps0: capture assert seq #84796
[ 3610.338832] pps pps0: PPS event at 1344058002.574529799
[ 3610.338859] pps pps0: capture assert seq #84797

edit: googling around, it looks like "PPS DEBUG" is an option compiled into the kernel, unfortunately.... Looks like I'll need to learn how to compile my own kernel!

In case of interest I attach a graph of the drift of the R-Pi clock (with NTP turned off) relative to a more stable external PPS signal. You can see that the delay is variable but always positive (on time or late, but never early.) Superimposed on that is the longer-term drift.

Raspberry Pi Forums

NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS

Re: NTP PPS