I have been working with the library and a demo and it seems that hub.set messes with the GPS lock and perhaps other things. I don’t see this mentioned in the documentation though perhaps I missed it.
For example
{“req”:“card.location”}
{“status”:“GPS updated (622 sec, 0/33 dB SNR, 10/13 sats) {gps-active} {gps-sats} {gps}”,“mode”:“continuous”,“lat”:xx.097697333333328,“lon”:-xx.422966999999993,“time”:1620314964}
{“req”:“hub.set”,“product”:“com.documenteddesigns.brian:test_project_1”}
{}
{“req”:“card.location”}
{“status”:“GPS inactive {gps-inactive}”,“mode”:“continuous”}
{“req”:“card.location”}
{“status”:“GPS search (96 sec, 0/33 dB SNR, 10/13 sats) {gps-active} {gps-sats}”,“mode”:“continuous”}
{“req”:“card.location”}
{“status”:“GPS updated (190 sec, 0/34 dB SNR, 10/13 sats) {gps-active} {gps-sats} {gps}”,“mode”:“continuous”,“lat”:xx.0677275,“lon”:-xx.357390666666664,“time”:1620315178}
Note that I have a lock but immediately after hub.set GPS goes inactive, the ticker seems reset, and it takes 3 minutes to re-establish a lock. I don’t see why this should be the case.
Edit: I subsequently noticed the GPS coordinates were off. Way off. Many, many km away. I reissued a {“req”:“card.location.mode”,“mode”:“continuous”} and when it locked it locked correctly.
This brings up the question of when do I know I’ve got valid GPS coordinate and how accurate they are.
Hey @BrianP,
Totally valid question and I understand the confusion here. We are working towards putting together a GPS guide that will help explain this, but in the meantime:
When you perform a hub.set request, it’s telling the Notecard to update its configuration. This disables the modem to apply the change (regardless of the cellular or GPS mode you are in). Then, the Notecard has to reacquire a GPS satellite lock, which can take 30 seconds to a few minutes, depending on your location.
Thanks,
Rob
I thought as much however I still have the question of knowing when a fix is valid as I mentioned the fix I was given after restarting was many kilometers away I.e one full degree latitude or more and one full degree longitude or more so it’s not a stale fix or a tower or anything it’s a completely wrong fix
Hi @BrianP,
By any chance are you able to replicate the incorrect GPS fix? If not, sometimes you’ll see GPS pulling inaccurate lat/lon, especially when it’s just started acquiring satellite fixes. This obviously improves quickly when more satellites are acquired. Related to this can be the location of the device: are you indoors or outdoors, how clear is the view of the sky, etc.
I can also tell you that the next release of the Notecard firmware fixes what could be misleading GPS diagnostics in terms of the number of satellites that are actually fixed vs how many the module thinks should be visible. For example, your GPS fix might be with 3 satellites, when the Notecard API tells you that 10 are available. Not incorrect, just not clear!
One final note: reissuing the card.location.mode request with mode:continuous to a Notecard that is already in continuous mode will NOT restart the GPS. So if you thought the command corrected the GPS error, it’s more likely that the signal just converged closer to your correct location.
Rob:
The distance in question is 128.4 km (coordinate provided vs known location). I have never seen a GPS provide such an incorrect figure and I don’t see how I can determine it is a wildly wrong figure from the response provided.
For example here are good (correct) and bad responses
good
{“status”:“GPS updated (27877 sec, 0/39 dB SNR, 9/15 sats) {gps-active} {gps-sats} {gps}”,“mode”:“continuous”,“lat”:*3.532762500000007,“lon”:-*0.031226333333338,“time”:1620344293}
bad
{“status”:“GPS updated (622 sec, 0/33 dB SNR, 10/13 sats) {gps-active} {gps-sats} {gps}”,“mode”:“continuous”,“lat”:*4.097697333333328,“lon”:-*1.422966999999993,“time”:1620314964}
The only difference, other than times and location is the number of satellites reported
I will attempt to recall and document how I got that reading. Since I’d prefer not to post my location to the Interwebs I’ll PM it to you. Since it is from memory it might be wrong, but I’ll try my best.
Thanks for sending details in the PM. For public reference, I would always recommend using hub.set once (at the beginning) to set your cellular mode to periodic or minimum when working with GPS. Then you can safely set your GPS mode and not worry about cellular after that.
We need to improve our documentation around GPS best practices for sure, along with info on using external antennas, realizing how long low-power devices can take to gather a GPS fix, and so on.
I’m copying the PM reply I sent to you in case somebody else has a similar issue. See also Card.status is never "connected"? - #16 by BrianP
After going back to basics I realized that I was passing bad data in the
{“req”:“hub.set”,“product”:“org.documenteddesigns:test_project_1”}
My notehub address is com, not org
{“req”:“hub.set”,“product”:“com.documenteddesigns:test_project_1”}
As such, hub syncs were not happening. It appears than unless a sync is done, things like card.time is not populated. I would have expected card.time to reflect the network information (i.e. tower coordinates, local time, etc), and independent of a valid sync. Because there was no error I didn’t realize this until I stated from scratch and noticed a
{“req”:“hub.sync.status”}
{“alert”:true,“status”:“connect delayed (57 min remaining): opening notehub: no project was found with product UID product:org.documenteddesigns.brian:test_project_1 {product-noexist} {service}{extended-service-failure}”,“time”:1620398664,“completed”:9}
I think this is a transient message: if you don’t ask for hub status at the right moment you miss the message and just realize the sync reply isn’t right.
I believe this is pretty opaque, especially to people learning the system. I might be wrong about these various things but either improved documentation or better yet, improved error messages might be useful.