system_thread, modes, gps

Hi @Galluta - most welcome.

Re TinyGPS++ age vs AssetTracker:
It’s not so much the age of the libraries as it is the stability of them. @jmccorm looks to have demonstrated that there are significant errors in the Assetracker library. It’s a long thread that’s referenced above but has good info. AFAIK the TinyGPS++ library has no such history of errors. For me, it’s been rock solid. I’ve run a Photon monitoring a GPS for weeks at a time and correctly processed millions of GPS sentences with that library.

Re TinyGPS++ and UltimateGPS:
They definitely will work together. I’ve go an UltimateGPS here somewhere and am using a GTOP chipset (same brand as Ultimate GPS) in my current solution.

Re how often I poll:
At the moment the loop checks the serial port connected to the GPS about every 50 milliseconds and will run a tight loop parsing any characters in the buffer each time. Since all I’m interested in from the GPS is the position fix, I’ve commanded the GPS to only issue the RMC sentence. Therefore I know the buffer will only have GPS sentences in it that contain data I want.
Now, every ten seconds or so I take a temperature reading which could result in the code not getting back to the GPS for 750 - 1000 ms. It seems to handle that just fine.

Re SYSTEM_THREAD:
I have the code running on an Electron with only SYSTEM_THREAD enabled and auto for the cloud. As long as I wrap any call that might talk to the cloud inside a test for Particle.connected() the code doesn’t hang. I’ve run it more on the Photon, true. But the Electron seem to be fine with 24-48 hour test runs.

Finally, re example code:
Sadly, the GPS code is all enmeshed with the rest of the application code. I can’t readily extract it. However, there’s a simple looking example here: Example TinyGPS. TinyGPS++ is a newer version of TinyGPS but this should let you see some working code.
It occurs to me that all I really use in TinyGPS++ is the position parsing. There may be bugs lurking elsewhere; can’t say.

Mike