1139284 - [Woodduck] MLS very slow for location

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia, defect, P2)

Description

[sync-1]

Created an attachment (id=1172917)
 Part 1 video of the reference vs the DUT
 
 DEFECT DESCRIPTION: Geolocation is really slow when you use a app like maps. Takes too long to pin point your exact location
 
  REPRODUCING PROCEDURES: In the search tab in the man page look for "maps" choose google maps or any other option, open it, click on the button for location.
 
  EXPECTED BEHAVIOUR: To be quick, i know is AGPS but it should find you in less than a minute

Comment 1

[sync-1]

Attachment: Part 1 video of the reference vs the DUT

Comment 2

[sync-1]

Attachment: Part 2 video Reference vs DUT

Comment 3

[sync-1]

Attachment: Logs of Fire 2 3.5 during the location test

Comment 4

[sync-1]

Hi my results where that in the Fire 2 3.5, aprox time was 10 minutes for exact
 location in the Fire C it was 2 and a half minutes, big difference, same wifi
 network, both just had a factory reset.

Comment 5

[Josh Cheng [:josh]]

Hi Jamin,
Could you help to check this issue? Thanks!

Comment 6

[Jamin Liu [:jaliu][:Jamin]]

Hi [e-mail],

I have few questions for you.
Did this test was conducted in indoor environment without SIM card ? 

Where did the test was conducted ? Would you please provide the name of city or the latitude and longitude ?


I can't reproduce this bug on Fire 2(3.5) in Taipei. (It took about 3 seconds to get MLS location.)
Device version:
 - Firefox OS: 2.0m
 - Build Identifier：20150303154026
 - git commit info : a1b59597

Would you mind to provide "Gecko Geolocation Log" by turn it on in Settings app ?
Here is the procedure to produce "Gecko Geolocation Log".

1) Turn on Developer Menu
   [Settings] --> [Device information] ---> [More Information]  --> [Developer Menu]
2) Turn on ADB debugging
   [Settings] --> [Debugging via USB] ---> [ADB an DevTools]
3) Turn on Geolocation log
   [Settings] --> [Developer] ---> [Geolocation output in ADB]
4) Turn on WiFI
5) Open Browser app and open any remote page to make sure WiFi connection is functional.
6) Use the ADB command "adb logcat -v time" to save the log and time
7) Use geoloc app, google map or HERE map to query the location.

Thank you very much. :)

Comment 7

[sync-1]

Created an attachment (id=1187071)
 LOG from Moxico

Comment 8

[sync-1]

Created an attachment (id=1187071)
 LOG from Moxico

Comment 9

[sync-1]

Attachment: LOG from Moxico

Created an attachment (id=1187071)
 LOG from Moxico

Comment 10

[Josh Cheng [:josh]]

Revise name to reflect actual issue is MLS.

Comment 11

[Josh Cheng [:josh]]

