Closed Bug 892057 Opened 11 years ago Closed 11 years ago

[GPS] Can't get a GPS lock

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: nick, Unassigned)

References

Details

testing on a ZTE Open, Geeksphone Keon, and Unagi all 1.0.1 with GPS enabled in settings.  I've tried HERE maps, Rob Nyman's Boilerplate, and Evernav (under review).  None get a gps lock over wifi.  I also tested the keon with just my SIM and no luck.
Indoors or Outdoors? Geolocation works for me outdoors on unagi. Indoors I believe it will not work.
I just tested Unagi outdoors and it did not seem to work for me. I wonder if it depends on the version of the drivers installed on the Unagi? Sometimes it seems to work and sometimes it does not...

How long does it take for you Jason? Is it fast or do you have to wait quite a while?
(In reply to Donovan Preston from comment #2)
> I just tested Unagi outdoors and it did not seem to work for me. I wonder if
> it depends on the version of the drivers installed on the Unagi? Sometimes
> it seems to work and sometimes it does not...
> 
> How long does it take for you Jason? Is it fast or do you have to wait quite
> a while?

Disregard my original comment - that testing from a few weeks back. Just retested this now outside of the Mt View office - this isn't working for me.
Doug - Any ideas why the Geolocation appears to be failing entirely right now (specifically outdoors)?
Flags: needinfo?(doug.turner)
So this just worked for me on a Unagi when I built from source (on device it's listed as 1.1.0 git commit info 2013-07-10 16:18:38).  If I run `adb shell cat system/b2g/defaults/pref/user.js | grep supl` all devices are using supl.izatcloud.net:22024 (unless overridden somewhere else).  But I literally have not been able to use GPS on any other device & os version pairing.  This is a huge issue for reviewers since they're testing apps for 1.0.1, yet gps doesn't seem to be working on any devices on 1.0.1.
Nick, as i mentioned to you on IRC, part of the configuration to get AGPS working is out of our hands -and- in the hands of the OEM.  That is to say, it isn't sufficient to just look at our user.js file and assume that if we have the supl server set, then things will work.

What you have to do is to check both that the right supl server is set (you got that), and check to see if the modem is configured problems.  The problem with checking the modem is that we do not have the tools to look at the modem configuration (yea! binary blobs ftw).  This is the QC magic suase that OEMs configuration themselves.  You can look send me etc/gps.conf and I might be able to tell if there is a chance that it is configured right.

Given that the Unagi's work and the other devices don't... I presume that the Geekphone is somehow misconfiguration.

Btw -- I do not think that geekphone (some 1.0.1 rev) has agps configured in any way to work.

I think you should focus on 1.1 and up.
Flags: needinfo?(doug.turner)
(In reply to Doug Turner (:dougt) from comment #6)
> 
> Btw -- I do not think that geekphone (some 1.0.1 rev) has agps configured in
> any way to work.
> 
> I think you should focus on 1.1 and up.

Doug, we are telling developers that buying a Geeksphone is the best phone to use when developing their apps, including apps that rely on geolocation. I don't think we can live with this.
Note - this bug is also happening on production ZTE Open devices, not just non-target production phones.
Thanks Jason, I was hoping it would be only Geeksphones and Unagis.

Doug, do you have an Unagi or a Geeksphone at hand to verify and do the tests you recommended? Otherwise I go ahead and get the gps.conf from the various devices I am testing on.
(In reply to Doug Turner (:dougt) from comment #6)
> Btw -- I do not think that geekphone (some 1.0.1 rev) has agps configured in
> any way to work.

This is not true. AGPS has been configured on both Geeksphone models, Peak and Keon, and I was able to get a GPS lock. I will re-check with current builds to see if there was a regression.
Okay, just confirmed that I am able to get a GPS lock in HERE maps, outdoors, on both the Keon and Peak, with latest stable builds from GP (5 July for Keon, 13 June for Peak).
> Okay, just confirmed that I am able to get a GPS lock in HERE maps, outdoors, on both the Keon and Peak, with latest stable builds from GP (5 July for Keon, 13 June for Peak).

That does not mean AGPS is configured.
Per Kevin Hu's email on 7/15 - He will ping Michael Vines and loop ZTE in and ask QC to help ZTE sort this out. Meanwhile, we will also make sure it can work with ZTE Open market phones. 

We need to validate this works indoors in a reasonable amount of time.
Using the ZTE Open in San Francisco (I have two ZTE Open devices, one from Spain and one with the Latam build), I am able to get GPS to work and find my location in the map, but it takes nearly two minutes to complete. 

I can get it to work indoors over wifi. To do it:

1. Open Here maps and tap the menu button in the upper-right. 
2. Tap Route. A message appears 'Finding current location'. And it takes about two minutes until the button in the bottom-right turns green. 
3. Tap the green button and it successfully goes to my location in the map. I can then get directions to a destination, etc.
Dear all, although I'm not a GPS expert, let me give you some information, hoping it helps to clarify this issue:

- Current implementation of Firefox OS, AFAIK doesn't support Cell-ID (i.e. the handset does not report the information about the serving cell to the AGPS server)

- Since there is no Cell-ID support, the information provided by the AGPS server will only help the device to get GPS location faster (in few minutes, while GPS standalone could take up to 15 minutes to get first location. This is called TTFF or Time To First Fix).  
--> this means it will only work outdoors, as GPS signal is not available indoors.

(In reply to Michelle Luna from comment #15)
> I can get it to work indoors over wifi.
The key here, I believe, it's that you are using a Wifi connection. Many providers include "Wi-Fi positioning system" information that could help to locate the handset. (I'm not sure how providers get this data but Google explains here how what they did: http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/es-419//googleblogs/pdfs/google_submission_dpas_wifi_collection.pdf)

As soon as Cell-ID is implemented in Firefox OS, TTFF will be much faster and it will perfectly work indoors.

Regards
Juan, this is incorrect.

Firefox OS *does* support Cell-ID AGPS via QC.  mvines, who should Juan talk to on your side to get updated?
Going through the usual support channels would be best.
Juan, can you please contact QC using the usual support channels?  We need to get this configuration confusion behind us quickly.
Hi, 

We can talk this offline if you prefer. We can also make this bug private, if you're concerned about any confidential issues. 

Thanks!
David
Hi Doug, 

I will contact QC to clarify this issue, and will give feedback here as soon as we reach to some conclusions.

BR
CCing GP, it seems like comment #6 has some pretty good info here and work needs to be done on the manufacturer side to get this working right.
All oem/operators have been notified.  There is nothing mozilla can do here.

https://wiki.mozilla.org/B2G/Geolocation
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Is there somewhere else interested parties can monitor status of this bug?
Not really.  Most of this is now between OEMS, chip manufactors, and operators.  Mozilla is not involved directly.
Doug - understand the issue is now dealt directly with OEMs, chip manufacturers and MNOs. That said we (app review team, partner engineering, dev engagement etc) are speaking to several developers/content partners who would like to understand when AGPS/geolocation will work on FxOS. Who do you suggest we speak to within Mozilla to get the latest updates? Thanks.
You need to log in before you can comment on or make changes to this bug.