Archer c7 - 5 ghz channel - power consumption heat

I have no need to use the AC (5 GHz) portion of the Archer C7 V2 as I am using another AP. I have disabled the 5 Ghz radio on Luci. Is it actually consuming less power or more importantly generating less heat in the router?

I am using 2.4 Ghz radio.

I'm not sure if you're asking or telling.

Yes.

If you turn off any radio transmitter, you would reduce power roughly by the amount needed to power that WiFi chip. This amount may be negligible, though.

Since the WiFi (and most circuits) produces heat, it would reduce heat by some amount.

Unlikely that it will reduce total power consumption or heat generation by any significant amount. I recently tested one of my Archer C7 v2 units and found only ~4 W being consumed during operation (measured at the DC input, exclusive of mains power-supply losses).

I was asking and you answered the question. Thank you.

I stated that I am using 2.4 GHz radio but turned off 5 GHz radio using the Web interface.

According to https://wikidevi.com/wiki/TP-LINK_Archer_C7_v2.x my router uses two different chips. I just wanted to confirm my assumption. My WiFi on 2.4 GHz dies randomly and I am trying to debug. There are other mentions of C7 WiFi failing after some time but there is no concrete answer.
I noticed
Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
In my boot log and I thought it might help to disable that radio. The kernel log still shows the error message though.

It is normal to see firmware load failed because it tries several different file names for the firmware and only successfully loads one.

The 5 GHz chip has its own CPU that runs the firmware loaded into it. If you remove kmod-ath10k, the 5 GHz radio chip will likely stay in a low power "unstarted" condition.

That would need confirmation by testing this very closely, uninitialized chips might actually draw more power than enabled ones left (mostly) idle. This is very device, firmware and driver specific though.

Those log messages are "normal" -- regrettably the drivers call it an "error" or "warning" if one of the many places that firmware might be found doesn't exist, but don't clearly report "success" at all

2018 Sep 12 09:14:20 devel info kernel: [   14.092845] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
2018 Sep 12 09:14:20 devel warning kernel: [   14.374607] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:00:00.0.bin failed with error -2
2018 Sep 12 09:14:20 devel warning kernel: [   14.385485] ath10k_pci 0000:00:00.0: Falling back to user helper
2018 Sep 12 09:14:20 devel err kernel: [   14.480760] firmware ath10k!pre-cal-pci-0000:00:00.0.bin: firmware_loading_store: map pages failed
2018 Sep 12 09:14:20 devel warning kernel: [   14.610231] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-6.bin failed with error -2
2018 Sep 12 09:14:20 devel warning kernel: [   14.621122] ath10k_pci 0000:00:00.0: Falling back to user helper
2018 Sep 12 09:14:20 devel err kernel: [   14.718054] firmware ath10k!QCA988X!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
2018 Sep 12 09:14:20 devel info kernel: [   15.083976] ath10k_pci 0000:00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
2018 Sep 12 09:14:20 devel info kernel: [   15.093383] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
2018 Sep 12 09:14:20 devel info kernel: [   15.106429] ath10k_pci 0000:00:00.0: firmware ver 10.2.4-1.0-00037 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 a4a52adb
2018 Sep 12 09:14:20 devel warning kernel: [   15.151451] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
2018 Sep 12 09:14:20 devel warning kernel: [   15.162059] ath10k_pci 0000:00:00.0: Falling back to user helper
2018 Sep 12 09:14:20 devel err kernel: [   15.251342] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
2018 Sep 12 09:14:20 devel info kernel: [   15.260592] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
2018 Sep 12 09:14:20 devel info kernel: [   16.369056] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1

Thanks @jeff and everybody else on this thread. As per the wisdom on this thread, I will keep 5 GHz radio as is (disabled) and look elsewhere for my 2.4 GHz failing. Surprisingly there is no mention of 2.4 GHz being down in the log. Today it went down and came back on its own after few minutes while I was trying to dig through the log. Is there any way to increase the debug log level for WiFi and VLAN?

Yes, you can increase the logging level for the wireless, but it will involve you building your own image (or at least your own packages) as the low-level debugging for hostapd isn't included, primarily because of size, from what I understand.

It's a rather bizarrely named config parameter, from my git logs CONFIG_WPA_MSG_MIN_PRIORITY and its levels don't correspond to syslog levels. I believe it is managed at run time in /etc/config/wireless by log_level. Your logging system needs to manage the logs, which, as I recall, are pretty lengthy at debug level. You might want to either log to /var/ somewhere and possibly install "full" less to look at the file.

Looks like they're defined in the hostap source at src/utils/wpa_debug.h and I recall those macros being redefined in the OpenWrt patches as well by patches/410-limit_debug_messages.patch.

enum hostapd_logger_level {
        HOSTAPD_LEVEL_DEBUG_VERBOSE = 0,
        HOSTAPD_LEVEL_DEBUG = 1,
        HOSTAPD_LEVEL_INFO = 2,
        HOSTAPD_LEVEL_NOTICE = 3,
        HOSTAPD_LEVEL_WARNING = 4
};

I vaguely remember some other strangeness, but it's been a long time.

1 Like

@jeff recompiling driver is beyond my scope for now but I do have a local Debian server running rsyslog. I changed openwrt to point to this server IP and set the log level to debug. I will see if I find something in there.