Run vs new?
Is the new count meaning new to me or new to wigle?
And if it sees a Mac address it seen before but in a new location, is it new or remapped?
And if it sees a Mac address it seen before but in a new location, is it new or remapped?
is this in WiGLE WiFi Wardriving for Android?
If so, "Run" is the number of networks you've seen since launch + scan. "New" is the number new to your local database (the app is designed to be self-contained)
WiGLE's estimate of a network is updated with each uploaded observation, based on weighted signal-strength trilateration. Your app will keep a local list of locations per-MAC-address as well as a Network table entry using your "best" location for each net.
If so, "Run" is the number of networks you've seen since launch + scan. "New" is the number new to your local database (the app is designed to be self-contained)
WiGLE's estimate of a network is updated with each uploaded observation, based on weighted signal-strength trilateration. Your app will keep a local list of locations per-MAC-address as well as a Network table entry using your "best" location for each net.
OK, so I just installed wigle on android and did a run. Lots of spots are misplaced (understandable). I would expect that if I did another run on the other side of the block, the spots would move closer to their correct place, since they would register their location two times. however, when I click the button to upload the data, I get a message that the file would be empty.
Could you elaborate a bit on how this app works? Does it take a different user in order to triangulate the wifi spots location better?
Could you elaborate a bit on how this app works? Does it take a different user in order to triangulate the wifi spots location better?
I just noticed that on WiGLE WiFi the WiFi spots are much better placed, however on the web database most of them are off by 200-300m.
Hi!
There are a lot of items that can effect this, so I'll try and give a framework for all of it here, and we can drill down on individual items:
1. Locally, you store your observations (you can see dots when you select an individual network) and a "best" location in the network table (we don't do any estimation on the client currently)
2. When you upload, you send those observations to be incorporated into the database this takes place via a process probably best called "weighted centroid multilateration." - just means "we estimate the probable location using an average of locations - but the "weight" of each location in the calculation is based on the square signal strength"
if you've done a good job detecting the network accurately on your handset, your local record will probably be great, but other observations in the database get factored in, and drag things off course.
There are a few possible causes of this:
1. moving the access point: We do some statistical analysis, but if the AP was located elsewhere before, it takes an accumulation of data to "snap" it to the new location.
2. High-powered wardriving rigs: someone driving a few streets over with a directional antenna and amplifier might have registered the point with a really strong signal some distance away- but they might have skewed our guess because of that.
3. Phone GPSes are surprisingly dishonest: frequently phones will report a high-quality lock when they in fact don't have it. We're actually working on improving detection for these cases in source data on the server side, we hope to be able to make some improvements (discarding high-confidence, low-accuracy observations) in the near future!
Cheers, and thanks for your interest!
There are a lot of items that can effect this, so I'll try and give a framework for all of it here, and we can drill down on individual items:
1. Locally, you store your observations (you can see dots when you select an individual network) and a "best" location in the network table (we don't do any estimation on the client currently)
2. When you upload, you send those observations to be incorporated into the database this takes place via a process probably best called "weighted centroid multilateration." - just means "we estimate the probable location using an average of locations - but the "weight" of each location in the calculation is based on the square signal strength"
if you've done a good job detecting the network accurately on your handset, your local record will probably be great, but other observations in the database get factored in, and drag things off course.
There are a few possible causes of this:
1. moving the access point: We do some statistical analysis, but if the AP was located elsewhere before, it takes an accumulation of data to "snap" it to the new location.
2. High-powered wardriving rigs: someone driving a few streets over with a directional antenna and amplifier might have registered the point with a really strong signal some distance away- but they might have skewed our guess because of that.
3. Phone GPSes are surprisingly dishonest: frequently phones will report a high-quality lock when they in fact don't have it. We're actually working on improving detection for these cases in source data on the server side, we hope to be able to make some improvements (discarding high-confidence, low-accuracy observations) in the near future!
Cheers, and thanks for your interest!
In my city, there was just one run as of yesterday. I did a couple yesterday, adding ~2000 spots. All of them were new. Some of them, whom I know their actual location, are off by 300m, and they show up on the client OK, so it wasn't a GPS fix issue.
Ps trying to post an example BSSID, but having a hard time searching through the mobile web page.
Ps2. Added a screenshot from the client. I guess green dots are observations, but -geezzz- do they look strange to me...
Ps trying to post an example BSSID, but having a hard time searching through the mobile web page.
Ps2. Added a screenshot from the client. I guess green dots are observations, but -geezzz- do they look strange to me...
- Attachments
-
- QuickMemo+_2017-08-05-15-59-05.png (176.11 KiB) Viewed 27729 times
Those radial lines are consistent with a common GPS failure we see.
if you look at the points, I think you'll find that they have excellent signal and accuracy according to the wifi/GPS, but a timestamp of 1970-01-01 00:00:00.000 - which means that while the GPS is claiming to be accurate, it's actually failing.
We'll start discarding these observations on the server side, which should leave only the accurate observations for those points.
if you look at the points, I think you'll find that they have excellent signal and accuracy according to the wifi/GPS, but a timestamp of 1970-01-01 00:00:00.000 - which means that while the GPS is claiming to be accurate, it's actually failing.
We'll start discarding these observations on the server side, which should leave only the accurate observations for those points.
Return to “WiGLE Project Suggestions”
Who is online
Users browsing this forum: Ahrefs [Bot] and 1 guest