Mon 20 May 2013 08:54:18 PM UTC, comment #1:
I don't think there's a bug here; I think you misunderstand what the code is supposed to be doing. But this is not unreasonable, as it's a rather dusty and poorly-documented corner of the codebase.
PGRME gives a horizontal circular error probability, not separate x and y error components; the PGRME handler computes those, adjusting for a 95% confidence interval rather than the 50% interval that Garmin is thought to use (see the comment nesr line 640 in driver_nmea0183.c).
Thus, when cheapflats=yes, you shouldn't expect the relationship between the PGRME data and what GPSD reports in JSON to be numerically obvious.
The behavior with cheapfloats off is not a bug either, as the cheapfloats switch's documentation warns that you won't get error modelling in that case. Setting cheapfloats off disables computation from DOPs; it just happens that the circular error probability from PGRME gets passed through to epe.
The real message I'm getting from this bug report is that (a) the option to set cheapfloats off was probably a bad idea and should be removed, and (b) if I keep it, PGRME interpretation should be explicitly disabled in the NMEA driver because it involves float operations and is only feeding the disabled error modeller.
|
Thu 16 May 2013 09:08:10 PM UTC, original submission:
Host system: Intel D525MW (Atom-based)
OS: Custom Linux based on LinuxFromScratch, Kernel 3.8.13, GCC 4.7.2
GPSD version: 3.8, 3.9, 3.10~dev
GPSD compile-time options: aivdm=no ashtech=no bluez=no cheapfloats=no chrpath=no clientdebug=no control_socket=yes controlsend=yes coveraging=no dbus_export=no debug=no earthmate=no evermore=no force_global=yes fury=no fv18=no garmin=yes garmintxt=no geostar=no gpsclock=no ipv6=no itrax=no libQgpsmm=no libgpsmm=yes limited_max_clients=4 limited_max_devices=2 mtk3301=no navcom=no ncurses=yes netfeed=no nmea=yes nmea2000=no ntpshm=yes ntrip=no oceanserver=no oldstyle=no oncore=no passthrough=yes pps=yes profiling=no python=no reconfigure=yes rtcm104v2=no rtcm104v3=no shared=yes shm_export=yes sirf=no socket_export=yes squelch=no strip=yes superstar2=no sysconfdir=/etc systemd=yes timing=no tnt=no tripmate=no tsip=no ubx=no usb=no
GPS device: Garmin 17x HVS in serial NMEA mode
Serial configuration: 4800 8N1
Other configuration: PGRMC,A,,,,,,,,A,3,1,,,
Other configuration: PGRMC1,1,1,2,,,,2,W,N,1,1,1
Firmware: 2.90
My Garmin 17x HVS GPS is configured to send $PGRME sentences, which GPSD picks up and reports on, as follows:
gpsd:DATA: PGRME: epx=4.70 epy=4.70 epv=13.29
gpsd:DATA: packet type 1 from /dev/ttyS0 with {ONLINE|HERR|VERR|PACKET|PERR}
These EP values, however, are not passed on to any clients. My code which interfaces with GPSD via sockets (or shm) does not see these values (nan) and neither does cgps (they remain n/a). HERR and VERR are not set. To be more specific, gps_data.fix.epx/epy/epv remain NaN. On the other hand, there is a value for gps_data.epe (which I'm assuming is derived from DOP data). GPSD in this case has been compiled with cheapfloats=no.
If I recompile GPSD with cheapfloats=yes, then gps_data.epe becomes NaN, while epx/epy/epv are filled in with derived values. These derived values ARE NOT equivalent to what PGRME keeps reporting, though.
Unless my understanding of PGRME is flawed, GPSD should be listening to this information if it's available rather than trying to derive it.
|