[TIMOB-2139] GPS cuts out sporadically
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Cannot Reproduce |
Resolution Date | 2011-06-13T10:00:47.000+0000 |
Affected Version/s | Release 1.4.0 |
Fix Version/s | Sprint 2011-24 |
Components | Android |
Labels | android, geolocation, gps |
Reporter | Anthony Webb |
Assignee | Opie Cyrus |
Created | 2011-04-15T03:11:41.000+0000 |
Updated | 2017-03-31T17:22:52.000+0000 |
Description
I noticed this on the kitchenshink app and have also confirmed with a very simple app.js (http://pastie.org/1233923">http://pastie.org/1233923) Load and wait for 10-20 seconds and the GPS will start shutting off then back on.
I am seeing this on my droid running 2.2, and 1.4.1.1
Updating with a new pastie, moved GPS code to its own URL but still see the same behavior of GPS turning off and on sporadically:
http://pastie.org/1248564">http://pastie.org/1248564
10-25 14:49:57.387: DEBUG/libgps(1089): GpsInterface_start()
10-25 14:50:08.385: DEBUG/libgps(1089): GpsInterface_stop()
10-25 14:50:13.393: DEBUG/libgps(1089): GpsInterface_start()
10-25 14:50:24.385: DEBUG/libgps(1089): GpsInterface_stop()
10-25 14:50:29.387: DEBUG/libgps(1089): GpsInterface_start()
10-25 14:50:40.385: DEBUG/libgps(1089): GpsInterface_stop()
Updating with a new pastie, moved GPS code to its own URL but still see the same behavior of GPS turning off and on sporadically:
http://pastie.org/1248564">http://pastie.org/1248564
10-25 14:49:57.387: DEBUG/libgps(1089): GpsInterface_start()
10-25 14:50:08.385: DEBUG/libgps(1089): GpsInterface_stop()
10-25 14:50:13.393: DEBUG/libgps(1089): GpsInterface_start()
10-25 14:50:24.385: DEBUG/libgps(1089): GpsInterface_stop()
10-25 14:50:29.387: DEBUG/libgps(1089): GpsInterface_start()
10-25 14:50:40.385: DEBUG/libgps(1089): GpsInterface_stop()
Love to see this added to the 1.5 roadmap. Kind of hard to write a proper GPS app when the GPS is cutting out regularly.
investigation and testing. Unable to reproduce reported behavior. GPS only updates when location changes are detected so sitting relatively still while testing GPS will result in a lack of GPS updates which may give the impression of GPS not working.
Opie, it's not the lack of GPS updates...it's that the GPS radio turns off after 10-20 seconds, then turns back on 4-5 seconds later. This is clearly demonstrable in the Kitchen Sink geolocation example. Watch the GPS radio indicator at the top of the device (you must test this on an Android device...not the emulator). Still an issue with 1.8.0.v.......
We just learned that there's an undocumented Ti.Geolocation.frequency property that defaults to 5 (seconds). Setting this to 1 keeps the GPS on (stops it from cycling off and on every 5 seconds). This is for Android...I'm not sure if the same problem exists for iPhone or not. Appcelerator, please check the default for this property. Here's one of several Q&A topics about this problem. It is clearly reproducable by several Titanium users: [http://developer.appcelerator.com/question/117489/gps-turns-off-every-few-seconds-on-android]
After testing Shawn's theory and I agree. It would be helpful for Ti.Geolocation.frequency to be defaulted to 1 instead of 5. It would also be helpful to have this property in the documentation. We found this when we saw the following console message: I/TiLocationHelper( 526): (kroll$4: app://MORegisterNewModules.js) [10,21569] registering listener with provider [gps], frequency [5000], distance [1.0] Naturally we tried setting "Ti.Geolocation.frequency=1000;" That turned out to be a mistake, it seemed to break the GPS completely. Little did we know that we were setting the frequency to 1000 seconds. By chance we try "1" and we got what we were looking for, the GPS remained active! When we did this the console message was as follows: I/TiLocationHelper( 526): (kroll$4: app://MORegisterNewModules.js) [10,21569] registering listener with provider [gps], frequency [1000], distance [1.0] It would also be helpful if the Ti.Geolocation.frequency matched the console message. To be consistent with other properties in the system I would suggest Ti.Geolocation.frequency be in milliseconds instead of seconds. However, that would break code for people currently using Ti.Geolocation.frequency.
Closing ticket as it has been over 5 years since the last update.