[Ubuntu Phone] With WIFI = ON the GPS stops

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

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!

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

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!

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

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)?

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!

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.

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

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!

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.

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

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

A hug!

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.

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!

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!

@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!

Hola Marcos,

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

Nexus 7 2013

Muchas gracias!

Saludos.

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?).

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!

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

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.

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.

did some housekeeping to get it into the queue

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)

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.

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

see bug #1469007 for a related symptom

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

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

@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...

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

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.

@mardy: Could you please check for crash logs?

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.

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

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 :)

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.

@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?

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.

@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.

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! :)

(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)

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

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

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.