Display Slows and Slows

[AgileEngineeringLLC]

Hi,
Great tool!! Got a question tho...

I'm running the current version of pygpsclient on a Ubuntu linux laptop with 22 cores, usb ZED-F9P, and streaming Geodnet corrections for RTK. Pygpsclient seems to keep up (1 sec updates) for a while, but then after a 10-20 min it slowly starts bogging down. For example, right now it's been running 30 min or so, and is updating every 4 sec. The System Mon tab seems to show everything as fine.

What might I do (turn off, disable) to allow pygpsclient to keep up?

thanks!
Don

[semuadmin]

Hi Don @AgileEngineeringLLC

Sorry you're having difficulties. This may be related to another current discussion #262, which unfortunately I've not yet had the time to get to the bottom of.

There was a clear memory leak issue in pygpsclient<1.7.1 which has now been resolved, but there appear to be other residual issues which only arise when the UI is left unattended (i.e. no user interaction) for several hours. I'm personally finding that any 'lag' disappears almost immediately upon new user interaction (e.g. resizing the panel or opening a pop up dialog), but I'm not sure if that's the general experience on Ubuntu. This may be to do with idle tkinter events stacking up, but AFAIA the code already includes the usual recommended mitigations against this.

Could I ask you to confirm:

1. That by 'latest version' you mean v1.7.2?
2. Which specific version of Python and tkinter are you using (this will be displayed in the About help dialog), and how were these installed if not part of the standard Ubuntu distro?
3. What navigation/measurement rate do you have the ZED-F9P set to? There was an issue in earlier versions with the console not keeping up with very high transaction rates, but - again - that's been resolved in pygpsclient>=1.7.1 (and, as you mention, you'd see any obvious I/O issues in the System Monitor)
4. What autoscroll line value do you have set in the settings panel? The default is 100 lines - higher values will have a marginal performance impact but this shouldn't be significant in most instances.
5. What do you have the GUI refresh rate (guiupdateinterval_f) set to in your json configuration file? The default is 0.5 seconds. You could try increasing this, but it really shouldn't be necessary on a platform as capable as yours (the parameter was more to accommodate low-end SBC platforms)
6. You could try turning off some or all of the user-selectable widgets to see if this makes any difference, but this really shouldn't be necessary.
7. Does the lag go away for you if you interact with the GUI in any way e.g. resizing the main panel?

[AgileEngineeringLLC]

Please see answers below. Also, I thought the issue might be I was using WiFi originally, but switching to wired ethernet didn’t help. When I look at the Ubuntu Activity Monitor, I don’t see a heavy core burden, memory usage is low (4%), and network flow looks fine up and down. Don On Jul 29, 2026, at 12:51 PM, SEMU Admin ***@***.***> wrote: Hi Don @AgileEngineeringLLC <https://github.com/AgileEngineeringLLC> Sorry you're having difficulties. This may be related to another current discussion #262 <#262>, which unfortunately I've not yet had the time to get to the bottom of. There was a clear memory leak issue in pygpsclient<1.7.1 which has now been resolved, but there appear to be other residual issues which only arise when the UI is left unattended (i.e. no user interaction) for several hours. I'm personally finding that any 'lag' disappears almost immediately upon new user interaction (e.g. resizing the panel or opening a pop up dialog), but I'm not sure if that's the general experience on Ubuntu. This may be to do with idle tkinter events stacking up, but AFAIA the code already includes the usual recommended mitigations against this. Could I ask you to confirm: That by 'latest version' you mean v1.7.2? Version 1.7.0 (I just did the update to 1.7.2, and now will test it) Which specific version of Python and tkinter are you using (this will be displayed in the About help dialog), and how were these installed if not part of the standard Ubuntu distro? 3.12.3, 8.6.14 Standard Ubuntu I believe What navigation/measurement rate do you have the ZED-F9P set to? 1 Hz There was an issue in earlier versions with the console not keeping up with very high transaction rates, but - again - that's been resolved in pygpsclient>=1.7.1 (and, as you mention, you'd see any obvious I/O issues in the System Monitor) What do you have the GUI refresh rate (guiupdateinterval_f) set to in your json configuration file? Default 0.5 The default is 0.5 seconds. You could try increasing this, but it really shouldn't be necessary on a platform as capable as yours (the parameter was more to accommodate low-end SBC platforms) You could try turning off some or all of the user-selectable widgets to see if this makes any difference, but this really shouldn't be necessary. Does the lag go away for you if you interact with the GUI in any way e.g. resizing the main panel? Does not appear to —

