Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on
- David Taylor
December 20, 2013, 4:50 pm

Folks,
At the moment, I am recompiling the Wheezy kernel to add PPS support
(required for NTP timekeeping amongst other things). However, I do also
note the capability to add modules at boot-up by editing the file:
$ sudo nano /etc/modules
Adding lines like:
wire
w1-gpio
w1-therm
Being a novice with Linux, I wonder why kernel-mode PPS support cannot
be added in a module rather than requiring a recompile?
I ask here as it may be something Raspberry Pi specific, and I would
like to learn. (I have coded device drivers under VMS).
At the moment, I am recompiling the Wheezy kernel to add PPS support
(required for NTP timekeeping amongst other things). However, I do also
note the capability to add modules at boot-up by editing the file:
$ sudo nano /etc/modules
Adding lines like:
wire
w1-gpio
w1-therm
Being a novice with Linux, I wonder why kernel-mode PPS support cannot
be added in a module rather than requiring a recompile?
I ask here as it may be something Raspberry Pi specific, and I would
like to learn. (I have coded device drivers under VMS).
--
Thanks,
David
Thanks,
David
We've slightly trimmed the long signature. Click to see the full one.

Re: Kernel - why the need to recompile to add PPS support?

Are you sure you need PPS support?
What type of device are you trying to link to ntpd?
The NTP server, ntpd, runs quite satisfactorily on the standard Raspbian
kernel using the standard internet time services as its master time
source. That was one of the first things I configured and had running on
mine.
Have you considered using GPS receivers with NMEA output?
This one, for instance:
(Amazon.com product link shortened)
B008200LHW/ref=pd_cp_ce_1
Is powered through its USB connector and uses gpsd to interface it to
ntpd. gpsd is a standard Debian package for connecting GPS receivers that
use the NMEA protocol to ntpd.
Garmin also sell similar receivers but they generally need a 12v power
supply and use serial connections, so you'd need a 12v PSU and a serial
to USB adapter to connect them to an RPI. That said, suitable models are
the Garmin GPS18 GPS19 (current models), GPS25 or GPS35 (look on eBay).
More detail on using gpsd is here:
http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php
If the above doesn't help, you may want to ask on comp.protocols.time.ntp,
which is apparently a good place to ask NTP-related questions.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
martin@ | Martin Gregorie
gregorie. | Essex, UK
We've slightly trimmed the long signature. Click to see the full one.

Re: Kernel - why the need to recompile to add PPS support?

GPS with NMEA is worthless for accurate time sync.
A network time source will normally perform much better.
(unless your network is via WiFi or UMTS/GSM of course)
GPS can be used as a good timesource but you need the PPS signal.
It can be fed to the kernel without PPS support, e.g. with gpsd.
However those that want PPS support usually know what they are talking
about and want it for some reason.
I think the PPS support changes more than just the addition of
some functions, that is why it is not a module. The reason I originally
added PPS support to gpsd (which works reasonably well on a lightly
loaded system) was that I did not like to recompile the kernel
either. It takes a long time and makes tracking security updates
from the distributor a lot more difficult.

Re: Kernel - why the need to recompile to add PPS support?

Thanks for your comments, Rob. I have tried a user-mode program on the
RPi which injects PPS times (from a specified GPIO pin) into the shared
memory segment provided by (I believe) gpsd. With this program I can
get down to around 5 microseconds averaged jitter on the RPi.
http://vanheusden.com/time/rpi_gpio_ntp
Using kernel-mode PPS (and ensuring that the kernel is not compiled with
"tickless" set) reduces the averaged jitter to 1-2 microseconds.
It is a pity that the default Raspberry Pi software is not supplied with
PPS support from a programmable GPIO pin, and without "tickless".
--
Cheers,
David
Cheers,
David
We've slightly trimmed the long signature. Click to see the full one.

Re: Kernel - why the need to recompile to add PPS support?

