Frank, WA2KWR, and myself (AE6XE) tested a 3Ghz link with the AREDN 3.15.1.0b01. The conditions:
Node A: Rocket M3 with 120 degree AirMax Sector Antenna (18dBi dual channel @ 25dBM)
Node B: NanoStation M3 (13dBi dual channel @ 25dBMm)
3.42Ghz and 14.4 MIles apart in metropolitan area of RF noise!
| Signal Strength | -84dBm | -81dBm | -78dBm |
| BW | 20Mhz | 10Mhz | 5Mhz |
| Run 1 | 1.88 | 2.13 | 2.01 |
| Run 2 | 2.03 | 2.17 | 2.03 |
| Run 3 | 2.01 | 2.3 | 1.98 |
| Run 4 | 1.98 | 2.39 | 1.93 |
| Run 5 | 1.98 | 2.04 | 1.07 |
| Run 6 | 2.14 | 2.11 | 1.98 |
| Run 7 | N/A | 1.95 | 1.98 |
| Average | 2.00 | 2.16 | 1.85 |
| Values in Mbps |
LQ and NLQ remained at 100%
--- ae6xe-rm3-120 ping statistics ---
5508 packets transmitted, 5498 packets received, 0% packet loss
round-trip min/avg/max = 1.773/5.876/362.059 ms
root@wa2kwr-30:~#
If we make this setup permanent, the sweet spot of our testing appears to be 3.420 GHz at a 10 MHz Bandwidth.
Also, please see how easy it is to do a temporary mount in the attached photo.
Ubiquiti has a suction cup mount for the NanoStation series.
NanoStation M3 on suction cup mount.
Can you share what elevations each site was at and approximate terrain conditions?
see attached elevation profile. This is SoCal, rolling hills, lots of palm trees transplanted in and coastal desert.
Thanks....that's very helpful to see. If I had the chance to put something up 2000' above my other nodes I'd jump on it! Here in the flatlands of Illinois, the highest windbreak is a 200' building.
73, Mike
Funny enough, I want to trade you for the flat lands.
I can't even go 1/8 mile from my house without having a 200 foot hill obstruct me, of course if I go 1/6 of a mile I'm back on top of another hill and all is good until I go to a 1/4 mile away and I'm in another deep valley. That is one of the flatest plot maps I've seen in a long time for SoCal
Guess we all have our own terrain issues to deal with. We are lucky to have large hill's to put stuff on, but those hills also cause us lots of problems in doing a flooding coverage lots of spots we will have to 'back fill' to get into.
Of course than there are people with flat lands and very tall Forrest between, now that really has got to be annoying.
At least it doesn't cost you thousands of $$ to climb a hill, like our 900' tower. ;-)
Nice work. Interesting how there's a sweet spot on bandwidth. Why does the signal power drop with bandwidth? Does the power amplifier have to be backed off because of a greater peak/average ratio for the wider waveforms?
I'd otherwise expect the signal strength to remain constant with bandwidth and the noise power to increase 3 dB for each doubling of bandwidth.
Do you guys know about the 'mtr' command? It's a graphical form of traceroute that keeps statistics on delay and packet losses for each step of a path. The thing with a tool like iperf (assuming you're using it in TCP mode) is that sometimes you're measuring the behavior of the TCP more than the channel.
Thanks for the tip, Phil - that sounds like a really useful tool. I'm not where I can check; is mtr implemented or available for AREDN firmware?
Orv
You may find these references helpful:
https://en.wikipedia.org/wiki/MTR_(software)
https://www.bitwizard.nl/mtr/
http://winmtr.net/download-winmtr/ for Windows
mtr assumes a graphical environment (usually X-windows) though it does seem to have a text-mode fallback using ncurses. So it's probably best to run it on a host computer attached to the mesh node rather than on the mesh node itself.
see my posting here
https://groups.google.com/d/msg/boar-net/lMFhc1couwY/1UAKQ6ppFAAJ
Regards
Ken
Interesting, I don't know what the regulations are for how wide those signals above 3500 can be or how much rolloff they are suppose to have. That would be interesting to look into with a real spectrum analyzer and see what the real rolloff is (AirOS is not a quality spectrum analyzer, it gives you an idea but is not as good as a spectrum analyzer we do always recommend doing an AirOS site survey BEFORE flashing to AREDN)
I will be curious if anyone else has similar interference reports, I had been worrying about US Navy radar (we are a training coast down here) I hadn't even thought about very wide rolloffs from very high power transmitters above 3500
Regarding your comment about putting a signal below 3400, to my knowledge the USA HAM band is down to 3300, however we have tested the amplifiers to roll off below 3400 they are still useable down to just below 3380 (we allow 3380 as a center frequency in AREDN) is there another concern below 3400 to be worried about that I'm not thinking of at this time?
Until receiving these NS3 units, my only familiarity with the band was the weak signal (3456) window. The unit I have covers 3.4-3.7 GHz so my caution about knowing where you are might better be applied to the top of the band. Except with all that QRM there, its unlikely you would want to use it.
I ran the airView function again and set it to cover down to 3.5 GHz and you can see a roll-off in the background noise level starting at 3.38. So that lines up with your comment (except this is the receive side).
Looking forward to the new release then :-)
Ken
that should read
cover down to 3.35 GHz
Actually... I decided to throw caution to the winds and load the "experimental release" for nano stations into my NSM3 units - which are cruising along on 3390 MHz at the moment :-) Anything I should be watching out for?
I did notice that the max bandwidth was 20 MHz - any chance to go more on this band?
Ken
Ken,
We've been running production with the beta on NSM3s for several months with no issue. Since then, I've even tested a 42 mile link with a NSM3 (Rocket with 120 sector on other end). It was a ~60% LQ link, but quite amazing for the distance. 3Ghz has proven to be the best performing band in our RF congested area. Locally we're on 3420 @ 10 Mhz BW--in the tests above in this thread, we found this had a little higher through-put than using more BW.
In regards to 40Mhz channel widths with 802.11n... The current firmware is still using 802.11 in ad-hoc mode, same as the early days of BBHN on linksys. Ironically, I took a detour in the last couple of days to investigate the state of the linux wireless drivers available to us in hopes to exploit the 802.11n 40Mhz and MIMO modes (including MCS8 to MCS15 rates which use 2 spatial streams). At present our max rate is 54Mbps (on all bands) and this may be achieved with 5 Mhz or 10Mhz channel widths. Doubling the channel width doubles the noise with same xmit power, so you may find it less likely to get the higher rates solely by increasing the channel size.
If you want to see the details of what rate your mesh node is determining is best to receive from a given neighbor:
# cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/<mac address of neighbor>/stations/rc_stats
the row with the "A" in the 1st column is the chosen best rate.
Joe AE6XE
I was in a unique position to do some bench testing of the 3 GHz Nano Stations in both the OEM firmware versus the AREDN MESH. These were connected to the DtD port of switches with a WAN (internet) port on one switch and my test PC on the other switch. There were a couple of 2 GHz mesh nodes at each end but only background traffic. The main traffic was "speedtest.net" from the WAN to the PC. Here are the results (each an average of 3 runs):
MESH (download/upload per the speedtest dot net protocol)
5 MHz 5.5 / 5.1 Mbps
10 MHz 10.5 / 9.7
20 MHz 18.6 / 15.2
OEM (Access-point / station in bridge mode))
5 MHz 14.3 / 13.7 (signaling rate 32.5 Mbps)
10 MHz 25 / 27.2 (signaling rate 65 Mbps)
20 MHz 29 / 43 (signaling rate 130 Mbps)
40 MHZ 63 / 86* (signaling rate 180/240/270/300 Mbps)
(This last one* limited by ISP - only 75 is guaranteed).
==> so: absent interfering signals, 20 was better than 10 in both cases and, if it were available, 40 would be better than 20. Of course this requires a clear channel and strong signals.
Using the 3 GHz as a two-node link between two meshes, there seems little reason to configure it as mesh, I think - other than being able to access the "admin console"
Running > 50 Mbps net throughput, the DtD link would be essentially invisible as a "hop."
= = =
I think I saw some of that 'spacial diversity' effect. I pretty much left the units in a fixed position. But I found that small adjustments to one Nano Station at 20 MHz, I could make the throughput jump from 17 to 35.
= = =
It was not clear to me how to look at /sys/kernel/debug/ieee80211/phy0/netdev .... when the units are connected as DtD?
Regards
Ken
Ken,
This data compares with the difference between OEM MIMO (2 unique spatial streams of data) 802.11n AP mode vs. non-MIMO 802.11a ad-hoc mode for the MESH. The raw rates in your data for OEM are 130Mbs @ 20 Mhz = MCS15 Cut the rate in half for 10Mhz and so on. Here is a good reference:
https://wireless.wiki.kernel.org/en/developers/documentation/ieee80211/8...
This data is in the ball park of expected. While it is somewhat of an apples and oranges to compare different protocols, we can try to compare OEM using 802.11n AP mode vs. MESH 802.11a ad-hoc mode. Here's a rough way to compare: the ratio of (actual data through-put) / (raw protocol MCS rate in use) is:
20Mhz: OEM 29/130 = 22% MESH 18.6/56 = 33%
10Mhz: OEM 25/65 = 38% MESH 10.5/28 = 37.5%
5Mhz: OEM 14.3/32.5 = 44% MESH 5.5/14 = 39%
What would give a fuller picture is if the packet failure/drop rates were included. We can see this in the rc_stats data on the mesh nodes. This data is only observed on the nodes with the RF link.
The ability of AirOS to do TDMA and MIMO is the reason and approach taken to build a back bone link for point-to-point connectivity between mesh islands here in Southern CA.
Joe AE6XE
Poking around in OpenWrt, I did stumble across use of HT mode HT40- running at 135 Mbps on an AirGrid M5 ...
http://wiki.openwrt.org/toh/ubiquiti/airgrid?s[]=ht40&s[]=atheros
Ken
Was it in adhoc (IBSS) mode or AP mode?
The documentation is out of date. This has moved to only "HT20" and "HT40". But the significant issue is that 802.11n mode (higher than 56Mbps rates) only appears to be implemented (in the version of the driver we are using) for 802.11 AP mode. We are using 802.11 'adhoc' or 'IBSS' mode and on top of running OLSR mesh protocol. adhoc mode in the driver is only using 802.11a (max 56Mps). No one's investigated to this depth before in the history of BBHN/AREDN that I'm aware of.
In ~2012, the primary developer of the driver for the linux community, Adrian Chadd, reportedly implemented 802.11n with adhoc mode to obtain these higher rates, but in one video I reviewed he claimed in 2013, "that was a mistake". No idea what he meant, be it is entirely possible that there is no driver available that currently implements 802.11n and adhoc mode to obtain the higher rates in AREDN. The jury is still out and I am investigating.
There are other reasons to consider AP and P2P 802.11 modes and obtain the higher rates, but there's no design of how a MESH using something like OLSR works on top of these modes--what tradeoffs have to be made to make them compatible or we figure out another way to do routing. This is not a short term option...
Joe AE6XE
Update Nov 15,2015: Confirmed that there is a way in the linux driver and have early tested 802.11n rates using MESH-adhoc mode in AREDN. Bench testing is now demonstrating up to 300Mbps rates with 40Mh channels. This will need further development and testing to understand any shortcomings, if any, including use of extended part 97 only channels.