[Ubuntu Phone] With WIFI = ON the GPS stops

[costales]

Hi!

Steps:
1. Enable WIFI = ON on phone.
2. Run one of these apps: GPS Navigation, HERE maps, Sensor Status.
3. Drive.
4. When you'll be into a WIFI area as a town or city, I'm thinking the WIFI will try to search WIFIs and then the GPS will stop, the GPS apps will not receive more new positions from the GPS.

Extra info1: If you had GPS Navigation & Sensor running, both of them will not receive new GPS positions from the device. If you restart for example GPS Navigation, GPS Navigation will receive new positions, but Sensor Status not, until you restart it too.

Extra info2: When the GPS stops the icon in the status disappears, but it you kill and relaunch the app, the icon will appear again.

Thanks in advance!

[Ilonka (ilonka-o)]

Hi Marcos,
the last days I recognized that after I drove some meters the arrow stand still and also the plan didn't actualise. Could it be that perhaps a weak GPS signal cause this problem? I've got this problem mostly in the town where I live. Three days ago I was in another town and there the App works ok.
I've got a BQ 4.5 Aquaris with Ubuntu 14.10 (r22)
Another possibility could be that the problems caused through the OS himself. I've got to reboot my BQ a few times the last days. If I can send you a log which helps you please tell me.
Ilonka

[costales (costales)]

Thanks for your feedback Ilonka!

> "the arrow stand still and also the plan didn't actualise"

The arrow & map will be change the position just when them receive a new
GPS signal.
If the arrow & map are fix in a position, means that a no new GPS position
is received.

> "perhaps a weak GPS signal"

A signal can be with a low or high accuracy, but not weak :)

A hug!

[Edwin (7-ek)]

Hello,
first of all, I want to thank Marcos Costales for his great work, the time and the endurance he brought into this very, useful and necessary project!!!
Maybe the problem is the automatically change of the data provider . I have experienced it on more than 1000km . My guess : If you use the provider  o2 in Germany , the cellular - network will change between o2 and E-Plus network which has been available for some time . It's like data - roaming . If the network change - GPS navigation freeze. I have the same experience even if I change form my Wi-Fi- network  into cellular network. I'm not 100% sure, but for me it seems so. Using bq aquaris 4.5

[costales (costales)]

Hi! Today I get a freeze on the app startup.
It was just when I changed from wifi to 3G and I launched the app.
The app had not a real data connectivity in that moment, a connectivity
error should be appear, but not, just an app freeze.
Maybe that can help.

We should need an user will a persist problem all the time :(

Thanks in advance!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sergi Quiles Pérez (sergiqp)]

Yesterday I had 4 freeze error (with needing to restart the app) and 3 times with no problems.

The freeze errors always happened when driving in a town, not on the road. So I think what Edwin says is possible.

I have a question:

      It is necessary to have 3G all the time or the app has the ability to work with just the GPS signal (without refresh the map)?

[costales (costales)]

On Tue, Jun 9, 2015 at 5:33 PM, Sergi Quiles Pérez <email address hidden>
wrote:

> It is necessary to have 3G all the time or the app has the ability
> to work with just the GPS signal (without refresh the map)?
>

Thanks for your feedback Sergi! :)

The app needs 3G for set the route & maps.
Do you have the freeze issue always in the same point? It could be great
for debug things.

FYI You can set a route with 3G and then, disable the 3G. You'll have a
white map (no map) and it can't be recalculate the route.
If you'll be in the right way all the time you'll see the blue route line
using just GPS.

A hug!

[Olivier Tilloy (osomon)]

Marcos, I just had a quick look at the code for unav, and I think it would be very useful if you could instrument the JS code with a few debug logs to try and figure out what’s going on for users who can observe the freeze.

Could you get someone who can reliably reproduce the issue attach the corresponding log file? It should be at /home/phablet/.cache/upstart/application-click-navigator.costales_navigator_0.11.log

