On 3/26/14, 7:08 AM, Julien Wajsberg wrote:
Le 25/03/2014 14:05, Adrian Custer a écrit :
Already, I have started wondering about problems in the data gathering
of the Wifi base station locations. (I suspect, but have not yet
confirmed, that the hardware and code behind the
navigator.mozWifiManager API call are storing signals based on the
periodic broadcast from wifi base stations but only dropping the base
station after some timeout. I am seeing residence times of base
stations in the data reported by the above API of around a full
minute, a time within which I have moved far out of radio contact with
the base station, far enough away that relating the later positions to
the wifi base station makes for a crummy position estimate (~300meters
of that error term alone).
300 meters is not bad already ;)
"In that error term alone" is a key qualifier in the sentence above.
This is essentially saying that you start your error calculation with
your actual position on the surface of the earth known only to a
precision of +/- 300 meters *before* you start the error calculation of
all the other terms: the error in the GPS coordinate estimate based on
the Positional Degree of Precision calculation of the GPS device, and on
and on. If you trace that through the error propagation to the end
result you could give the user, it's not great. Oh, you will know you
are in Montevideo, even in the city center, at the end of the process,
but that is information that we tend know without asking our phones for
help.
Confirming this and figuring out how to handle it will require a bunch
of field work, something I am not yet sure how to do.) A solution
might eventually be to eliminate the presence of a wifi for all
positions beyond a certain distance (or time) from initial observation
(or at a position or time based on some calculation involving initial
observation and the evolution of signal strength), something which
could even be done on the server eventually for already accumulated data.
I'm not an expert at all, and I don't know the app either, but I think
we know the signal strength, right? Maybe the app is recording this as
well, and we're removing the station with too weak signal?
The issue is that we are not *measuring* the wifi signal at every time
step. Instead, the system accumulates wifi signals as they are broadcast
into a set of current signals and uses that store to answer API queries.
So you are getting the 'signal strength of the last received broadcast'.
From unstructured observation, it seeems that new signals tend to show
up fairly quickly, but signals don't disappear from the 'observed set'
until they have not been seen 'for a while.' And that is how all my wifi
adaptors (on laptops) have worked up until now, which is why you are
offered a list of wifi devices that grows over time and if you turn off
a base station nearby it is still offered by your network access system
for a while. I do not know of any other mechanism that could use the
periodic broadcasts put out by the wifi base stations to answer user
queries. If the API were giving us only the Wifi base stations that have
currently been received that would be fine---we would get less data to
send MLS but it would be more accurate for this purpose. However, the
wifi chips have all be designed on the presumption that you want the
data in order to be able to connect to some network, not that you want
real time data about the broadcasts. So my working thesis is that we
have an issue, we should be able to do better, and I need to work on
this someday, among many other issues.
My original question was what work was going on at Mozilla to deal with
all these issues, if the Mozilla Location Services is going into production.
~adrian
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
