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.

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

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.

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.

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

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

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?

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.

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.

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.

Screenshot after workaround.

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.

The -b workaround seems to work. So add

GPSD_OPTIONS="-b"

in /etc/default/gpsd

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/

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.

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.

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.