GPS issue: Updates the speed field only

Very similar behaviour on:

current build number: 313
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en
last update: 2016-04-14 06:07:41
version version: 313
version ubuntu: 20160414
version device: 20160329-a9bacdb
version custom: 20160324--36-54-vivid

I can not support exactly 11 seconds update frequency but at least several seconds. Speed update is very regular. I have tested this with uNav, Activity Tracker and OSM Scout.

The behavior changed with http://bazaar.launchpad.net/~phablet-team/location-service/trunk/revision/229 on purpose, addressing the common request for filtered/fusioned location updates, ensuring that only more accurate updates are delivered to the client. We do not have an estimate on the accuracy of velocity, so we hand out the specific data regardless.

I will start investigating whether we should tune the fusioning engine such that a newer update with lower accuracy could still be accepted if it is contained within the accuracy circle of the previous update. I will update this bug report going forward.

Having done the math under the assumption of 100 km/h, the position moves ~27 m/s. Common accuracy for a position estimate provided by the GPS is ~5 m. With that, we would still reject updates. We will investigate an alternative approach accepting decreases in accuracy by a certain percentage (likely something around 25%, to account for fluctuations in estimates originating from satellite-based positioning providers).

What is happening if you're using a GPS app walking? You'll not have those
27m/s.

It would obviously work in that case, and even the current filtering would likely work for a lot of situations. We are searching for a robust addition that works for all velocities , though.

Thanks to Scott, we now have some actual data available for a highway scenario (see attached plots). Left plot shows a histogram over the quality ratio accuracy(new)/accuracy(old), with an expected peak around 0 (logarithmic scale). Right plot shows a boxplot of the values, with most of them in [0.9, 1.2]. With that, the threshold approach present before would likely work.

However, after some internal discussions we realized that we should actually assume that updates from the same source are consistent. That is, we will only filter updates that originate from different sources instead of trying to come up with a meaningful threshold that behaves robustly across a lot of different scenarios.

Before this task gets forgotten, I just would like to raise my voice here again. My user feeling on this is, that Navigation with the current settings (only updates after some significant seconds) is not what I expect.

I would appreciate that this gets fixed in a sense that the GPS signals get flowing again.

Please do not forget this topic. I would assume that this gets into the stable channel with OTA11? This would cause some irritation for many users.

I am agree. I can't even test uNav in RC proposed :( This will not arrive to OTA right??

Hi,

the behavior still persists in OTA11.

Just right after OTA10 one started to play around with the location-service in rc-proposed, leading to following behavior:
While speed still was updated every second, position started to be updated most likely only every 9 seconds.
As i am working on a navigation app, I stopped using rc-proposed channel (it is not intended for every day use and it seemed not to go hand in hand with (navigation-)app development.

Ok, one wanted to use the 6 week slot to play with location-service.
But, to be honest, I am a bit disappointed about the situation, that this bug is now found in ota11 still.
This is critical to any navigation app.

In my opinion, flowing position updates are more important than in small range accuracy.

Let us know if something starts moving in rc-proposed. I am back on ota10.1 now.

Thanks, best Joerg

Hi, it is a weird behavior. A new coordinate is returned each ~11 seconds, but they are returned the same coordinate 3 times at the same time. You can check it with Activity Trracker.
Best regards.

For bug subscribers: The fix is staged here https://requests.ci-train.ubuntu.com/#/ticket/1534 and about to hit rc-proposed.

This bug was fixed in the package location-service - 3.0.0+16.10.20160616-0ubuntu1

---------------
location-service (3.0.0+16.10.20160616-0ubuntu1) yakkety; urgency=medium

  [ Scott Sweeny ]
  * Fusion provider: Always use an update that came from the same source
    as the previous used update (fixes LP: #1570878) (LP: #1570878)

 -- Thomas Voß <email address hidden> Thu, 16 Jun 2016 06:03:16 +0000

Well done! Thanks.

Thanks a lot! It's working again.