[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-dev] Need p/d help with gpsd and or gps HW - no response after gps
From: |
Steve Lang |
Subject: |
[gpsd-dev] Need p/d help with gpsd and or gps HW - no response after gps polling |
Date: |
Tue, 12 Jul 2016 22:47:19 -0500 |
Folks .. would like some p/d help from the group to determine if I am
dealing with a gpsd defect or a gps hw bug.
HW Config: Pi 3, Adafruit GPS hat, and LNA
SW Config: latest Jessi / clockmaker install script abd SW updates to
support installing the following scons options:
shm option enabled with compiled ntpsec
scons timeservice=yes nmea0183=yes fixed_port_speed=9600
fixed_stop_bits=1 xgps=yes leapfetch=yes qt=yes gpsdclients=yes
Symptoms: gpsd appears to hang if gpsd does not receive data
-D6 logging enabled
gpsd work good maybe for a day at the most and as long as a few hours.
When the problem happens, ntp moves off the gps shm source to an
external provider and the following is logged:
-----------------Cut-------------------------
Jul 10 20:35:56 chilipi gpsd[430]: gpsd:PROG: GPRMC ends a reporting cycle.
Jul 10 20:35:56 chilipi gpsd[430]: gpsd:DATA: packet type 1 from
/dev/gpsd0 with {ONLINE|TIME|LATLON|SPEED|TRACK|PACKET|REPORT|NTPTIME}
Jul 10 20:35:56 chilipi gpsd[430]: gpsd:IO: <= GPS:
$GPVTG,286.74,T,,M,0.02,N,0.03,K,D*36
Jul 10 20:35:56 chilipi gpsd[430]: gpsd:DATA: packet type 1 from
/dev/gpsd0 with {ONLINE|PACKET}
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:PROG: KPPS:/dev/pps0 assert
1468200957.000886155, sequence: 517, clear 0.000000000, sequence: 0
- using: assert
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:PROG: KPPS:/dev/pps0 Assert
cycle: 1000001, duration: 0 @ 1468200957.000886155
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:PROG: PPS:/dev/pps0 Assert
cycle: 1000001, duration: 0 @ 1468200957.000886155
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:PROG: NTP:
ntpshm_put(/dev/gpsd0 pps) 1468200957.000000000 @
1468200957.000886155
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:INFO: PPS:/dev/pps0 Assert
hooks called clock: 1468200957.000886155 real: 1468200957.000000000:
accepted
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:PROG: PPS:/dev/pps0 Assert
accepted @ 1468200957.000886155 offset -0.000886155
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:DATA: /dev/gpsd0 returned zero bytes
Jul 10 20:35:57 chilipi gpsd[430]: gpsd:DATA: /dev/gpsd0 will be
repolled in 0.010000 seconds
Jul 10 20:35:58 chilipi gpsd[430]: gpsd:PROG: KPPS:/dev/pps0 assert
1468200958.000884876, sequence: 518, clear 0.000000000, sequence: 0
- using: assert
Jul 10 20:35:58 chilipi gpsd[430]: gpsd:PROG: KPPS:/dev/pps0 Assert
cycle: 999998, duration: 0 @ 1468200958.000884876
Jul 10 20:35:58 chilipi gpsd[430]: gpsd:PROG: PPS:/dev/pps0 Assert
cycle: 999998, duration: 0 @ 1468200958.000884876
Jul 10 20:35:58 chilipi gpsd[430]: gpsd:PROG: PPS:/dev/pps0 Assert
rejected this second already handled
----------------Cut----------------------------
The last 4 lines are repeated for the remainder of the log file.
Based on the following lines below
----------Cut------------
gpsd:DATA: /dev/gpsd0 returned zero bytes
gpsd:DATA: /dev/gpsd0 will be repolled in 0.010000 seconds
---------Cut-------------
ibgpsd_core.c
gpsd_multipoll()
..
..
} else if (changed == NODATA_IS) {
/*
* No data on the first fragment read means the device
* fd may have been in an end-of-file condition on select.
*/
if (fragments == 0) {
gpsd_log(&device->context->errout, LOG_DATA,
"%s returned zero bytes\n", <-
device->gpsdata.dev.path);
..
..
} else {
/*
* Disable listening to this fd for long enough
* that the buffer can fill up again.
*/
gpsd_log(&device->context->errout, LOG_DATA,
"%s will be repolled in %f seconds\n", <-
device->gpsdata.dev.path, reawake_time);
device->reawake = time(NULL) + reawake_time;
return DEVICE_UNREADY;
taking us back to gpsd.c / main()
case DEVICE_UNREADY:
FD_CLR(device->gpsdata.gps_fd, &all_fds);
adjust_max_fd(device->gpsdata.gps_fd, false);
Due to lack of logging in this path I cant tell where we ended up and
if an attempt was planned to resume IO to this GPS.
I ran gpsmon when this condition is happening.which seems to return
valid data ..
I have spoken with another contributor who suggested I run cgps to
determine if the gps is actually alive which I will do tomorrow. Once
I have this info I'll return and re-post.
Regards,
--Steve
- [gpsd-dev] Need p/d help with gpsd and or gps HW - no response after gps polling,
Steve Lang <=