You are here

3Ghz test results in Orange County SoCAL

23 posts / 0 new
Last post
AE6XE
AE6XE's picture
3Ghz test results in Orange County SoCAL

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!

'iperf' Through-Put Results
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:~# 

 

wa2kwr
Observations: 3Ghz test results in Orange County SoCAL

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.

wa2kwr
Trying again for the photo

NanoStation M3 on suction cup mount.

Image Attachments: 
kg9dw
kg9dw's picture
elevations?

Can you share what elevations each site was at and approximate terrain conditions? 

AE6XE
AE6XE's picture
see attached elevation

see attached elevation profile.   This is SoCal, rolling hills, lots of palm trees transplanted in and coastal desert.

Image Attachments: 
kg9dw
kg9dw's picture
thanks!

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

KG6JEI
Funny enough, I want to trade

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.

 

 

K5DLQ
K5DLQ's picture
At least it doesn't cost you

At least it doesn't cost you thousands of $$ to climb a hill, like our 900' tower.  ;-)

 

KA9Q
Nice work. Interesting how

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.

w6bi
w6bi's picture
mtr

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

WU2S
WU2S's picture
References for mtr

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 

KA9Q
mtr assumes a graphical

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.

 

KE2N
KE2N's picture
3 GHz here today
KG6JEI
Interesting,  I don't know

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?

 

KE2N
KE2N's picture
the bottom

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

KE2N
KE2N's picture
correction

that should read

cover down to 3.35 GHz

 

KE2N
KE2N's picture
3 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

 

AE6XE
AE6XE's picture
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

KE2N
KE2N's picture
Mesh vs OEM and Speed vs BW

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

 

AE6XE
AE6XE's picture
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

KE2N
KE2N's picture
HT40

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

 

 

K5DLQ
K5DLQ's picture
Was it in adhoc (IBSS) mode

Was it in adhoc (IBSS) mode or AP mode?

AE6XE
AE6XE's picture
The documentation is out of

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.   

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer