GPS position information doesn't update beyond a first fix with certain devices (e.g. u-blox 6). The issue has been discussed in the gpsd gitlab. Building current versions from source fixes this issue.

[Cornelius von Einem]

gpsd launches and connects to the gps device. Information is monitored for example using cgps or gpspipe. The device establishes a first fix and reports the position. From this point on, gpsd keeps updating the number of visible satellites, the timestamps (synching to gps clock works), but doesn't update the reported position. it will remain at the first fix.
This has been observed using a u-blox 6 device.

removing the apt version of gpsd and building a newer version from source (e.g. 3.25) fixes this issue and everything works as expected.

This has been observed on ubuntu 20.04, where the gpsd version from apt is 3.20.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gpsd (not installed)
ProcVersionSignature: Ubuntu 5.14.0-1057.64-oem 5.14.21
Uname: Linux 5.14.0-1057-oem x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Mar 15 15:46:44 2023
InstallationDate: Installed on 2022-05-05 (313 days ago)
InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223)
SourcePackage: gpsd
UpgradeStatus: No upgrade log present (probably fresh install)

[Paride Legovini (paride)]

Hello and thanks for this bug report. Working on this bug won't be easy as reproducing it requires specific hardware. We'll need some guidance from you in order to decide how to proceed (we can't just update to the latest version, see [1]). In particular I have a few questions:

- Does the bug affect Ubuntu 22.04 (Jammy), which packages gpsd 3.22? You may be able to test this booting to the ISO image live system.
- Does the bug affect Bionic (gpsd 3.17)?
- Can you point us to the upstream discussion you mentioned?

Thanks!

[1] https://wiki.ubuntu.com/StableReleaseUpdates

[Cornelius von Einem (ceinem)]

Hello, thanks for getting onto this so quickly. My u-blox is quite old and builidng the latests gpsd from source fixed the issue for me, so I think this is quite niche.

The upstream discussion I mentioned is here: https://gitlab.com/gpsd/gpsd/-/issues/138
There they also test with 3.17 where it seems to work fine.

I will try to test with Jammy and Bionic myself and add another comment here accordingly.

[Cornelius von Einem (ceinem)]

Hello,

I finally had a chance to test this today on Ubuntu 22.04 with the default version from apt (3.22). Same issue persists. GPSD keeps reporting the same position of the first fix it got, but still keeps updating #satellites and timestamps. If GPSD is restarted, it gets a new first fix and then keeps reporting this one. Very weird behavior. Again, compiling a newer version completely fixes this.

I didn't have time yet to test on Ubuntu 18 as my machine had some driver issues booting into 18.

[Miriam España Acebal (mirespace)]

Hi Cornelius,

Thank you for the test and for sharing the upstream's thread. I read at the end of the discussion that the reporter there fixed the issue by resetting the device with

ubxtool -p RESET

Can you test it?

On the other hand, gpsd package is in sync with Debian and Debian doesn't yet have the latest version 3.25 (Jan 10 2023).

If the resetting doesn't work for you, the next actions should be to have a reproducible set of steps to go through the issue (maybe a raw log from gpspipe? ) and the code commit(s) on upstream from version 3.25 that fix the issue as you commented before. Could you please provide those? All of this is needed to start an SRU procedure [1] as Paride commented before.

Furthermore, as also commented by Paride, this test is high dependant on hardware as a handicap to qualify for an SRU process, but the impact can be measured better starting with the steps of reproduce. Maybe we can hit it in other "certains devices" as you set on the bug's title ... or sadly not.

The bug will remain as "Incomplete" while we don't have that information. When you submit it, please mark the bug as "New" to let us know we can continue with additional actions due to this new info.

Thank you in advance!

[1] https://wiki.ubuntu.com/StableReleaseUpdates

[Dennis Real (x-ubunmuone-z)]

Same problem here for with u-blox 7 receiver and gpsd 3.22-4ubuntu2 on Ubuntu 22.04.3 LTS (jammy).

[Lucas Kanashiro (lucaskanashiro)]

Dennis, did you try the workaround mentioned by Miriam in comment #5? Does that fix your issue?

If not, could you please provide detailed steps (commands) to reproduce this issue?

[Sergio Durigan Junior (sergiodj)]

Hello,

Yesterday I triaged bug #2037904 which is a duplicate of this one.

It would be great if we could have a reproducer or a link to an upstream bug report/commit.

[Dennis Real (x-ubunmuone-z)]

Lucas, the ubxtool -p RESET workaround works. But it has to be done at every startup by hand.

So steps tp reproduce:

- Boot machine
- Plug in GPS receiver
- gpsd will stuck: cgps and python lib stuck, interestingly gpsmon shows some coordinates
- Run "ubxtool -p RESET" and all clients will receive a valid position. It seems that more messages are received from the dongle than before.

[Dennis Real (x-ubunmuone-z)]

I took 2 screenshots of cgps (left) and gpsmon (right).

Before running the workaround only gpsmon shows coordinates; the messages below show some kind of hex data?!?

After running the ubxtool -p RESET workaround both programs show the correct position AND the messages under gpsmon change from hex values to $GPsomething.

If I disable gpsd completely and open the dongle (freshly plugged in) I see $GP.. messages as well.

[Dennis Real (x-ubunmuone-z)]

Screenshot after workaround.

[Dennis Real (x-ubunmuone-z)]

Some more observations:

It seems that the dongle delivers NMEA messages by default. gpsd knows better and tries several drivers and switches over to an u-blox specific protocol. This is understood by gpsmon but other clients like cgps or the python library only get the first coordinate and no updates. This behaviour seems to be fixed in gpsd 3.25.

Another potential workaround: Run gps with option -b (read only mode to prevent the u-blox protocol being used). This could be a promising workaround, at least on the command line it worked. Will test this option with hotplug later.

[Dennis Real (x-ubunmuone-z)]

The -b workaround seems to work. So add

GPSD_OPTIONS="-b"

in /etc/default/gpsd

[Paride Legovini (paride)]

Hello, in order to move forward this in Ubuntu it would be helpful to know if the issue is still happening with gpsd 3.25-2ubuntu2, packaged in Mantic. You should be able to test it booting a live system from a USB stick. Mantic will be released next week, but you can download a daily image from [1] if you don't want to wait for the release.

The upstream changelog [2] has this entry under 3.23.1:

  Fix u-blox M6, M7 initialization issues.

Could that be related to this issue?

[1] https://cdimage.ubuntu.com/ubuntu/daily-live/current/

[Dennis Real (x-ubunmuone-z)]

Did a short test of release 23.10 Ubuntu Mantic Minotaur (development branch) with gpsd Version: 3.25-2ubuntu2 in a virtual machine. Worked without any issues.

[Athos Ribeiro (athos-ribeiro)]

Then, this should be fixed in mantic. The next steps would be to isolate the fix (starting from the changelog entry pointed by Paride) and pushing it to a PPA for users to verify. It would also be nice to check if Lunar is also affected.

[Dennis Real (x-ubunmuone-z)]

Tested

Distributor ID: Ubuntu
Description: Ubuntu 23.04
Release: 23.04
Codename: lunar

gpsd Version: 3.22-4.1

Result:

Does NOT work. Initial coordinates are sent to cgps all the time.

[Mitchell Dzurick (mitchdz)]

Hi, thanks everyone.

There are a ton of commits between 3.22 and 3.25, so it is difficult to pinpoint the exact commit that may or may not fix this issue. I'd like to find the exact version that gpsd starts working, which will greatly narrow down the range of commits.

I tried scraping the commits but there's just a ton of them and I couldn't find anything obvious at first glance.

@Dennis if you're okay with this, would you mind building tag 23.1 and seeing if that works? This reddit thread claims it works - https://www.reddit.com/r/hacking/comments/qg64n2/kali_kismet_and_a_gps_dongle_that_doesnt_want_to/ which would really narrow down the commits we would have to check.

[Dennis Real (x-ubunmuone-z)]

Hope I made no mistakes while building.

$ /usr/local/sbin/gpsd --version
/usr/local/sbin/gpsd: 3.23.1 (revision 3.23.1)

=> OK

$ /usr/local/sbin/gpsd --version
/usr/local/sbin/gpsd: 3.23 (revision 3.23)

=> FAIL

[Bryce Harrington (bryce)]

Looks like 128 commits between those two releases:

https://gitlab.com/gpsd/gpsd/-/compare/release-3.23...release-3.23.1?from_project_id=5693143&straight=false

Skimming through those, many of the commits are cleanup/refactoring/warnings/etc. A bunch of others are against core code serial.c and libgpsd_core.c whereas this issue sounds maybe more like a hardware-specific fix. As Paride mentioned, the NEWS file mentions these changes, which seems the most pertinent:

  Add new u-blox M10 messages.
  Fix u-blox M6, M7 initialization issues.

I don't see any commits matching those exact messages, however it looks like the u-blox support is handled in file gps/ubx.py, for which there were a few changes included between 3.23 and 3.23.1:

  4b451ea5 gps/ubx.py: Add new M10 config items.
  0c30f517 gps/ubx.py: Add UBX-NAV-EELL decode.
  1491110a gps/ubx.py: Add poll for UBX-NAV-EELL Position error ellipse parameters

The last one adds protocol for polling "Position error ellipse". The issue identified in this bug report is that it does not "update the reported position", so I wonder if that might be a match? If so, I suspect both those last two commits would be needed, at least.

[Christian Ehrhardt  (paelzer)]

Sorry to stall this, but I think this comes down to someone with the right hardware to bisect this issue to identify the fix to backport (and also help describing the case and helping to verify the SRU).

Can someone provide that