WiGLE.net

I'm not quite sure how to pose this question; please bear with me.

I'm not new to wardriving, but I'm new to having a GPSr with me to do it. I have my work laptop (Dell D630 w/Dell 1395 wifi card) set up with Netstumbler connected via serial to a Magellan Sportrak Map. No problems with this setup so far.

My question is this. Is there a program out there that will generate a transparent "signal radius" overlay for a map (google earth, google maps, anything)?


My thought is this. By using the co-ordinates where you first detect signal, and the co-ordinates where you last see a signal, you have a straight line - a chord on the circle. Use that distance to formulate a square with sides whose length is the distance between "signal found" and "signal lost." Using this square, generate a circle that touches the four corners of the square.

This circle would be roughly equivalent to the radius of the signal.

My goal with this is to take the data and overlay it as a transparency over a map just to see how "covered" my hometown is.

I'm a technician, not a programmer - I don't know how hard this would be to implement.

Search the forum here for Netstumbler and Google, there are several programs/sites that will put Netstumbler points on maps. I don't know about drawing range circles with Netstumbler, I've never used it.

If you are willing to learn about Linux a little, Kismet includes a program called Gpsmap that will draw range circles based on your wardriving. Using two points as you mentioned is very inaccurate for making range circles. The nature of wifi is very short wavelengths, that are easily blocked and deflected by nearby metal objects.

Here's an example. Say that you have an AP sitting on a desk, a fairly common situation. In the kitchen may be a refrigerator. In another room there may be a big metal filing cabinet. Any object like this will substantially shield the AP in that direction. A real range circle is usually a blobby, non-round shape.

That said, Gpsmap can still produce good results. If you drive around and around many times (to collect lots of data, not just a 'signal acquired' and a 'signal lost') Gpsmap can draw a blobby, non-round area around each AP. The catch is, to be anywhere near accurate, you have to drive 360 degrees (best scenario) around all the APs you want to map. Picking them up on the interstate a block away will make perfect circles based on when you first/last saw them. These circles will be pretty inaccurate as to each APs actual coverage.

Still, even with casual wardriving, Kismet can make some approximations. Here are two that I made from my driving. This one is Gpsmap drawing overlays on a US Census Tiger map. These maps come out with the US Census, I guess when they do a census (every ten years?). They are not updated, new construction will not be shown. This map is zoomed out pretty far, it covers about ten miles. Only the largest/strongest/best elevation APs show a range circle at all.



The next map is of a much smaller area (an airport), and even though there is a lot of overlap, I was able to back off the opacity enough to show approximate coverage. I had it overlaid onto a Terraserver map of my drive. In both maps, the blue line is the path that I drove (not seen very well in the first one).




I don't have any maps handy of doing an accurate (blobby, non-round) map. These are all of casual drives, and not very accurate at all.

Gpsmap has lots of options. You can juggle the size of the dots and lines. In these two maps, the APs are shown in random colors, to make then stand apart a bit. You can choose to color them based on SSID, encrypted or not, or channel number.

Gpsmap can also feather the opacity based on the signal strength. This is the most accurate, though in an area with many APs, can quickly get lost. It can filter by APs to be included or excluded, so you are able to get a fairly accurate range circle of any given AP. The only problem is that you have to drive it a lot, and be willing to exclude nearby ones to see the results the best.

EDIT: Idiot Alert.... and the program is of course named Gpsmap, not Kismap.

Picking them up on the interstate a block away will make perfect circles based on when you first/last saw them. These circles will be pretty inaccurate as to each APs actual coverage.

I understand what you are saying. Most of it I knew, but was kind of ignoring, figuring that the implementation would be rather difficult.

I've been a Linux user on and off for many years (a dabbler), I just don't have a good laptop that I can work with. I found a spare drive for my company laptop that I might put a distro on and run with, and just swap drives in and out to change OSes.

I like your maps - thank you.

The "inaccurate circles" you describe - do you have any insight into how they are calculated? Does KisMap use some method similar to what I suggest, or does it do so wildly different?

Yes, on a simple level, it does it exactly as you described, except not on one "found it" and one "lost it" bit of information. It extrapolates signal strength from all the packets it has, and builds an imaginary (and incorrect) range circle based on the farthest away that it ever saw the AP.

Kismet does an amazingly good job on placing the AP accurately on a small number of packets. It just can't accurately define range circles without have a lot of packets to work with.

Drawing odd polygons to make more accurate range circles and feathering color to indicate the signal strength just takes lots and lots of packets, to give it any degree of accuracy.

You might experiment with some of the liveCD distros that include Kismet so you don't have to swap hard drives around. If it's a work laptop, you might want to consider getting a junker to wardrive with. Vehicle life can be hard on a laptop. You can get a P2 450 laptop for practically nothing, which can run Kismet just fine.

