Feature: Autodetecting LAST_SENTENCE_IN_INTERVAL #177
Description
I'm using this library to receive GPS info from a GPS module. However, in our project we have a large number of devices and we use two or three different GPS modules (with the same connector and pinout), which have different sentence collections. Initially, we had two types that used the same last sentence (GLL), so we just modified LAST_SENTENCE_IN_INTERVAL, but now we use a new GPS module that does not send GLL at all (and ends with RMC).
In our project, we have novice users uploading the firmware, so we want to prevent them having to check the GPS module and then making changes to a library file (we could try, but in practice they will get it wrong).
So, I wonder: Would it make sense to modify the library to autodetect LAST_SENTENCE_IN_INTERVAL?
I can imagine this could be fairly easy, at least for GPS's that do a burst and then a longer quiet time. The most obvious way would be to just check the intervals between two messages, and whenever you see a larger one than before, update LAST_SENTENCE_IN_INTERVAL to the message seen before the interval, possibly with some extra code to ensure you only let intervalCompleted() return two when LAST_SENTENCE_IN_INTERVAL has been stable for a full cycle (i.e. only when you see it a second time after setting it).
This is likely something to make opt-in/configurable, maybe by having a special AUTODETECT value for LAST_SENTENCE_IN_INTERVAL? This way the configs for specific GPS modules can still set the value as before, and even the default can remain RMC as now (at least initialy).
A related improvement would be to allow setting/changing LAST_SENTENCE_IN_INTERVAL at runtime (which could then also allow setting the AUTODETECT value explicitly for the opt-in).
Does something like this sound feasible/acceptable? If so, I could try to find some time to take a stab at an implementation of this.