Slight modification to the GPS submission logic

ketilmo commented 5 years ago

If unable to acquire a valid GPS fix, the station will now use the previous values instead.

ketilmo commented 5 years ago

@matthijskooijman This modification is a simple attempt to mitigate the loss of position after a failed GPS refresh. Whenever the station is able to get valid coordinates, it will overwrite the old ones with the new ones. If the station is unable to get GPS fix, it will leave the previous coordinates untouched.

matthijskooijman commented 5 years ago

Thanks for your PR, nice!

Looking at it, I have two remarks:

I believe we should really keep track of the age of the GPS location, and after a certain period (7 days) stop sending an old position. This prevents the situation where the GPS breaks, or a station is moved to a place with no reception, and it will continue to send the old position indefinitely.
I wonder if queueData() is the right place to implement this behaviour? I would think that getPosition() would be more obvious, though I'm not entirely sure...

ketilmo commented 5 years ago

Hi @matthijskooijman,

Thanks for your prompt feedback!

To avoid increasing the data packet size, could we consider doing a "stamp" in the transmission on every cycle that includes a GPS update? For instance by postfixing an asterisk to the Fcnt? So the packet from a cycle without GPS would read "10" (like today), while a packet from a cycle with a GPS update would read "11*". Maybe a bit too simplistic? An alternative could be to transmit GPS_UPDATED true/false as it own value, but I guess this would require modifications on the receiving end? A third option would be to transmit "cycles since last GPS refresh" in every transmission, but this would be a bit heavy on the bandwidth. What do you think?
I agree that getPosition() would probably be the more logical place to implement the logic. I did it in queueData() primarily to do as few changes as possible. Will change it when we land on a new approach. :)
The GPS issues I have observed here in Bergen is a bit peculiar. At first, I thought that bad reception was the problem. But a reset of the unit instantly fixes the acquisition issues, in almost all the cases. If the unit is not reset, on the other hand, it's often not able to get new coordinates at all – even after days of being powered on. So it looks like the problem is trigged by a hardware or driver issue. Is it possible to do a hard reset of the stations via software in circumstances like this? So for example, after a week without GPS fix, the unit could hard reset itself?

ketilmo commented 5 years ago

I was unable to update this pull request, so I have created a new one: #15. This can be closed.

matthijskooijman commented 5 years ago

You could have done a force push to your branch, which would have updated this PR automatically.

ketilmo commented 5 years ago

@matthijskooijman I deleted my branch, and I think this caused the problems unfortunately.

meetjestad / mjs_firmware

Slight modification to the GPS submission logic #14