Enable Support for 5/10 MHz channel width on ath10K based wifi

I have some devices with ath9k chipsets running on 5/10 MHz channel width due to the distance between them.
Some time back I see there as an attempt to provide this support for the ath10k branch.

See https://patchwork.kernel.org/project/ath10k/patch/20171120150115.0c0a8a3c@friiks.de/

Are there any patches I can apply to get this working using the latest code from the master branch
so I can connect my Legacy devices to a device running with an ath10K chipset using a 5 or 10 Mhz channel
width on condition that the native firmware supports these bandwidths.

Haven’t seen this native support for ages…

1 Like

I do not have this device but see page 4 and you will see it supports 10 MHz channel bandwidth.
https://dl.ui.com/datasheets/LiteBeam/LiteBeam_AC_Gen2_DS.pdf

It is also support by OpenWrt but I think it is missing the 10 MHz Channel support in OpenWrt (https://openwrt.org/toh/ubiquiti/litebeam_5ac_gen2)

It is a radio link that operates in the 5GHz wifi band. It isn’t a 802.11 device. And 802.11 pretty much doesn’t have anything else than 20, 40, 80 and 160MHz bw.

1 Like

Yes these devices are typically used as radio links that allow Channel Bandwidths like 10 MHz. Using software based on OpenWrt and the ath9K chipset we have them connecting with other devices using either a 5 MHz or 10 MHz bandwidth depending on the distance. We would like to add devices with the ath10k chipset so they can connect to the devices with the ath9k chipset but so far OpenWrt has not added support for 5 or 10 MHz Channel Bandwidths.

Additionally, 802.11 does allow for channel bandwidths or 5 MHz or 10 MHZ as well.
See https://download.tek.com/document/37W-29447-2_LR.pdf Page 10 Heading Channel Bandwidths for the 2.4 GHz Band and page 16 where you will see Japan allows 10 MHz on the 5 GHz band.

try the patch you linked,also you need touch wireless reg.db

There's a lot of history to this; but it'll be sufficient to note that unless your National Radio Regulations restrict bandwidth/symbol rate (e.g. 20 MHz config would be problematic on channels that Amateur/Ham Radio power/antennas/specs can be used in the USA) - it will otherwise be OK.

The example above would be a licensed configuration (or more clear term is: "not licensed by regulation" i.e. not Part 15), hence those settings were removed long ago.

Also, I think the orginal specifications noting 5/10 MHz channels has long been obsoleted. That'll take a search thru the IEEE specifications to verify.

The IEEE specification, while less than 20MHz channel width options may have removed or does not address usage, 10MHz or less channel widths are commonly used with part 15 devices sold in the US.

Example 1: Ubiquiti AirMax best practices and selection of 10MHz channel width example:

https://support.hostifi.com/en/articles/6300438-airmax-wireless-best-practices#:~:text=Channel%20Width,-2.4%20GHz%20airMAX&text=On%205%20GHz%20airMAX%2C%20we,less%20spectrum%2C%20are%20more%20efficient.

Example 2: All airMax radios "feature custom channel widths (2/3/5/8/10/25/30/50/60 MHz)". See:
https://support.hostifi.com/en/articles/6300438-airmax-wireless-best-practices#:~:text=Channel%20Width,-2.4%20GHz%20airMAX&text=On%205%20GHz%20airMAX%2C%20we,less%20spectrum%2C%20are%20more%20efficient.

Summary: less than 20MHz channel widths are commonly used where optimal, and not outside of part 15 rules in the US, at least according to Ubiquiti.

5 and 10MHz channel widths are a desirable feature for any openwrt user that wishes to do longer distance links. When the channel width is cut in half, the symbol timing is doubled. This translates to ack response times and max distance increases with further protection from fading necessary to do longer distance links. I have a couple 60km links that maintain MCS15 rates in 10MHz channel widths (cut the 20MHz rate in half when set to 10MHz channel width).

I am unable to upgrade this link to openwrt (ath10k) 802.11ac devices, given lack of a 10MHz option. Sadly, I would have to upgrade to AirMax. On 20MHz channel width there is a limit of 46.6km distance settings on the ack timing.

1 Like

If the patch doesn't work then, please let us know.

I still need it for Amateur Radio use.

PM me if you have issues, I don't know any others who have the patch working on Linux Kernel >= 4.x (I KNOW HOW DOES have it working on currently marketed devices I'VE ASKED FOR CODE). Hope this helps.

Please request their code!

