[Server-devel] [OLPC Networking] RSSI value questions
david at lang.hm
david at lang.hm
Sat Apr 5 01:49:35 EDT 2008
On Fri, 4 Apr 2008, John Watlington wrote:
> A guiding design principle for any XO activity is that it be designed
> to work without a school server. Learning doesn't stop at the school gate!
>
> The only thing special about an XS (or any access point) is that we can
> know (absolutely) where it is. Whatever system is designed should
> allow arbitrary peers to declare that they know where they are (and
> should handle the fact that some of them either lie or have a very hazy
> idea of where they are...) Perhaps an XS Active Antenna or Access Point
> is simply an example of a certifiably trusted position beacon.
>
> I still prefer the idea of using audio, a la Acoustic Measure by Ben or
> a three-D, multiple device version:
> http://web.media.mit.edu/~vmb/papers/AES05.pdf
> (longer version at http://web.media.mit.edu/~vmb/papers/DaltonMS.pdf)
> Research into less intrusive methods (using ambient noise, or sounds
> generated by the systems while doing other tasks, as the
> basis for obtaining the location information) is needed.
you could take three laptops and have them do acoustic measures from each
other and then work out from that.
I don't think it's worth trying to deal with system lieing about their
location (at least not for the first cut)
one thing to keep in mind is that each measurement has an error band
accociated with it, so as you get secondary positions and work out from
there the locations become less precise.
one question about the XO hardware. are the two antennas directly
connected inside the machine, or is there some way (possibly requiring a
firmware modification) to find the difference between a given signal
between the two antennas?
David Lang
> Cheers,
> wad
>
> On Apr 4, 2008, at 4:39 AM, Oliver Mattos wrote:
>
>> why exactly is an XS needed at all - what about just a mesh of laptops with
>> no XS. I agree then there are NO refrence points at all, so orientation
>> and world-position of the generated map can't be determined, but the rest
>> of the info still remains useful. The XS is simply another node - there is
>> no reason it should be required.
>>
>> In terms of an algorithm for calculating positions from a series of metrics
>> with no known points, the best I can think of is successive approximation.
>> Basicly, place all the nodes randomly on a map, attach "virtual springs"
>> between nodes that have connectivity, where the springs ideal length is
>> determined by the signal strength/other metric, and springgyness is
>> determined by the metrics margin of error, and then do a physics simulation
>> of where they all end up when released. Using that algorithm, multiple
>> types of metric can be used to generate the same map.
>>
>> After generating the map once, future generations would require many fewer
>> iterations of the physics simulation, therefore less processing time even
>> for big meshes, so it would probably be possible to update the map in real
>> time as new results come in.
>>
>> There are quite a few optimisations for the above, for example "replusion"
>> springs with a negative force could be used for nodes that are currently
>> close together on the map but have no connectivity. - that would provide
>> much more accurate mapping in sparse meshes where some laptops have 2 or
>> fewer neighbors.
>>
>> On Fri, Apr 4, 2008 at 7:06 AM, Ryan Crawford Comeaux
>> <crawford.comeaux at gmail.com> wrote:
>> 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=30336&prod=CNF&arnumber=1394788&arSt=+133&ared=+136&arAuthor=Debono%2C+C.J.%3B+Buhagiar%2C+J.K.
>> http://ieeexplore.ieee.org/iel5/4222741/4222742/04222782.pdf?arnumber=4222782
>>
>> - Crawford
>>
>> _______________________________________________
>> Networking mailing list
>> Networking at lists.laptop.org
>> http://lists.laptop.org/listinfo/networking
>>
>>
>> _______________________________________________
>> Server-devel mailing list
>> Server-devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/server-devel
>
More information about the Server-devel
mailing list