[semuadmin]

Thanks - there were quite a few performance updates & bug fixes in v1.7.1 and v1.7.2 so let me know if any issues persist.

I suspect any unattended 'lag' issue is tkinter idle event-related and a trivial fix - I just need to find the time to investigate further.

[AgileEngineeringLLC]

I updated the versions, and am still seeing the display updating slower and slower. I did notice on the Ubuntu Utility Monitor that the demand on the processor cores seems to increase quite a bit over time. Memory and Network load seems to stay the same. Don

[AgileEngineeringLLC]

[semuadmin]

page is going back and forth between 3D and RTK FIXED

This is simply an artefact of the NMEA protocol. Depending on the version of NMEA in use, some NMEA messages (e.g. GLL) do not consistently differentiate between 3D and RTK fix modes, whilst others (e.g. RMC, GSA and GNS) do. If your receiver is outputting both message types, you may see the fix indicator alternating between statuses.

To get a consistent RTK FIXED or RTK FLOAT indication, you can either:

1. Turn off NMEA GLL message types (set CFG_MSGOUT_NMEA_ID_GLL_USB = 0).
2. Disable the NMEA protocol on the given port and enable u-blox's binary UBX protocol instead (NAV-PVT, NAV-SAT, etc.). This will give you a far more concise indication of navigation status (e.g. one NAV-SAT message per measurement rather than 10 or 15 GSV messages).

The PyGPSClient UBX Configuration Preset panel has preset commands you can use for this purpose.

[semuadmin]

For ease of monitoring, could I request that we keep this particular discussion to matters relating to display lag?

By all means raise another discussion topic if you have other observations you wish to share.

Also, be aware that if you respond to these messages by email, rather than via the GitHub web page, your full contact details are being displayed - not sure if that was your intention (I've redacted this information from your earlier posts).

Tx

[AgileEngineeringLLC]

Will do, thx.

[AgileEngineeringLLC]

An Update. I reduced the GNSS constellations down to just GPS, GAL, and SBAS, and I changed the screen update rate to 1.0s. Seems to be keeping up now (after 2 hours).

Thanks for the suggestion to disable GGA NMEA, the Fix: RTK FIXED is showing solid now.

Great tool, very easy to use once you get familiar with it, thanks!

[semuadmin]

An Update. I reduced the GNSS constellations down to just GPS, GAL, and SBAS, and I changed the screen update rate to 1.0s. Seems to be keeping up now (after 2 hours).

Useful to know - thanks. I'm confident it's a fixable (or at least mitigable) issue; just haven't quite got to the bottom of it yet. In the meantime I'll add it to the 'Known Issues' list.

I've run several extended tests on various Linux platforms ranging from high-end Xeon multi-cores with 64GB RAM to low-end SBCs and what I'm finding is that, while the GUI can lag if (and only if) left unattended (i.e. no user interaction) for an extended period of time, the underlying GNSS message processing (e.g. parsing & datalogging, which run in a separate thread) is unaffected and the GUI can, as it were, be 'woken up' via new user interaction, such as resizing the main panel. The key user-configurable parameter appears to be guiupdateinterval_f, as you mention above.

Thanks for the suggestion to disable GGA NMEA, the Fix: RTK FIXED is showing solid now.
Great tool, very easy to use once you get familiar with it, thanks!

👍