Custom objects: more convenient parsing of sentence name (was: Update TinyGPS++.cpp)

[88markus88]

Hi Mikal,

I am using your "TinyGPS++" library to create a generic NMEA info display for use on a boat. Thank you for your great work, the library works very well!

Nevertheless I 'd ask you for a modification in the handling of custom NMEA sentences. :-)

Background:
In the present version V1.0.2 the parser looks at the complete first term in a NMEA sentence - even though the actual identification of the NMEA sentence is only done in the last three characters of the first term, the first two characters are a manufacturer code.

Example: These two NMEA sentences "VHW" contain the same information, but differ in the first two characters ("II" vs. "VW"), (and the checksum):

$IIVHW,,,307.,M,08.08,N,14.97,K10
$VWVHW,,,307.,M,08.08,N,14.97,K11

To parse the data using TinyGPS++ two separate definitions are needed:

TinyGPSCustom nmeaLogSpeedKmh(gps, "GPVHW", 7); // Log Speed in km/h
TinyGPSCustom nmeaLogSpeedKmh(gps, "IIVHW", 7); // Log Speed in km/h

This makes it almost impossible to write a generic code, that works regardless of the manufacturer ID in the first two characters.

My request: The parser in TinyGPS++ can easily be modified to look only at the relevant sentence identifiers (VHW in the example above) and use this definition:
TinyGPSCustom nmeaLogSpeedKmh(gps, "VHW", 7); // Log Speed in km/h

With that change, the "VHV" data set can be extracted from NMEA sentences by any manufacturer without changing the software.

The only modification required is in line 223 of "tinygps.cpp", replacing "!strstr" for "strcmp", see - code change

[robertlipe]

I'd suggest backing that with strong test cases, but I agree that a fix like this is probably needed in (some subset of) the real world to support non-trivial NMEA-like chatter from appropriate devices. Simple point-to-point GPS usually starts with "$GP". If you're sitting on a real NMEA bus (it's multi-drop EIA422/3, not point-to-point EIA232) and those first two characters are the talker. Those sentences might be from components in the Integrated Navigation (the big one), HVAC, Engine, Cargo, and multiuple SV receivers listening to multiple constellations (e.g. GN for Glonass) The spec actually calls out the sentences as "GGA", "WPL" and so on exactly toi allow this diversity in talker codes.

$P is reserved for $Proprietary.

The code handling this in GPSBabel dates back to our C (we're C++ now) days and is rather unpleasant to read and recognize, but it's
https://github.com/GPSBabel/gpsbabel/blob/cfd661ded29e4ff264da5a7e0813c65faa402c35/nmea.cc#L875

The s1.mid(3,3) == sentenceFormatterMnemonicCode starts at offset 3 (grabbing the three characters at offset3, so the "GGA" in "$GPGGA".

So I won't comment on the implementation, but the problem that 88markus88 is trying to solve is a real one that DOES affect hardware in the real world. If you're just reading a handheld receiver ro logger, you'll admittedly probably never see this, but it's very common in marine applications.