Levandor

Router WiFi tuning — TX power is maxed, HE80→HE40 for range/wall penetration

4 min read

Weak WiFi signal / poor wall penetration on telep-router — root-caused to TX power already being at the regulatory ceiling on both radios (not a lever), then mitigated by narrowing the 5 GHz channel width HE80→HE40 to concentrate the same power into a narrower band (≈ +3 dB range/penetration). Real dead-zone fixes (band steering, a second AP) recorded but not yet applied.

For Agents

  • Complaint: weak signal, poor wall penetration; the OpenWrt UI shows “max” power.
  • Finding: BOTH radios are already at the HU/ETSI regulatory ceiling — 5 GHz radio0 = 23 dBm, 2.4 GHz radio1 = 20 dBm. TX power CANNOT go higher on the current channels. (HW max is 30 dBm but only on DFS channels 100–140.)
  • Change applied: wireless.radio0.htmode='HE40' (was HE80), uci commit wireless; wifi reload. Concentrates the same power into half the bandwidth → ≈ +3 dB effective range/penetration; peak link rate ~1200 → ~600 Mbps. Reversible — set htmode back to HE80.
  • Biggest un-applied win: band steering (needs the dawn package) so far/through-wall clients move to 2.4 GHz — 5 GHz simply cannot penetrate walls.

TX power is NOT a lever — both radios are already at the ceiling

RadioBandChannel (before)Current TX powerRegulatory ceiling (HU/ETSI)
radio05 GHz36, HE8023 dBm23 dBm (non-DFS) — HW max 30 dBm only on DFS ch 100–140
radio12.4 GHz1, HE2020 dBm20 dBm

The UI “max” is the truth: neither radio can legally transmit harder on its current channel. Turning power up is not an option.

Client survey during the complaint

  • 5 GHz: 5 clients; two at −83 / −85 dBm — effectively dying through the walls.
  • 2.4 GHz: nearly empty except the two Tapo cameras:
    • Dél .119 @ −42 dBm — good.
    • Észak .139 @ −67 dBm — the weak link; this is the camera that drops its RTSP.
  • Main SSID telep1 is dual-band (same SSID on radio0 + radio1), so a client CAN roam between bands. telep-cc is the separate 2.4 GHz camera SSID.

The change applied — HE80 → HE40 on 5 GHz

uci set wireless.radio0.htmode='HE40'   # was HE80
uci commit wireless
wifi reload

Why narrowing the channel helps range

The radio’s total TX power is spread across the channel bandwidth. Halving the width (80 → 40 MHz) concentrates the same power into half the spectrum, raising power spectral density by ≈ +3 dB → measurably better range and wall penetration. The trade-off is peak throughput: ~1200 Mbps → ~600 Mbps peak. Fully reversible by setting htmode back to HE80.

Recommendations recorded (NOT yet applied)

Ordered by impact

  1. Band steering (biggest win). Install the dawn package on OpenWrt so far / through-wall devices are steered onto 2.4 GHz — 5 GHz physically cannot get through the walls, so moving those two −83/−85 dBm clients to 2.4 GHz is the single largest improvement available from software.
  2. Optionally HE20 on 5 GHz for maximum range (another width halving) — drops peak to ~300 Mbps.
  3. Keep 2.4 GHz at 20 MHz — never run 40 MHz on 2.4 GHz (only 3 non-overlapping channels; 40 MHz self-interferes).
  4. The real dead-zone fix is a second AP / mesh node with WIRED backhaul. No single-router setting beats RF physics — walls attenuate, and one router cannot cover the whole site.

A wifi reload here took the cams VLAN + camwall DOWN

Changing the 2.4 GHz channel (radio1 1→11) with uci set wireless.radio1.channel=11; uci commit; wifi reload bounced the cams AP phy1-ap1, and OpenWrt left the wireless-only bridge br-cams stuck state DOWN — the cams gateway/DHCP 192.168.30.1 vanished, all 4 Frigate cameras went fps=0 and the camwall froze. Any wifi reload that touches radio1 must be followed by the br-cams down/up recovery. Full incident: 2026-08-15-camwall-dead-br-cams-bridge-down-after-wifi-reload.

Graph View

Backlinks