well...read the community thread & this forum.. the ax9000 doesn't behave with any other nss pbuf profile than 500mb... due to the three radios the pci and ahb have limited frequencies (pci lower 5ghz and ahb higher).
I think with all the info around you will do well and of course the community support
At the very top of this thread you can see Robi's info - maybe one of the outstanding topics could be your cadidate?
PS
I fully agree AX9000 is a great device, even without NSS which in the current form and shape will probably never be merged into the official OpenWRT release
Hello guys! Could anyone please update https://openwrt.org/toh/xiaomi/ax9000#potential_issueslimitations section with fresh entire command link in the lower 5 GHz band radio issue subsection?
Looks like current link is not working anymore. Cant find this instructions elsewhere.
@rmandrad just to check, which other values have you tried? I was just doing some data collection on the official firmware 3.0.40, it seems that there's a significant deadzone in the higher values. The fan starts working with PWM duty cycle set to 13. 0-12 does not enable the fan, but the RPM reading is always at least 960. From 13 to around 25 the RPM reading is not too reliable, with reported speed fluctuating slightly above 960.
Setting the duty cycle to 164 or more sets the fan to the maximum (reported) speed of around 3310 RPM. Anything above that won't affect the fan speed anymore.
As for the fan control binary (/usr/sbin/mitempcontrol), it uses the /usr/sbin/fancycle script to set the duty cycle to one of the 21 states based on the temperature reading. It's triggered by crontab every 3 minutes (seems like a very rough fan control granularity, at least temporally). 61 deg. C or more is the first step, from 0 to 1, which writes 13 to /sys/devices/platform/soc/78ba000.i2c/i2c-1/1-002f/pwm1 (i2cset is not used).
Step 13 (duty cycle 166) already sets the fan to the highest speed, so I'm not sure if they're using the rest of the PWM range just as a buffer to spin the fan at 100% for a large range of temps, or is it just lazy programming... Anyhow, it's also interesting that the max fan speed denoted in the fancycle script is 2500RPM, while the i2c chip reports 960 for disabled and 3310 for max... 3310-960=2350 so I guess it's just some reading offset... Who knows.
I still haven't built the image myself. If anyone has some time to check these vales at some point, please do.
good analysis... i spend sometime tweaking and porting what is on the rpi builds and honestly with not much knowledge of dts definitions ... but still the only way I can spin the fan is set to max ... if you anyone has knowledge pls feel free to improve the dts definitions
Sorry for disturbance, script was working great for me.
Need to run it again after attended sysupgrade to latest official firmware.
Link to textbin.net is not valid anymore. Kindly ask to update link.
Thank you for sharing! Unfortunately 160MHz don't work for me with your board-2.bin on 23.05.4. None of the clients detect the network, here's my radio3 config from /etc/config/wireless:
config wifi-device 'radio3'
option type 'mac80211'
option path 'soc/20000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option channel '44'
option band '5g'
option htmode 'HE160'
option he_su_beamformee '1'
option he_bss_color '33'
option country 'DE'
option cell_density '3'
As soon as I change htmode to 'HE80', it works. Any ideas?
Thanks!
I get this that 6Ghz is not allowed in China.
But given the ambiguity around fusing/board ID (0xa2 vs 0xff) and the fact it is QCN9074 after all, I am wondering if anyone has tried it?
Maybe this would work with some effort?
I know - that's what I currently got
But given the information that QCN9024 might be tri-band ... and what changes are needed to ath11k (board_id overrides) I am simply asking if anyone tried it?