Port Lockup - PyGPSClient + ArduSimple Calibrated Survey GNSS Tripleband + L-band antenna

[wittend]

I am so grateful for PyGPSClient and the related GNSS tools!
They have been working well for me for some time.

I'm not sure if this is the place to ask this, but I would appreciate any assistance

I am interested in measuring VTEC (Vertical Total Electron Content) among other things.
But for now I am running with default parameters just to get my feet wet.

I recently acquired an Ardusimple Calibrated Survey GNSS Tripleband + L-band antenna and placed it with a good but not ideal view of the sky.

Since I switched to the multi-band antenna, I am experiencing lockups in PyGPSClient (usually after 1-4 minutes of operation).

I am operating in a Python3 virtualenv.
I upgraded all of the components (Python: 3.10.6, PyGPSClient: 1.3.25, pygnssutils: 1.08, pyubx2 1.2.25, etc.)

I have been testing using the SparkFun ZED-F9P and ZED-F9T boards without any Ublox firmware upgrades.
I am running these tests from Mint 21 Linux on a 6 core AMD processor that is not otherwise under much load.

The error message in the status bar reads:
"/dev/ttyACM0: u-blox GNSS receiver @ 9600 | ...ice reports readiness to read but returned no data (device or multiple access on port?)"

Sometimes the port stays locked for a while.
Using different Port bps rates does not seem to make a noticeable difference.
Restricting the messages parsed and satellites displayed does not seem to help either.

I do not seem to experience this using the GPSd utility cgps (run > 12 hours):

dave

[semuadmin]

Hi @wittend

So you're absolutely in the right place to ask :-)

"/dev/ttyACM0: u-blox GNSS receiver @ 9600 | ...ice reports readiness to read but returned no data (device or multiple access on port?)"

So the error message says it all really. There is another process running on your (presumably Linux?) machine which is attempting to access the same device (serial port). The usual culprit is gpsd in one form or another. Remember, once installed as a daemon, gpsd will run continously in the background until explicitly stopped.

[wittend]

Thanks! I have tried stopping gpsd using `sudo systemctl stop gpsd.service` but I may have gotten confused. There seem to be three service modules connected to gpsd and some of them may have the ability to start the others even though I have stopped them. I need to investigate that further. There is so much that I don't know. Running at 57.6 K seems to help a bit. Mostly the new antenna seems to provide a lot more data. Dave

…

On Mon, 15 May 2023 at 14:05, SEMU Admin ***@***.***> wrote: Hi @wittend <https://github.com/wittend> So you're absolutely in the right place to ask :-) "/dev/ttyACM0: u-blox GNSS receiver @ 9600 | ...ice reports readiness to read but returned no data (*device or multiple access on port?*)" So the error message says it all really. There is another process running on your (presumably Linux?) machine which is attempting to access the same device (serial port). The usual culprit is gpsd in one form or another. Remember, once installed as a daemon, gpsd will run continously in the background until explicitly stopped. — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACSMIRRC5LIM4J3WP3LKWTXGJ5AHANCNFSM6AAAAAAYCPTPYU> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[wittend]

To close this topic, I am posting the instructions for disabling gpsd that fixed this problem for me. These steps may be useful for users who have similar systems (debian, Ubuntu, Linux Mint) where gpsd has been installed and the OS uses systemd to manage services.

First, see what is going on out there:

$ systemctl list-units | grep gpsd
gpsd.service loaded active running GPS (Global Positioning System) Daemon
gpsdctl@ttyACM0.service loaded active exited Manage ttyACM0 for GPS daemon
system-gpsdctl.slice loaded active active Slice /system/gpsdctl
gpsd.socket loaded active running GPS (Global Positioning System) Daemon Sockets

Then stop and disable the offending service components:

$ sudo systemctl stop gpsd.socket
$ sudo systemctl disable gpsd.service
$ sudo systemctl stop system-gpsdctl.slice
$ sudo systemctl disable system-gpsdctl.slice

Then check again:
$ systemctl list-units | grep gpsd

This should show no services running

Now I am running without errors at 57.6 k

Dave

[semuadmin]

Hi @wittend Thanks for this useful update. Glad the problem is sorted. Are you happy to close this one now?

[wittend]

Sure!

…

On Tue, 16 May 2023 at 03:36, SEMU Admin ***@***.***> wrote: Hi @wittend <https://github.com/wittend> Thanks for this useful update. Glad the problem is sorted. Are you happy to close this one now? — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACSMIWHEHNTTZEX3KKNGBLXGM4AXANCNFSM6AAAAAAYCPTPYU> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>