|
Size: 1279
Comment:
|
Size: 1811
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
|
Currently the maps.personaltelco.net data displays a pin point for each AP location. What would it take to display an empirical graph of the power output in order to see |
Currently the WnDB data display consists of a pin point for each AP location. How do we display an empirical graph of the power output in order to see |
| Line 5: | Line 5: |
|
The raw data required comes from a gps receiver and correlated with power output readings from a wifi card. This can be recorded by NetStumbler, dstumbler or kismet. Another approach would be to hack [http://nocat.net/download/wpm wpm] (the wireless power meter) or use linux wireless-tools and gpstrans directly. |
The raw data required comes from a gps receiver correlated with power output readings from a wifi card. This can be recorded by NetStumbler, Dstumbler or Kismet. Another approach would be to hack [http://nocat.net/download/wpm wpm] (the wireless power meter) or use linux wireless-tools and gpstrans directly. |
| Line 9: | Line 11: |
| Latitude Longitude SnR | |
| Line 11: | Line 14: |
|
The data set consists of measurements of at least a signal to noise ratio (or some other measure of AP power output) for each gps coordinate. |
The data set consists of measurements of signal to noise ratio (or some other measure of AP power output) for each gps reading. |
| Line 14: | Line 17: |
|
The next step is to use this data to produce a rough approximation of AP coverage. One way to do this is outlined at University of Kansas [http://www.ittc.ku.edu/wlan/procedure.shtml "ITTC"] Wireless Network Visualization Project. In order to compute the Inverse Distance Weighted |
The next step is to use this point map data to produce a rough surface approximation of AP coverage. One way to do this is outlined at University of Kansas ITTC Wireless Network [http://www.ittc.ku.edu/wlan/procedure.shtml "Visualization"] Project. In order to compute the Inverse Distance Weighted |
| Line 19: | Line 24: |
| [http://www.netlib.org/toms/790 Netlib]. The beginning of the file contains a lot of test code |
[http://www.netlib.org/toms/790 Netlib]. The beginning of the file contains a lot of test code |
| Line 21: | Line 27: |
|
Outstanding questions: * How quickly does AP coverage change? The coverage will change based on weather so we may want to track when the data was collected. This leads into collecting several maps for a location that record performance in different seasons. Or perhaps some sort of averaging of all data available depending on how much it varies. * How much data is required for a reasonable map? Long term ideas: Do mapping as part of a Public Node Audit. Possible use for the SatelliteTruck. |
Currently the WnDB data display consists of a pin point for each AP location. How do we display an empirical graph of the power output in order to see what area a particular node covers?
The raw data required comes from a gps receiver correlated with power output readings from a wifi card. This can be recorded by NetStumbler, Dstumbler or Kismet. Another approach would be to hack [http://nocat.net/download/wpm wpm] (the wireless power meter) or use linux wireless-tools and gpstrans directly.
Latitude Longitude SnR <Insert some sample data here>
The data set consists of measurements of signal to noise ratio (or some other measure of AP power output) for each gps reading.
The next step is to use this point map data to produce a rough surface approximation of AP coverage. One way to do this is outlined at University of Kansas ITTC Wireless Network [http://www.ittc.ku.edu/wlan/procedure.shtml "Visualization"] Project. In order to compute the Inverse Distance Weighted interpolation I plan to use a modified Shepard's Method routine from [http://www.netlib.org/toms/790 Netlib]. The beginning of the file contains a lot of test code so search for PRECISION FUNCTION CS2VAL for relevant comments.
Outstanding questions: * How quickly does AP coverage change? The coverage will change based on weather so we may want to track when the data was collected. This leads into collecting several maps for a location that record performance in different seasons. Or perhaps some sort of averaging of all data available depending on how much it varies. * How much data is required for a reasonable map?
Long term ideas: Do mapping as part of a Public Node Audit. Possible use for the SatelliteTruck.