(I'll research emails about code requests.)

Then you get into changing antennae (or lack thereof), gain ,etc. - regulated by FCC (at least in the US). This is why various boot configs, no serial pin outs, missing serial circuits, and even flash chips have set parameters, non-removable antennas,etc.

Lemme do math....that seems correct...

Wait.

You need a Distance Optimization longer than 46,000?!?!

60,000 m??? :open_mouth:

Ummmmm...wow!

What device?

OpenWrt?

(I'm researching this - but I literally think you just claimed the Earth long distance record for WiFi...) :partying_face:

I have that patch installed on a device with openwrt 22.03 and if I set the chanbw = 20 in /etc/config/wireless on both the ath10k and the ath9k devices they see each other. If I set the chanbw = 10 on both devices it does not work. Is there some other setting I need to change or some other way to activate 10 MHz channel width on the ath10k device?

These long distance links, and there are many of them in the https://www.arednmesh.org community, in US part 97 allocation for ham radio, typically use Rocket M and RocketDish devices. The longest regularly live link is in San Diego area around 70 to 80 km. I do not carry this distinction of longest link :slight_smile: . On 5GHz this is a 30dBi gain antenna with a ~25dBm xmit power or 55dBm = ~300W EIRP. lowering power to 23dBm would stay within part 15 200W EIRP limit in UNI3.

Note the ubiquiti specifications on the 5GHz Rocket M device defines 21dBm max at MCS15. Possibly this reduced xmit power at higher MCS rates is to stay within the Power Amp linearity and keep the signal clean -- they don't say why. I start at max 27dBm and reduce power as much as possible to stay in the MCS15 link rates.

I have a 3GHz link (Rocket 3M) and 5GHz links at this distance based on the openwrt release. This is in Southern California from Pleasants Peak with visibility and live links to all counties -- Los Angeles, Orange, Riverside, San Bernardino. The 3GHz link goes to the Jet Propulsion Lab campus in Pasadena (Los Angeles County). The 5GHz goes to San Bernardino County. It is 37.8 miles or 60.8 km.

Here's the 5GHz ath9k rate selection table, snapshot just now:

              best   ____________rate__________    ________statistics________    _____last____    ______sum-of________
mode guard #  rate  [name   idx airtime  max_tp]  [avg(tp) avg(prob) sd(prob)]  [retry|suc|att]  [#success | #attempts]
HT20  LGI  1         MCS0     0    1477     4.8       2.4      68.9      0.0       2     0 0          1914   5799
HT20  LGI  1         MCS1     1     738     9.7       9.7      96.1      0.0       4     0 0          3612   5995
HT20  LGI  1         MCS2     2     492    14.6      14.6     100.0      0.0       5     0 0         21566   29456
HT20  LGI  1         MCS3     3     369    17.0      17.0      96.3      0.0       5     0 0         20920   30122
HT20  LGI  1         MCS4     4     246    24.4      24.4     100.0      0.0       5     0 0         49788   63201
HT20  LGI  1         MCS5     5     185    29.2      29.2     100.0      0.0       5     0 0         92530   113993
HT20  LGI  1         MCS6     6     164    31.7      31.7     100.0      0.0       5     0 0         87947   119834
HT20  LGI  1      P  MCS7     7     148    34.1      31.7      82.4      0.0       5     0 0         33395   104052
HT20  LGI  2         MCS8    10     738     9.7       9.7     100.0      0.0       4     0 0          4211   6659
HT20  LGI  2         MCS9    11     369    17.0      17.0      97.3      0.0       5     0 0         44379   56773
HT20  LGI  2         MCS10   12     246    24.4      24.4     100.0      0.0       5     0 0        268418   297853
HT20  LGI  2         MCS11   13     185    29.2      29.2     100.0      0.0       5     0 0        764334   824538
HT20  LGI  2     D   MCS12   14     123    36.6      36.6      97.8      0.0       6     0 0       5216935   5525837
HT20  LGI  2    C    MCS13   15      92    43.9      43.9      88.1      0.0       6     0 0      24762999   26183695
HT20  LGI  2   B     MCS14   16      82    46.3      46.3     100.0      0.0       6     0 0      43492081   46115127
HT20  LGI  2  A      MCS15   17      74    48.8      48.8      92.8      0.0       6     3 4      18912074   22038990
1 Like

As noted above, some functionality in 802.11ac Qualcomm chips has moved into proprietary firmware. I understand an NDA and relationship with Qualcomm would be necessary to gain full access to this firmware source code, and anyone that has the NDA, could not redistribute code to a 3rd party. However, I understand there may be 5 and 10MHz channel widths working in some firmware distributed in the open source community.

The ham radio community, and openwrt users with a need to do these long distant links, would greatly benefit from having this capability. Hence, looking to sync up with others that have this need, and also anyone that is able to contribute.

Joe AE6XE

1 Like

i sended you a patch which helps you to implement 5 and 10 mhz for ath10k in openwrt. however. with vanilla firmwares it will only work on selected chipsets. (the ubnt ac mesh works for instance)
on all other chipsets the 5 and 10 mhz capabilities will simply not work.
if you use the firmwares provided with dd-wrt it will work on all chipsets since i was able to detect unsupported chipsets and i also was able to implement a different approach to get 5 and 10 mhz working. however. on unsupported chipsets the chipset gets measurable much hotter if you run 5 and 10 mhz.
i tested 10 and 5 mhz on qca988x, qca99xx and qca9984. all others may work too if you use the firmwares shipped with dd-wrt

Thank you very much. I will review the patch you have sent and test it when I have some time.
You have been a great help.

so it will not work on ipq40xx out of the box?

very likelly. but not tested so far. but my own firmwares are required.

thanks, all my ath9k devices 2.4/5.0 are able to do that, also on non common channels too. i was just curios about that. anyway at that bw the speed will be so low that you really don' t need wifi5.

what do you mean with low? with 10 mhz channels its possible to get some fair amount of bandwidth. depending on the rate you get about 40 - 50 mbit

Indeed, even with half or quarter chip rate, more advanced modulation schemes from 11n or 11ac are still useful. I wonder if we could get this working on CT firmware somehow, someday. This would be of great use for ham-radio communities or for Hamnet - for some countries, bandwidth for ham-radio operated channels is limited to 10MHz by law, and currently we're left with stock firmware on either Ubiquiti or Mikrotik ath10k devices because of that.

@BrainSlayer
With the Openwrt based Candelatech ath10k drivers I have the following Interface modes.

    Supported interface modes:
             * IBSS
             * managed
             * AP
             * AP/VLAN
             * monitor
             * P2P-client
             * P2P-GO
             * P2P-device

When using the standard ath10k drivers with your firmware for the QCA9888 I have the following Interface modes.

  Supported interface modes:
           * managed
           * AP
           * AP/VLAN               
            * monitor
           * P2P-client
           * P2P-GO
           * P2P-device

IBSS mode is missing.
How do I enable IBSS Interface mode, so it shows up with the standard ath10k drivers and your firmware?