-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
After the recent patch , we hold lock for a bit before updating the position. The positions that come in after the hold are genuinely better positions than what we've been doing before. However, they only come 20 seconds after we've got lock.
So, at the moment, to avoid badness while making an improvement what the code is set up to do is update the local position twice - first, when lock is obtained, and second, after the hold expires. Since local position updates are asynch to mesh broadcasts, it means in many cases the good position will be broadcast, but not always.
Instead, if the settings allow, we should skip that first local position update.
"If the settings allow" is the meat if this issue. If we look at the broadcast/smart update/gps update intervals and they are all well above 20 seconds, it's likely safe. However, on the other end, we don't want to break GPS updates for the people who leave GPS permanently on (gps_interval <10secs). We want to avoid potential loops where any of the broadcast/update/interval settings are set to exactly or less than the 20 second hold time. All doable, just needs some attention to detail.