Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ntpd connect gpsd shared memory driver
1,653 views
Skip to first unread message
Richard Cagley
Jun 17, 2013, 7:55:52 PM6/17/13
to
Based on poor luck with ntpd/pps, I'm trying to have ntpd use the shared
memory driver provided by gpsd. Do I need to give a special flag to
configure for ntp to tell it to build in support for the shared memory
driver?
Using this for my ntp.conf
---
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid NMEA
---
I get nothing
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
SHM(0) .NMEA. 0 l - 16 0 0.000 0.000
0.000
but, gpsd is patiently waiting for something to happen...
/ # gpsd -b -N -D5 /dev/ttyO0
gpsd:INFO: launching (Version 3.9)
gpsd:IO: opening IPv4 socket
gpsd:INFO: listening on port 2947
gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyO0 at slot 0
gpsd:INFO: running with effective group ID 0
gpsd:INFO: running with effective user ID 99
gpsd:INFO: startup at 2000-01-01T00:05:57.000Z (946685157)
Note, I can telnet to the local IP/port and if I issue a watch command the
gpsd starts grabbing nmea data.
memory driver provided by gpsd. Do I need to give a special flag to
configure for ntp to tell it to build in support for the shared memory
driver?
Using this for my ntp.conf
---
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid NMEA
---
I get nothing
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
SHM(0) .NMEA. 0 l - 16 0 0.000 0.000
0.000
but, gpsd is patiently waiting for something to happen...
/ # gpsd -b -N -D5 /dev/ttyO0
gpsd:INFO: launching (Version 3.9)
gpsd:IO: opening IPv4 socket
gpsd:INFO: listening on port 2947
gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyO0 at slot 0
gpsd:INFO: running with effective group ID 0
gpsd:INFO: running with effective user ID 99
gpsd:INFO: startup at 2000-01-01T00:05:57.000Z (946685157)
Note, I can telnet to the local IP/port and if I issue a watch command the
gpsd starts grabbing nmea data.
Rob
Jun 18, 2013, 3:30:12 AM6/18/13
to
is to be expected.
When you want gpsd to sync the clock even when you are not using its
API, you need to pass the -n flag at startup.
Also, your ntp config is not complete when you want to use pps.
There are two SHM segments, one for NMEA and one for PPS.
A C
Jun 18, 2013, 3:22:11 AM6/18/13
to
On 6/17/2013 16:55, Richard Cagley wrote:
> Based on poor luck with ntpd/pps, I'm trying to have ntpd use the shared
> memory driver provided by gpsd. Do I need to give a special flag to
> configure for ntp to tell it to build in support for the shared memory
> driver?
>
> Using this for my ntp.conf
> ---
> server 127.127.28.0 minpoll 4
> fudge 127.127.28.0 refid NMEA
> ---
> I get nothing
> / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> SHM(0) .NMEA. 0 l - 16 0 0.000 0.000
> 0.000
>
> but, gpsd is patiently waiting for something to happen...
> / # gpsd -b -N -D5 /dev/ttyO0
You need -n (lower case N) to force gpsd to start collecting data
> Based on poor luck with ntpd/pps, I'm trying to have ntpd use the shared
> memory driver provided by gpsd. Do I need to give a special flag to
> configure for ntp to tell it to build in support for the shared memory
> driver?
>
> Using this for my ntp.conf
> ---
> server 127.127.28.0 minpoll 4
> fudge 127.127.28.0 refid NMEA
> ---
> I get nothing
> / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> SHM(0) .NMEA. 0 l - 16 0 0.000 0.000
> 0.000
>
> but, gpsd is patiently waiting for something to happen...
> / # gpsd -b -N -D5 /dev/ttyO0
automatically. It normally waits for something to connect to its TCP
port and enable data collection (the WATCH command as you discovered).
If you start with just:
gpsd -bn /dev/ttyO0
You'll find the SHMs are populated after a few seconds (once gpsd syncs
with the data stream from the receiver).
Richard Cagley
Jun 18, 2013, 11:50:44 AM6/18/13
to
On Tue, Jun 18, 2013 at 12:22 AM, A C <agcarv...@acarver.net> wrote:
> You need -n (lower case N) to force gpsd to start collecting data
> automatically. It normally waits for something to connect to its TCP port
> and enable data collection (the WATCH command as you discovered). If you
> start with just:
>
> gpsd -bn /dev/ttyO0
>
> You'll find the SHMs are populated after a few seconds (once gpsd syncs
> with the data stream from the receiver).
>
Hmmm, i had tried the -n before. It doesn't seem to help. After several
> You need -n (lower case N) to force gpsd to start collecting data
> automatically. It normally waits for something to connect to its TCP port
> and enable data collection (the WATCH command as you discovered). If you
> start with just:
>
> gpsd -bn /dev/ttyO0
>
> You'll find the SHMs are populated after a few seconds (once gpsd syncs
> with the data stream from the receiver).
>
minutes there is no change to ntpq -p. Any other ideas for something
stupid I'm doing? Do you think it's a ntpd or gpsd issue...or something
else?
After several minutes, no change to ntqp -p
---
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
SHM(0) .SHM. 0 l - 16 0 0.000 0.000
remote refid st t when poll reach delay offset
jitter
==============================================================================
0.000
---
but gpsd seems to be active...
/ # gpsd -bn -N -D5 /dev/ttyO0
gpsd:INFO: launching (Version 3.9)
gpsd:IO: opening IPv4 socket
gpsd:INFO: listening on port 2947
gpsd:PROG: NTPDnew PPS source OMAP-SERIAL0 at ID 0
gpsd:IO: opening IPv4 socket
gpsd:INFO: listening on port 2947
shmat(0,0,0) suPPS source #0 "/dev/ttyO0" added
cceeded, segment 0
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: PPS thread launched
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyO0 at slot 0
gpsd:PROG: no /etc/gpsd/device-hook present, skipped running ACTIVATE hook
gpsd:INFO: stashing device /dev/ttyO0 at slot 0
gpsd:INFO: opening read-only GPS data source type 2 and at '/dev/ttyO0'
gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
gpsd:PROG: PPS chrony socket /var/run/chrony.ttyO0.sock doesn't exist
gpsd:INFO: KPPS checking /sys/devices/virtual/pps/pps0/path, /dev/ttyO0
gpsd:INFO: KPPS caps 1133
gpsd:WARN: KPPS kernel PPS will be used
gpsd:PROG: KPPS assert 0.000000000, sequence: 0 - clear
946685867.302809818, s1
gpsd:PROG: KPPS data: using clear
gpsd:INFO: KPPS cycle: 2060820377, duration: 0 @ 946685867.302809818
gpsd:INFO: PPS cycle: 2060820434, duration: 2060820434 @ 946685867.302866
gpsd:PROG: KPPS assert 946685867.402807225, sequence: 1 - clear
946685867.30281
gpsd:PROG: KPPS data: using assert
gpsd:INFO: KPPS cycle: 2060920375, duration: 99997 @ 946685867.402807225
gpsd:INFO: speed 4800, 8N1
gpsd:PROG: no probe matched...
gpsd:INFO: gpsd_activate(): activated GPS (fd 4)
gpsd:INFO: device /dev/ttyO0 activated
gpsd:PROG: KPPS assert 946685867.402807225, sequence: 1 - clear
946685868.30272
gpsd:PROG: KPPS data: using clear
A C
Jun 18, 2013, 12:08:06 PM6/18/13
to
out the data stream from your GPS and gave up. That's why you see no
data in SHM(0) because there is no valid data to put there. So the
first thing to do is figure out what protocol your GPS receiver is
speaking, then determine if gpsd was compiled for that protocol.
Rob
Jun 18, 2013, 12:27:17 PM6/18/13
to
Richard Cagley <rca...@gmail.com> wrote:
> On Tue, Jun 18, 2013 at 12:22 AM, A C <agcarv...@acarver.net> wrote:
>
>> You need -n (lower case N) to force gpsd to start collecting data
>> automatically. It normally waits for something to connect to its TCP port
>> and enable data collection (the WATCH command as you discovered). If you
>> start with just:
>>
>> gpsd -bn /dev/ttyO0
>>
>> You'll find the SHMs are populated after a few seconds (once gpsd syncs
>> with the data stream from the receiver).
>>
>
> Hmmm, i had tried the -n before. It doesn't seem to help. After several
> minutes there is no change to ntpq -p. Any other ideas for something
> stupid I'm doing? Do you think it's a ntpd or gpsd issue...or something
> else?
>
> After several minutes, no change to ntqp -p
> ---
> / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> SHM(0) .SHM. 0 l - 16 0 0.000 0.000
> 0.000
> ---
As I wrote before, your ntp config is not correct. please copy it
> On Tue, Jun 18, 2013 at 12:22 AM, A C <agcarv...@acarver.net> wrote:
>
>> You need -n (lower case N) to force gpsd to start collecting data
>> automatically. It normally waits for something to connect to its TCP port
>> and enable data collection (the WATCH command as you discovered). If you
>> start with just:
>>
>> gpsd -bn /dev/ttyO0
>>
>> You'll find the SHMs are populated after a few seconds (once gpsd syncs
>> with the data stream from the receiver).
>>
>
> Hmmm, i had tried the -n before. It doesn't seem to help. After several
> minutes there is no change to ntpq -p. Any other ideas for something
> stupid I'm doing? Do you think it's a ntpd or gpsd issue...or something
> else?
>
> After several minutes, no change to ntqp -p
> ---
> / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> SHM(0) .SHM. 0 l - 16 0 0.000 0.000
> 0.000
> ---
from the docs. However, that is not the cause of the problem.
(it would be the cause of severe inaccuracy once you obtain NMEA data
as you are not using PPS)
> but gpsd seems to be active...
situation. You need to paste more logging to see if there is lock
to the satellites.
Rob
Jun 18, 2013, 12:30:12 PM6/18/13
to
Rob <nom...@example.com> wrote:
>> but gpsd seems to be active...
>
> What you posted here looks OK but is too short to diagnose the
> situation.
I stand corrected, the "no probe matched" is indeed a fatal error.
>> but gpsd seems to be active...
>
> What you posted here looks OK but is too short to diagnose the
> situation.
Try to fix that first.
There should be more logging then, and the next step is to check
if there is a fix to the satellites.
Richard Cagley
Jun 18, 2013, 12:58:21 PM6/18/13
to
On Tue, Jun 18, 2013 at 9:30 AM, Rob <nom...@example.com> wrote:
> I stand corrected, the "no probe matched" is indeed a fatal error.
> Try to fix that first.
> There should be more logging then, and the next step is to check
> if there is a fix to the satellites.
>
adding the -b flag to gpsd seemed to do the trick. I now seem to get some
> I stand corrected, the "no probe matched" is indeed a fatal error.
> Try to fix that first.
> There should be more logging then, and the next step is to check
> if there is a fix to the satellites.
>
timing info. I do still get the "no probe matched". I can't tell if it's
fatal or not. I mean if I'm getting timing info now on the shared memory
that ntpd can see...is it really fatal?
/ # ntpq -pn
remote refid st t when poll reach delay offset
jitter
==============================================================================
*127.127.28.0 .SHMg. 0 l 4 16 377 0.000 10.131
jitter
==============================================================================
6.341
127.127.28.1 .SHMp. 0 l - 16 0 0.000 0.000
0.000
Rob
Jun 18, 2013, 1:16:18 PM6/18/13
to
Richard Cagley <rca...@gmail.com> wrote:
> On Tue, Jun 18, 2013 at 9:30 AM, Rob <nom...@example.com> wrote:
>
>> I stand corrected, the "no probe matched" is indeed a fatal error.
>> Try to fix that first.
>> There should be more logging then, and the next step is to check
>> if there is a fix to the satellites.
>>
>
> adding the -b flag to gpsd seemed to do the trick. I now seem to get some
> timing info. I do still get the "no probe matched". I can't tell if it's
> fatal or not. I mean if I'm getting timing info now on the shared memory
> that ntpd can see...is it really fatal?
Does it stop there or is there logging that indicates that it receives
> On Tue, Jun 18, 2013 at 9:30 AM, Rob <nom...@example.com> wrote:
>
>> I stand corrected, the "no probe matched" is indeed a fatal error.
>> Try to fix that first.
>> There should be more logging then, and the next step is to check
>> if there is a fix to the satellites.
>>
>
> adding the -b flag to gpsd seemed to do the trick. I now seem to get some
> timing info. I do still get the "no probe matched". I can't tell if it's
> fatal or not. I mean if I'm getting timing info now on the shared memory
> that ntpd can see...is it really fatal?
and understands data from the receiver?
> / # ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> *127.127.28.0 .SHMg. 0 l 4 16 377 0.000 10.131
> 6.341
> 127.127.28.1 .SHMp. 0 l - 16 0 0.000 0.000
> 0.000
What happens when you add some external timeserver(s)?
Are you within a fraction of a second from those?
Richard Cagley
Jun 18, 2013, 1:39:20 PM6/18/13
to
On Tue, Jun 18, 2013 at 9:27 AM, Rob <nom...@example.com> wrote:
> As I wrote before, your ntp config is not correct. please copy it
> from the docs. However, that is not the cause of the problem.
> (it would be the cause of severe inaccuracy once you obtain NMEA data
> as you are not using PPS)
>
yeah, figured I'd walk before I ran so I tried to make my ntp.conf file as
> As I wrote before, your ntp config is not correct. please copy it
> from the docs. However, that is not the cause of the problem.
> (it would be the cause of severe inaccuracy once you obtain NMEA data
> as you are not using PPS)
>
simple as possible to at least get some timing info, which thanks to your
and AC's help I now have.
ok, now onto pps. I went here
http://gpsd.berlios.de/gpsd.html
...and am now using this as my ntp.conf
---
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.420 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1
---
But, sadly no pps sync...
---
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*SHM(0) .GPS. 0 l 7 16 377 0.000 0.048
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
0.005
SHM(1) .GPS1. 0 l - 16 0 0.000 0.000
0.000
---
I have pps debug output built into the kernel and can see pps events on the
console while I look at gpsd output
---
PPS event at 9862
PPS event at 9962
PPS event at 10062
PPS event at 10162
---
Sorry, this is so long, but here's a dump of the gpsd output. There are
several things that concern me, such as some of the warning, but not sure
of the severity
/ # gpsd -bn -N -D5 /dev/ttyO0
gpsd:IO: opening IPv4 socket
gpsd:INFO: listening on port 2947
gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
gpsd:INFO: listening on port 2947
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: shmat() succeeded, segment 131076
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: shared-segment creation succeeded,
gpsd:PROG: PPS thread launched
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyO0 at slot 0
gpsd:PROG: no etc/gpsd/device-hook present, skipped running ACTIVATE hook
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/ttyO0 at slot 0
gpsd:INFO: opening read-only GPS data source type 2 and at '/dev/ttyO0'
gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
gpsd:PROG: PPS chrony socket /var/run/chrony.ttyO0.sock doesn't exist
gpsd:INFO: PPS cycle: 631139111, duration: 631139111 @ 1371576962.280231
gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
gpsd:PROG: PPS chrony socket /var/run/chrony.ttyO0.sock doesn't exist
gpsd:INFO: speed 4800, 8N1
gpsd:PROG: Probing "Garmin USB binary" driver...
gpsd:PROG: Probe not found "Garmin USB binary" driver...
gpsd:PROG: Probing "GeoStar binary" driver...
gpsd:IO: Sent GeoStar packet id 0xc1
gpsd:PROG: Probe not found "GeoStar binary" driver...
gpsd:PROG: Probing "Trimble TSIP" driver...
gpsd:INFO: speed 9600, 8O1
gpsd:INFO: speed 4800, 8N1
gpsd:PROG: Probe not found "Trimble TSIP" driver...
gpsd:PROG: no probe matched...
gpsd:INFO: gpsd_activate(): activated GPS (fd 4)
gpsd:INFO: device /dev/ttyO0 activated
gpsd:INFO: gpsd_activate(): activated GPS (fd 4)
gpsd:INFO: device /dev/ttyO0 activated
gpsd:INFO: running with effective group ID 0
gpsd:INFO: running with effective user ID 99
gpsd:INFO: startup at 2013-06-18T17:36:02.000Z (1371576962)
gpsd:INFO: running with effective user ID 99
gpsd:PROG: switch_driver(Generic NMEA) called...
gpsd:PROG: selecting Generic NMEA driver...
gpsd:INFO: /dev/ttyO0 identified as type Generic NMEA (0.564143 sec @
4800bps)
gpsd:IO: <= GPS:
$GPRMC,173602.00,A,3425.96985,N,11951.97924,W,0.039,,180613,,,A*63
gpsd:DATA: merge_ddmmyy(180613) sets year 2013
gpsd:DATA: GPRMC: registers fractional time 173602.00
gpsd:DATA: RMC: ddmmyy=180613 hhmmss=173602.00 lat=34.43 lon=-119.87
speed=0.02 track=0.00 mode=2 status=1
gpsd:DATA: GPRMC time is 1371576962.000000 = 2013-06-18T17:36:2.00Z
gpsd:PROG: GPRMC sentence timestamped 173602.00.
gpsd:PROG: GPRMC starts a reporting cycle.
gpsd:DATA: packet type 1 from /dev/ttyO0 with
{ONLINE|TIME|LATLON|SPEED|TRACK|STATUS|MODE|PACKET|DRIVER|CLEAR}
gpsd:IO: <= GPS: $GPVTG,,T,,M,0.039,N,0.072,K,A*2C
gpsd:DATA: packet type 1 from /dev/ttyO0 with {ONLINE|PACKET}
gpsd:IO: <= GPS:
$GPGGA,173602.00,3425.96985,N,11951.97924,W,1,06,2.39,2.7,M,-33.5,M,,*6B
gpsd:DATA: GPGGA: registers fractional time 173602.00
gpsd:DATA: GGA: hhmmss=173602.00 lat=34.43 lon=-119.87 alt=2.70 mode=3
status=1
gpsd:DATA: GPGGA time is 1371576962.000000 = 2013-06-18T17:36:2.00Z
gpsd:PROG: GPGGA sentence timestamped 173602.00.
gpsd:DATA: packet type 1 from /dev/ttyO0 with
{ONLINE|TIME|LATLON|ALTITUDE|STATUS|MODE|PACKET}
gpsd:IO: <= GPS: $GPGSA,A,3,16,06,07,23,10,13,,,,,,,3.29,2.39,2.26*00
gpsd:PROG: GPGSA sets mode 3
gpsd:DATA: GPGSA: mode=3 used=6 pdop=3.29 hdop=2.39 vdop=2.26
gpsd:DATA: packet type 1 from /dev/ttyO0 with {ONLINE|MODE|DOP|PACKET|USED}
gpsd:IO: <= GPS:
$GPRMC,173603.00,A,3425.96981,N,11951.97923,W,0.039,,180613,,,A*61
gpsd:DATA: merge_ddmmyy(180613) sets year 2013
gpsd:DATA: GPRMC: registers fractional time 173603.00
gpsd:DATA: RMC: ddmmyy=180613 hhmmss=173603.00 lat=34.43 lon=-119.87
speed=0.02 track=0.00 mode=2 status=1
gpsd:DATA: GPRMC time is 1371576963.000000 = 2013-06-18T17:36:3.00Z
gpsd:PROG: GPRMC sentence timestamped 173603.00.
gpsd:PROG: GPRMC starts a reporting cycle.
gpsd:PROG: tagged GGA as a cycle ender.
gpsd:DATA: packet type 1 from /dev/ttyO0 with
{ONLINE|TIME|LATLON|SPEED|TRACK|MODE|PACKET|CLEAR}
gpsd:IO: <= GPS: $GPVTG,,T,,M,0.039,N,0.072,K,A*2C
gpsd:DATA: packet type 1 from /dev/ttyO0 with {ONLINE|PACKET}
gpsd:IO: <= GPS:
$GPGGA,173603.00,3425.96981,N,11951.97923,W,1,06,2.39,2.6,M,-33.5,M,,*68
gpsd:DATA: GPGGA: registers fractional time 173603.00
gpsd:DATA: GGA: hhmmss=173603.00 lat=34.43 lon=-119.87 alt=2.60 mode=3
status=1
gpsd:DATA: GPGGA time is 1371576963.000000 = 2013-06-18T17:36:3.00Z
gpsd:PROG: GPGGA sentence timestamped 173603.00.
gpsd:PROG: GPGGA ends a reporting cycle.
gpsd:DATA: packet type 1 from /dev/ttyO0 with
{ONLINE|TIME|LATLON|ALTITUDE|STATUS|MODE|PACKET|REPORT}
Richard Cagley
Jun 18, 2013, 1:54:23 PM6/18/13
to
On Tue, Jun 18, 2013 at 10:16 AM, Rob <nom...@example.com> wrote:
> It now locks to the serial data but not yet to the PPS.
> What happens when you add some external timeserver(s)?
> Are you within a fraction of a second from those?
>
after about 5min...
> It now locks to the serial data but not yet to the PPS.
> What happens when you add some external timeserver(s)?
> Are you within a fraction of a second from those?
>
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*SHM(0) .GPS. 0 l 4 16 377 0.000 11.086
jitter
==============================================================================
0.992
SHM(1) .GPS1. 0 l - 16 0 0.000 0.000
0.000
+clock1.redhat.c .CDMA. 1 u 12 64 37 79.170 -169.23
3.578
-a1.hotfile.com 209.51.161.238 2 u 7 64 37 59.899 -172.68
3.375
+200.140.8.72.in 64.147.116.229 2 u 11 64 37 7.124 -170.26
1.946
-ec2-50-16-231-1 209.51.161.238 2 u 11 64 37 72.309 -172.73
1.987
-nbg1.shellvator 209.51.161.238 2 u 7 64 37 74.942 -173.58
7.111
It's not very close I suppose. Maybe I just need to be patient? Unclear me
how close the time needs to be for pps to "kick in"
A C
Jun 18, 2013, 2:06:03 PM6/18/13
to
probes and it's obviously decoding data now using the generic NMEA. The
fatal error is the other one you had before ("no probe found") which is
what happens when gpsd gives up totally. The -b prevents gpsd from
writing to and reprogramming the receiver. It may have switched it to a
binary mode that it doesn't understand which would explain the probe
failure.
I suspect you may have a conflict between the kernel attempting to
control PPS and gpsd attempting to use it. Try adding "disable kernel"
to the ntp.conf to shut off the kernel's use of PPS and see if that
wakes up gpsd. If so, your serial driver doesn't want to play nice and
share the DCD line between two processes.
Rob
Jun 18, 2013, 2:28:15 PM6/18/13
to
second SHM segment and lets ntpd pick it up there. This was coded
in the days that Linux kernels often came without pps support and
additional patches would have to be applied.
I'm not too familiar with kernel pps or how you tell the kernel where
to look for the pps, and if this can interfere with gpsd.
Maybe gpsd has been updated to recognize kernel pps and stay out of
the way, but it does not look like it in your debug log.
(it still creates the pps thread)
I would try removing the kernel pps config while you use gpsd, or only add
it after it has been shown to work without it.
>
> Sorry, this is so long, but here's a dump of the gpsd output. There are
> several things that concern me, such as some of the warning, but not sure
> of the severity
>
> / # gpsd -bn -N -D5 /dev/ttyO0
> gpsd:INFO: launching (Version 3.7)
> gpsd:IO: opening IPv4 socket
> gpsd:INFO: listening on port 2947
> gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
> gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
> gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
> gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
> gpsd:PROG: shmat() succeeded, segment 131076
> gpsd:PROG: shared-segment creation succeeded,
> gpsd:PROG: PPS thread launched
> gpsd:INFO: NTPD ntpd_link_activate: 1
> gpsd:INFO: stashing device /dev/ttyO0 at slot 0
> gpsd:PROG: no etc/gpsd/device-hook present, skipped running ACTIVATE hook
> gpsd:INFO: opening read-only GPS data source type 2 and at '/dev/ttyO0'
> gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
> gpsd:PROG: PPS chrony socket /var/run/chrony.ttyO0.sock doesn't exist
> gpsd:INFO: PPS cycle: 631139111, duration: 631139111 @ 1371576962.280231
earlier log there were a few PPS pulses that looked OK.
(but then they were not used because no valid serial data was coming in)
Did you change something?
Rob
Jun 18, 2013, 2:30:03 PM6/18/13
to
There are problems when it is off by more than 400ms.
gpsd gets the serial data and the pulses, and it has to correlate the
pulses with the correct absolute timestamp. This cannot be done reliably
when the reception of the absolute timestamp is too far of the correct
time (the PPS could pull the clock to the next second). However, this
is not happening here.
Richard Cagley
Jun 18, 2013, 2:15:48 PM6/18/13
to
On Tue, Jun 18, 2013 at 11:06 AM, A C <agcarv...@acarver.net> wrote:
> I suspect you may have a conflict between the kernel attempting to control
> PPS and gpsd attempting to use it. Try adding "disable kernel" to the
> ntp.conf to shut off the kernel's use of PPS and see if that wakes up gpsd.
> If so, your serial driver doesn't want to play nice and share the DCD line
> between two processes.
Yeah, I agree. This definitely seems like the problem. I have pps support
> I suspect you may have a conflict between the kernel attempting to control
> PPS and gpsd attempting to use it. Try adding "disable kernel" to the
> ntp.conf to shut off the kernel's use of PPS and see if that wakes up gpsd.
> If so, your serial driver doesn't want to play nice and share the DCD line
> between two processes.
built into the kernel. Should I remove that support? It's slightly
confusing to me who "controls" the pps line as there are several actors in
play here...gpsd, ntpd, the kernel.
With the new entry "disable kernel" in ntpd.conf...
---
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.420 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1
server clock.redhat.com
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.420 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
disable kernel
---
I get this after about 5 min...
---
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*SHM(0) .GPS. 0 l 14 16 177 0.000 20.062
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
12.250
SHM(1) .GPS1. 0 l - 16 0 0.000 0.000
0.000
clock1.redhat.c .CDMA. 1 u 56 64 3 81.138 -165.16
0.000
14.327
vimo.dorui.net 198.82.1.203 3 u 56 64 3 81.730 -166.40
14.743
soft-sjc-01.ser 64.250.229.100 2 u 56 64 3 12.289 -165.71
10.420
199.4.29.166 64.113.32.5 2 u 56 64 3 74.375 -162.43
11.199
66-162-15-65.li 64.236.96.53 2 u 59 64 3 64.446 -159.15
10.202
---
Richard Cagley
Jun 18, 2013, 2:16:33 PM6/18/13
to
On Tue, Jun 18, 2013 at 11:06 AM, A C <agcarv...@acarver.net> wrote:
> Your "Probe not found" messages are fine since those are for specific
> probes and it's obviously decoding data now using the generic NMEA. The
> fatal error is the other one you had before ("no probe found") which is
> what happens when gpsd gives up totally. The -b prevents gpsd from writing
> to and reprogramming the receiver. It may have switched it to a binary
> mode that it doesn't understand which would explain the probe failure.
thanks. That's a great explanation.
> Your "Probe not found" messages are fine since those are for specific
> probes and it's obviously decoding data now using the generic NMEA. The
> fatal error is the other one you had before ("no probe found") which is
> what happens when gpsd gives up totally. The -b prevents gpsd from writing
> to and reprogramming the receiver. It may have switched it to a binary
> mode that it doesn't understand which would explain the probe failure.
David Taylor
Jun 18, 2013, 2:48:42 PM6/18/13
to
On 18/06/2013 18:54, Richard Cagley wrote:
[]
Now you can take the average of the offset values, say -171
(milliseconds) in round numbers, and change the ntp.conf to read:
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.171 refid GPSD
This will make the serial data be approximately in sync with the
external servers. Ideally, average over a few minutes, but it doesn't
need to be that exact unless you will have no PPS signal.
I just did the same on my Raspberry Pi test server:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
How are you feeding the PPS data into the system?
--
Cheers,
David
Web: http://www.satsignal.eu
[]
> after about 5min...
> / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> *SHM(0) .GPS. 0 l 4 16 377 0.000 11.086
> 0.992
> SHM(1) .GPS1. 0 l - 16 0 0.000 0.000
> 0.000
> +clock1.redhat.c .CDMA. 1 u 12 64 37 79.170 -169.23
> 3.578
> -a1.hotfile.com 209.51.161.238 2 u 7 64 37 59.899 -172.68
> 3.375
> +200.140.8.72.in 64.147.116.229 2 u 11 64 37 7.124 -170.26
> 1.946
> -ec2-50-16-231-1 209.51.161.238 2 u 11 64 37 72.309 -172.73
> 1.987
> -nbg1.shellvator 209.51.161.238 2 u 7 64 37 74.942 -173.58
> 7.111
>
> It's not very close I suppose. Maybe I just need to be patient? Unclear me
> how close the time needs to be for pps to "kick in"
Progress!
> / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> *SHM(0) .GPS. 0 l 4 16 377 0.000 11.086
> 0.992
> SHM(1) .GPS1. 0 l - 16 0 0.000 0.000
> 0.000
> +clock1.redhat.c .CDMA. 1 u 12 64 37 79.170 -169.23
> 3.578
> -a1.hotfile.com 209.51.161.238 2 u 7 64 37 59.899 -172.68
> 3.375
> +200.140.8.72.in 64.147.116.229 2 u 11 64 37 7.124 -170.26
> 1.946
> -ec2-50-16-231-1 209.51.161.238 2 u 11 64 37 72.309 -172.73
> 1.987
> -nbg1.shellvator 209.51.161.238 2 u 7 64 37 74.942 -173.58
> 7.111
>
> It's not very close I suppose. Maybe I just need to be patient? Unclear me
> how close the time needs to be for pps to "kick in"
Now you can take the average of the offset values, say -171
(milliseconds) in round numbers, and change the ntp.conf to read:
server 127.127.28.0 minpoll 4 maxpoll 4
This will make the serial data be approximately in sync with the
external servers. Ideally, average over a few minutes, but it doesn't
need to be that exact unless you will have no PPS signal.
I just did the same on my Raspberry Pi test server:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
How are you feeding the PPS data into the system?
--
Cheers,
David
Web: http://www.satsignal.eu
David Taylor
Jun 18, 2013, 2:56:52 PM6/18/13
to
On 18/06/2013 19:48, David Taylor wrote:
[]
If you have PPS support in the kernel you need a type 22 driver as well
as the type 28.0 driver. Type 28.1 assumes you have some software
poking timestamps into the second shared memory segment provided by
gpsd, as my user-mode Raspberry Pi system has.
Something like:
# Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag3 1 refid PPS
[]
> Progress!
>
> Now you can take the average of the offset values, say -171
> (milliseconds) in round numbers, and change the ntp.conf to read:
>
> server 127.127.28.0 minpoll 4 maxpoll 4
> fudge 127.127.28.0 time1 0.171 refid GPSD
>
> This will make the serial data be approximately in sync with the
> external servers. Ideally, average over a few minutes, but it doesn't
> need to be that exact unless you will have no PPS signal.
>
> I just did the same on my Raspberry Pi test server:
>
> http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
>
> How are you feeding the PPS data into the system?
The above assumes that time1 was initially set to zero.
>
> Now you can take the average of the offset values, say -171
> (milliseconds) in round numbers, and change the ntp.conf to read:
>
> server 127.127.28.0 minpoll 4 maxpoll 4
> fudge 127.127.28.0 time1 0.171 refid GPSD
>
> This will make the serial data be approximately in sync with the
> external servers. Ideally, average over a few minutes, but it doesn't
> need to be that exact unless you will have no PPS signal.
>
> I just did the same on my Raspberry Pi test server:
>
> http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
>
> How are you feeding the PPS data into the system?
If you have PPS support in the kernel you need a type 22 driver as well
as the type 28.0 driver. Type 28.1 assumes you have some software
poking timestamps into the second shared memory segment provided by
gpsd, as my user-mode Raspberry Pi system has.
Something like:
# Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag3 1 refid PPS
Rob
Jun 18, 2013, 3:06:23 PM6/18/13
to
You also need to wait a bit longer before giving up, especially when
you have been frantically changing things and restarting the different
daemons (but not the entire system).
ntpd does not like that.
> Yeah, I agree. This definitely seems like the problem. I have pps support
> built into the kernel. Should I remove that support? It's slightly
> confusing to me who "controls" the pps line as there are several actors in
> play here...gpsd, ntpd, the kernel.
I think with kernel pps you somewhere have to define what line is
to be used for the pps. Some specification of a tty device and a
line (e.g. DCD). I don't remember how it works exactly. However,
for testing with gpsd it seems best to remove that definition for now.
you have been frantically changing things and restarting the different
daemons (but not the entire system).
ntpd does not like that.
> Yeah, I agree. This definitely seems like the problem. I have pps support
> built into the kernel. Should I remove that support? It's slightly
> confusing to me who "controls" the pps line as there are several actors in
> play here...gpsd, ntpd, the kernel.
to be used for the pps. Some specification of a tty device and a
line (e.g. DCD). I don't remember how it works exactly. However,
for testing with gpsd it seems best to remove that definition for now.
Richard Cagley
Jun 18, 2013, 3:28:14 PM6/18/13
to
On Tue, Jun 18, 2013 at 11:56 AM, David Taylor <
david-...@blueyonder.co.uk.invalid> wrote:
> If you have PPS support in the kernel you need a type 22 driver as well as
> the type 28.0 driver. Type 28.1 assumes you have some software poking
> timestamps into the second shared memory segment provided by gpsd, as my
> user-mode Raspberry Pi system has.
>
> Something like:
>
> # Kernel-mode PPS ref-clock for the precise seconds
> server 127.127.22.0 minpoll 4 maxpoll 4
> fudge 127.127.22.0 flag3 1 refid PPS
>
I'm having a hard time understanding this. Let's consider two cases:
david-...@blueyonder.co.uk.invalid> wrote:
> If you have PPS support in the kernel you need a type 22 driver as well as
> the type 28.0 driver. Type 28.1 assumes you have some software poking
> timestamps into the second shared memory segment provided by gpsd, as my
> user-mode Raspberry Pi system has.
>
> Something like:
>
> # Kernel-mode PPS ref-clock for the precise seconds
> server 127.127.22.0 minpoll 4 maxpoll 4
> fudge 127.127.22.0 flag3 1 refid PPS
>
1.) I have pps support built into my kernel:
In addition to the 127.127.28.0 to grab nmea time data You suggest using
the pps line driver instead of 127.127.28.1? You're saying that gpsd will
not do this for me? I'm not sure what "some software" refers to. Should I
be using 127.127.28.1 ever?
2.) I don't have pps support:
Well, I'm not sure what to do in this case but others have indicated that
gpsd can grab both nmea and pps. Hence, I would think I'd use 127.127.28.0
and 127.127.28.1.
Richard Cagley
Jun 18, 2013, 3:44:40 PM6/18/13
to
On Tue, Jun 18, 2013 at 11:28 AM, Rob <nom...@example.com> wrote:
> Well, gpsd does not use kernel pps. It puts the pps time into the
> second SHM segment and lets ntpd pick it up there. This was coded
> in the days that Linux kernels often came without pps support and
> additional patches would have to be applied.
> I'm not too familiar with kernel pps or how you tell the kernel where
> to look for the pps, and if this can interfere with gpsd.
> Maybe gpsd has been updated to recognize kernel pps and stay out of
> the way, but it does not look like it in your debug log.
> (it still creates the pps thread)
> I would try removing the kernel pps config while you use gpsd, or only add
> it after it has been shown to work without it.
>
> Well, gpsd does not use kernel pps. It puts the pps time into the
> second SHM segment and lets ntpd pick it up there. This was coded
> in the days that Linux kernels often came without pps support and
> additional patches would have to be applied.
> I'm not too familiar with kernel pps or how you tell the kernel where
> to look for the pps, and if this can interfere with gpsd.
> Maybe gpsd has been updated to recognize kernel pps and stay out of
> the way, but it does not look like it in your debug log.
> (it still creates the pps thread)
> I would try removing the kernel pps config while you use gpsd, or only add
> it after it has been shown to work without it.
>
> Strang that this is the last that is heard from PPS, while in your
> earlier log there were a few PPS pulses that looked OK.
> (but then they were not used because no valid serial data was coming in)
> Did you change something?
>
Yeah, it's a huge mystery to me how the kernel is getting pps info without
> earlier log there were a few PPS pulses that looked OK.
> (but then they were not used because no valid serial data was coming in)
> Did you change something?
>
me even telling it where the pin is. I can build in kernel pps support and
debug output and see messages ever second on the console without ever
explicitly doing an ldattach to /dev/ttyO0. I'm using the DCD pin, which I
think is default. Maybe the kernel can generate it's own pps signaling, but
I don't think it can. I'm using plain jane pps source out of the 2.6.37
kernel.
The output you refer to may be partial. I do see lots of NMEA data.
Richard Cagley
Jun 18, 2013, 3:47:04 PM6/18/13
to
On Tue, Jun 18, 2013 at 11:48 AM, David Taylor <
david-...@blueyonder.co.uk.invalid> wrote:
> How are you feeding the PPS data into the system?
DCD pin on /dev/ttyO0
david-...@blueyonder.co.uk.invalid> wrote:
> How are you feeding the PPS data into the system?
Richard Cagley
Jun 18, 2013, 3:50:41 PM6/18/13
to
On Tue, Jun 18, 2013 at 12:06 PM, Rob <nom...@example.com> wrote:
> You also need to wait a bit longer before giving up, especially when
> you have been frantically changing things and restarting the different
> daemons (but not the entire system).
>
> ntpd does not like that.
>
> You also need to wait a bit longer before giving up, especially when
> you have been frantically changing things and restarting the different
> daemons (but not the entire system).
>
> ntpd does not like that.
>
> I think with kernel pps you somewhere have to define what line is
> to be used for the pps. Some specification of a tty device and a
> line (e.g. DCD). I don't remember how it works exactly. However,
> for testing with gpsd it seems best to remove that definition for now.
>
I typically just reboot rather than starting/stopping daemons so I'm back
> to be used for the pps. Some specification of a tty device and a
> line (e.g. DCD). I don't remember how it works exactly. However,
> for testing with gpsd it seems best to remove that definition for now.
>
into a known state.
Does "removing a definition" refer to removing one of the timeservers from
the ntp.conf file? Presently, I don't have pps support built into my kernel.
Rob
Jun 18, 2013, 4:46:36 PM6/18/13
to
Richard Cagley <rca...@gmail.com> wrote:
> Does "removing a definition" refer to removing one of the timeservers from
> the ntp.conf file? Presently, I don't have pps support built into my kernel.
I'm sorry, but I am not familiar with it.
> Does "removing a definition" refer to removing one of the timeservers from
> the ntp.conf file? Presently, I don't have pps support built into my kernel.
I use gpsd+ntpd on a system without pps support.
I think it can be done in two ways (but I am not sure):
1. by using a driver inside ntpd to support a GPS receiver
2. by using some program to tell the kernel where to look for pps pulses.
That program is then probably called somewhere in system startup.
But I don't have any details on that.
What should be clear is that you *cannot* use the ntpd driver for a
GPS receiver and gpsd at the same time. They would have to share the
data from the serial port.
In fact this is one of the reasons why gpsd exists at all, and why it
has time sync functions. When you want to use the receiver both for
time sync and position info, the data somehow has to be multiplexed.
(it seems there is some limited function in one of the ntpd GPS drivers
to save the position info somewhere where it can be accessed by other
programs)
Doug Calvert
Jun 18, 2013, 6:35:49 PM6/18/13
to
On Tue, Jun 18, 2013 at 4:46 PM, Rob <nom...@example.com> wrote:
>
> (it seems there is some limited function in one of the ntpd GPS drivers
> to save the position info somewhere where it can be accessed by other
> programs)
Fudge flag4=0 should put location data in clockstats:
>
> (it seems there is some limited function in one of the ntpd GPS drivers
> to save the position info somewhere where it can be accessed by other
> programs)
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html#fudgeflag4
http://www.eecis.udel.edu/~mills/ntp/html/monopt.html
David Taylor
Jun 19, 2013, 1:14:18 AM6/19/13
to
On 18/06/2013 20:28, Richard Cagley wrote:
[]
transition times. I saw this:
$ sudo ppstest /dev/pps0 # press Ctrl-C to cancel..
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1351501153.999956346, sequence: 47481 - clear
0.000000000, sequence: 0
source 0 - assert 1351501154.999954601, sequence: 47482 - clear
0.000000000, sequence: 0
source 0 - assert 1351501155.999951856, sequence: 47483 - clear
0.000000000, sequence: 0
^C
Sorry about the wrap! The "some software" refers to the Raspberry Pi
I'm using, where a 3rd-party program supplies the PPS data to the gpsd
memory segment number 1. I don't know whether gpsd can time the DCD
line or not - it's outside the scope of my experience. If it can, use
28.1, if not, use 22.0.
[]
> I'm having a hard time understanding this. Let's consider two cases:
>
> 1.) I have pps support built into my kernel:
> In addition to the 127.127.28.0 to grab nmea time data You suggest using
> the pps line driver instead of 127.127.28.1? You're saying that gpsd will
> not do this for me? I'm not sure what "some software" refers to. Should I
> be using 127.127.28.1 ever?
>
> 2.) I don't have pps support:
> Well, I'm not sure what to do in this case but others have indicated that
> gpsd can grab both nmea and pps. Hence, I would think I'd use 127.127.28.0
> and 127.127.28.1.
To distinguish between 1 and 2, run the PPS test, which shows the
>
> 1.) I have pps support built into my kernel:
> In addition to the 127.127.28.0 to grab nmea time data You suggest using
> the pps line driver instead of 127.127.28.1? You're saying that gpsd will
> not do this for me? I'm not sure what "some software" refers to. Should I
> be using 127.127.28.1 ever?
>
> 2.) I don't have pps support:
> Well, I'm not sure what to do in this case but others have indicated that
> gpsd can grab both nmea and pps. Hence, I would think I'd use 127.127.28.0
> and 127.127.28.1.
transition times. I saw this:
$ sudo ppstest /dev/pps0 # press Ctrl-C to cancel..
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1351501153.999956346, sequence: 47481 - clear
0.000000000, sequence: 0
source 0 - assert 1351501154.999954601, sequence: 47482 - clear
0.000000000, sequence: 0
source 0 - assert 1351501155.999951856, sequence: 47483 - clear
0.000000000, sequence: 0
^C
Sorry about the wrap! The "some software" refers to the Raspberry Pi
I'm using, where a 3rd-party program supplies the PPS data to the gpsd
memory segment number 1. I don't know whether gpsd can time the DCD
line or not - it's outside the scope of my experience. If it can, use
28.1, if not, use 22.0.
Charles Elliott
Jun 19, 2013, 5:23:38 AM6/19/13
to
You can slightly improve NTPS's performance by suppressing all the NMEA
messages except the one NTPD needs for the time, such as RMC. That way the
program does not have to sort through the receive buffer looking for the
particular message type it needs, and there is much less traffic on the
RS-232 line. Many GPS device manufacturers have manuals that tell how to
change the NMEA message output rate. If you have a SiRF or SURE chip, I can
help with such a manual.
Charles Elliott
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
messages except the one NTPD needs for the time, such as RMC. That way the
program does not have to sort through the receive buffer looking for the
particular message type it needs, and there is much less traffic on the
RS-232 line. Many GPS device manufacturers have manuals that tell how to
change the NMEA message output rate. If you have a SiRF or SURE chip, I can
help with such a manual.
Charles Elliott
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
Charles Elliott
Jun 19, 2013, 5:48:52 AM6/19/13
to
> When you want to use the receiver both for
> time sync and position info, the data somehow has to be multiplexed.
While this does not help the present problem, it may be possible to
> time sync and position info, the data somehow has to be multiplexed.
multiplex GPS device output under Windows and using a SiRF receiver. The
new SiRF demo program (Version 3.87) says it can read a SiRF receiver using
SiRF's proprietary protocol binary output, and the demo program will output
corresponding NMEA ASCII messages to a virtual COM port. If that works, and
I have not tried it, one could see position, time, and a satellite map in
the demo program and NTPS could still receive the NMEA messages.
One can find SiRFDemo (3.87) by searching for it with Google or Bing.
Charles Elliott
> -----Original Message-----
> From: questions-bounces+elliott.ch=veriz...@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=veriz...@lists.ntp.org] On
> Behalf Of Rob
> Sent: Tuesday, June 18, 2013 4:47 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] ntpd connect gpsd shared memory driver
>
Richard Cagley
Jun 19, 2013, 10:58:31 AM6/19/13
to
On Tue, Jun 18, 2013 at 10:14 PM, David Taylor <
david-...@blueyonder.co.uk.invalid> wrote:
> To distinguish between 1 and 2, run the PPS test, which shows the
> transition times. I saw this:
>
> $ sudo ppstest /dev/pps0 # press Ctrl-C to cancel..
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1351501153.999956346, sequence: 47481 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1351501154.999954601, sequence: 47482 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1351501155.999951856, sequence: 47483 - clear
> 0.000000000, sequence: 0
> ^C
>
> Sorry about the wrap! The "some software" refers to the Raspberry Pi I'm
> using, where a 3rd-party program supplies the PPS data to the gpsd memory
> segment number 1. I don't know whether gpsd can time the DCD line or not -
> it's outside the scope of my experience. If it can, use 28.1, if not, use
> 22.0.
>
Thanks. It appears it may have just been a patience issue on my part. I let
david-...@blueyonder.co.uk.invalid> wrote:
> To distinguish between 1 and 2, run the PPS test, which shows the
> transition times. I saw this:
>
> $ sudo ppstest /dev/pps0 # press Ctrl-C to cancel..
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1351501153.999956346, sequence: 47481 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1351501154.999954601, sequence: 47482 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1351501155.999951856, sequence: 47483 - clear
> 0.000000000, sequence: 0
> ^C
>
> Sorry about the wrap! The "some software" refers to the Raspberry Pi I'm
> using, where a 3rd-party program supplies the PPS data to the gpsd memory
> segment number 1. I don't know whether gpsd can time the DCD line or not -
> it's outside the scope of my experience. If it can, use 28.1, if not, use
> 22.0.
>
it run overnight with this
server 127.127.20.0
fudge 127.127.20.0
server 127.127.22.0
fudge 127.127.22.0 flag3 1
and got this
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
xGPS_NMEA(0) .GPS. 0 l 29 64 377 0.000 140.035
remote refid st t when poll reach delay offset
jitter
==============================================================================
0.002
xPPS(0) .PPS. 0 l 28 64 377 0.000 -129.94
0.002
Now, I guess I need to figure out why the date is so off...
/ # date
Sat Jan 1 14:26:50 UTC 2000
Rob
Jun 19, 2013, 11:21:31 AM6/19/13
to
Charles Elliott <ellio...@verizon.net> wrote:
>> When you want to use the receiver both for
>> time sync and position info, the data somehow has to be multiplexed.
>
> While this does not help the present problem, it may be possible to
> multiplex GPS device output under Windows and using a SiRF receiver. The
> new SiRF demo program (Version 3.87) says it can read a SiRF receiver using
> SiRF's proprietary protocol binary output, and the demo program will output
> corresponding NMEA ASCII messages to a virtual COM port.
That is like what gpsd does.
>> When you want to use the receiver both for
>> time sync and position info, the data somehow has to be multiplexed.
>
> While this does not help the present problem, it may be possible to
> multiplex GPS device output under Windows and using a SiRF receiver. The
> new SiRF demo program (Version 3.87) says it can read a SiRF receiver using
> SiRF's proprietary protocol binary output, and the demo program will output
> corresponding NMEA ASCII messages to a virtual COM port.
David Taylor
Jun 20, 2013, 1:43:35 AM6/20/13
to
On 19/06/2013 15:58, Richard Cagley wrote:
[]
NTP would refuse to start? Is the date from the GPS receiver correct?
Some older receivers had a GPS week roll-over issue. To get the date
right, I would add some Internet servers perhaps via the POOL directive
as a sanity check:
# UK pool servers
pool uk.pool.ntp.org iburst
Choose your appropriate region, of course, or just use:
pool pool.ntp.org iburst
There's a way to get NTP to force a date and time setting at start-up, a
command parameter: "-g". See:
http://www.meinbergglobal.com/download/ntp/docs/ntp_cheat_sheet.pdf
Maybe you already have that set?
[]
> Now, I guess I need to figure out why the date is so off...
> / # date
> Sat Jan 1 14:26:50 UTC 2000
If the date and time is more than a certain amount out, I thought that
> / # date
> Sat Jan 1 14:26:50 UTC 2000
NTP would refuse to start? Is the date from the GPS receiver correct?
Some older receivers had a GPS week roll-over issue. To get the date
right, I would add some Internet servers perhaps via the POOL directive
as a sanity check:
# UK pool servers
pool uk.pool.ntp.org iburst
Choose your appropriate region, of course, or just use:
pool pool.ntp.org iburst
There's a way to get NTP to force a date and time setting at start-up, a
command parameter: "-g". See:
http://www.meinbergglobal.com/download/ntp/docs/ntp_cheat_sheet.pdf
Maybe you already have that set?
Richard Cagley
Jun 20, 2013, 10:29:14 AM6/20/13
to
On Wed, Jun 19, 2013 at 10:43 PM, David Taylor <
david-...@blueyonder.co.uk.invalid> wrote:
> If the date and time is more than a certain amount out, I thought that NTP
> would refuse to start? Is the date from the GPS receiver correct? Some
> older receivers had a GPS week roll-over issue. To get the date right, I
> would add some Internet servers perhaps via the POOL directive as a sanity
> check:
no internet access ;)
david-...@blueyonder.co.uk.invalid> wrote:
> If the date and time is more than a certain amount out, I thought that NTP
> would refuse to start? Is the date from the GPS receiver correct? Some
> older receivers had a GPS week roll-over issue. To get the date right, I
> would add some Internet servers perhaps via the POOL directive as a sanity
> check:
I ended up using gpsd to set the date/time on cold start. Yes, ntp requires
the time to be within 4 hours in order to start updating.
0 new messages