Hadn't really thought of LiveCDs. I think think about DSL in QEMU, but didn't think it would work well running through QEMU.

I've got a 160 GB drive in my work laptop, and a spare 40 GB now. I'm going to *NIX the 40 GB probably this weekend and see what I get.

http://code.google.com/p/omwpt/

or

http://www.qsl.net/kd2bd/splat.html

Kismac knows an a bit more sophisticated render mode for QoS-maps

it uses mutiple point (actually all points it found and draws smaler areas for it (not colored) so you can just see where you have had reception and where not (but as you can filter for free nets or WEP oder WPA you can also draw more helpful maps)

rendering in HQ takes a lot of time on my C2D 2.1GHz macbook

Open networks in my area

This is a new site that might be of interest on this thread. You can do one free map. It uses Radio Mobile on the back end. www.mywificoverage.com
We have posted a quick how to video here http://www.youtube.com/watch?v=QmcMaC8Rw_Q

The catch is, to be anywhere near accurate, you have to drive 360 degrees (best scenario) around all the APs you want to map. Picking them up on the interstate a block away will make perfect circles based on when you first/last saw them.

Unfortunately, WiGLE doesn't seem to have a good, reliable AP positioning algorithm. For an obvious specific example, consider Vancouver Washington, at NE Seasons Ln, just north of the intersection between NE 18th and NE Seasons Ln. It's a winding road generally going NNE, away from buildings for a few hundred feet, but nevertheless surrounded by housing further away. I scanned this entire area, multiple times, and you can see the result. Notice from the AP's positions that they are set in grassy fields where they could not possibly be located.

Unfortunately, WiGLE doesn't seem to have a good, reliable AP positioning algorithm. For an obvious specific example, consider Vancouver Washington, at NE Seasons Ln, just north of the intersection between NE 18th and NE Seasons Ln. It's a winding road generally going NNE, away from buildings for a few hundred feet, but nevertheless surrounded by housing further away. I scanned this entire area, multiple times, and you can see the result. Notice from the AP's positions that they are set in grassy fields where they could not possibly be located.

As far as I am aware WiGLE determines the locations by assuming the inverse square law to be true which strictly speaking is only correct if the propagation medium is entirely uniform, the real world however doesn't happen to conform to the theoretical model since at minimum the propagation medium includes a combination of air in some directions a big rock in the other direction and a surface covered in an array of organic and inorganic objects of all manner of descriptions.

Of course all this assumes that the measurement position for each data point is itself accurate, urban areas present problems for GPS due to multipath echo since they are full of radio reflectors from the frames of buildings and other static reflectors and worse large numbers of mobile reflectors like cars determining which of the many reflections of the satellites signal is the true one is not exactly simple it's not like you can simply assume that the strongest or quickest arriving copy of the signal must be the correct one or at least if you do there is a probability that you are wrong a reflection from the car in the lane next to yours may well be stronger or seem to arrive earlier than the true signal if you happen to be sat in the shadow of say a building and the reflection isn't. But in fact if you go on that one then your timing will be off by at least twice the distance between the GPS receiver and the reflecting object as you can imagine when all the signals are coming from half a dozen or more satellites in different directions with potentially thousands of paths for each and every one of them to reach your antenna GPS tends to be somewhat prone to drift in urban areas.

[quote][/quote]

32894156 wrote:
""Unfortunately, WiGLE doesn't seem to have a good, reliable AP positioning algorithm. For an obvious specific example, consider Vancouver Washington, at NE Seasons Ln, just north of the intersection between NE 18th and NE Seasons Ln. It's a winding road generally going NNE, away from buildings for a few hundred feet, but nevertheless surrounded by housing further away. I scanned this entire area, multiple times, and you can see the result. Notice from the AP's positions that they are set in grassy fields where they could not possibly be located.""

"As far as I am aware WiGLE determines the locations by assuming the inverse square law to be true which strictly speaking is only correct if the propagation medium is entirely uniform, the real world however doesn't happen to conform to the theoretical model since at minimum the propagation medium includes a combination of air in some directions a big rock in the other direction and a surface covered in an array of organic and inorganic objects of all manner of descriptions."

I realize that your statement sounds like a good description of the ideal situation. But I believe that WIGLE.NET simply does not implement an accurate version of this location process. I gave a specific example, an easily-found area which is almost entirely flat terrain, where it is clear that there are no WiFi emitters, and where there are indeed emitters relatively far away from the locations that appear to be shown as the mapped source of the RF. Therefore, I believe that WIGLE simply hasn't, and doesn't, actually TEST the proper operation of their algorithm.