gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Invalid position given by Telit HE910-EUG


From: Titouan Christophe
Subject: Re: Invalid position given by Telit HE910-EUG
Date: Sat, 4 Apr 2020 12:37:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

Hello Gary and all,

On 4/04/20 04:45, Gary E. Miller wrote:
Yo Titouan!

On Fri, 3 Apr 2020 18:02:16 +0200
Titouan Christophe <address@hidden> wrote:

Today I observed that one of my Telit HE910-EUG GPS module (NMEA0183
over USB serial) emitted an invalid position in a $GPRMC message. The
reported latitude is 153__N, which is clearly invalid.

Ouch.  And you are sure it is plain NMEA0183?

As far as I can tell, yes.


See 2 sentences obtained from gpspipe below:

# Normal position (51__26.953'N)
$GPRMC,120212.953,A,5126.1926,N,00758.5483,E,0.01,0.0,180800,,,A*5F
# 1s after: invalid position (153__35.322'N)
$GPRMC,120213.953,A,15335.322,N,00758.5483,E,0.01,269.58,180800,,,A*60

How did you ruin gpspipe?  With "-R", "-r", or "-w"?

Some more context: we're remotely operating a fleet of embedded devices that are installed into rail vehicles. The device on which the error happened is running gpsd 3.18. Our end user applications use the gpsd C client, and makes use of gpsdata->fix.latitude/longitude (amongst others). This is how we connect to gpsd and read TPV data:

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
        }
    }
}


Because we have had a lot of trouble with these Telit HE910-EUG chips, we also run a daemon that continuously dump the NMEA stream into a weekly rotated log, as to make post-mortem analysis of GPS failures.

We invoke gpspipe like this:
gpspipe -r -T %s -n $LINES -o $FILENAME


As you can see, this GPS has also rolled over in year 2000, but this
is a different subject.

gpsd in git head can often handle GPS week roll over (WKRO) problems
now.

This Telit chip has a pretty bad behaviour (see https://rutronik-tec.com/wp-content/uploads/2019/02/Telit_Cellular_WeekRollover_Application_Note_r0.pdf), and there was no WKRO patch available for 3.18 at that time (it was maybe even 3.17 back then), so we maintain a patch out of the gpsd tree for that matter; see http://paste.awesom.eu/QGyb


However, we have applications that use gpsd to get the geolocation
information, and these applications received this wrong latitude.

Not good.

Hence my question: shouldn't gpsd filter out these invalid
coordinates ?

You might think so, but initially gpsd was designed to pass unfiltered.
Otherwise hard to debug receiver firmware.  And some people think the
out of band (OOB) values are signaling values.  Just last year someone
complained about gpsd filtering OOB values.

I tend to agree with you that gpsd needs to handle these odd values
because the average person writing gpsd clients does not understand
all the ways receivers send corrupted data.

Get back to us about your gpspipe settings then I can find the best
place to add checks for your problems.

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


Kind regards,

Titouan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]