tinkering guidance

[kellyfo-r]

Please guide me away from accuracy detrimental fiddling of settings, but also help me understand how to evaluate settings changes. I have read the settings change description in the editor, however I cannot grasp the implications.

I want to start by requiring a higher gps accuracy. My handset is frequently capable of 3 meter precision.

[n76]

I guess that means the description of the advanced settings at https://github.com/n76/wifi_backend#advanced-settings is not clear enough. . .

The background thread that builds the local database asynchronously receives reports from the GPS indicating where the phone is located and reports from the WiFi system listing the APs that the phone detects. If we think we have a good location, then we process the APs.

The first four settings described at the above link control if we think a GPS reading is (still) good enough that we can process a list of WiFi APs. The first, required accuracy, is used to check the accuracy reported by the GPS system (in your case that might be as little as 3 meters). The next two, sample distance and sample time, are parameters passed to the GPS system and control how often the GPS will provide a location value, more details in the Android library call documentation available elsewhere. The fourth, GPS valid time, is how long we believe the position report is good for. If you are stationary or walking this can be a fairly long value. If you are on a motorway, your position may be changing at 25 to 35 m/s so the position won't be valid for as long.

In practice, the constraints don't seem to matter as much as I thought when I made them available. The algorithm is looking for an the center of an area defined by edges. So if the a couple of drive-by samples are acquired from each direction, the edges of the coverage are generally affected equally meaning the coverage radius is affected more than the estimated center.

FWIW, I put this aside for a long while but with a new phone that gives me more sensor options I am planning to do a major enhancement of this backend and I may will remove these advance options in the process.

[gdt]

@kellyfo-r The big question is what your goals are. For me, this backend is really useful in two circumstances. One is when I start OsmAnd and am able to roughly locate on the map immediately, both to see it, and to start calculating a route. The fact that my position is off even 30m is not important in that case, but it is really important that I get a position immediately. The other is inside buildings. Here, part of the value is immediately getting a position that's sort of near the right building. A further value, more cool than useful so far, is getting relatively decent in-building positions.

In thinking about how to improve the situation, I don't see requiring better GPS accuracy as really useful. The GPS fix being 3m vs 10m off (and I'm skeptical of a phone and 3m, although I believe it reports it) isn't really the real issue, since you aren't at the APs you hear. To get better accuracy requires fusing multiple observations of each AP based on signal strength, GPS location, and GPS accuracy to get an estimated AP location and also signal strength/distance curve. Then the backend has to fuse those estimates for all heard APs to get an estimated position. (I think it's already doing a fair bit of this, but I haven't had time to dig into the code.)

My opinion is that improving the two fusing steps is going to make a much bigger difference than worrying about how good a GPS fix is needed. Also, I'd say that a GPS fix with a 200m error (crazy high I know) is better than no fix, if it leads to a position that's even 300m off rather than no fix. As long as that accuracy is recorded with the sample, it shouldn't affect the fusing result much after there are better samples.