Re: Invalid position given by Telit HE910-EUG

[Gary E. Miller]

Yo Titouan!

On Sun, 5 Apr 2020 16:21:22 +0200
Titouan Christophe <address@hidden> wrote:

> Hello Gary and all,
> 
> On 4/04/20 21:14, Gary E. Miller wrote:
> > Yo Titouan!
> > 
> > On Sat, 4 Apr 2020 12:37:12 +0200
> > Titouan Christophe <address@hidden> wrote:
> >   
> >>> Ouch.  And you are sure it is plain NMEA0183?  
> >>
> >> As far as I can tell, yes.  
> > 
> > Not totally convincing.  
> 
> If I open a serial console on the GPS port, all I get is plain
> NMEA0183. I also checked with hexdump that there are no undisplayable
> characters.

GNSS receivers work differently when talking to gpsd.  You can only
open the serial port when gpsd is not running.  So not a test of what I
want to know.

> >> we're remotely operating a fleet of embedded
> >> devices that are installed into rail vehicles.  
> > 
> > Not sure why that matters to this issue.  
> 
> Just wanted to let you know the context, how I obtained the data.

I'm not sure how "rail vehicles" applies to obtaining data?  I thought
they were mostly iron.

> >> gps_stream(&gps_data, WATCH_ENABLE | WATCH_JSON | WATCH_NMEA,
> >> NULL); while (running) {
> >>       if (gps_waiting(&gps_data, 2000000)) {
> >>           r = gps_read(&gps_data, NULL, 0);
> >>           if (r > 0){
> >>               // do something with gps_data
> >>           }
> >>       }
> >> }  
> > 
> > Of course the issue you report is in the "do something" part.  So
> > that snippet not useful.
> 
> Maybe the flags passed to gps_stream could have been wrong ?

Nope.

> As I stated in my original email, we use the content of 
> gps_data->fix.latitude/.longitude/.speed/...

And yet, you have never, ever provided evidence of that.

> We then pack them into JSON format (with libjansson),

Uh, wait a minute??  gpsd sends in JSON, why are you repacking?

> and send them
> via MQTT. Here is an extract of our program:
> http://paste.awesom.eu/fHqV

Useless.  Not sufficient to build and test, and missing the parts where
users commonly make errors.

Also, lat/lon w/o a time is useless...

> >> We invoke gpspipe like this:
> >> gpspipe -r -T %s -n $LINES -o $FILENAME  
> > 
> > So dumping the raw NMEA.  Why not -R?  There may be stuff other than
> > NMEA in there.  
> 
> Well, the manpage is not very explicit about that. What's the
> difference between "raw" and "super raw" ?

"super raw" is EXACTLY what the receiver sent.  "raw" is just NMEA and
may be the NMEA the receiver sent, or may be psuedo NMEA built from the
binary data, or some combination of both.

So -R (super raw) is the only option that tells you exactly what gpsd
saw.  And -w, (native JSON) is the only things that tells you what
gpsd thinks is valid.

If you have a suggestion on how to make the doc clearly, send a patch.

> > So, back to your original issue.  The current gpsd code works for
> > me. We agree the NMEA 0183 in is bad.  I showed you that current
> > gpsd does the right thing with your data.  You have not shown that
> > the gpsd 3.18 is sending bad data.  
> 
> Sorry for losing your time then. There is no mention of such
> filtering in the release notes 

The release notes are for major stuff that most people will see, and
is long enough.  If you want to see everything, then read git log.

> My mail was intended to know if gpsd was
> supposed to handle that case or not.

And that is now answered?  Right?

> and the rollover is correctly handled.

Which was in the releae notes for 3.20.  Thanks for confirming.  Much
of this would have been not needed if you used current code.

> For the record, when using gpsdecode from release-3.19 on the same
> dump file, I also obtain a wrong latitude:

Don't care.  You should be using 3.20 or git head.  gpsd does not do
patches for 

> I will give a try to update gpsd to 3.20 in Buildroot 
> (https://git.buildroot.org/buildroot/tree/package/gpsd) so we can
> update our fleet soon. However, it does not seem easy, because gpsd
> 3.20 does not cross-compile anymore as is.

3.20 had over a month of testing before release.  No cross-compiling
people decided to use that window.  If you care about this code in
a cross-compiling environment, then please test git head so these things
do not end up in releases.

> The problem is in the SContruct file, in the function CheckSizeOf(), 

We can't fix 3.20.  It is what it is.  Please try 3.20 and we can
explore solutions.

> In the meantime I updated the is_valid() function in the snippet I 
> linked earlier in this message, to only accept [-90,
> data->fix.latitude, 90] and [-180, data->fix.longitude, 180] like
> this:

DO NOT USE isnan()!!!!!!!!

let me repeat that:

DO NOT USE isnan()!!!!!!!!

isnan() is broken in all libc I've tested.

Use isfinite()

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpetRm4DKrTU.pgp
Description: OpenPGP digital signature