You are here

Use of AirFiberX

16 posts / 0 new
Last post
K7OPA
K7OPA's picture
Use of AirFiberX
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
KG6JEI
The AirFibre does not support

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,
 

K7OPA
K7OPA's picture
thanks
Thanks for the reply.  We are looking at a 60 mile link and AirFibreX appears to be the best way to ensure a solid stable connection.  I do not have the expertise to know how to disable encryption.  
KF6NMZ
Wouldn't the exception be the
Wouldn't the exception be the AirFiber 24/24HD? It runs on frequencies that overlap with ham bands. So out of the box, encrypt or not, it is legal.

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?
AE6XE
AE6XE's picture
I've not looked at one of
I've not looked at one of theAirFibres, but anyone that wants to ship me one, I'll be happy to dig under the hood :) .   Theorizing a little on my part here...   The GPS sync is used for co-located nodes at the site to time so that the multiple "AP"s at the tower all xmit at the same time and then receive all at the same time.  This is so that one AirFibre doesn't transmit and trash the receive of another AirFibre.  Think of 80% downlink of internet content and 20% of the time RX from all the clients and pre-coordinated TX/RX slots.   The time control or governance is in the software driver of the Atheros chips we currently use.   This must still hold true with the AirFibre--these are all essentially SDRs.  

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. 
KF6NMZ
I've only used the AF24's.
I've only used the AF24's. There are only two channels to choose from for 24GHz. I know that Ubiquity has AP's with GPS specifically designed for collocating on a tower, but my impression was the AF's seem to take it one step further. Is this exactly the same as their collocating AP's but applied to PtP links or something slightly different? Either way, it would be nice to get support for AF's. There was a huge different in latency when we moved to AF's and turned on GPS. From a couple of ms to 0.485 - 0.538 ms.

https://dl.ubnt.com/datasheets/airfiber/UBNT_DS_airFiber_HDD.pdf:


TX and RX frames are completely concurrent and therefore do not consume excessive amounts of overhead, which typically happens in conventional TDD systems. Based on the ranging algorithm built into the air protocol, the airFiber radios use breakthrough HDD technology to calculate the propagation delay and know when each radio can transmit and receive, so they send packets in precise synchronization. The transmissions remain clear even though the packets cross paths half-way. GPS is used to trigger the airFiber radios to transmit at the same time; however, the primary benefit of GPS is that it enables the concurrency of TX and RX frames for co-location of master nodes (airFiber radios).

K6AH
K6AH's picture
How did oyu do so under Part
How did oyu do so under Part 97?  Did yoh manage to defeat the encryption?  Or are you running these under Part 15?
 
KE2N
KE2N's picture
X

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?

K7OPA
K7OPA's picture
AF-5X
As we separate groups mature in our learning and identifying legitimate emcomm needs for MESH it becomes more obvious to me that we need a broader range of equipment to choose from.  Kudos to all that have gotten us this far, I am just asking how we make the decision on which models to modify next?  I vote for the AF-5X :) ! 
AE6XE
AE6XE's picture
AREDN is built on top of
AREDN is built on top of other open source software with 1000s of people that contribute to all the building blocks.   Thus, these other open source components need to support the hardware to become a feasible candidate for AREDN consideration.    It's a safe bet that if the hardware is not in the list of compatible devices with OpenWRT or DDWRT, then there won't be an option anytime soon to turn it into an AREDN mesh node.   If it is in OpenWRT or DDWRT's list, then it's still not a given that we can get it working on part 97 only frequencies.   Some 802.11 drivers do not have the full source code available to tweak into part 97 channels or may be overly complex to figure out.

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
K6AH
K6AH's picture
Hi Ron,
Hi Ron,

What's your specific need for links greater than 50-60 miles?

Andre
 
K7OPA
K7OPA's picture
More is better??
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.??
K6AH
K6AH's picture
I don't dispute it...

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
 

K7OPA
K7OPA's picture
Andre - so you are using
Andre - so you are using Rockets with dishes for those long links?
Also, am I correct that you would need an additional piece of equipment (AR or switch) to implement the DtD?
K6AH
K6AH's picture
Rocket with RocketDish
Yes.  The Rocket with RocketDish (M3 in my case).  Two devices can simply be connected together with an Ethernet cable.  You would need a switch when there are more than 2 devices connected DtD .  
K7OPA
K7OPA's picture
Thanks
Thanks Andre - I went back and reviewed the DtD docs and the penny finally dropped.  I have been thinking about how you would connect an appliance (Phone etc) to one of the nodes if they were both directly connected but I missed the point that you are setting these up barefoot - all apps and devices would be linked in via other nodes or clusters via switches, etc.
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.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer