gpsd clients get "stuck" and report incorrect status & position info

[Ryan Collins]

Using the current version of gpsd in the Raspbian Buster repository (gpsd 3.17-7), GPS clients appear to get "stuck" reporting a 3D FIX, even when the GPS does not in fact have a fix. If a new client is started while the GPS doesn't have a fix, it will correctly report a status of NO FIX, while the original clients continue to report 3D FIX. I've tested this by disconnecting and reconnecting the patch antenna (https://www.adafruit.com/product/960).

Some configuration information: I am running Raspbian GNU/Linux 10 (buster) on a Raspberry Pi 4 with the Adafruit Ultimate GPS Hat (https://www.adafruit.com/product/2324). I've configured Pi to use the hardware UART for the GPS and have also configured PPS support (following the steps in this guide for the relevant portions http://www.unixwiz.net/techtips/raspberry-pi3-gps-time.html). I have confirmed this on two separate Pi 4 w/ GPS Hat setups.

Steps to reproduce:

1. Install gpsd "apt-get install gpsd gpsd-clients libgps-dev"

2. Configure the GPSD startup options in the file /etc/default/gpsd
START_DAEMON="true"
USBAUTO="true"
DEVICES="/dev/ttyAMA0 /dev/pps0"
GPSD_OPTIONS="-n -r"

3. Enable and start gpsd
# systemctl enable gpsd
# systemctl start gpsd

4. With the GPS antenna connected, start cgps and wait for it to report a status "3D FIX"
$ cgps

5. While cgps is still running, disconnect the GPS antenna. In the case of the Adafruit GPS, you can confirm NO FIX by observing a 1 Hz blink on the GPS's PCB.

6. After confirming that the GPS receiver has no fix, observe the running cgps program in the terminal. It will continue to report "3D FIX" along with position information.

7. In a new terminal window launch a new instance of cgps. This instance will report the correct status of "NO FIX" while the old instance will continue to erroneously report a "3D FIX".

This bug implies that any active libgps client cannot successfully determine if its position fix is valid or not. It will never know if the receiver has lost its fix.

Solution:

I have confirmed that the bug is not present in gpsd-3.19, but it is present in gpsd-3.17, 3.18, and 3.18.1. To test gpsd-3.19 I ran the following

pi@raspberry:~ $ sudo systemctl start gpsd.service gpsd.socket
pi@raspberry:~ $ wget https://download-mirror.savannah.gnu.org/releases/gpsd/gpsd-3.19.tar.gz
pi@raspberry:~ $ tar -xzf gpsd-3.19.tar.gz && cd gpsd-3.19
pi@raspberry:~/gpsd-3.19 $ scons -j4
pi@raspberry:~/gpsd-3.19 $ sudo ./gpsd -n -r -N -D3 /dev/ttyAMA0 /dev/pps0

In another console, run cgps 3.19

pi@raspberry:~/gpsd-3.19 $ ./cgps

Repeat the steps to reproduce the bug, and confirm that after disconnecting the antenna and observing the GPS has no fix, cgps 3.19 status will change from "3D FIX" to "NO FIX".

Additional bug information:

I also cloned the gpsd git repository <https://gitlab.com/gpsd/gpsd> and performed a git bisect between the tags "release-3.19" (commit 680abf041) and "release-3.17" (commit 18bc54e3e). Commit f9621160c is the first commit where I could not reproduce the bug and cgps correctly changes its status from "3D FIX" to "NO DR FIX" after the patch antenna is disconnected (DR means dead reckoning).

Miscellaneous system information:

kernel version: Linux rq-ntp 4.19.71-v7l #3 SMP Fri Sep 13 20:29:56 UTC 2019 armv7l GNU/Linux
libc version: 2.28-10+rpi1