how should getXXX handle stale/failed data?

[tedder]

ignoring the template because this is philisophical, YOLO.

The m.o. of this library is to try to return fresh data using moduleQueried. That's great, but it doesn't leave much room for failure. In other words, take getLatitude:

//Get the current latitude in degrees
//Returns a long representing the number of degrees *10^-7
int32_t SFE_UBLOX_GPS::getLatitude(uint16_t maxWait)
{
  if (moduleQueried.latitude == false)
    getPVT();
  moduleQueried.latitude = false; //Since we are about to give this to user, mark this data as stale

  return (latitude);
}

Now, what if a call to getPVT fails? moduleQueried.latitude will still be false, but we'll just steam right ahead and return.. something. It might be super-super-stale data or the init data, there's no way to know.

I'm using iTOW as a way to sniff "last updated time", but it's a bit of a hack.

Ideas:

• haveValidData()
• lastValidUpdateTime()
• timeSinceLastSuccessfulUpdate()

[tedder]

An example of how this is problematic is when getPVT fails. Imagine calling getYear/getMonth/getDay/getHour etc with getPVT failing. Each one of those will try the call and wait to time out, so calling all those functions takes a huge amount of time.

[nseidle]

ignoring template = totes ok.

@tedder - Agreed.

@tve - As the original user of PVT, any thoughts?

[tve]

IMHO all the getXXX functions are optimistic and YMMV (designed to make a first encounter of the library easy). If you are concerned about failures why don't you call getPVT explicitly yourself, check the return value, and then proceed to call the appropriate getXXX functions only if the result is OK?

[tedder]

Thanks tve. I can do that, for sure. I didn't know that was the m.o. If I get some time to focus on it I'll update docs and perhaps code to encourage that (like getData()). I'll noodle around it.