Good thing you're no longer using it -- the form is really buggy (clicking "Review" clears half the values on Chrome at least).
Based on the FAQ I found, and the buggy form, to be honest I wasn't even sure if gpsd was actively supported or not based on that site, despite a few recent updates. I'm glad you are using a real bug tracker now.
> Anyone have any ideas about this?
Many, but you did not send the data we need:
The full info was sent via the form, as requested in the FAQ :-)
> The u-blox M8 device delivers location updates to gpsd clients roughly
> twice per second,
Which M8 device? There are many, they perform differently. 2Hz by
default would be odd.
I'm using the Here2 GNSS GPS module with a Silicon Labs CP210x UART Bridge:
I have updated the receiver to the latest u-blox firmware (3.01).
You're right, the actual location update frequency seems to be 1Hz, I was mis-estimating the frequency as I was trying to figure out how many updates were coming up in clusters of 2 or 3 at a time.
Do not mistake what cgps shows for what the M8 is sending. gpsd listens
to the receiver, and sends updates when it can. Note the dynamic
tension between reporting each incoming TPV tidbit ASAP, and waiting
until all TPV data for a cycle is in and only reporting once.
Some of the updates seem to be issued when no additional location information is received (e.g. for a message only enumerating satellite locations -- SKY?). The slight drift in location during these non-location updates is probably due to Kalman filtering or something.
> These messages are near-duplicates, except that the altitude seems to
> swing up and down.
What version gpsd? Altitude handling was funcky until very recently.
Be sure you are using at least 3.19.
[...]
Which might be the bug fixed in 3.19. Is the delta equal to your geoid
separation?
What is your version of gpsd? How did you install it? From package,
from source? What exact model of receiver? How did you configure the
receiver?
I'm using 3.19 (specifically Fedora's binary gpsd-3.19-2.fc31.x86_64 package).
I didn't configure the receiver, I just plug it in and gpsd detects it and starts. (Or maybe gpsd starts when a client tries to connect to it, I'm unsure of the mechanism.) I am using only defaults.
I don't know how to check delta or geoid separation, please advise.
Yeah, it can happen. Without your raw data, no way to know what is
happening.
[...]
How did you capture those two logs? The prefered method is:
gpspipe -R -n 100 > raw.log
I captured the previous logs with `gpscat`. But I am attaching logs captured with: gpspipe -R -n 100 > raw.log
(hopefully the list can handle attachments)
> I'm not the only one who ran into this sort of issue on the u-blox M8,
> although the proposed client patch does not address the underlying
> issue in gpsd:
>
> https://github.com/swri-robotics/gps_umd/issues/14
> https://github.com/ros-drivers/gps_umd/issues/3
Uh, this is gpsd. What is gps_umd? Why do we care about gps_umd here
at gpsd?
I know the gpsd team is not concerned with specific clients such as gps_umd -- I was only pointing out that downstream consumers of gpsd messages are running into the same issue with the same receiver device. And one of the suggestions was to not update position on GSV, but rather GLL message. I didn't know if that was relevant. But the issue is upstream, because I see the clusters of 2 or 3 nearly-identical updates (with oscillating altitude) happening even with the xgps client.
You are getting doubles because you are using NMEA (discouraged)
Here are the first few messages displayed by cgps, which seem to indicate that gpsd has automatically switched the receiver to binary mode ("nmea":false)
{"class":"VERSION","release":"3.19","rev":"3.19","proto_major":3,"proto_minor":14}
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyUSB0","activated":"2020-02-26T20:39:55.189Z","native":0,"bps":4800,"
parity":"N","stopbits":1,"cycle":1.00}]}
{"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
You are getting doubles because you are using NMEA (discouraged) and the
NMEA trickles in the TPV data. So gpsd reports ASAP when it gets sufficient
data for a TPV, then again after it has an entire cycle of data. That
cuts the baby in half for those that want TPV ASAP, and for those that want
the TPV data in one place.
Please let me know if this is still your conclusion after looking at the attached raw log. Thanks.
Thanks for looking into this!
Luke
raw.log.gz