I came across AREDN while researching solutions that exist for low-cost/power/mass/volume mesh networking solutions that can support TCP/IP, bitrates >=100kbps, and distances in the 10s or 100s of meters. AREDN seemed to check more boxes on my list than any other solutions (particularly with ease of setup and deployment). However, I've got some questions to confirm its suitability.
There's currently a challenge going on for technologies that operate in complex underground environments. Click the link to learn more, but short of entirely autonomous solutions, the challenge involves getting some communication to work 100s of meters into a cave, tunnel, or underground structure, between and to unmanned assets (beyond line of sight, but maybe line of sight between nodes if they end up in the right spots).
The first stage of the systems competition was in August, and teams had success using wireless mesh networking to communicate into a tunnel system. Multiple mobile robot platforms would act as nodes and could also drop off battery-powered nodes as they moved along (the competition runs are ~1-2 hours). On first glance and after a bit of reading it seems that AREDN would work for this kind of setup, but I'm hoping that the experienced users and developers here might be able to offer some thoughts.
- Would there be anything wrong (in the non-technical sense) with using AREDN for this on the 2.4GHz ISM/WiFi channels? Obviously AREDN is intended for amateur radio and so this would be a non-standard application, but from my reading of the terms, it seems like it would be okay.
- How would AREDN handle >10 nodes being colocated and all in range of one another (at the beginning of a run)? Would one expect uninterrupted communication with nodes as they spread out from there into a chain or tree?
- Among the cheap (~$50) and small ("pocket-sized") supported/nightly platforms, what would be the hardware recommendations? Would 2x2 MIMO be considered a "must-have" or a "nice-to-have"? I've been reading up on the Mikrotik hAP AC Lite RB952Ui-5ac2nD, the GL.iNET AR300M16, and the GL.iNET AR750 Creta. 5.8GHz WiFi support would be preferred so that close-proximity data offload and debugging could be done without burdening the mesh network. The Mikrotik hAP AC Lite seems to be preferred here over the AR750, but the 5V supply on the AR750 would be better for me. (And the alternative of 12V that's available to me seems to be associated with some flakiness on the Mikrotik?) On either of those, I'd do external antenna modifications. After reading the threads on the AR300M16, it seemed like great bang-for-the-buck (and no board mods), but it doesn't seem to as readily available or cheap as it was before.
- Are there better solutions out there for the rough environments and requirements I've described? Other solutions at all? Most of what I came across would be a lot more "hands-on" in terms of setup and deployment.
That ended up being a big wall of text, especially for a first post, so I'll stop here. Would appreciate any answers/comments/thoughts!
John
KM6IIX
BTW, I think it's wrong to link MikroTik to power issues. In fact, the benefit of MikroTik is that it works with 9-28V and sometimes up to 30V or more, depending. This is compared to Ubiquiti's strict 10-24V power input. I run all of my mobile Ubiquiti and MikroTik devices off of a 12V battery without issue.
If you really want to get good, proven 2.4Ghz AREDN nodes in a small battery-operated package, you could attempt to modify the PBE-M2-400 feedcone as I have done. That's a lot of work per node and requires some soldering skills and knowledge of building an adapter for your battery that corresponds with the Ethernet pins of Ubiquiti nodes and replacing the testpoint RF connectors with ufl connectors.
I built these lightweight devices for drones and mylar balloons to create my own high ground nodes (see image):
-Damon K9CQB
I will do a write up when I finally get a chance to knock it out.
-Damon K9CQB
Here's what I'd try first using AREDN...
I would configure dual 5GHz node relay-stations and leave them behind at strategic points navigating into the environment. Links going out in different directions of this station would be on different channels. In AREDN terminology, these are 2 nodes dtdlink'd together. In fact in 5GHz there's enough channels, every link would have a clear channel. Think of a bread crumb trail chain of these stations going out 20, 30, or more links -- how big is the rover... If you drop a station behind while it still has sufficient SNR with the prior station, then you will have a very high speed link-chain, think 65Mbps from end-to-end on 10MHz channels (or 130Mbps on 20Mhz) with very low latency, at these relatively short distances, like 20ms to 50ms end-to-end. Each link has uncontested use of the channel and all links can transmit data at the same time.
You could also drop small ipCams along the way, having one on the rover to see and make decisions. With this kind of setup and full use of the entire band, you could be streaming back probably up to 10 HD (<1Mbit streams). I've done this at community events streaming many video streams down this chain, it works. The key is to monitor snr of the prior link to drop a station behind, you'd begin to recognize what SNR levels are needed to sustain sufficient thoughput. With advanced usage, you could monitor and remotely change link channels along the way, to work around interference.
If looking at a solution where all these stations or nodes are on the same frequency space, the performance will not compare. Wireless channels are half duplex and only one node can transmit at a time. The protocols have to deal with hidden node issues, contention for the channel, and more. Limiting the solution to a narrow use of the available frequencies is at a disadvantage. It's the sharing of a given frequency space by many nodes, regardless of the protocols that introduces overhead and channel contention to deal with. The approach above, doesn't have to deal with these kinds of losses.
You definitely would want to use OFDM and MIMO technology (both in 802.11n used by AREDN), which mitigate multipath issues very effectively. 802.11n and AREDN rate selection will dynamically choose the modulation and coding scheme (MCS options) that optimize data thoughput for the real-time conditions.
Joe AE6XE
Joe (as usual) has good advice. If you string out a series of mesh nodes on the same frequency and same SSID, the OLSR system will try to minimize the number of hops and will prefer one really weak link to a double-hop strong link. When you have a good SNR (like 20 dB) on two successive links, chances are that the first and third node will hear each other weakly and the traffic will bypass the center node. (Of course, in a cave your mileage may vary ... a lot). Joe's suggestion forces the links to use that center (double) node.
A way to do this on a common channel is to change the SSID of each successive link. But you still have contention for the common frequency so it not as good. But on 2.4 GHz (outside a cave) it may be the only option.
This is a case where the Access Point / Client mode would be nice. You could use a client<->AP<->double-client<->AP<->client configuration and save on the number of radios (at the cost of slightly slower operation).
Ken
KE2N