So, I believe I have read that the AREDN SW is compatible with the Ubnt OS, by that I mean I could set up a backhaul using Ubnt OS and link to local nodes using AREDN - correct?
If so, and I use 3Ghz backhaul, using a freq within ham band, would I identify backhaul with my callsign or is that not permitted/necessary.
tx Ron K7OPA
If so, and I use 3Ghz backhaul, using a freq within ham band, would I identify backhaul with my callsign or is that not permitted/necessary.
tx Ron K7OPA
The AirFibre does not support being deployed unencrypted. Its user interface mandates that you must set encryption on the link (unknown if there is an unsupported way to override that from the CLI, no one I know of has had the funds to test it). The other AirOs devices don't have this limitation.
If run on ham bands you would indeed need to identify over the link. The simple method would be to run a cronjob on the AirOS device.
We have a feature request being worked on to officially support a 'backhaul' network (most have been backhaulding the dtdlink which is a bit fragile as it can only support 10% packet loss) I think I need to take a note back and say we should probably have this 'new' backhaul support auto-identify the node for users (I know I thought about it a year ago when the thought first came up but I forgot to spec it as a core requirement now that we started working on it) If I put that on the support list it would prevent the need to put a job on the AirOs device and make it cleaner.
If you do happen to test disabling encryption on the AIrFibre we certainly would like to hear the results, I know a number of people who are interested in the devices for backbone links but the encryption restriction has halted them,
If the desire is the run the AirFiber 5GHz model over ham bands. then the encryption would have to be disabled.
Part of the magic of the AirFibers is how the GPS is used to time the transmitter. Is there any special requirement from the driver to make this work? Or is this magic done in hardware, so the driver doesn't need to care?
The GPS access is both at the kernel level and standard serial port feed of the GPS data to applications. (side note, I've been loading gps packages and looking at the RocketM5-GPS under AREDN when I can slip in a few minutes recently.) Most of the magic for the AirFibre would be Ubiquiti proprietary and done in software with the linux platform. However, it appears the encryption may be done in hardware (can NOT turn on/off) per user manual.
https://dl.ubnt.com/datasheets/airfiber/UBNT_DS_airFiber_HDD.pdf:
The 24 GHz stuff will not do long range. That is a high enough frequency that water vapor starts to cause problems. They consider 13 kM to be *extreme range* at that frequency. Whoopee.
The AF-5X is pretty interesting. It can do long range and/or high throughput. It is supposed to have split frequency operation*
It is not that expensive considering the features - especially if you avoid putting up an intermediate tower somewhere.
http://www.nasdaq.com/press-release/ubiquiti-airfiber-sets-new-world-record-for-long-range-wireless-broadband-20160629-00972#/ixzz4DQX8K5XI
Encryption - as I understand it - hams can run an encrypted link if they post/publicize the encryption key(s) so that they can be readily found. Perhaps AREDN can have a section where all these keys can be listed as required for FCC compliance ;-)
There is still the issue of FCC-ID if you are running a master/slave protocol.The slave (station) cannot send a beacon and may not be considered to ID properly. I think I read that Ubiquiti no longer allows custom scripts to run under OEM firmware.
* the present version of the operating manual refers to cases where the transmit and receive frequencies are different. But, in the setup, says that you always make the TX/RX frequencies the same. I am not sure why that is - maybe waiting for firmware update/FCC certification?
Sadly, I don't see AF-5X on the openwrt list of compatible devices. But we can use these devices with part 97 licensing on the channels functional under AirOS. Then run the mesh over the top of the AF-5X bridge-link (as if it was a cat5 cable and DtDlink between two mesh nodes).
Joe AE6XE
What's your specific need for links greater than 50-60 miles?
Andre
Being here in rural Arizona we are finding it difficult to locate accessible high ground to link, for example, Phoenix to Prescott. We are really interested in providing a solid path for these two counties (Maricopa and Yavapai) and hopefully expand outward in the future.
Due to the terrain and the population dispersal we are beginning to see Arizona as potentially multiple separate 'islands' of mesh nodes with fairly long distances between them. The more options we have for long but stable backhauls gives us more flexibility. We are taking the position that this is primarily for worst case disaster/ emergencies and so are not even considering tunneling in our thinking.
Sorry to be so uninformed but I am not quite sure how the AirOS and AREDN combo can work. Do we have to be a commercial operation to utilize the nodes using AirOS, etc.??
I don't dispute it gives one more flexibility. It seems though, you could easily build out coverage for populated areas with the devices we already have. In So. Cal, we are building a San Francisco to Tijuana network with links up to 50 miles and more.
As Joe was saying... If you really need longer links, then you can use a pair of AF5X and AirOS in the Part 15/97 overlap channels. The AirOS link can be configured to look like an Ethernet cable to the AREDN nodes connected to the link endpoints. We utilize AREDN DtD to do this.
Andre
Also, am I correct that you would need an additional piece of equipment (AR or switch) to implement the DtD?
Also did not realize that the DtD is there, waiting for a connection, and does not have to be accessed via a port on the switch.
Slowly getting educated - thanks for the patience.