My Archer C20 v1 (22.03.2) has slow wifi.
2.4GHz (40Mhz) is 14 MBit/s, while 5.8GHz (by another router chip) ok.
Old TL-WR740N is ok too (~90 MBit/s 2.4 GHz).
Original firmware, as i remember, was ok too.
The only significant 2.4 wifi errors in log:
Sat Dec 17 10:41:13 2022 kern.err kernel: [ 48.998741] rt2880-pinmux pinctrl: pa is already enabled
Sat Dec 17 10:56:45 2022 kern.err kernel: [ 51.495537] ieee80211 phy1: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access failed, aborting
Sat Dec 17 10:56:45 2022 kern.warn kernel: [ 51.504984] ieee80211 phy1: rt2800_loft_iq_calibration: Warning - RF RX busy in LOFT IQ calibration
Sat Dec 17 10:56:45 2022 kern.err kernel: [ 51.687605] ieee80211 phy1: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access failed, aborting
Sat Dec 17 10:56:45 2022 kern.warn kernel: [ 51.697054] ieee80211 phy1: rt2800_loft_iq_calibration: Warning - RF RX busy in LOFT IQ calibration
Sat Dec 17 10:56:45 2022 kern.err kernel: [ 51.825633] ieee80211 phy1: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access failed, aborting
Sat Dec 17 10:56:45 2022 kern.warn kernel: [ 51.835081] ieee80211 phy1: rt2800_rxiq_calibration: Warning - Timeout waiting for MAC status in RXIQ calibration
Sat Dec 17 10:56:45 2022 kern.warn kernel: [ 51.896097] ieee80211 phy1: rt2800_rxiq_calibration: Warning - RXIQ calibration FAIL
I'm in a big apartment building in the city. There are a lot of neighbors APs here, but almost all of them are 40 MHz, and they don't interfere with my old router, if that's what you're talking about. I can send a screenshot of LinSSID if you are interested. If i changes the channel width to 20 MHz, the speed does not change at all.(PS: but i could see that my laptop was connected by 40MHz channel when AP was 40 MHz) I didn't have any problems with interfere at all with the old router.
No, but Archer C20v 1 has an unusual procedure for flashing the OpenWRT firmware. However, I think that the errors in the log mention special-purpose registers of some router chip that's do not relate to Flash.
0x13b0 and 0x2320 are register addresses so we are writing these registers on-the-fly.
When the driver gets loaded, it will first read the EEPROM content and initialize registers, including the TX power control ones. Unfortunately, many devices have incorrect TX power settings in the EEPROM and MediaTek told the vendors to use external text files for power settings and ignore whatever set in the EEPROM lol. The upstream mt76 driver, however, does not support external power settings and will set TX power based on the EEPROM. That explains why even though there has been zillions of complains so far but Linux wireless task group still cannot fix the issue.
So to fix this, we can either write the correct values to the EEPROM or override the register values in real-time. We chose not to touch EEPROM content because it varies device from device and writing wrong values to EEPROM could permanently brick the device. There are only two registers to be checked and if we did something wrong, we can always do a factory reset and start over again. No firmware update, no EEPROM burning.
My current solution is to put a bash script in /lib folder and use a crontab to run it every one hour. I only set register 0x13b0 and that seems to be a constant value once set. Too bad, the OpenWRT cannot rung a script after a Wi-Fi interface is up. We cannot put the register settings in the startup script either because at the time the boot process loads the startup script, the mt76 driver is not yet loaded.
People are trying to fix it by changing EEPROM register values:
Unfortunately, many devices have incorrect TX power settings in the EEPROM and MediaTek told the vendors to use external text files for power settings and ignore whatever set in the EEPROM lol. The upstream mt76 driver, however, does not support external power settings and will set TX power based on the EEPROM.
Seems like an awfully simple fix. Why can't the driver support it?
There have been multiple patches and proposed hacks in this thread to set proper tx rates for various mediatek chipsets.
Is there a way to create a pull-request and commit these to OpenWRT master branch?
Is it impossible to rewrite mt76 driver to provide support for external power setting? Or is it not desired?
Is it impossible to communicate with Mediatek manifacturers and hint about the possibility to write better values into the EEPROM to keep compliant with mt76 driver? (Of course I assume that probably would only fix new manifactured devices.)
@ThiloteE My idea is that it is very unlikely to happen to all three requests.
IMO, mt76 already has a correct logic but simply because it relies on wrong EEPROM inputs and results in bad TX outputs
It means we will need to obtain the external power definition file but not every vender provides its source codes.
MediaTek is phasing its mt76 series chip and now focusing on its mt79 product line for Wi-Fi 6 and 7.
Our work here so far is a hack but a proper hack could still be helpful. I am thinking we could create a new debug branch or add more tweak options in using debugfs.
So, unfortunately, not so simple after all
Let's just hope Mediatek writes better values into the EEPROM in future.
Furthermore, the existence of a regression window and different wifi behaviour between 22.03.0-rc4 and newer versions of OpenWRT could mean that tx power is not the only thing that is broken. I don't understand how old versions of OpenWRT seem to work better (but not perfect) than newer versions. Though, fixing tx power seems to make it work the best (even better than old versions of OpenWRT), if comments in that threat are to be believed.
However the mt7620 does not use the mt76 driver. In September of last year, some patches to improve the wireless performance of mt7620 were merged into 22.03 and master branches. So you need to use the latest 22.03 or snapshot firmware and adjust the tx power to 12-17 dbm. Again, do not use wpa3 encryption. I can get 100 + mbps with internal iperf3 sever and 60+ mbps with pppoe mode.
With internal iperf3 server I can get ~200 mbps at 5.8GHz and only ~14 mbps at 2.4GHz (Archer C20 v1, OpenWRT 22.03.3).
Old TL-WR740N speed was ~90 MBit/s at 2.4 GHz.
Because of this, I think it's a MT7620A problem, not MT7610E or WPA3.
And the 2.4 GHz transmission power looks sufficient: speed measurements was in 20 cm near router and 5 meters, with 20 MHz and 40 MHz channel, with different tx power - fairly stable 14 mbps.
22.03.1 changelog has a commit with suspicious description: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7c459ac1d5a9a5c507afd7a3205dccfad20883d1
By the way, in 22.03.0 I still has the same problem too.
Perhaps the calibration data is really incorrect. However, most users only have problems with 5GHz because of this.
Today I discovered that 802.11w Management Frame Protection was "Optional" all the time (by default). When I turned it off, the 2.4GHz speed increased from 14 Mbps to 55 Mbps (HT40), and to 27 mbps (HT20). This option did not affect the speed of 5 GHz.