Re: [Server-devel] [OLPC Networking] RSSI value questions
I realized after chatting with Ben that my assessments were wrong about this being a feasible project for the summer. The main issue is still that the radios dynamically adjust their gain to increase RSSI between nodes that are farther apart. I do have ideas that may be possible to overcome this, but some experimentation would be needed. Depending on how often the gain is adjusted and in what ways, inferring the gain may be possible. According to the link below, the setbcnavg command can be used to set the weighting factor for calculating RSSI, but I'm not sure how this affects connectivity between nodes. If setting the value as high as possible or as low as possible causes nodes to disappear from a radio's view, then direction is easy to discover by having all XOs step through the values and recording which nodes come back within view and when. I think this would provide direction, unless the command doesn't affect connectivity. I'll post the rest of my thoughts later, as I need to finish some other work. Unfortunately, I don't have the equipment necessary to test out any other theories, nor do I feel I have the technical knowledge to see this project through, so I'm afraid this is where I get off the bus. Thanks for all of your input. http://wiki.laptop.org/go/Wireless_Driver_README - Crawford ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
I'm not very concerned about FUD (fear, uncertainty, and doubt) being spread by providers of a competing operating system. The inclusion of GPS data into the system would be purely optional and currently and the XOs do not have GPS capabilities. A software implementation COULD be put in the system that would contact a server that uses the XO's IP to identify the country and possibly the city a machine is connecting from, but since the software is open-sourced, it would be easy to remove from the system. Regardless of all this, what I'm proposing is also completely optional an available for anyone to use if they so choose. My application would not be contacting systems outside of the network that the machines are running on, so any worries concerning privacy and control would be meaningless. Thanks for your concern, though, and I appreciate any suggestions you may have that would comfort people's fears concerning privacy, especially when it comes to the program's use outside of the US. - Crawford ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
Just to address a few other issues/questions raised... If there is only one antenna on a server, then as long as 3 other nodes are considered relatively stationary, I think their 2D locations can be deduced from each node's measurements of the other 4. An easy to use interface can allow the user to orient the generated map with respect to whatever reference point they like; ideally, the final program would allow for a floor plan of the building to be displayed underneath the topological mapping. With respect to granularity of different measurements, I think inaccurate measurements can be averaged over time, since some would necessarily be more accurate than others, allowing for a more accurate map as time passes. Ben stated that the dynamic gain isn't available in user space. I'm just wondering if there's a way to passively determine the gain and if this would even be helpful in determining location. Any ideas? I'm not so experienced in RF tech that I can come up with how knowing the gain would be useful, but if it is useful, then I think it'd be easy enough to figure out some sort of indicator that's relative to the fluctuations in whatever measurements the gain affects. Again, let me know if I'm that kid out in left field wearing his glove on his head and facing away from the bases... I feel pretty optimistic about the feasibility of this kind of project. There seem to be a few good measurement techniques to go by, as well different methods to compute the data. If the XOs pitch in and tell the server where they think other nodes and themselves are, relative to each other, that would provide another set of input to include when averaging out measurements. For those of you that would like some light reading on the topic of modeling this information and computing it, here are a couple of papers that attempt to do similar things with GSM signals and neural networks: http://ieeexplore.ieee.org/iel5/9603/30336/01394788.pdf?isnumber=30336prod=CNFarnumber=1394788arSt=+133ared=+136arAuthor=Debono%2C+C.J.%3B+Buhagiar%2C+J.K . http://ieeexplore.ieee.org/iel5/4222741/4222742/04222782.pdf?arnumber=4222782 - Crawford ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
On Thu, Apr 3, 2008 at 8:55 PM, [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008, Michail Bletsas wrote: Let's not forget that you need some fixed reference points. In commercial systems, the locations of the access points are well known. In ad-hoc networks the best that you can hope for is a topological map. the assumption was that the measurements are being done from fixed points. either the school server antenna locations, or the known locations of specific assistant laptops. without known locations you can't do much. David Lang Suppose you have your initial fixed points with known locations (server antennas and any standalone repeaters). Wouldn't you be able to identify temporarily stationary points that, after deducing their locations, could be deemed additional listening stations? Once a node is identified as such, any additional measurements it provides can be deemed credible and then used to determine the locations of less stationary nodes. As David said, some commercial solutions require calibration by walking a node around the premises. I think this has been shown to be fairly accurate for a single AP's coverage area without having to add additional APs to the network. Most of the comments have been along the lines of using single measurements to identify distances of separation. I think a better solution would be to include the mesh's routing table, packet arrival times, etc. along with RSSI measurements. If you generate one or more likely maps from each and then average them out, I suspect you'd get a fairly accurate estimation of where everybody is. Coupled with preloaded measurements from around the premises, a viable solution seems likely. Is the XS capable of installing/pushing applications onto XOs automatically? If so, that allows for a very easy way to let the XOs participate in the process without bothering users, as well as distributing some of the number-crunching to take make things easier for the XS app. Am I displaying complete naivety here about everything involved or does any of this stuff make sense to you guys? -Crawford ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
On Thu, Apr 3, 2008 at 8:55 PM, [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008, Michail Bletsas wrote: Let's not forget that you need some fixed reference points. In commercial systems, the locations of the access points are well known. In ad-hoc networks the best that you can hope for is a topological map. the assumption was that the measurements are being done from fixed points. either the school server antenna locations, or the known locations of specific assistant laptops. without known locations you can't do much. David Lang Suppose you have your initial fixed points with known locations (server antennas and any standalone repeaters). Wouldn't you be able to identify temporarily stationary points that, after deducing their locations, could be deemed additional listening stations? Once a node is identified as such, any additional measurements it provides can be deemed credible and then used to determine the locations of less stationary nodes. As David said, some commercial solutions require calibration by walking a node around the premises. I think this has been shown to be fairly accurate for a single AP's coverage area without having to add additional APs to the network. Most of the comments have been along the lines of using single measurements to identify distances of separation. I think a better solution would be to include the mesh's routing table, packet arrival times, etc. along with RSSI measurements. If you generate one or more likely maps from each and then average them out, I suspect you'd get a fairly accurate estimation of where everybody is. Coupled with preloaded measurements from around the premises, a viable solution seems likely. Is the XS capable of installing/pushing applications onto XOs automatically? If so, that allows for a very easy way to let the XOs participate in the process without bothering users, as well as distributing some of the number-crunching to take make things easier for the XS app. Am I displaying complete naivety here about everything involved or does any of this stuff make sense to you guys? -Crawford ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
RSSI value questions
I'm looking to build an application through Google's Summer of Code for the school server that uses wireless location detection methods to monitor and approximate the physical location of all nodes within the mesh. Unfortunately, I can't seem to find any information on whether or not the network allows the server to poll nodes within the network for RSSI measurements the nodes have made between themselves and all others within their range. Is this something that the networking firmware/drivers even allow? If not, is it functionality that could be requested of Marvell to provide? If so, how accurate are the RSSI measurements and to what decimal precision are they available? Also, what kind of interest within the community is there for this kind of application, if any? I think the idea at least has interesting uses as far as securing the network goes, but I'd really like to know what everyone actively using and/or developing for the systems thinks. -Crawford Comeaux ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
