Hello!
Thank you for allowing me to join this forum. I am involved in AREDN activities on mid Vancouver Island. I do have a concern and some questions, but please allow me to set some context.
There are two 5 GHz nodes mounted on top of a mountain, and they provide coverage to a good part of mid Vancouver Island (Nanaimo and area). I belong to a group of hams who live up island, and we have been experimenting with connecting to the Nanaimo nodes. I flashed a couple of SXTsq 5 HP dishes- I configured them to the channels (133 and 172) and bandwidth (5 Mhz) of the main nodes. Note- the channels were planned thoughtfully, and for many reasons only 5 MHz bandwidth is used. In any event, I flashed initially with 3.22.6.0 firmware. The dishes were powered by a battery (12V) and I used a small wireless access point (a Mikrotik MQS actually) connected to the SXT so I could connect with my cell phone. I used wifi scan to see if I could see the signals from various locations around my QTH. This configuration worked… after I updated to 3.22.8.0, I started to experience problems. Simply put, the wifi scan did not work- at best it was hit/ miss from locations where I know I should receive a signal. Indeed, I work at an office that is line of sight to the mountain top nodes- I could not consistently see any signal with wifi scan or when the SXT tried to mesh (it meshed successfully with the older firmware).
This problem intrigued me, so I looked as much as possible into the docs/ messages. I see threads about 5 Mhz issues with Mikrotik gear (I ran my dishes at 24V POE)- but nothing that really helped me understand this problem (failure of wifi scan/ mesh on 5 MHz for SXT dishes). From what I gather, adjusting bandwidth is critical for:
- wifi scans: will only look for signals with the same bandwidth
- mesh: any nodes meshing need to align bandwidth (and obviously channel…)
I accessed the SXT’s by SSH, just to see what showed when I examined the interface. After all that, I’m not convinced that changing bandwidth on the web page actually changes bandwidth at the interface for my SXT dishes. My first attempt to see the information for my interface by SSH:
root@VA7LMP-SXTsq5HP-mobile-1:~# iw wlan0 info
Interface wlan0
ifindex 8
wdev 0x2
addr 2c:c8:1b:36:6d:8c
ssid AREDN-5-v3
type IBSS
wiphy 0
channel 133 (5665 MHz), width: 20 MHz, center1: 5665 MHz
txpower 28.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 859 0 0 0 0 107256 859
I’m not sure what to make of the “width: 20 MHz” when the node is nominally set to 5 MHz. Just to experiment, I put the interface in monitor mode and reassigned the channel/ 5 MHz bandwidth:
root@VA7LMP-SXTsq5HP-mobile-1:~# ifconfig wlan0 down
root@VA7LMP-SXTsq5HP-mobile-1:~# iw dev wlan0 set type monitor
root@VA7LMP-SXTsq5HP-mobile-1:~# ifconfig wlan0 up
root@VA7LMP-SXTsq5HP-mobile-1:~# iw dev wlan0 set channel 133 5MHz
root@VA7LMP-SXTsq5HP-mobile-1:~# iw wlan0 info
Interface wlan0
ifindex 8
wdev 0x2
addr 2c:c8:1b:36:6d:8c
type monitor
wiphy 0
channel 133 (5665 MHz), width: 5 MHz, center1: 5665 MHz
txpower 28.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 894 0 0 0 0 111740 894
It seems like I can “force” a 5 MHz channel width..? FWIW- I could not wlan0 down/ change mode to IBSS- message was “invalid interface.”
I did a lot more poking around thru SSH than this, but I’ll leave at this for now- a few questions…
Am I interpreting the return from the first info request properly? Despite what the setup page states (supposed to be 5 MHz bandwidth), is the interface actually on a 20 MHz channel width? If not, how do I confirm actual bandwidth/ channel width?
I’ve read about the Atheros chip set, “forcing” smaller bandwidths, etc… there are references to “HT Capability Overrides” that seem relevant, I just can’t find a good reference- anything I should read?
I’m also including a screenshot of my setup page- this was the setup I checked thru SSH.
Any thoughts or help is appreciated!
73
Scott VA7LMP
1. Recommend to not use 'auto' distance with nodes < 4 miles (6 km).
Around my house/garage I use the shortest setting, 0.62 mi ( 1 km ).
A too short setting is always extremely harmful to throughput.
A too long setting reduces throughput if/when a packet is lost.
If no packets are lost, there is no reduction in throughput.
I apologize in advance, but I would like to hear the reasons for 5 MHz bandwidth.
IMHO, as long as one can keep 15 dB SNR or better, the highest bandwidth should be chosen.
This keeps 'emitted power over time' low and increases channel availability for others.
Trivial:
I think that the Mikrotik RB SXTsq devices actually have a 'panel' style antenna, even though
the enclosure is slightly concave on the antenna side.
Without an antenna at a 'focal point' of a parabolic reflector, there is no 'dish antenna'.
73, Chuck
K6CCC- I think you are right, I've seen some references to the problematic use of 5 Mhz with Mikrotik gear, just nothing definitive- can you point me to any threads or docs?
Chuck- You are right! I think of my gear as "routers" and "dishes," I just lapsed into that language while composing my comment. That said the SXT panels have a lot of potential- apart from "sniffing" AREDN nodes, we are talking about using them for rapidly deploying networks to support public events, extending our nodes in other ways...
That said, I can reach out to the folk who made the decision but I believe that 5 Mhz was chosen as the bandwidth best able to support the anticipated distances of the links. We live in an area with *lots* of tall, mature trees and variations in elevation- we are lucky to have some nodes on a mountain. The network is already established, several folk have RF links so there is a need to get gear to work on 5 Mhz. In this part of the world, Mikrotik gear is much more accessible (and affordable), so I am motivated to see if it will work on a 5 Mhz bandwidth.
Any thoughts on the apparent disconnect between the SSID (AREDN-5-v3) and the apparent bandwidth of 20 MHz? I can see how this could "confuse" the node if it's "looking" for 5 MHz sites but really operating with a 20 MHz width...might it explain the intermittent ability to connect/ sniff the node?
Comments and thoughts are welcomed!!
73
Scott
As I understand it, the iw utility always defaults to showing 20mhz. You can ignore that value -- your node is using whatever value is set on the Basic Settings display.
Regarding the choice of the 5.8 GHz band for an area with dense tree cover, that band requires clear line of sight between endpoints. It does not penetrate tree cover very well. Make sure you get your nodes up high above the trees. The only supported devices that have a chance of penetrating dense tree cover are ones using the 33cm band.
and thanks- I could not find that information about iw anywhere... still puzzling to me...
I'm fortunate (or not...) to live in an area with beautiful, tall, mature trees. Yes- 33 cm would be better- as I understand the situation, it's no longer manufactured and it's hard to come by at a decent price (I just looked at eBay). Sigh. I believe the decision to use 5.8 GHz was made for several reasons- there is a mountain top node location (look up Mount Benson on Vancouver Island), despite the trees there are open areas (much of Nanaimo has coverage from Benson). I live up Island (Parksville area). There *are* open areas, so the band is not totally inappropriate for our area. We are going to experiment with a mountain top node near where I live but in any event, regardless of band, all of us are resigned to deploying nodes in high places.
thanks again
Scott VA7LMP
Are you referring to a 'Wi-Fi Scan'?
Chuck
Hi, Scott:
'Deploying', yes.
'Support public events', yes.
'Extending our nodes in other ways', huh?
That I do not understand.
Chuck
Hi, Scott:
Did the folk try other bandwidths or did they make a decision without testing?
Are you willing to try?
"bandwidth best able to support the anticipated distances of the links. "
IMHO, 20 MHz bandwidth may not work well beyond around 22 to 25 miles,
10 MHz...beyond 44-50 miles.
What is the distance between nodes in your local network?
IIRC, at 5 MHz bandwidth, Mikrotik devices to not work well with other manufacturers.
So, if your local network has mixed manufacturers, your folk may be deciding to have a network that does not work well from the start.
73, Chuck
Yes- I am talking about using wifi scan to "sniff" areas where we could receive the signal. As I understand it, in wifi scan the devices are passive- active antennas, as it were. The SXT devices did work for this, not so much after the firmware upgrade.
Indeed, the planning involves long distances- perhaps 50 miles or more. We are looking at deploying other nodes closer to my QTH. I did ask my colleagues about the decision to use 5 MHz bandwidth, and it was primarily about distance. I'm not sure they are willing to experiment with different bandwidths given the number of folk already connected to the nodes. Stay tuned...
Yes- as far as I can tell from digging into the forum and docs, there is an issue with Mikrotik and 5 MHz bandwidth- lots of folk here use Mikrotik gear to access the mountain top nodes, so far nobody has reported any problems, but the group is aware and we are monitoring- again, stay tuned!
I used loose language when I talked about "extending." By that, I mean extending access to the nodes by:
-new packet radio (we've conducted some experiments, might be the workaround for many access issues)
-I've experimented with meshtastic/ MQTT protocols integrated with an AREDN node- someone can send a message thru the mesh, at my node (or the nearest node) it is relayed to me on 70 or 33 cm to my meshtastic device, I receive it at some distance from the node
thanks for your help and responses!
Scott VA7LMP
Hi, Scott:
At '50 miles or more' 5 MHz BW may be a requirement.
Keeping with affordable Mikrotik devices...I have had very good success
mixing SXTsq panels and LHG dishes.
Over the last 7 years our local network has evolved from 32 nodes all on channel '-2' @ 10 MHz to
60+ nodes with 90% redundant point-to-point links.
Our channel '-2' links have gone from 32 to
one user active with one of our high profile channel '-2' Omnis.
I wonder if the 'New Packet Radio' through-put can handle just the maintenance data of an AREDN network.
An isolated NPR link could handle maybe one VoIP link, but maybe not a PBX with 2 active calls.
Certainly not video.
'someone can send a message'
If you must reduce your available services to messaging, maybe consider a BBS/CHAT service that can
perform at 1200 to 9600 baud. That would be a light load upon a 100 kbps NPR link.
73, Chuck
I suppose NPR could be used in a couple of ways... in one scenario, as you suggest, NPR would act as a way of linking/ meshing nodes. We are thinking about NPR to access advertised services on a node, such as Meshchat, email, or other message services- we are going to experiment and push its limits. VOIP of some sort would be an interesting experiment. Otherwise I agree with your suggestion about keeping the load light for such a link.
73
Scott
You mentioned you have Mikrotik SXTsq5 radios at your QTH, but what type of radios and antennas are on the mountaintop?
Your SXTsq radios are dual polarity (MIMO) devices -- and MIMO to MIMO links should work pretty well. But if the radios on the mountaintop are (for example) Ubiquity Bullet radios (SISO) on omnidirectional antennas, then you can expect significant issues. Also, what distances are you traversing between your stations and the mountaintop? There are several computer modeling tools that are freely available and pretty easy to use which can predict the level of SNR that you could expect between your two endpoints. Here are some examples of these tools:
https://arednmesh.readthedocs.io/en/latest/arednNetworkDesign/network_modeling.html
In my experience, VE2DBE’s Radio Mobile Tool is very useful. Not only do you need to consider strict "line of sight" but also factor in whether the first Fresnel zone has enough clearance from obstacles in the path. Radio Mobile will give you an idea whether a viable radio link is even possible between your sites.
As for distances... I try to access from a couple of locations. One location- one of my offices- looks at the mountain top, maybe a few kilometers line of sight. I have tested the SXT's from my office- they will see the signal and even mesh (LQ 100%, NLQ 60-80% or better sometimes) Even then, the wifi scan and ability to mesh is hit and miss. I'm more interested in seeing if I can receive the signals some distance away- around 30- 40 km. I don't expect the SXT's to mesh, but with the previous firmware I was able to see the signals using wifi scan- the wifi scan does not seem to work as well once I updated firmware. That is the main use case- using the SXT's simply to see where the mountain top nodes can be received around the area where I live. I have a Mikrotik LHG5, I am going to test this gear from my home QTH shortly. Again- not sure about Mikrotik and 5 Mhz bandwidth...
I was aware of Ubiquiti link planning software- I forgot about the other apps, thank you for providing a link!
Chris VE7TOP
Ubiquiti AM-5G*-120 sector antennas ... at 1100m a.m.s.l.:
An AM-5G16-120, mounted exactly vertically, will be optimized to sea level at 15.77 km.
Linking to a station farther away or higher in elevation worsens SNR.
To link with a station farther away, some up-tilt in the mounting might help.
An AM-5G19-120, mounted exactly vertically, will be optimized to sea level at 31.52 km.
Linking to a station farther away or higher in elevation worsens SNR.
To link with a station farther away, some up-tilt in the mounting might help.
http://localnode.local.mesh/help.html
...
The maximum distance settings the ath9k wireless driver allows is dependent on the Channel Width:
20MHz: 46666 meters
10MHz: 103030 meters
5MHz: 215757 meters
73, Chuck
/sys/kernel/debug/ieee80211/phy0/ath9k/chanbw
in openwrt, and thus AREDN firmware, you can set the channel width in /etc/config/wireless and then do the command "wifi down ; wifi up" to put into effect.
Refer to the on-node help file for the documented max distance settings for channel widths. These values may be buried in the ath9k driver source code, but are reported to come from the NDA chipset specs.
Joe
AE6XE
Ok, thank you- your explanation helps me make sense of what I am seeing when I look at paths/ files.
I do continue to notice that connectivity with my gear at 5 MHz width is still a bit hit and miss... but thanks for helping eliminate one presumed problem.
Scott VA7LMP
I found:
option chanbw '20'
option country 'HX'
option distance '0'
option hwmode '11a'
option htmode 'HT20'
Is
option chanbw '40'
option country 'HX'
option distance '0'
option hwmode '11a'
option htmode 'HT40'
available?
3s, Chuck
In 802.11n, the 40MHz channel width is 2 x 20MHz channels. This is specified in the /etc/config/wireless settings with the htmode option: HT20, HT40-, HT40+, ...
In AREDN, htmode is always HT20 (hasn't been a compelling need to implement 40). But note, in the settings, the "40-" and "40+" spell out to put the 2nd 20MHz channel below or above the channel freq setting of the 1st 20MHz channel (the freq setting is not the center of the 40MHz band width).
Also, note the /sys/kernel/debug/ieee80211/phy0/ath9k/chanbw settings are only 5, 10, and 20. I suspect if you set this to 5 and 10 on an HT40-/+ setting, ether it would toss an error, or there will be 2 x 5MHz/10MHz bw signals with 20Mz/10MHz gap between them. Not a relevant setting unless htmode is HT20...
See: https://openwrt.org/docs/guide-user/network/wifi/basic
Joe AE6XE
Thanks.
That link was an interesting read.
Yes, no compelling need...just for fun and experiment.
I may try to configure HT40+ on channel 1 of 2.4 GHz on a pair of my GL iNet devices.
73,
Chuck