Traceback from gpscsv

[Hans Mayer]

Dear All,

my environment:

Debian GNU/Linux 11 (bullseye)

# python
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux

ggpd: 3.25.1~dev (revision 3.25.1~dev-2023-06-14T22:10:56.286651)

gpsd: commit 18106fdacda9a6287bc56c96ef5296f05ec21422 dated Mon Jun 5 21:05:57 2023

this server has no gpsd running

on another box I am running U-blox ZED-F9P with version 27.12 ( same gpsd version )

the issue:

in the past gpscsv was running successfully but now it stops with a backtrace

mayer# gpscsv -n 1 -c SAT --header 0 pi4.home.yer.at:gpsd:/dev/serial0
Traceback (most recent call last):
  File "/usr/local/bin/gpscsv", line 345, in <module>
    subreport = {'time': session.data['time']}
  File "/usr/local/lib/python3/dist-packages/gps/client.py", line 351, in __getitem__
    return self.__dict__[key]
KeyError: 'time'

But other programs like xgps or cgps are working fine.

I thought maybe some updates did break this program. Therefore i started from scratch downloading gpsd, compiling it and installing it. But this didn't help. (but I am on the latest version now)  Randomly I fixed this issue.

The fix was I send a "RESET" to the ZED-F9P as described in https://gpsd.io/ubxtool-examples.html

In the meantime I can also reproduce the issue. After sending a "WARMBOOT" to the u-blox the problem exists.  After waiting this WARMBOOT has finished gpscsv generated this nasty traceback.

So what does WARMBOOT do ? As far as I understand "RESET" will set all values to default values from layer 7 to lower layers. But a WARMBOOT after a RESET should change anything in my opinion. Or does the RESET only write from default layer 7 to RAM but not to BBR and flash ?

Then the question is: what changed ?

The interfacedescription PDF in 3.10.19.1 describes hot start, warm start and cold start and different reset types. How does this reflect to RESET, COLDBOOT and WARMBOOT in https://gpsd.io/ubxtool-examples.html  ?

Kind regards

Hans

--