[DisasterRadio] Using ESP32 WiFi mesh as local 'backbone' of preference?

[Marc Juul]

On Tue, Jan 2, 2018 at 2:22 PM, <samuk at disroot.org> wrote:

> So thinking about the limitations of mesh networks in general, and
> wondering how your LoRa network would scale.
>
> I'm guessing that in common with WiFi mesh reducing the traffic would
> help, particularly if you ended up with a fairly high node density and a
> well-used & congested network.
>
> So I was wondering if it would be possible to pass off local traffic to a
> WiFi mesh? (Run on the same hardware) So if I want to communicate with my
> neighbour two streets away it goes over WiFi, if it's someone on the other
> side of town it would go over LoRa?
>

Yeah this is a good idea and is something we're planning to support. If
each node had multiple software defined radios capable of a very wide
frequency range/bandwidth and 360 degree high-gain phased array
multi-frequency antennas then with each node added to the mesh the nodes
could auto-detect that the distance between them had decreased and switch
to a high-frequency and thus increase the bandwidth. In this scenario each
node added to the mesh increases total mesh bandwidth, though
latency-sensitive traffic would have to be routed differently to minimize
multi-hop latency. In the absence of such perfect mesh nodes we can at
least get closer to the ideal node by adding multiple radios and
supplementing a long-range low-bandwidth radio like the LoRa chips with a
shorter-range high-bandwidth radio like WiFi is a great way to do this.

I am planning to make the disaster.radio firmware auto-detect the presence
of existing mesh routers from the People's Open Network and act as wifi
clients instead of wifi access points whenever such a network is present
and has internet. This solves your use case and also makes it easier to use
disaster.radio nodes because you now don't have to manually connect to the
disaster.radio hotspot: You can simply access the disaster.radio node from
the normal wifi mesh. If the wifi mesh nodes loose power then the
disaster.radio node will continue to operate as an access point. Sending
all disaster.radio traffic to every wifi mesh node with a connected
disaster.radio node should be simple enough. It would be even simpler if
our mesh supported IPv6 multicast but alas we have not yet added multicast
routing support.

The remaining issue is how to power the mesh in a disaster scenario. One
idea is to bundle a low-cost emergency power solution with each wifi mesh
node: A ziplock containing a long cable for hooking a mesh node into a car
battery (with a small circuit for preventing reverse-polarity and
preventing discharging the battery so low that it won't start the car) and
laminated instructions. This should allow people to power their nodes using
the convenient gasoline generators sitting on every street which would be
enough for the short term immediately following a disaster. Unfortunately
this solution requires active intervention from lots of people who might be
slightly distracted. Any other solution we've come up with requires
expensive solar panels / wind generators and batteries that need to be
installed, preferably by someone who knows what they're doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/disasterradio/attachments/20180104/121021b6/attachment.html>