Is it possible that the index.html page is ever reloaded, thus leading to more than one call to watchPosition() through the lifetime of the app?
Also, I’m not really sure what purpose the "if (prev_run <= $.now())" test serves. According to the W3C spec for watchPosition (http://dev.w3.org/geo/api/spec-source.html#watch-position): « the successCallback is only invoked when a new position is obtained and this position differs significantly from the previously reported position ». So presumably if you get two success callbacks in a row, it’s because the position has changed enough that you really want to update the position on the map anyway.

[Olivier Tilloy (osomon)]

I tentatively added an oxide task, and I’m confirming the issue for unav.

[costales (costales)]

Hi Olivier! Thanks a lot for your support! Really :)

> instrument the JS code with a few debug logs to try and figure out what’s
going on for users who can observe the freeze.

I'll do it ;) but will be this a problem with a big .log for the system?
the app will write several lines every second.

> Could you get someone who can reliably reproduce the issue attach the
corresponding log file? It should be at
/home/phablet/.cache/upstart/application-click-navigator.costales_navigator_0.11.log

This is the log without the debug trace: http://paste.ubuntu.com/11696576/
I didn't see anything on it.

> Is it possible that the index.html page is ever reloaded, thus leading to
more than one call to watchPosition() through the lifetime of the app?

I think not.

> Also, I’m not really sure what purpose the "if (prev_run <= $.now())"
test serves

Yes, I'm agree with you, but for example, I'm getting 1 position for every
~600 microseconds. As so many users reported a freeze problem, I'm forcing
just 1 call in 800 microseconds. But the users have the same problem.

> it’s because the position has changed enough that you really want to
update the position on the map anyway

It's giving me a problem, because between position & position I'm
calculating things like rotation, distance, time, I'm on route, draw the
map...
Then, the app has problem with a big (really big) routes (Madrid-Berlin for
example).

A hug!

[Sergi Quiles Pérez (sergiqp)]

When I had driven for 20 km by car, when it was perfect, the car (arrow) stopped.
SensorsStatus told me that GPS sensor was down. When GPS worked again the app was not able to continue the navigation.

I closed the app and started it again and it was all fine.

After driving for a long time the GPS failed again and forever. The car (arrow) stopped. After restarting the phone everything was working again.

I think that it could be a bug in Ubuntu Touch when it works with GPS sensor. Sometime ago I experienced the same issue in Here Maps.

I attach three logs.

[costales (costales)]

Great Sergi!!!!
Your log has an uncatch exception :D Fixed!
Then, we have to try again in the next 0.12 :)
Thanks a lot!

[Sergi Quiles Pérez (sergiqp)]

Congratulations for your persistent job and enthusiasm. I am waiting for 0.12 release. :-)

A hug!

[Martin (acevedom)]

Hola Marcos,

Comprobé lo siguiente.

Mismo dispositivo, misma versión pero la primera instalada hace un tiempo la cual se ha actualizado varias veces. En esta la aplicación se congela al minuto.

En el segundo caso con ubuntu recién instalado funciona perfecto.

Nexus 7 2013.

Espero que sea de ayuda. Felicitaciones por la app y gracias.

Saludos.

[costales (costales)]

Gracias Martín :)
Mañana publicaré (espero) la versión 0.12 y te agradecería si puedes
comprobar cómo va :)
¡Gracias y un abrazo!

[costales (costales)]

Hi!

First: I want to thank you to all of you your testing and feedback :)

Second: I released version 0.12 into the Store. Please, check if the
problem is fixed :)
Remember to kill the app ;)

If the problem persist, please, attach here you file log:
/home/phablet/.cache/upstart/application-click-navigator.costales_navigator_0.11.log
An easy way is to use the logviewer app from the Store.

And a Sensor Status screenshot too, please.

A hug and thanks in advance!

[costales (costales)]

@Olivier, We found a behavior (weird):

I was driving 6 weeks with wifi = off. All was perfect, always!

Today, by a Edwin's report I was driving with wifi = on. The GPS didn't report new positions to HERE, GPS Navigation or even Sensor status until restart those apps. It's happening when you're near to towns or cities with WIFIs.

Which project should we report this? Can I attach any useful log file?

Best regards and thanks in advance!

[Martin (acevedom)]

Hola Marcos,

Actualicé a la versión 0.12 y el problema desapareció. Felicitaciones.

Nexus 7 2013

Muchas gracias!

Saludos.

[Olivier Tilloy (osomon)]

