I have a Photon and an AdaFruit “Ultimate GPS” and an active GPS antenna with a clear view on the roof.
I’m getting sporadic values for my location when I have a solid 3d fix.
So I added a call to preNMEA() to print the last NMEA sentence.
I collected 60 seconds worth of NMEA messages, @ ~ 10Hz. After “uniq” ing them, I had 78 lines.
Of those 78, only 34 were valid. The rest were either incomplete, or malformed “joins” of 2-3 messages.
That’s less than 50%!
It looks like a flow control problem in the library.
Welcome.
Firstly a little search offers a few threads that look tantalisingly close to describing your very problem. Perhaps continue this search and then if you have no answers then post some code.
2 Likes
I looked through several of the threads you suggested… thanks. Unfortunately, I was not able to find anything that addressed my issue. Many were complaining about not getting a 3d fix.
However, I was able to solve my issue. I think my inability to find good documentation on the library was the major roadblock. Anyway, the key to solving my issue was this:
The call to updateGPS() must be made at a higher rate than messages are sent from the GPS.
Which translates to: you can’t put a delay(1000) in loop(), rather, you need to have a state machine that only executes code when it’s time, and allow loop() to be called as often as possible. I suspect this a general rule for “all things Photon” and not unique to the AssetTracker library. (I love being a noob!)
2 Likes
I am glad you found a solution !! - the above is very true of not only photon but probably "all things". What many don't know is that there are other things that happen outside of the loop to keep things working - Loop is really where you should call lots of things from and try and make sure none of them block for significant periods while "waiting for stuff" - as you so rightly say, a state machine is a great way to do this - or even a few timers that call functions periodically and then return!