Initialize all members + sanity check on received data

[TD-er]

Perform a sanity check on the received data for time/date and position.

Also added a separate commit of parsing the fix quality and fix mode flags, which I had implemented a while ago.

[TD-er]

Just a small status update from tests running here with this code.
There used to be some fluke measurements which had a position offset of several km upto 100 km, every now and then.
Now the max. offset I see from the stationary position the node is at is +/- 250 m.
That's to be expected, especially considering the receiver is indoors on my desk.
Those extremes are only a handful of updates, from a run of 2 weeks.

[cyberman54]

@mikalhart ping - can we merge this?

[mikalhart]

There is some thoughtful and arguably helpful content here, but I think I am going to decline to merge, because I want TinyGPS++ to focus on parsing rather than interpreting. I don't want TinyGPS to conceal the fact, e.g, that the Quectel L80 misreports the date as 1/1/80 for a few seconds at cold start. That's something that should not be hidden from a system designer, I think.

[TD-er]

Would you perhaps consider having a boolean flag (or #ifdef compiler flags) to allow for some sanity checks?
This way the user may decide whether or not processing invalid data is desired.

[robertlipe]

In GPSBabel, we've concluded by observing tons of GPS dumps that if the receiver marks 'V' (not for "Valid" - quite the opposite; it's "Void") tags for the fix type in $GPGGA, $GPRMC, and friends, the units will basically make up nonsense. Some will spit up their last powered-up data, some will report dead-recok data, some will report coordinate fields that are total garbage like latitudes over 100 and other crazy stuff. We simply toss them.

If we don't do this, the consumers of the output have to deal with "zingers" where their track zipped over to Null Island and then back two seconds later, giving an average speed of 1,000 mp/h, but only for two seconds - with no acceleration - and other crazy stuff.

Life reading GPS is hard enough but any time the GPS knows enough to KNOW that it reserves the right to fib (and the NMEA spec leaves this wiggle room) you should, IMO, take that opportunity to simply toss the lie and not try to figure out if any part of that sentence might be true or useful. Wait a few hundred milliseconds - there'll be more.

I think we do issue a warning if we drop ALL the input records because the GPS knew enough to tell us that everything was a lie. It's a better UX to know WHY your input data is empty (you're inside a parking garage, a basement, a metal garage, ...) than to either hand them an empty record OR data with those zingers because you passed under a bridge briefly.

The decision on whether you squash those lies or pass them on is, of course, up to you, but I certainly understand why TD-er wants that fork. I'd do the same. (Oh, wait, I did. :-)