It looks like the issue is with the location service that stops reporting position updates under certain conditions (that sometimes involve wifi networks).

I’m marking location-service affected, in the hope that someone familiar with the location service can comment (maybe it’s a known issue?).

[costales (costales)]

I updated the title & description bug after 3 weeks of tests.

I'm attaching a few things:

6.54PM_before_fail_with_GPS_icon.jpg: Screenshot before fail the GPS. You can see the GPS icon into the status bar.
6.56PM_after_fail_no_GPS_icon.jpg: Screenshot just alter fail the GPS. The GPS icon dissapeared.

dmesg-status_sendor_stop1.txt: dmesg just after fail with Sensor Status.
dmesg-status_sendor_stop2.txt: dmesg just after fail with Sensor Status the 2º time.
dmesg-here_maps_stop1.txt: dmesg just after fail with HERE MAP

Thanks in advance!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sergi Quiles Pérez (sergiqp)]

I have done a these tests:

   * Data OFF, Wifi OFF: It works perfectly without updating the map
                                           nor the route.

   * Data ON, Wifi OFF: It works perfectly updating the map and route
                                          if you have coverage.

   * Data ON, Wifi ON: It works well until you reach a zone with many wifi
                                        networks when the car freezes. The map
                                        and route update until it fails.

   * Data OFF, Wifi ON: It works well until you reach a zone with many wifi
                                         networks when the car freezes. The map
                                         and route don't update.

In conclusion:
      With wifi ON it fails sometimes and with wifi OFF it works always,
      and it doesn't depend on if data is ON or OFF.

I think GPS in Ubuntu Touch fails when it has to manage many wifi networks, not a few.

[Kuroen (jlm-verschuuren)]

Hi All,

Today I started driving with the following services on:
1. WIFI
2. GPS
3. Data connection (SIM)
4. Location detection

After a few km I got a freeze. The map no longer scrolled an the blue arrow did not move over the map.

I stopped the navigation and waited for a minute before restarting it.
Before I restarted it I switched off the "Location detection". After this I had no problems driving for over 70 km. At this time I started the "Location detection" again and then it froze after a few km.

So I agree with Olivier Tilloy. It looks like a bug in the location-service.

Hope this helps.

[Olli Ries (ories)]

did some housekeeping to get it into the queue

[Ilonka (ilonka-o)]

Hi all!

I did also some tests and want to post my results:

I test GPS signal with WIFI = ON and location service = OFF -> Then you got no GPS signal in the Apps Here, Sensor Status, GPS Navigation

GPS signal WIFI = Off and location service = OFF -> NO GPS signal in all three Apps

WIFI = ON and location service = ON -> GPS Signal was online but it freezed sometimes in all three Apps. Actual GPS Signal only after restart of the Apps. I also recognized that NearBy Scope showed that I should be on a place which was about 250km away.

WIFI = OFF and location service = ON -> GPS Signal was activ all the time, GPS Navigation App wasn't freezed

I tested it with a BQ Aquaris 4.5 Ubuntu 15.04 (r23)

[Joe Odukoya (jodukoya)]

This is a pretty serious bug - can we please give it some attention as a priority.
I've raised the product priority to Critical to reflect this.

Many thanks.

[costales (costales)]

I confirm that this is happen in BQ E4.5, BQ E5 & Meizu MX4.

[Pat McGowan (pat-mcgowan)]

see bug #1469007 for a related symptom

[Andrea Bernabei (faenil)]

is there any news about this bug? it was raised to Critical more than 2 months ago :)

[Markcortbass (markcortbass)]

I confirm this critical and annoying bug, BQ Aquaris E4.5 Ubuntu Editon.

[Tony Espy (awe)]

@Markcortbass

Do you have the latest OTA installed?

Which app were you using when you hit the bug?

Also, it's possible that bug #1480877 might have something to do with this, as when WiFi is enabled, and HERE Maps is run, a new WiFi scan is triggered every 4-5s, and the resulting spike in DBus traffic can cause hangs in the UI.

I'll talk to the location service developers and see if there's a way to read the location service updates from the command-line so that we can get a better test case for this...

[Thomas Voß (thomas-voss)]

For a very simple cli client that connects to the service:

