On 26. März 2014 13:22:15 MEZ, Adrian Custer <[email protected]> wrote: >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-geolocation mailing list >[email protected] >https://lists.mozilla.org/listinfo/dev-geolocation
https://github.com/mozilla/MozStumbler/issues/38 _______________________________________________ dev-geolocation mailing list [email protected] https://lists.mozilla.org/listinfo/dev-geolocation
