Hi everyone
Please take this as a constructive question, because that is what I intend. I am enthusiastic about amateur radio mesh technology and its application to public service and emergency communications. I am deeply grateful for the hard work and creativity of the AREDN team. I am currently operating a two-node mesh in Charlottesville, VA, and actively seeking sites to expand and enhance the network. Our county public safety communications folks are excited about the possibilities.
My question: what is the future for mesh hardware? The Ubiquiti devices that are supported by the AREDN current release (and those in the next RC) are already legacy as far as Ubiquiti is concerned. They have moved on to the next generation (AC). I presume from the rate at which new devices are supported by AREDN that it is getting harder and harder to do.
My fear is that after all the work we have all done to develop software, design and deploy networks, and educate hams and non-hams about the potential, we are rapidly approaching a hardware dead end.
Where do we go from here? What can we do to expand the range of hardware available for deployments? What does the future look like to the AREDN developers?
Again, this is not a criticism of . It seems to me that we have a major challenge and I'm interested in finding answers.anyone
Many thanks. Mike
Please take this as a constructive question, because that is what I intend. I am enthusiastic about amateur radio mesh technology and its application to public service and emergency communications. I am deeply grateful for the hard work and creativity of the AREDN team. I am currently operating a two-node mesh in Charlottesville, VA, and actively seeking sites to expand and enhance the network. Our county public safety communications folks are excited about the possibilities.
My question: what is the future for mesh hardware? The Ubiquiti devices that are supported by the AREDN current release (and those in the next RC) are already legacy as far as Ubiquiti is concerned. They have moved on to the next generation (AC). I presume from the rate at which new devices are supported by AREDN that it is getting harder and harder to do.
My fear is that after all the work we have all done to develop software, design and deploy networks, and educate hams and non-hams about the potential, we are rapidly approaching a hardware dead end.
Where do we go from here? What can we do to expand the range of hardware available for deployments? What does the future look like to the AREDN developers?
Again, this is not a criticism of . It seems to me that we have a major challenge and I'm interested in finding answers.anyone
Many thanks. Mike
A big list of candidates that we can consider for the future can be found at this link below. Devices that are Atheros-Qualcomm based chipsets running ath9k (802.11n) and ath10k (802.11ac) wireless drivers are the candidates. These are opensource wireless drivers and we can modify to extend for part 97 channels. This is going to be the chips AR71xx, AR72xx, AR9xxx and QAC9xxx generally. Nothing that a bit of sweat and time can't solve to get under support.
https://openwrt.org/toh/views/toh_admin_modem_wlan
The Ubiquiti lines with Rocket AC models are using what is advertised in the literature as proprietary technology. I wouldn't expect to see these newer lines in our list -- black boxes to opensource.
Also, note that moving to 802.11ac is not necessarily going to give improved performance. But, I'd want to test to know for sure. The higher data rates are achieved by using more than 2 polarities and channel widths up to 160Mhz. Don't think I've ever seen a dish with more than V and H dual polarity before. This large channel width is actually counter productive with the SNR levels of long distance links. the same limited power stretched over that bandwidth would yield lower SNR, it wouldn't work past a certain (not that far) distance, not enough SNR in a give OFDM bin to be decoded. The only thing I've found that might add benefit to move to 802.11ac devices is the ability to transmit different data on each polarity that is intended for 2 different neighbor devices at the same time. But this may just half the rate compared to using all the energy to a given neighbor at a time.
The biggest reason IMHO, to move to newer devices, is with progress, the firmware packs in more and more capabilities and we need more and more RAM.
Joe AE6XE
Good and fair questions to ask.
First off, while the Ubiquiti AirMax line is called Legacy over at Ubiquiti that is only because it is not the newest set of products to be created. The AirMax M line has just gone through a hardware refresh (XW boards) which was a complete overhaul of the hardware with a different CPU and other board changes. This line isn't expected to go end of support any time soon from Ubiquiti with WISP's still standing behind it as it meets deployment needs.
After that as Joe mentioned there is consideration for other vendors, most the times the issue is at AREDN we just don't know about a device, so many routers are not suited for AREDN (they are intended for inside use only on a desk) wading through the list of products vendors put out isn't a high priority, but if someone brings forward a sutible option it can be evaluated further to see if it hardware meets the needs.
A large part of the delays have been internal to AREDN and are not so much hardware itself related. For example what stopped some of the XW hardware was the fact we couldn't get AREDN to load via TFTP for recovery (we could load it via AirOs however but if you can't recover a unit its a dangerous situation and wouldn't meet AREDN specs) a fix for that had been proposed a year and a half prior, but due to incorrect testing it was dismissed prematurely and only re-visited a year and a half later when more evidence showed it had to be the correct option.
Another slow down to hardware adoption is how poor the code in the backend is right now, it is very much tied to being hardware and core OS specific, (something I want to see change, but that is not an easy project (will require a UI re-write) which can slow down adopting new vendors as it at times requires re-writes in the backend to make it work.
Tack on slugbug (which had a 3 month delay due to faulty testing by the developer in charge of it at the time) and that slows us down ever further on adding new hardware support.
After that we always have the option of creating our own vendor if we need to, but hopefully it wont ever come to that. Worst case someone buys up a container of Ubiquiti hardware and resales it
So hardware availability is a fair item to keep an eye on, but its not something I expect to stop us in the next couple years, and after that I expect we will have more options open to us again.