Issues connecting to GPS device

[invader-zimm]

Hi,

I'm trying to use PyGPSClient on Artix Linux and I'm encountering some issues. The GPS device I have is this one and I installed PyGPSClient using pip as described in the github readme (python -m pip install --upgrade PyGPSClient).

The first issue is that I can't seem to run the application without root/sudo. The docs say to add my user to the tty group (there is no dialout group on my system), and I did that but PyGPSClient still says it cannot connect to the device:

I also tried changing the permissions for /dev/ttyACM0 using udev rules, like this one
KERNEL=="ttyACM[0-9]*",NAME="tts/ACM%n",SYMLINK+="%k",GROUP="tty",MODE="0666"
but I still couldn't connect to the GPS device. Is something mis-configured on my machine or is there a PyGPSClient issue?

Another problem is that even if I connect as root, the connection to the device seems to drop at random. It takes anywhere between 2-3 seconds to 30 seconds to get a status bar message saying "End of file reached":

Sometimes I see an error saying that the device returned no data:

I also see this error printed out several times in the console where I start PyGPSClient from:

 Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.10/tkinter/__init__.py", line 1921, in __call__
    return self.func(*args)
  File "/usr/lib/python3.10/site-packages/pygpsclient/serial_handler.py", line 324, in on_read
    self._parse_data()
  File "/usr/lib/python3.10/site-packages/pygpsclient/serial_handler.py", line 350, in _parse_data
    (raw_data, parsed_data) = self._reader.read()
  File "/usr/lib/python3.10/site-packages/pyubx2/ubxreader.py", line 130, in read
    raise ube.UBXStreamError(f"Unknown protocol {byte1 + byte2}.")
pyubx2.exceptions.UBXStreamError: Unknown protocol b'$6'.

Other GPS apps work fine, I'm seeing these issues only with PyGPSClient and I'm not sure if these are bugs or problems with my machine/OS. Any help is greatly appreciated.
Thank you.

[semuadmin]

Hi @invader-zimm,

I'm away from the office at the moment so these are just some preliminary observations/queries for now.

1. what hardware platform are you running on?

2. What version of PyGPSClient are you using?

3. is there a typo in your udev rule - should 'tts' be 'tty'?

4. What happens if you try the following command and then run it as a normal user after logging out and in?

sudo chmod 0666 /dev/ttyACM0

5. Have you changed the default serial port timeout setting at all?

6. I'm not familiar with this particular GPS device. I presume it is based in a u-blox chip; probably the NEO-M6 or M7. Can you confirm the u-blox device version and protocol (it's shown on the PyGPSClient UBX configuration panel)?

7. Most budget GPS receivers output NMEA by default. I presume you have configured yours to output UBX instead - did you use PyGPSClient to do this? If not, how?

8. You mention it works with other GPS apps. Which specific GPS apps are you using on the same platform, and are you decoding UBX data via these apps?

9. This may just be an artefact of the screen print copy & paste, but I notice most of the fields in the settings panel do not appear to be populated, which would suggest the installation is corrupted. Are you seeing these fields populated on your screen?

10. Would you be able to provide a raw dump of the serial input data stream via the terminal (e.g. via cat or screen)

Professor Membrane (aka semuadmin)

[invader-zimm]

Hello,

1. I have a Thinkpad T460s laptop with an Intel i5-6300U CPU; The OS is Artix Linux, all packages are up to date
2. When I made the first post I was using v1.1.4. I updated to v1.1.7 but I get the same errors and behaviour
3. I'm not sure if there's a typo, I was following the instructions from this post and the udev rule seems to work as expected; I don't get any errors and the user/group permission are set correctly when I plug in the GPS
4. Manually setting the permission to 0666 doesn't change anything, I still cannot connect except as root
5. I have not changed any of the serial port settings, everything should be at default values
6. According to the U-Center utility from ublox (which I ran on a Windows machine), the device has a ublox M8/8 chip; I haven't found a way to get the firmware version though... The UBX config dialog in PyGPSClient shows this:
   
7. I have not changed the output type, it looks like only PyGPSClient shows UBX messages. For example, I used putty on Windows to connect to the GPS device using the serial connection, and the messages I see are all NMEA:
   
   I noticed that in PyGPSClient, immediately after I click the connect button, the console shows a few NMEA messages but everything after that is UBX. I don't know how/why, I have not specifically configured it that way (at least not intentionally).
8. I was referring to utilities like cgps, gpsmon and xgps which are available from the official repos. I don't know if they use the UBX protocol (probably not). I also use an app called OpenCPN which for sure doesn't know about UBX, I was able to make it connect to the GPS using the gpsd protocol/daemon and the messages received by OpenCPN from the GPS are all NMEA
9. This might be a bug. It looks like the fields are populated, but they only show something if I click them first. I thought it might be an issue with the desktop color theme (I use the MATE Desktop environment) and I switched between dark and light themes a few times but it didn't help, most of the controls (edit fields, checkboxes, int/float fileds etc) do not update their contents properly. You can see that in the UBX config screenshot posted above, all UI controls look empty; The "ESF-ALG" parameter from the "CFG-MSG Message Rate Configuration" list in the bottom left corner of the dialog was invisible until I clicked on it.
10. Sure. Something like in the putty screenshot?

Thanks,
Z.

EDIT: using U-Center, I found the NMEA messages related to the hardware and firmware versions:

01:01:31  $GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
01:01:31  $GNTXT,01,01,02,HW UBX-M8030 00080000*60
01:01:31  $GNTXT,01,01,02,ROM CORE 3.01 (107888)*2B
01:01:31  $GNTXT,01,01,02,FWVER=SPG 3.01*46
01:01:31  $GNTXT,01,01,02,PROTVER=18.00*11
01:01:31  $GNTXT,01,01,02,GPS;GLO;GAL;BDS*77
01:01:31  $GNTXT,01,01,02,SBAS;IMES;QZSS*49
01:01:31  $GNTXT,01,01,02,GNSS OTP=GPS;GLO*37
01:01:31  $GNTXT,01,01,02,LLC=FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFD*2F
01:01:31  $GNTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*3E
01:01:31  $GNTXT,01,01,02,ANTSTATUS=OK*25

[semuadmin]

Ok something really bizarre is going on here which I've never seen before in any mainstream linux dist. It looks like PyGPSClient, Python or tkinter is not properly installed.

I'm not too familiar with Artix linux - is there any particular reason why you chose this over a more mainstream dist like Ubuntu? I'm not suggesting this is the source of the issue necessarily - just wondering if there's something peculiar about the Python and/or tkinter implementation on this distribution. Are you successfully running any other Python/tkinter GUI apps on this platform?

Your GPS device is a NEO-M8 running firmware SPG 3.01, UBX protocol version 18.0, which is perfectly standard. PyGPSClient v1.1.7 can decode NMEA, UBX and RTCM3 GNSS protocols (the other utilities you mention only handle NMEA natively, and may obscure/ignore any underlying ubx protocol issues) but it only shows what the device has been explicitly configured to output. The UBX configuration panel does send a few UBX messages to the device when it's first opened to establish the current state of the device, but it will not leave the device outputting UBX navigation messages unless you explicitly configure it that way.

As I say, the fact that you're not seeing the panel entry fields displayed (until you click on them) suggests there's something seriously wrong with Python and/or tkinter.

When I'm back in the office I'll try to spin up an Artix VM and see if I can recreate the problem, but off the top of my head I'd say it was a Python/tkinter implementation problem.

Out of interest, have you tried installing PyGPSClient on a Windows platform and, if so, does it work OK with this GPS device?

[semuadmin]

PyGPSClient was originally designed as a kind of "u-center Lite" for Linux platforms. It has been rigorously tested on most mainstream Linux dists but not, admittedly, on Artix (that's an omission we'll endeavour to rectify in future releases). It uses the standard and well-proven pySerial library for serial port handling.

In the meantime, I hate to give you a stock "have you tried uninstalling and reinstalling?" reply but in this case it may be worth a try. Uninstall PyGPSClient using pip uninstall, then reinstall ensuring that all the tkinter & python dependencies mentioned in the installation instructions are present.

As an aside, I normally install Python/tkinter from source on Linux platforms to take advantage of various performance optimisations. But PyGPSClient should run fine on the version of Python (>=3.7) supplied in the standard repos, though you do normally have to install all the tkinter dependencies separately.

[invader-zimm]

Sigh... I must bow my head in shame... The suggestion "uninstall, reinstall and try again" was the right call. I had tried that a couple of times, but on a more thorough inspection it turned out i had multiple PyGPSClient versions installed in /usr/lib/python3.X/site-packages and ~/.local/lib/python3.X/site-packages, for python 3.9 and 3.10. I must have run the installation as root or with sudo a few times, then as a regular user and forgot all about it. Cleaning everything up and reinstalling again fixed all of the UI issues, everything looks and behaves as expected now. I don't see any more Tkinter errors in the console either.

For the intermittent disconnects, it turns out that gpsd was the culprit. It was configured to automatically start the daemon when the GPS was connected through USB and I guess it would put some sort of lock on /dev/ttyACM0. Disabling the service or killing the gpsd process after the GPS is connected solves the random disconnects and not being able to connect from PyGPSClient except as root.

The only issue remaining is the UBX messages instead of NMEA, but it doesn't look like that's a real problem since everything else seems to work fine. These are the settings in the main UI and in the config dialog:

As far as I can tell, the device is set to output NMEA as well but the only such messages I see in the PyGPSClient console are immediately after clicking the connect button. The NMEA messages are the ones mentioned at the bottom of my previous post, they're about the hardware/firmware versions, protocol, antenna etc. Everything else after that is UBX.
Do you think that's worth investigating further?

Lastly, Artix is pretty much Arch Linux with various choices for the init system. A lot of the packages I have installed come from the Arch repositories. I landed on it a while back when I was distro hopping and wanted to try new things. I kinda got used to it and never moved on...

[semuadmin]

Hi @invader-zimm OK, glad you got to the bottom of it - at least I know what to suggest if I get a similar issue in the future! No need to bow head in shame - we've all been there ;-)

As to why the device is outputting UBX rather than (or as well as) NMEA data, that's another puzzler. Are you saying that it's ONLY outputting UBX messages, or NMEA AND UBX messages (your previous terminal screen shots seem to indicate that it is outputting NMEA data). Does it still do this even after powering off and on?

I can only imagine that either the device was configured that way out of the box (which seems highly unlikely) or you've inadvertantly sent one or more 'turn on UBX message' commands from the PyGPSClient UBX configuration panel.

Assuming PyGPSClient is connecting and working as expected now, you should be able to open the UBX Configuration panel and select from the various preset NMEA/UBX message options on the lower right. These allow you to quickly turn on or off all the NMEA and/or UBX message types supported by your receiver, or select a 'minimum set' of NMEA or UBX message types (i.e. just NMEA GSA & GSV OR UBX NAV-PVT & NAV-SAT). You should see a series of ACK-ACK or ACK-NAK responses (don't worry if you see some red ACK-NAK responses - this just signifies that your M8 receiver doesn't support all possible NMEA or UBX message types).

I can only suggest that you try this and let me know how you get on.

(PS NOTE that M8 receivers don't support CFG-VALSET, CFG-VALGET or CFG-VALDEL commands - you need a generation 9+ device for this e.g. ZED-F9P or NEO-M9).

[semuadmin]

Hi @invader-zimm Are you happy for this issue to be closed?

[invader-zimm]

Hi, sorry I was afk for a while. Yes the issue can be closed, the NMEA/UBX issue is not really a problem for me and your suggestion of using the presets from the UBX config dialog worked as well.
Thank you for the replies.