GPS only working for initial fix

[jakobmn]

I have tested ZephCore on one of my rak wismesh tags for a while, and observed, that the position only updates once after powering it on. My devices are configured to not include position in adverts, and to allow position in telemetry for specific contacts, so we can use it to find each other.
If I power down the wismesh tag, and power it up again, the position gets updated.
The tag can't get a GPS fix when it is inside connected to my computer, so I don't know how to get more debug information about what happens. Any ideas as to what I could do?

I recently changed my ThinkNode M1 to run ZephCore as well. Since the M1 has a display, it is possible to get a bit more information out of it:

• My M1 also only updates its position once after power up
• I have disabled/enabled GPS both via SW and the HW toggle, and this does not give a new position in the telemetry data either
• While I was out on a long walk yesterday, I observed the behavior, and could see that almost every time, the device found ~7 satellites before the 30s timed out, without it getting a new fix
  
• I observed, that the "Last fix" updated at least twice while I was far away from the position I get through telemetry request from another device, or by looking at the device position from my companion app

It seems like there are at least two issues:

• The position never gets updated after initially being set - even if the device gets a fix
• My two devices have a really hard time getting a GPS fix within 30s

Additionally, for my use case of using the GPS position to locate each other, it would be preferable, if there was a cool-down time (maybe 5-10min?) after a telemetry request, where the GPS was kept on, to give a faster and more accurate position. This way the power consumption can be kept low most of the time, while still having just as good positioning while we locate each other, as the vanilla firmware.

[liquidraver]

I only "implemented" the GPS fix behaviour to sync time to be honest, I don't use on companions.
The logic is this:
After boot: No timeout, wait for 3 consecutive good fixes, write lat/lon to prefs
After that, every 5 mins: 30 sec timeout, write the new lat/lon to prefs after 3 consecutive good fixes (>3 satellites)

I've catched a bug too, the fw doesn't clear "first_fix_acquired" on GPS off, so next GPS on is 30 sec timeout again.

I've fixed the bug and increased timeout to 120 sec (in dev branch only for the time being)

[jakobmn]

Thanks. I will give the latest dev branch a try.

[jakobmn]

Seems to have solved the issue on the M1. The times I looked at it while being out today, it said less than 5min simce last fix. And the telemetry data updates as well. Hope to have time for testing it on the tag soon.
What are your thoughts on a feature for keeping the GPS on for a while after getting a telemetry request?

[jakobmn]

The wismesh tag started out with a position from earlier.
After taking it outside, the position updated to "0.0, 0.0" but I can see that the altitude updates periodically within a few meters of the expected value here.

[liquidraver]

The wismesh tag started out with a position from earlier. After taking it outside, the position updated to "0.0, 0.0" but I can see that the altitude updates periodically within a few meters of the expected value here.

I think it is resolved with the latest dev commit. I can't test it, I don't have the hardware

[jakobmn]

I have not been able to reproduce the "0.0, 0.0" issue again after that change.

[liquidraver]

Telemetry request asks for a GPS fix:
57aab5f

[jakobmn]

Cool! I will give it a try this weekend.

[jakobmn]

I tested this a bit today, and it behaves as if the GPS starts over getting a fix from scratch, even if requesting telemetry position periodically: It takes a long time for the position to update, and if the device I'm tracking is stationary, it sometimes gets a position close to where it is, but the next time, it updates, the position can be >100m away.
Looking at the code in ZephyrGPSManager, it looks like it will be in GPS_STATE_ACQUIRING state until 3 consecutive_good_fixes, and will then go to GPS_STATE_STANDBY, only to be sent back into GPS_STATE_ACQUIRING state on the next periodic telemetry request.
The ideal behavior would be to keep it in GPS_STATE_ACQUIRING for a timeout after the latest telemetry request, which would ensure fast and accurate updates.