Results 1 to 19 of 19
  1.    #1  
    I'd love to hear from some other people who have written Location based apps (like GeoStrings, Foursquare, etc), and see if they have similar issues and how they've addressed them.

    I'm writing a location based app that polls for the user's current position every X minutes and if they are in a certain location, it will then take some action. Everything works great, EXCEPT the gps results. Often, the GPS result shows a horizontal Accuracy of 1000 (the max amount it can be off). What gives? Has anyone else seen this?

    I can understand this happening when you are indoors and it can't get a good signal and has to rely on cell towers to locate you. But I've found that the phone gets to point after a few days where EVERY result is "poor" in terms of accuracy, and the only way to get it working properly again is to reboot the phone.

    I've tried a couple methods to work around this. The 1st thing I tried was to continue getting positions until an accurate result was returned, or X amount of time has passed. If it can't get an accurate position, then it averages all the crappy positions.

    The 2nd method I tried is instead of getting a single position, I used the tracking service to get continual positions until a good result is returned, at which point the tracking is stopped and I continue processing with the good result. This method seems to work, but is a significant battery drain, even though the tracking is running for a short period of time.

    My third (and current) solution, is to try using the getPosition to get a good result. If it can't after a few tries or X seconds, then I resort to the tracking method above.

    Has anyone else noticed issues with the GPS getting "stuck" to where it never returns an accurate result? How do you get around this problem? My app kinda depends on the result being fairly accurate.
  2. #2  
    It is a problem that I have encountered in Weatherman and People Finder, and so far I have found it to be the GPS hardware or the actual phone.

    On my phone, I get fixes with an accuracy of 1920 (yes, that exact number) for 3 tries (in tracking mode) and then it returns a moree accurate value (100 or less). Another phone I test with has an accuracy of 2000+ and will NEVER change. The only way I could get an accurate fix on that phone was turning it off and back on again (NOT a restart, must be off/on).

    In People Finder I use the tracking method-- 5 tries, if the accuracy is below 300 then stop and return the value, otherwise keep going until the 5 tries are over.

    This is something that has to be addressed by Palm-- I am not sure if it is hardware or software, but the GPS APIs are something to stay away from if possible.
    Sprint Palm Pre - WebOS 2.1 > Sprint HTC Arrive
  3. #3  
    If you are on Verizon you may as well give up on an accurate GPS fix until such time as Palm and Verizon resolve a solution to Verizon's GPS implementation
    Palm m130 > Verizon Trēo 650 > Verizon Trēo 755p > Verizon Palm Prē Plus > TouchPad > Verizon Palm Prē 2
    ~ The Future's Just Not What it Used To Be ~
  4.    #4  
    I'm glad to know that there are others who are having this problem. I'm not on Verizon, but I have read all about the Verizon GPS issues. The problem for me, is that in the case of my particular app, it requires a fairly accurate GPS reading in order to be useful. Sometimes I get readings that are over a mile away from my current location. That's unacceptable.
  5.    #5  
    the other problem I'm having is that when calling getCurrentPosition ... If I use a timeout of anything other than 1, my callback method never gets called. What gives there?
  6. #6  
    I've noticed that the GPS (via the getCurrentPosition API call) can produce inaccurate results at times. On my phone, it'll stay pretty dead on for awhile and then it'll start producing less accurate results.

    In GeoStrings, I've done a few things to try to workaround inaccurate GPS results:

    1) Checking horizontal accuracy and retrying to see if I can get a more accurate fix.

    2) Running with the highest accuracy possible in the getCurrentPosition call. Prior to webOS 1.4.0, I also ran with a responseTime of 3 which gave the GPS plenty of time to return an accurate result. However in webOS 1.4.0, background tasks were broken and I had to resort to using a responseTime of 1. Once 1.4.5 is released, I'll up that to 2. Technically 1.4.1.1 would be sufficient to support a responseTime of 2; however most carriers are still running 1.4.1 (where background tasks are killed within 10 seconds).

    3) Checking for impossible readings based upon the user's speed. I once witnessed the GPS return my position in the middle of the Atlantic Ocean (900 miles away!). That's a drastic example, but even some normal, everyday inaccurate readings may be physically impossible. So my app rejects any readings that are not physically possible.

    4) I've produced a FAQ (available on the app's help screen) and one of the questions provides GPS troubleshooting tips. You can also view the FAQ here: Hedami.
    Quick Post: The quick way to post messages and photos to Twitter & Facebook (video link)
    Music Player (Remix): The next generation music listening experience on webOS (video link)
    GeoStrings: Set location-based reminders and never forget another task (video link)

    Twitter: @Hedami
  7.    #7  
    @DanPLC

    Thanks for the info. My app is in some ways very similar to GeoStrings in that it allows you to setup "location profiles", and then monitors your position and when you arrive at one of your location profiles, it takes some action (although that action is quite different from GeoStrings). I just got done reading every post in the thread you started awhile back on the palm developer forums in which the Palm folks reluctantly admitted that they changed the background processing time to 10 or so seconds, and suggested opening a dashboard stage every time the background task runs (I'd laugh at that, except it isn't funny ... ). That shed a lot of light on why my app is behaving the way that it is.

    In scenario 1 you mentioned above (checking horizontal accuracy and retrying to try and get a better fix), what do you do in a situation in which it keeps giving inaccurate results? The only options I can think of are to average all of the inaccurate readings in the hope that an average will produce something closer to reality (this still doesn't seem like a good approach), or to just skip processing all together (also no good in the case when the gps seems to be permanently stuck).

    Finally, Would you mind if I poach the GPS FAQ info you have for GeoStrings for use in the help section of my own app? If I can't get accurate gps data for my users, at least I can give them some info and a method for trying to make things better.

    Thanks.
  8. #8  
    Quote Originally Posted by Bradleycorn View Post
    @DanPLC

    Thanks for the info. My app is in some ways very similar to GeoStrings in that it allows you to setup "location profiles", and then monitors your position and when you arrive at one of your location profiles, it takes some action (although that action is quite different from GeoStrings). I just got done reading every post in the thread you started awhile back on the palm developer forums in which the Palm folks reluctantly admitted that they changed the background processing time to 10 or so seconds, and suggested opening a dashboard stage every time the background task runs (I'd laugh at that, except it isn't funny ... ). That shed a lot of light on why my app is behaving the way that it is.
    It is comical, but it's definitely not funny. Changing the way background tasks operated was/is a major headache.

    Quote Originally Posted by Bradleycorn View Post
    In scenario 1 you mentioned above (checking horizontal accuracy and retrying to try and get a better fix), what do you do in a situation in which it keeps giving inaccurate results? The only options I can think of are to average all of the inaccurate readings in the hope that an average will produce something closer to reality (this still doesn't seem like a good approach), or to just skip processing all together (also no good in the case when the gps seems to be permanently stuck).
    I'm not in front of my code now, but I'm pretty sure I retry once if the accuracy is too low and then immediately take another reading. If that reading is also bad I set a very small alarm timer (around 10 seconds) and once my app is re-awakened, I try to get another set of readings. If those fail, I use the average of all the bad readings. In my opinion, it's better than nothing.

    There are probably other things that could be done to try to estimate your current position based upon your current trajectory and speed, but in my opinion in an ideal world, these are the types of things that should be done at a lower OS level instead of on a per-app basis. But we don't always live in an ideal world which is why these types of tweaks/workarounds need to be implemented in apps.

    Quote Originally Posted by Bradleycorn View Post
    Finally, Would you mind if I poach the GPS FAQ info you have for GeoStrings for use in the help section of my own app? If I can't get accurate gps data for my users, at least I can give them some info and a method for trying to make things better.

    Thanks.
    I obtained much of the information from others, so I don't mind if you use it.

    Speaking of possible issues your app may have with users, you mentioned that your app will be polling the GPS every X minutes. So I assume you're using the alarm service to wake up your app. My app does the same thing. The first thing I do is re-send an alarm request. Occasionally this does not work. The app will just die and never return an onSuccess or onFailure. This results in no alerts being generated until the app is re-opened by the user. I've verified in the logs that the app dies within the first second, so it's not related to the app being closed within 10 seconds of running in headless mode. The developer of YouView has posted a similar issue in the Palm dev forums and I suspect we're experiencing the same webOS service request bug.

    I'm still trying to come up with some type of workaround for this one. But if we can't rely on alarm service requests to complete properly, it's going to be tough. Luckily though it doesn't happen too often.
    Quick Post: The quick way to post messages and photos to Twitter & Facebook (video link)
    Music Player (Remix): The next generation music listening experience on webOS (video link)
    GeoStrings: Set location-based reminders and never forget another task (video link)

    Twitter: @Hedami
  9.    #9  
    Quote Originally Posted by DanPLC View Post
    Speaking of possible issues your app may have with users, you mentioned that your app will be polling the GPS every X minutes. So I assume you're using the alarm service to wake up your app. My app does the same thing.
    You are right, although I've tried ("tried" being the key word) to make it a bit more sophisticated. In my app I use the velocity and heading elements of the gps reading (assuming they are correct ... ) to estimate the time of arrival at the nearest "location profile". It's a crude estimation, but it can help save battery life. For example, if all my profiles are setup in city X and I'm tooling around in city Y 500 miles away, there's no need to poll the gps every 5 minutes. So what I do, is as soon as the timer fires and the app launches, I set another alarm for the default poll interval (I let the user configure the default), and then after my processing I reset the alarm based on the distance/heading/velocity calculations, or use the default interval if we're not very far from a location profile. Setting the initial alarm covers a situation where the GPS fails to respond or something like that which would cause the new alarm to not get set.

    Quote Originally Posted by DanPLC View Post
    The first thing I do is re-send an alarm request. Occasionally this does not work. The app will just die and never return an onSuccess or onFailure. This results in no alerts being generated until the app is re-opened by the user. I've verified in the logs that the app dies within the first second, so it's not related to the app being closed within 10 seconds of running in headless mode. The developer of YouView has posted a similar issue in the Palm dev forums and I suspect we're experiencing the same webOS service request bug.

    I'm still trying to come up with some type of workaround for this one. But if we can't rely on alarm service requests to complete properly, it's going to be tough. Luckily though it doesn't happen too often.
    Are you referring to setting up the initial background alarm cycle the first time the app is launched? I don't do that automatically when the app is first launched. My reasoning is that when you launch the app the first time, you can't possibly have any profiles created, so there's no need to start polling. Whenever you create (or edit a profile) the app checks to see if the alarm cycle has been started, and if not, it sets an alarm for 30 seconds, which in effect starts the background alarm cycle. So effectively, the app doesn't start setting alarms until you've added your first profile. I don't think I've seen the issue you mentioned above. Perhaps it has something to do with that first alarm being set "too quickly" after the launch, and so for whatever reason (like a bug in the OS) it doesn't actually get set and thus never fires? Or maybe you are talking about something entirely different and I've missed the boat all together. It certainly won't be the first time that's happened.
  10. #10  
    Quote Originally Posted by Bradleycorn View Post
    You are right, although I've tried ("tried" being the key word) to make it a bit more sophisticated. In my app I use the velocity and heading elements of the gps reading (assuming they are correct ... ) to estimate the time of arrival at the nearest "location profile". It's a crude estimation, but it can help save battery life. For example, if all my profiles are setup in city X and I'm tooling around in city Y 500 miles away, there's no need to poll the gps every 5 minutes.
    I do something similar. My app doesn't poll at a constant rate. It's dynamic based upon several conditions, one of which being the distance to the closest target.

    Quote Originally Posted by Bradleycorn View Post
    Are you referring to setting up the initial background alarm cycle the first time the app is launched?
    No, I'm talking about when the app is re-launched via an alarm timeout. As soon as the app starts running in the background it resets the alarm. Sometimes this alarm request never gets initiated and the app just dies.
    Quick Post: The quick way to post messages and photos to Twitter & Facebook (video link)
    Music Player (Remix): The next generation music listening experience on webOS (video link)
    GeoStrings: Set location-based reminders and never forget another task (video link)

    Twitter: @Hedami
  11.    #11  
    Quote Originally Posted by DanPLC View Post
    No, I'm talking about when the app is re-launched via an alarm timeout. As soon as the app starts running in the background it resets the alarm. Sometimes this alarm request never gets initiated and the app just dies.
    Oh that's not good. I'll be on the lookout for that. I did have something similar for awhile. When my app launched, I send a ActivityStart request, and in it's OnSuccess handler I would start the processing that my app needs to do. I noticed that many times, the OnSuccess handler never gets called (what's the point of having OnSuccess, OnFailure, OnError if none of them get called?) and my app would die. Finally I changed my code up, and I just start my processing right after calling ActivityStart. That seems to have fixed that problem.
  12. #12  
    getCurrentPosition isn't great at all. In foursquare, I actually initiate a startTracking call as soon as the app loads in the AppAssistant and then when I'm ready, I check the GPS object that's being updated for its accuracy. If its accuracy is what the user specifies is okay, I stop the tracking and move on. If it's not good, I wait until it is. After 10 seconds of waiting, the app moves forward with the less-accurate results but displays a message that it's still finding better accuracy. It continues this search indefinitely.

    I've found that this works about 90% of the time because during tracking, it's continually finding more and more satellites so the accuracy is increasing. However, there is that 10% time when tracking fails just as easily as getCurrentPosition. It's a huge headache, but unfortunately, there isn't a whole lot you can do.

    I've created a class to do what I explained and it's got the GPS ServiceRequest wrapped so it doesn't get garbage collected. You can take a look at it here: http://github.com/foursquare/foursqu...app/lib/gps.js

    You can poke around the rest of the foursquare source to get a better idea of how I accomplished this. Warning: my code is sloppy and poorly commented.

    The gist of it all is this: try to keep the request from getting GC'd, wait for the max amount of satellites, and hope. Honestly, hardware is an issue here and the Pre and Pixi (plus and regular) GPS isn't the best. In addition, there's some webOS bugs where sometimes the OS returns a cached GPS result even though you explicitly told it not to return cached results. If you have an app that extensively relies on GPS you will get negative reviews in the App Catalog. Unfortunately, that's how it is. It's my biggest pet peeve about webOS development.

    But the 90% of the time this works, it works great!
  13. #13  
    Thanks for the insight. I had been contemplating playing around with using tracking (vs. getCurrentPosition) to see if I can improve my results when querying GPS position in the background, but I haven't tried it out yet.

    I knew going into the GeoStrings project that I'd be subject to a certain amount of negative reviews based upon GPS hardware/OS issues. But it was a risk I was willing to take considering the potentially amazing results I could achieve by using the GPS in a unique way. I have received a few negative reviews; however overall the reviews have been overwhelmingly positive (4.8 average). I think most people realize that GPS, especially on smartphones, is not perfect. When they have issues in all other GPS apps (including Google Maps and Navigation), I think most level-headed people will not trash one particular GPS app. But yes, there is more potential for negative reviews when relying on GPS.
    Quick Post: The quick way to post messages and photos to Twitter & Facebook (video link)
    Music Player (Remix): The next generation music listening experience on webOS (video link)
    GeoStrings: Set location-based reminders and never forget another task (video link)

    Twitter: @Hedami
  14.    #14  
    @Zhephree thanks for the info.

    I've noticed similar results when using tracking vs get currentPosition. I do something similar. I start tracking right away, and stop as soon as I get a result with acceptable accuracy, or after X seconds, whichever comes first.

    One caveat to using tracking instead of getCurrentPosistion. I did a test (on my Sprint Pre) to compare tracking vs getCurrentPosistion, and tracking used significantly more battery. On day 1 I used the tracking method, I had a full charge in the morning, and by the end of the day my battery (the seidio extended life battery) was dead. On day 2 I reverted to getCurrentPosistion, and again started the day with a full charge, at the end of the day I still had about 30% battery remaining.

    My testing seemed to indicate that startTracking will give MUCH more accurate results, but at the expense of more battery usage. That's actually what got me started on this whole thread. I was going to try to solve my getCurrentLocation accuracy issues so I could revert back to that to save battery, and opened this thread to see if others could help me solve those issues. It seems like we're all in the same boat though.
  15. ToddK's Avatar
    Posts
    666 Posts
    Global Posts
    905 Global Posts
    #15  
    wow. enlightening. I don't completely understand everything I've read, but it's clear the GPS on the Pre is less than "stellar" ;-) It's too bad the GPS hardware in the Pre is so bad. (and that some users blame the app, for the hardware's shortcomings. But, it is so frustrating when it happens, and there doesn't seem to be any surefire way to "jumpstart" a sleeping / dead GPS. ...short of a 4-5 min reboot.

    Can't wait to see webOS (and these great apps), running on solid, reliable hardware.
  16.    #16  
    @DanPLC, @Zhephree (and/or anyone else for that matter)

    Have you gotten any word on wheter the 1.4.5 update addresses any of the issues we've discussed? Either the GPS accuracy or the background process timeouts?
  17. #17  
    I have 2 apps that rely on GPS and both of them have lower ratings than the rest of my apps because of the poor GPS system Palm included. I end up trouble shooting a lot for people that have issues with getting a good location fix and it almost always involves restarting their phone.

    In my code I end up setting the response time at 1 for each of the calls because otherwise it can timeout and do nothing and then the user assumes the app is crap.

    I know most people want more hardware choices from Palm, but I would be happy with 1 hardware choice if Palm would just build a good quality phone.
  18. #18  
    The background process time was increased to 60 seconds in 1.4.1.1. 1.4.5 doesn't change this. And as far as I know, it doesn't affect GPS accuracy. Most of the changes in 1.4.5 are related to the PDK.

    I'm guessing a future version of webOS (2.0?) will re-vamp how background processes work. I think the 60-second solution was meant to be a temporary fix.

    My gut tells me that many of the GPS issues we experience are actually software-related and not due to faulty hardware. So hopefully a future webOS revision will make things better.
    Quick Post: The quick way to post messages and photos to Twitter & Facebook (video link)
    Music Player (Remix): The next generation music listening experience on webOS (video link)
    GeoStrings: Set location-based reminders and never forget another task (video link)

    Twitter: @Hedami
  19. #19  
    Quote Originally Posted by jason.o View Post
    I have 2 apps that rely on GPS and both of them have lower ratings than the rest of my apps because of the poor GPS system Palm included. I end up trouble shooting a lot for people that have issues with getting a good location fix and it almost always involves restarting their phone.

    In my code I end up setting the response time at 1 for each of the calls because otherwise it can timeout and do nothing and then the user assumes the app is crap.

    I know most people want more hardware choices from Palm, but I would be happy with 1 hardware choice if Palm would just build a good quality phone.
    Quote Originally Posted by Bradleycorn View Post
    the other problem I'm having is that when calling getCurrentPosition ... If I use a timeout of anything other than 1, my callback method never gets called. What gives there?
    I'm wondering if you could use a longer timeout if you use the Service Wrapper described here:

    ServiceRequestWrapper Update - incaseofstairs

    Using the wrapper has made a huge difference in my app. I was doing downloads and sometimes would never get the calls to my callback. The wrapper has completely solved that for me.

Posting Permissions