> sudo apt-get install ubuntu-location-service-examples
> /usr/lib/arm-linux-gnueabihf/ubuntu-location-service/examples/client --bus system

[Alberto Mardegan (mardy)]

I reproduced this bug, both on the BQ and Nexus 4.

BQ:
- client: Nokia Here
- mobile data connected
- bug appeared shortly enabling wifi
- manually killed espoo location provider from the terminal: no difference

Nexus 4:
- client: Google maps
- no valid SIM inserted (=> no data connection)
- bug appeared shortly enabling wifi
- manually killed ubuntu-location-service from the terminal: no difference (this is probably another bug: we should be able to recover from crashes)

I'm going to attach the logs soon.

[Thomas Voß (thomas-voss)]

@mardy: Could you please check for crash logs?

[Thomas Voß (thomas-voss)]

I managed to reproduce the issue with a non-responding client. The service *should* not wait for the client to answer to position updates, but we apparently do. For that, I attached a branch that tackles the issue by asynchronously handling (lack of) responses.

[Alberto Mardegan (mardy)]

Ah, it appears that I do have a crash indeed:
https://errors.ubuntu.com/oops/72d47fa0-78a7-11e5-9a8b-fa163e373683

[Thomas Voß (thomas-voss)]

We have got fixes staged in silo 10 (see https://requests.ci-train.ubuntu.com/#/ticket/559). Before hnading over to QA, we would greatly appreciate feedback from people who contributed to this bug. If you want to give the fixes a spin, please install the silo by:

  [1.] Enable developer mode on your phone, unlock and connect to your machine via USB.
  [2.] Install the silo tools with: sudo apt-get install phablet-tools-citrain
  [3.] Deploy to device via: citrain device-upgrade 10 ${YOUR_DEVICE_PASSWORD}

Please note that the procedure makes your image on the phone writable, so you should know what you are doing :)

[Alberto Mardegan (mardy)]

I tried silo 10, and I couldn't reproduce this bug anymore. Before, it was reliably happening after about 5 minutes of cycling around a densely habitated area, but with this silo installed I was out for about 30 minutes and the location was always working.

[Tony Espy (awe)]

@Thomas

What's the client component in this case, and why wasn't it responding?

Also, does this still tie into the WiFi state per the original description?

[taiebot65 (dedreuil)]

I tested this silo for this bug #1480877 and it does seem to solve the problem also. GPS seems to work nicely on Mako.
The only stuff i have noticed with this silo is the photo inside scopes are much bigger than normally. e.g. go to weather map scope and click on one icon. the icon goes almost full screen i do not think that was happening before.

[Thomas Voß (thomas-voss)]

@Tony: The client is the app, which is potentially sigstop'd by our lifecycle. The dbus daemon does not detect the app being sigstop'd and we might end up trying to call into a stopped app, waiting for a response (for too long).

The WIFI tie-in is removed by the MP attached to this bug, we will move reporting infrastructure to an external component soon'ish anyway.

[costales (costales)]

Hi @Thomas,

> trying to call into a stopped app, waiting for a response (for too long)

FYI, this bug could have conflicts waiting a long response:
https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1468020

Best regards! :)

[Timo Jyrinki (timo-jyrinki)]

(in vivid overlay)

location-service (2.1+15.04.20151109.2-0ubuntu1) vivid; urgency=medium

  [ Alberto Mardegan ]
  * Make sure that injected time is given in milliseconds

  [ Thomas Voß ]
  * Cherry-pick rev. 196 and 199 from lp:location-service. The changes
    got accidentally removed by merging the outstanding documentation
    branch.
  * Handle responses of clients to updates asynchronously. Rely on
    dummy::ConnectivityManager as harvesting is disabled anyway. (LP:
    #1462664, #1387643)

[FreeFri (freefri)]

When is this supposed to be fixed? I am using Ubuntu Touch 15.04 (OTA-8.5) on a nexus 4 and the GPS does not seem to be working

[costales (costales)]

It is working in my MX4 & BQ E4.5.
I think Nexus 4 is not in the same branch of code (?).

[Richard Somlói (ricsipontaz)]

The default Nexus 4 channel hasn't got the HERE AGPS, but if you change to the bq-aquaris.en channel (yes, it works well with N4) you can use it.