|
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*60How 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
[Prev in Thread] | Current Thread | [Next in Thread] |