Ok I'll admit that I forgot we are on a Raspberri Pi, not NTP, group.
What gpsd can do is to receive GPS data on a serial port, and at the
same time receive PPS pulses on a handshake line of that port, usually
DCD.
However, while the Raspberri Pi does have a serial port, it does not
come with a handshake line. So this function of gpsd cannot be used.
Of course it is possible to have another program running that inputs
a generic input pin and does the same thing as gpsd does.
The shared memory segment is not used by gpsd, it is used by ntpd.
It is filled by gpsd or the special program you use.

Re: Kernel - why the need to recompile to add PPS support?
On 21/12/2013 09:05, Rob wrote:
[]

.. and gpsd works very well indeed - thanks very much for that! The
great thing about the user-mode program is that the pin to use can be
specified on its command-line, whereas the kernel patch is to a port
defined at patch time.
[]

.. and gpsd works very well indeed - thanks very much for that! The
great thing about the user-mode program is that the pin to use can be
specified on its command-line, whereas the kernel patch is to a port
defined at patch time.
--
Cheers,
David
Cheers,
David
We've slightly trimmed the long signature. Click to see the full one.

Re: Kernel - why the need to recompile to add PPS support?

Well, I wrote the initial code for timesync in gpsd, but after me a
lot of other people have further refined it. The command-line spec
of the input pin is one of those changes made by others. In fact, when
I wrote my code I was asked not to use any configuration options, in
those days gpsd was supposed to be completely auto-configuring.
(the code auto-detects the presence and polarity of the PPS pulse)

Re: Kernel - why the need to recompile to add PPS support?
On 21/12/2013 11:20, Jasen Betts wrote:

Thanks, Jasen! Well, please tell me more! This is what I currently
need to configure:
- Make the system /not/ tickless
- Enable PPS support
- Enable Generic memory mapped GPIO support
==================================================
General setup --->
Timers subsystem ---> [ ]
Tickless System (Dynamic Ticks)
Next turn on PPS support
Device Drivers --->
PPS support --->
<M> PPS support
[ ] PPS debugging messages (NEW)
<*> PPS kernel consumer support
*** PPS clients support ***
< > Kernel timer client (Testing client, use for debug)
< > PPS line discipline
<M> PPS client using GPIO
Device Drivers --->
-*- GPIO Support --->
--- GPIO Support
[ ] Debug GPIO calls
[*] /sys/class/gpio/... (sysfs interface)
*** Memory mapped GPIO drivers: ***
<*> Generic memory-mapped GPIO .. (MMIO platform)
==================================================
in addition to applying this patch:
https://raw.github.com/lampeh/rpi-misc/master/linux-pps/linux-rpi-pps-gpio-bcm2708.diff
I suspect the patch is the killer, even if the three items above can be
done in a command line.

Thanks, Jasen! Well, please tell me more! This is what I currently
need to configure:
- Make the system /not/ tickless
- Enable PPS support
- Enable Generic memory mapped GPIO support
==================================================
General setup --->
Timers subsystem ---> [ ]
Tickless System (Dynamic Ticks)
Next turn on PPS support
Device Drivers --->
PPS support --->
<M> PPS support
[ ] PPS debugging messages (NEW)
<*> PPS kernel consumer support
*** PPS clients support ***
< > Kernel timer client (Testing client, use for debug)
< > PPS line discipline
<M> PPS client using GPIO
Device Drivers --->
-*- GPIO Support --->
--- GPIO Support
[ ] Debug GPIO calls
[*] /sys/class/gpio/... (sysfs interface)
*** Memory mapped GPIO drivers: ***
<*> Generic memory-mapped GPIO .. (MMIO platform)
==================================================
in addition to applying this patch:
https://raw.github.com/lampeh/rpi-misc/master/linux-pps/linux-rpi-pps-gpio-bcm2708.diff
I suspect the patch is the killer, even if the three items above can be
done in a command line.
--
Cheers,
David
Cheers,
David
We've slightly trimmed the long signature. Click to see the full one.

Re: Kernel - why the need to recompile to add PPS support?

I only know it's possible.
On PCs there's paramteres like VGA and 8250_NR_UARTS
which configure setting of built-in code

yeah, these would be features you want would need to be compiled they
could be be enables or fine-tuned at boot-time
many thing can be built as modules and configured at load-time by
similar means.
--
For a good time: install ntp
For a good time: install ntp

