[Server-devel] [OLPC Networking] RSSI value questions

[Oliver Mattos]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/server-devel/attachments/20080404/d5aa83b0/attachment.htm