[gpsd-dev] Need p/d help with gpsd and or gps HW - no response after gps polling

[Steve Lang]

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