Re: Kernel - why the need to recompile to add PPS support?
On 20/12/2013 20:01, Martin Gregorie wrote:

Thanks for your reply, Martin. Yes, PPS is essential for precise
timekeeping. I am linking devices which have a PPS output such as:
Adafruit GPS:
http://www.adafruit.com/products/746
and U-blox 7Q:
http://ava.upuaut.net/store/index.php?route=product/product&path59%_60&product_id95%
NMEA alone is totally inadequate for precise time-keeping, as the serial
output has a low prority within the GPS receiver and can, consequently,
have a very large jitter. It may actually be worse than a reasonable
Internet connection.
I am moderately familiar with NTP. Do you have an answer to my question?

Thanks for your reply, Martin. Yes, PPS is essential for precise
timekeeping. I am linking devices which have a PPS output such as:
Adafruit GPS:
http://www.adafruit.com/products/746
and U-blox 7Q:
http://ava.upuaut.net/store/index.php?route=product/product&path59%_60&product_id95%
NMEA alone is totally inadequate for precise time-keeping, as the serial
output has a low prority within the GPS receiver and can, consequently,
have a very large jitter. It may actually be worse than a reasonable
Internet connection.
I am moderately familiar with NTP. Do you have an answer to my question?
--
Cheers,
David
Cheers,
David
We've slightly trimmed the long signature. Click to see the full one.

Re: Kernel - why the need to recompile to add PPS support?
s. My GPS has a very jittery serial data, but precise PPS - but NTP refuse
s to accept PPS when it departs from the GPS time, but the GPS time will be
constantly moving.
But for the kernel, I have a project on github, https://github.com/tz1/pike
rnomatic that builds kernels, and gpio_pps that allows a module to be loade
d to specify the GPIO pin (since I'm swapping hardware the available pins c
hange).
Is there anyway to just use /dev/pps0 and ppsctl that bypasses NTP complete
ly and have the kernel itself sync to PPS? (Or I might write my own to use
adjtime). I already have a GPS NMEA decoder that sets the time (actually
a bit before due to serial latency) - that is webgpsd on github.

Re: Kernel - why the need to recompile to add PPS support?
On 27/03/2014 19:22, snipped-for-privacy@gmail.com wrote:

I must confess to not having seen this problem myself, but I always use
other NTP servers to set the coarse time. You can mark the GPS serial
server as "noselect", and just monitor it, if you like.
Are you allowed to connect to other NTP servers in the system you are
building? That might solve the problem.
NTP will need to have a way of knowing the coarse seconds - it can't
work from PPS alone. I'm wondering whether you may be in the situation
of the man with two clocks, not knowing which is right, but if the PPS
is working properly I would have expected NTP to choose it over the GPSD
every time. There may be parameters you can twiddle, but perhaps the
best approach is to ask the gurus over on:
nntp://comp.protocols.time.ntp
I have a feeling there's something obvious which I'm missing! <G>

I must confess to not having seen this problem myself, but I always use
other NTP servers to set the coarse time. You can mark the GPS serial
server as "noselect", and just monitor it, if you like.
Are you allowed to connect to other NTP servers in the system you are
building? That might solve the problem.
NTP will need to have a way of knowing the coarse seconds - it can't
work from PPS alone. I'm wondering whether you may be in the situation
of the man with two clocks, not knowing which is right, but if the PPS
is working properly I would have expected NTP to choose it over the GPSD
every time. There may be parameters you can twiddle, but perhaps the
best approach is to ask the gurus over on:
nntp://comp.protocols.time.ntp
I have a feeling there's something obvious which I'm missing! <G>
--
Cheers,
David
Cheers,
David
We've slightly trimmed the long signature. Click to see the full one.
Site Timeline
- » Raspberry-Pi -> VGA socket monitor?
- — Next thread in » Raspberry Pi Group
-
- » wifi and wpa_supplicant
- — Previous thread in » Raspberry Pi Group
-
- » Strange scroll wheel behavior
- — Newest thread in » Raspberry Pi Group
-
- » OpenGL Application: FrameNumber for examining display monitors !
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Rules
- — The site's Last Updated Thread. Posted in » Microcontrollers (Russian)
-