hdop value exposed as integer (194) instead of float (1.94) about tinygpsplus

[mikalhart]

Hi Mario—

It was a design decision—possibly flawed—to deliver the HDOP exactly as reported by the NMEA string. NMEA reports HDOP in hundredths. We could have made this return a floating-point with the correct value, but at the time it seemed better to not introduce floating-point values. Just convert to float and divide by 100 and you should be good. Thanks for the feedback.

Mikal

From: Mario Cannistrà [mailto:[email protected]]
Sent: Monday, December 08, 2014 4:52 AM
To: mikalhart/TinyGPSPlus
Subject: [TinyGPSPlus] hdop value exposed as integer (194) instead of float (1.94) (#8)

Hi Mikal.
I'm using your wonderful library since September and worked fine. Thank you!

Today I've found a small issue with "hdop". I need to log all error info about my GPS (Locosys LS20031) to calculate statistics and then work on sensor fusion with an IMU.
I configured the following custom fields and I'm getting their values without issues:

TinyGPSCustom pdop(gps, "GPGSA", 15); // $GPGSA sentence, 15th element
TinyGPSCustom vdop(gps, "GPGSA", 17); // $GPGSA sentence, 17th element

Instead, when I try to display hdop (already directly managed in your library) i get an integer value.
For example, when a message like this is received:

$GPGSA,A,3,04,19,14,22,27,,,,,,,,2.17,1.94,0.98*07

I get 2.17 and 0.98 in the custom elements values.
But I get 194 in gps.hdop.value() . You can see this behavior using the KitchenSink.ino example.

I also tried adding hdop as a custom element:

TinyGPSCustom hdop(gps, "GPGSA", 16); // $GPGSA sentence, 16th element

but that change breaks the normal processing and i can't get any value updated by the library.

Could you please have a look at the hdop processing ? If it is not a bug and I'm doing something wrong please let me know.

PS: I know I could divide that by 100 but it could also be one of those subtle bugs hiding possible other issues with specific devices or new messages... just in case.

Thank you,
Mario

—
Reply to this email directly or view it on GitHub #8 .Image removed by sender.

[mariocannistra]

Hi Mikal.
Thank you for your kind answer.
I did that change (convert to float and /100) and my app is working fine but the point is exactly about the format of the PDOP, HDOP, VDOP values: the messages I'm getting from the Locosys are not in hundredths but in float with decimals:

$GPGSA,A,3,04,19,14,22,27,,,,,,,,2.17,1.94,0.98*07

Not a major issue for me, just slightly worried about my sw that could work or not depending on which gps i will attach or change in the future...
Googling around i just saw at least 5 other example $GPGSA messages with floats and no one with hundredths . Did this change during the years? Just seen also in this SiRF pdf : https://www.sparkfun.com/datasheets/GPS/NMEA%20Reference%20Manual1.pdf

I'm now just wondering if Locosys (and possibly other manufacturers) is not respecting the standard. But...is there a published standard for NMEA ?

Just for the sake of curiosity... :-)

[mikalhart]

Mario, I think the values reported in GPGGA are integral hundredths, while those in GPGSA are floating. So I think the same values are being reported--just in different formats. TinyGPS doesn't normally look at GPGSA.

[mikalhart]

Hmm... although the example in the SIRF reference manual you linked would suggest otherwise. I know that in my SIRF-3 EM-406A, the GPGGA HDOP values are integral. I never see values like "1.09" as the example suggests.

[Eheran1]

This is from a MTK3339:
$GPGSA,A,3,10,24,15,18,17,12,,,,,,,1.56,1.28,0.89*05

This is a MT3329:
$GPGSA,A,3,05,12,14,31,29,02,21,26,25,,,,1.48,0.99,1.10*07

In specsheets its always displayed as a decimal number. I have not seen DOP values without the decimal point so far.

[Eheran1]

Here is a MT3333 chipset:
$GPGSA,A,3,25,31,20,05,29,26,21,16,,,,,1.14,0.79,0.83*0A

(does anyone know how to use Galileo with the MT3333? Its really weird...

[mikalhart]

Fixed! :) See version 1.0.2.

For backwards compatibility gps.hdop.value() still returns an integer, but the new gps.hdop.hdop() returns the 2-digit decimal value as a float.