<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 2, 2018 at 2:22 PM,  <span dir="ltr"><<a href="mailto:samuk@disroot.org" target="_blank">samuk@disroot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So thinking about the limitations of mesh networks in general, and wondering how your LoRa network would scale.<br>
<br>
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.<br>
<br>
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?<br></blockquote><div><br></div>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. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div></div></div>