|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
gpsd 1 PPS problemI'm using Debian Lenny, gpsd 2.37, ntp (not openntp), Trimble Resolution-T receiver, TSIP protocol, serial port ttyS0.
The debug output from gpsd confirms time, position, etc. are okay -- but the 1 PPS seems to be ignored. With the 1 PPS applied to Carrier Detect pin, should the debug list (D6) show CD updates? I suspected the low voltage (2.8 V) from the Resolution-T but 4.5V does not make any difference. See the debug output, shmat assignments, and 'ntpq -p' sample below. Thanks for any information or suggestions. --------- gpsd -n -N -D6 /dev/ttyS0 gpsd: launching (Version 2.37) gpsd: listening on port gpsd gpsd: shmat(0,0,0) succeeded gpsd: shmat(0,0,0) succeeded gpsd: shmat(0,0,0) succeeded gpsd: shmat(0,0,0) succeeded gpsd: running with effective group ID 0 gpsd: running with effective user ID 0 gpsd: opening GPS data source at '/dev/ttyS0' gpsd: speed 9600, 8N1 gpsd: => GPS: $PASHQ,RID*28\x0d .. .. gpsd: Satellite Tracking Status: Ch 0 PRN 9 Res 0 Acq 1 Eph 1 SNR 29.5 LMT 427358.4688 El 15.5 Az 37.1 .. gpsd: TSIP packet id 0x8f length 17: ab0006855f0622000f03182a160b0207da gpsd: GPS Time 427359.000000 1570 15 .. -------------------- cat /proc/sysvipc/shm key shmid perms size cpid lpid nattch uid gid cuid cgid atime dtime ctime 1314148400 0 644 80 2466 3108 1 0 0 0 0 1265928142 1265928144 1265927571 1314148401 32769 644 80 2466 3108 1 0 0 0 0 1265928142 1265928144 1265927571 1314148402 65538 644 80 2466 3108 0 0 0 0 0 1265928142 1265928144 1265927571 1314148403 98307 644 80 2466 3108 0 0 0 0 0 1265928142 1265928144 1265927571 0 131076 1600 393216 2925 2940 2 1000 1000 1000 1000 1265927615 1265927615 1265927614 0 163845 1600 393216 2972 2859 2 1000 1000 1000 1000 1265927621 0 1265927621 0 196614 1600 393216 2949 3111 2 1000 1000 1000 1000 1265928181 1265928181 1265927623 0 229383 1600 393216 2952 2859 2 1000 1000 1000 1000 1265927623 0 1265927623 0 262152 1600 393216 3002 2859 2 1000 1000 1000 1000 1265927627 0 1265927627 0 294921 1600 393216 2930 2859 2 1000 1000 1000 1000 1265927631 0 1265927631 0 327690 1600 393216 2952 2859 2 1000 1000 1000 1000 1265927632 0 1265927632 0 360459 1600 393216 3007 3032 2 1000 1000 1000 1000 1265927659 1265927659 1265927638 0 393228 1600 393216 2945 2859 2 1000 1000 1000 1000 1265927638 0 1265927638 0 425997 1600 393216 2945 2859 2 1000 1000 1000 1000 1265927638 0 1265927638 ---------- ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== SHM(0) .GPS. 0 l 481 16 0 0.000 -52.658 23.954 SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.001 *131.107.13.100 .ACTS. 1 u 29 64 377 57.593 -35.208 8.365 _______________________________________________ Gpsd-users mailing list Gpsd-users@... https://lists.berlios.de/mailman/listinfo/gpsd-users |
|
|
Re: gpsd 1 PPS problem-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Yo Robert! On Thu, 11 Feb 2010, Robert Livingston wrote: > I'm using Debian Lenny, gpsd 2.37, ntp (not openntp), Trimble Resolution > -T receiver, TSIP protocol, serial port ttyS0. 2.37 is ancient. Lot's of PPS fixes up to 2.90. Upgrade now. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem@... Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFLdL1kBmnRqz71OvMRAli2AKCpRSvchojK56Nxmkr/M44pDveNDQCgnaW0 +ckkshAMGhKQ4YI4Ww40N9k= =RaaD -----END PGP SIGNATURE----- _______________________________________________ Gpsd-users mailing list Gpsd-users@... https://lists.berlios.de/mailman/listinfo/gpsd-users |
|
|
interpreting ntpq with 1 ppsGary,
As you suggested in your reply a couple of weeks ago, moving to 2.90 under Debian Squeeze solved my 1 pps problems. Thanks. With the 1 pps, the typical 'ntpq -p' output looks like that below, i.e. selection of the 1 pps and correspondingly low jitter. It will log something like the following for hours/days: remote refid st t when poll reach delay offset jitter ========================================== +131.107.13.100 .ACTS. 1 u 14 64 337 57.288 2.164 0.238 +SHM(0) .GPS. 0 l 12 16 377 0.000 -23.984 2.135 *SHM(1) .GPS1. 0 l 5 16 377 0.000 -0.003 0.001 However, there was one period I observed when ntpd suddenly bounced around the servers, discarding all at one point, and mostly ignoring the 1 pps. These log entries are separated by 10 minutes: remote refid st t when poll reach delay offset jitter ======================================= 131.107.13.100 .ACTS. 1 u 129 64 0 57.456 3.205 0.000 xSHM(0) .GPS. 0 l 10 16 377 0.000 -31.983 4.781 xSHM(1) .GPS1. 0 l 14 16 377 0.000 -2.915 0.256 remote refid st t when poll reach delay offset jitter ======================================= x131.107.13.100 .ACTS. 1 u 18 64 357 57.539 7.029 4.929 +SHM(0) .GPS. 0 l 9 16 377 0.000 -19.983 5.856 *SHM(1) .GPS1. 0 l 8 16 377 0.000 3.066 0.227 remote refid st t when poll reach delay offset jitter ======================================= 131.107.13.100 .ACTS. 1 u 39 64 300 57.306 6.150 0.358 +SHM(0) .GPS. 0 l 15 16 377 0.000 0.016 15.042 *SHM(1) .GPS1. 0 l 3 16 377 0.000 2.851 0.677 remote refid st t when poll reach delay offset jitter ======================================= x131.107.13.100 .ACTS. 1 u 2 64 376 57.548 3.578 0.668 xSHM(0) .GPS. 0 l 3 16 377 0.000 -35.983 12.095 xSHM(1) .GPS1. 0 l 15 16 377 0.000 0.045 0.019 remote refid st t when poll reach delay offset jitter ======================================= 131.107.13.100 .ACTS. 1 u 22 64 0 58.081 3.197 0.000 xSHM(0) .GPS. 0 l 11 16 377 0.000 -39.983 16.970 xSHM(1) .GPS1. 0 l 9 16 377 0.000 0.185 0.079 remote refid st t when poll reach delay offset jitter ======================================= +131.107.13.100 .ACTS. 1 u 45 64 17 56.978 1.852 0.158 +SHM(0) .GPS. 0 l 8 16 377 0.000 -39.983 9.681 *SHM(1) .GPS1. 0 l 18 16 377 0.000 -0.698 0.426 Once settled back, the jitter will drop down to 0.001 and stay there again for hours/days. Is there anything systematic about such excursions (e.g. incorrect ntpd settings), or was this one a fluke? Robert Gary E. Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yo Robert! > > On Thu, 11 Feb 2010, Robert Livingston wrote: > > >> I'm using Debian Lenny, gpsd 2.37, ntp (not openntp), Trimble Resolution >> -T receiver, TSIP protocol, serial port ttyS0. >> > > 2.37 is ancient. Lot's of PPS fixes up to 2.90. Upgrade now. > > RGDS > GARY > - --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 > gem@... Tel:+1(541)382-8588 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFLdL1kBmnRqz71OvMRAli2AKCpRSvchojK56Nxmkr/M44pDveNDQCgnaW0 > +ckkshAMGhKQ4YI4Ww40N9k= > =RaaD > -----END PGP SIGNATURE----- > > > > _______________________________________________ Gpsd-users mailing list Gpsd-users@... https://lists.berlios.de/mailman/listinfo/gpsd-users |
|
|
Re: interpreting ntpq with 1 pps-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Yo Robert! On Tue, 23 Feb 2010, Robert Livingston wrote: > As you suggested in your reply a couple of weeks ago, moving to 2.90 > under Debian Squeeze solved my 1 pps problems. Thanks. Glad to hear it. > Is there anything systematic about such excursions (e.g. incorrect ntpd > settings), or was this one a fluke? Most likely you had some other work happening on your clock server that increased the interrupt latency. It would be useful to compare the times you had bad jitter to the sar report. You can help things a lot by being sure that ntpd and gpsd are both running at a high negative nice number. ntpd now has the -N option to do this, gpsd should probably have something similat. Try running gpsd this way: nice -n -20 gpsd -nNGD 6 /dev/ttyS0 2>&1 | egrep 'PPS|NTP' The nice will give gpsd a high priority and the egrep will log the PPS relevant info. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem@... Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFLhC7YBmnRqz71OvMRAqABAKCX25a0csDmPxh2zdfGQ135j8jJGQCgxO28 5HYe1HTjsNBrFNWWk7u3Vhk= =S6sS -----END PGP SIGNATURE----- _______________________________________________ Gpsd-users mailing list Gpsd-users@... https://lists.berlios.de/mailman/listinfo/gpsd-users |
| Free embeddable forum powered by Nabble | Forum Help |