David,
running RPi with GPS+PPS here.
I compiled my own kernel and the one major gotcha I had was an RTFM
issue. The kernel used on the RPi is not the compressed vmlinuz
kernel used on PC's. I recompiled my kernel 10 times or more before I
went back scouring the 'net to find out the kernel in use was the
kernel.img file. Reason I say this is the first time I thought I had
this working I was seeing kernel generated PPS signals and not GPS
generated PPS signals. Life got much easier when I figured that out
:)
Having said all that this is what I see in my syslog when my system
restarts, my GPS has battery backup so it's not a cold start on it
when I reboot my RPi.
Nov 15 19:17:41 pisces kernel: [ 102.192261] pps_core: LinuxPPS API
ver. 1 registered
Nov 15 19:17:41 pisces kernel: [ 102.192269] pps_core: Software ver.
5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giome...@linux.it>
Nov 15 19:17:41 pisces kernel: [ 102.195682] pps_core: source
pps-gpio.-1 got cdev (251:0)
Nov 15 19:17:41 pisces kernel: [ 102.195702] pps pps0: new PPS source
pps-gpio.-1
Nov 15 19:17:41 pisces kernel: [ 102.195745] pps pps0: Registered IRQ
194 as PPS source
Nov 15 19:17:41 pisces kernel: [ 102.470452] pps pps0: PPS event at
1353035851.050598985
Nov 15 19:17:41 pisces kernel: [ 102.470479] pps pps0: capture assert seq
#1
my /etc/modules consists of:
loop
pps_gpio
my /etc/ntp.conf consists of:
# NEMA data on /dev/gps0
server 127.127.20.0 mode 48 minpoll 3 iburst prefer
fudge 127.127.20.0 flag1 0 time2 0.400
#PPS on /dev/pps0
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag3 1 flag4 1
/dev:
crw-rw---T 1 root dialout 204, 64 Nov 19 17:46 /dev/ttyAMA0
lrwxrwxrwx 1 root root 7 Dec 31 1969 /dev/gps0 -> ttyAMA0
crwxrwxrwt 1 root tty 251, 0 Nov 15 19:17 /dev/pps0
lrwxrwxrwx 1 root root 4 Nov 15 19:17 /dev/gpspps0 -> pps0
and this is what I am seeing in ntp:
ntpq -c lpeers
remote refid st t when poll reach delay offset
jitter
==============================================================================
*GPS_NMEA(0) .GPS. 0 l 1 8 377 0.000
-55.452 9.778
oPPS(0) .PPS. 0 l 8 16 377
0.000 -0.001 0.001
+69.85.88.32 128.4.1.1 2 u 26 64 377 101.895
4.132 1.447
-irc.indoforum.o 64.147.116.229 2 u 37 64 377 18.260
4.336 2.875
-ntp1.ResComp.Be 128.32.206.55 3 u 51 64 377 38.992 6.287
2.307
+199.241.31.96 164.244.221.197 2 u 7 64 377 70.261
-21.524 3.039
I don't see any problems with the RPi creating the /dev/pps0 device on
startup and since I've done more RTFM I actually get good PPS data :)
I did contribute to the thread listed at the RPi forums but need to go
back and add what got it working for me. I also moved to a more
current kernel. I compiled a bunch of extra stuff in there as I want
to play with the networking stuff too so my kernel is not a small one.
uname -a
Linux pisces 3.6.1+ #1 Fri Nov 2 02:10:35 PDT 2012 armv6l GNU/Linux
James
=================================================
James,
Many thanks for that. Treating me as a beginner in Linux, could you perhaps
give step-by-step instructions for recompiling the kernel (together with an
indication of the time it may take) as I feel sure I will need to do this at
some time? I take it that there is just the single PPS/GPIO code so that
you are also working with pin 24? Just maybe the newer kernel doesn't have
this same delayed start-up issue.
I would like to add statistics gathering, but I don't want the files to
accumulate and I'm unsure about how to create a scheduled task which would
delete statistics file more than, say, 30 days old. Another gap in my Linux
knowledge, I'm afraid! I'm suspect that CRON come into it, though.
Many thanks,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