(In reply to sync-1 from comment #9)
> Created attachment 8575101 [details]
> LOG from Moxico
> 
> Created an attachment (id=1187071)
>  LOG from Moxico

Hi Reporter,
Which device log is this? Fire C or Woodduck?

Comment 12

[sync-1]

(In reply to comment #6)
 > Comment from Mozilla:(In reply to sync-1 from comment #9)
 > > Created attachment 8575101 [details]
 > > LOG from Moxico
 > > 
 > > Created an attachment (id=1187071) [details]
 > >  LOG from Moxico
 > Hi Reporter,
 > Which device log is this? Fire C or Woodduck?
 
 
 Woodduck device

Comment 13

[sync-1]

Created an attachment (id=1188869)
 geo log of fire 235 and fire E in huizhi

Comment 14

[sync-1]

Created an attachment (id=1188869)
 geo log of fire 235 and fire E in huizhi

Comment 15

[sync-1]

Attachment: geo log of fire 235 and fire E in huizhi

Created an attachment (id=1188869)
 geo log of fire 235 and fire E in huizhi

Comment 16

[Josh Cheng [:josh]]

Hi Jamin,
Could you help to check the log from China team per comment 15? Thanks!

Comment 17

[Jamin Liu [:jaliu][:Jamin]]

Hi Henry,

NetworkGeolocationProvider uses WifiMonitor to scan available WiFi APs and send list of APs to MLS server for positioning.
https://dxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js#311

In Taipei office, Fire 2 (3.5) can find a lot of APs during MLS positioning in Taipei.
> *** WIFI GEO: sending {"wifiAccessPoints":[
> {"macAddress":"00-00-00-00-00-00","signalStrength":0},
> {"macAddress":"dc-38-e1-83-13-44","signalStrength":-37},
> {"macAddress":"dc-38-e1-83-13-48","signalStrength":-37},
> {"macAddress":"dc-38-e1-83-13-46","signalStrength":-37} ...

MLS works well on Fire 2 (3.5) in Taipei, however, our partner reported that MLS can't work well in Moxico.
I noticed the log in #attachment 8572465 [details] indicates that Fire 2(3.5) didn't find any APs by WiFi scanning.
> *** WIFI GEO: sending {}

However, there are few WiFi AP was logged in log file.
> D/WifiHW  (  167): leave --> reply=bssid / frequency / signal level / flags / ssid
> D/WifiHW  (  166): 24:0a:11:7b:c6:02	2422	-67	[WPA2-PSK-CCMP][WPS][ESS]	H850-VAL
> D/WifiHW  (  166): 1c:e6:c7:f0:57:71	2437	-60	[WPA2-PSK-CCMP+TKIP][ESS]	TCTPortal
> D/WifiHW  (  166): 1c:e6:c7:f0:57:70	2437	-60	[WPA2-PSK-CCMP+TKIP][ESS]	TCTMobile
> D/WifiHW  (  166): 1c:e6:c7:f0:57:74	2437	-60	[WPA2-EAP-CCMP][ESS]	EAP-SIM
> ...
> D/WifiHW  (  167): enter -->wifi_send_command cmd=IFNAME=wlan0 DRIVER SCAN-PASSIVE

Do you have any idea why these WiFi APs can't be found by WifiMonitor ?
Thank you.

Comment 18

[sync-1]

Created an attachment (id=1189910)
 mozilla build geo log and screen shot in huizhou

Comment 19

[sync-1]

Created an attachment (id=1189910)
 mozilla build geo log and screen shot in huizhou

Comment 20

[sync-1]

Attachment: mozilla build geo log and screen shot in huizhou

Created an attachment (id=1189910)
 mozilla build geo log and screen shot in huizhou

Comment 21

[Josh Cheng [:josh]]

Hi Jamin, Could you please help to check the log for Woodduck of Mozilla build per comment 20? Thanks!

Comment 22

[Jamin Liu [:jaliu][:Jamin]]

I compared the log from #attachment 8575798 [details] with the log from #attachment 8575872 [details].
Although TCL build didn't find any WiFi APs by WiFi scaning, Mozilla build found many WiFi Aps during MLS positioning.

Fire 2 (3.5) with TCL build (FxOS 2.0m)
> *** WIFI GEO: sending {}

Fire 2 (3.5) with mozilla build (FxOS 2.0m)
> *** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"00-00-00-00-00-00","signalStrength":0},{"macAddress":"3a-a4-f6-71-ac-8b","signalStrength":-56},{"macAddress":"54-78-1a-a1-fc-60","signalStrength":-57},{"macAddress":"4e-a4-89-1a-f3-4d","signalStrength":-58},{"macAddress":"54-78-1a-a1-27-10","signalStrength":-58},{"macAddress":"a2-dc-ea-b9-a6-d0","signalStrength":-58},{"macAddress":"62-a4-81-2c-c3-a1","signalStrength":-59},{"macAddress":"02-11-22-33-44-40","signalStrength":-60},{"macAddress":"a2-ab-af-9d-f8-d0","signalStrength":-60},{"macAddress":"02-5b-42-35-28-1b","signalStrength":-61},...

Both MLS results are inaccurate, however, the causes are different.

TCL build build can't get accurate location from MLS since the WiFi scan isn't functional.

Mozilla build can't get accurate location from MLS since there is no MLS collected data samples in Huizhi.
(Please refer to https://location.services.mozilla.com/map#2/15.0/10.0)

I think we should test Mozilla build 2.0m in Mexico to clarify the issue.

Comment 23

[Henry Chang [:hchang]]

It appears there're access points in the testing environment but none of them
were seen for location query request. If this issue can be reproduced with 2.0m,
we can then focus on the location provider components.

Comment 24

[sync-1]

what we should do is find out the cause why requestData is null of code "xhr.send(requestData);" with TCL build
 
 Fire 2 (3.5) with TCL build (FxOS 2.0m)
 > *** WIFI GEO: sending {}
 
 
 onChange: function(accessPoints) in file NetworkGeolocationProvider.js, where the value "accessPoints" passed from?

Comment 25

[Josh Cheng [:josh]]

Hi Henry, Could you please shade some light on the question per comment 24?
Thank you!

Comment 26

[Henry Chang [:hchang]]

(In reply to sync-1 from comment #24)
> what we should do is find out the cause why requestData is null of code
> "xhr.send(requestData);" with TCL build
>  
>  Fire 2 (3.5) with TCL build (FxOS 2.0m)
>  > *** WIFI GEO: sending {}
>  
>  
>  onChange: function(accessPoints) in file NetworkGeolocationProvider.js,
> where the value "accessPoints" passed from?

|onChange| is callback function by |wifiService.startWatching|.
You can also refer to nsIWifiListener.idl for further information!

Comment 27

[sync-1]

Created an attachment (id=1194121)
 geo log after fix AP scan issue in México
 
 please refer to the geo log 
 Access Point info was sent to MLS this time.
 the test location is City "Guadalajara – Jalisco – México"
 
 Here is test result descrition
 
 ” aproximatelocation was faster and more accurate than before, the problem is that this time is that the exact location is never given”

Comment 28

[sync-1]

Created an attachment (id=1194121)
 geo log after fix AP scan issue in México
 
 please refer to the geo log 
 Access Point info was sent to MLS this time.
 the test location is City "Guadalajara – Jalisco – México"
 
 Here is test result descrition
 
 ” aproximatelocation was faster and more accurate than before, the problem is that this time is that the exact location is never given”

Comment 29

[sync-1]

Attachment: geo log after fix AP scan issue in México

Created an attachment (id=1194121)
 geo log after fix AP scan issue in México
 
 please refer to the geo log 
 Access Point info was sent to MLS this time.
 the test location is City "Guadalajara – Jalisco – México"
 
 Here is test result descrition
 
 ” aproximatelocation was faster and more accurate than before, the problem is that this time is that the exact location is never given”

Comment 30

[sync-1]

Hi mozilla friends,
 
 This is a urgent issue, please help to handle ASAP, thanks !

Comment 31

[Jamin Liu [:jaliu][:Jamin]]

(In reply to sync-1 from comment #30)
> Hi mozilla friends,
>  
>  This is a urgent issue, please help to handle ASAP, thanks !

Hi [e-mail],

MLS can only provide approximate location.
If users want to get precise location, they have to use GPS.

According to the log, The MLS result is (20.6449596, -103.4070207).
http://maps.google.com/maps?q=20.6449596%2c-103.4070207

Could you provide the actual latitude and longitude as a ground truth ?

Comment 32

[Josh Cheng [:josh]]

Update:
Qualcomm replaces LocationProvider from Mozilla at vendor/qcom/proprietary/b2g_location. The server is not the same as Mozilla Location Server. The result is as expected now.

Comment 33

[Beatriz Rodríguez [:brg]]

(In reply to Josh Cheng [:josh] from comment #32)
> Update:
> Qualcomm replaces LocationProvider from Mozilla at
> vendor/qcom/proprietary/b2g_location. The server is not the same as Mozilla
> Location Server. The result is as expected now.

Could you please confirm that Woodduck (not QC based product) is not having this issue anymore?
I only want to be sure we are on the same page.

Comment 34

[Wesly Huang (EPM)]

Hi Beatriz:

Regards to MLS "slow" symptom addressed in this bug title, I think it was clarified as a bug during OEM integration, and get fixed already. Thus we put WORKSFORME here.


The left MLS related symptom we see, is the precision of MLS in some discussion and we think this is limited by it's design and the ricnness of database of the area under test.

Please let us know if any further question, thank you!

Comment 35

[sync-1]

Hi wei,
 CTS has closed the bug, I think it is time ti close.
 
 thanks for mozilla firends.