You stated:
>> And we are receiving over 100 identical records which are not in the
>> gpsd message debug log.
>And yet you complain about a bug in gpsd...
Certainly: since the same client code works with gpsd 3.17 but fails with all versions of the library on 3.23.2~dev, it seems that it is the change in gpsd which is triggering the problem. If it were the gpsd client library I would expect different results with different versions of the library, but the results are constant across versions.
The MT3333 unit is an externality, but it also works smoothly with gpsd 3.17.
Like wise Direwolf 1.7 works with gpsd 3.17 but not 322-400 onward.
So the only piece which when changed causes a failure is gpsd.
Now there are multiple possible scenarios:
- gpsd 3.23.2~dev is generating a message format which can't be handled by the gps_read code: both come from the gpsd team
- there is a bug in the gps_read code (but across all versions?)
- there is a bug in the Dire Wolf implementations of the gps_read code (but it works with gpsd 3.17)
The variable which triggers the problem appears to be the gpsd code.
One can look at the entire routine:
but I don't see anywhere in the code where spurious messages can be generated except in the gps_read routine provided by the gpsd team as part of the client library.
Again, I am not a c expert, so I might be confused.
But I did, as requested, demonstrate the failure with gpsd 3.23.2~rev with a client using the lib.so.29 library from the gpsd 3.23.2~r distribution. The results were consistent with previous testing./
Again, thanks for everyone's help and support!