[Captivate Q&A, Help & Troubleshooting] halfhp:
Ok..this is going to be a little long-winded so bear with me.

So there seems to be a new fix posted for gps every other day, some are just snake-oil while others might actually be doing something. The problem is how to tell what is working and what is not...and to what degree. Trusting the word of some guy on a forum with 200 posts is NOT the answer. What we need are some objective tests that produce quantitative data. It would also be nice to objectively compare our device's performance to the performance of other android devices out there too...to get an idea of what a realistic gps performance expectation would be.

So far MyTracks seems to have been the best approach but it's still a very poor method for several reasons:

The software acts as an abstraction layer - it's unknown what kind of filtering may be occurring here.

The data is only meaningful to the originator; we don't know which street(s) you were really on.

At best only 1 dimension of the error is preserved; we might be able to assume you were driving down street X, but how do we know how far down the street you actually were when the sample was captured?

Bottom line, there is no way to programmatically extract quantitative results.

I've got half of the solution: Collect a series of samples from a stationary position and collect lat/lon/alt/time, reported gps accuracy, number of satellites used, time to lock, device make/mode, device uptime (to weed out the "I rebooted and it works!" phenomenon) etc.

With this data we can calculate things like jitter, deviation, acquisition latency and all kinds of other interesting things.

I know that sounds like lots of work, but I've already done all of the above (scroll down to the bottom to read more about that) and for the most part the data collection and result presentation components work. The problems I am running into are related to the details of how the above data maps to real world performance.

So let's talk about some potential algorithms:

1. Deviation

This was my first hope as a solution; grab bunch of gps coordinates and use the lat/lon positions along with reported accuracy to get a centroid location. Then using the centroid, calculate the distances between each point and the centroid to measure accuracy. In theory, if the distribution was random, this would work. In practice however, I found that:

A - You get A LOT of duplicate points that throw off the statistics.

B - Even if you throw out duplicates, the coordinates you get are usually very close to one another, in spite of being far from the true location. In hindsight, I think that should have been obvious. Oh well.

In any case, let me illustrate:

I took 30 samples sitting in front of my office. The distribution looks like this:

http://maps.google.com/maps/api/staticmap?size=512x512&maptype=hybrid&markers=color:blue|label:1|37.280015489448,-121.943445407709&markers=color:blue|label:2|37.280015489448,-121.943445407709&markers=color:blue|label:3|37.2799150689755,-121.943469689324&markers=color:blue|label:4|37.2798287737251,-121.943507481842&markers=color:blue|label:5|37.2797409130025,-121.943532462122&markers=color:blue|label:6|37.2796490544446,-121.94354159922&markers=color:blue|label:7|37.2796117648545,-121.943468886907&markers=color:blue|label:8|37.2796034813727,-121.943455640717&markers=color:blue|label:9|37.2795946561935,-121.94344227994&markers=color:blue|label:10|37.2795861462627,-121.943431154687&markers=color:blue|label:11|37.2795786087998,-121.94342342341&markers=color:blue|label:12|37.2795720667083,-121.943418240036&sensor=false&sensor=false

And the centroid I calculated from these looks like this:

http://maps.google.com/maps/api/sta...7,-121.943465819874&sensor=false&sensor=false

Looks pretty good so far right? Not even close. You can almost predict where the gps will say I am going to be next just by looking at those points. Unfortunately, there's no data there about where I actually am. I was actually standing outside of the building, smack in the middle, which is about 30 meters south of the closest sample I got.

Which brought me to idea #2:

Measure reported accuracy, sampling frequency/jitter, time it took to acquire the initial lock and call it a day.

Which brings me here - I'd like to do this right and so I'd love to get anybody's feedback on what kind of algorithm to use to characterize gps performance.

Also, if anybody wants to take a peek at whats been done so far, here's a link to a page with the latest version of the android client. Just install it and start it up. It will pop up and error if it can't connect to the server and the server does go down from time to time, so if you get a connection error, try again a little later. The other thing to be aware of is that I enforce the "stationary collection" rule by monitoring the accelerometer. When you hit start you will have 3 seconds to put your phone on a table or the sidewalk or somewhere else that isn't moving. Once the collection starts, it will monitor GPS until it gets 30 samples. You can cancel at any time by moving the phone. If any samples were collected, they will be uploaded and you will get an option to view the results. The results aren't too terribly meaningful for now, but there are a couple interesting statistics there and you will be helping me out by stress testing the server. Feedback appreciated!

Thx