Recommended RRM Power Profile

15 m density, dual‑band OpenWiFi deployment. Position‑based power planning with no scanning.

For a site where APs are placed on a floorplan roughly 15 m apart, the channel plan is already committed, and no RRM scanning is performed. Power is planned from AP positions alone: the planner takes each AP’s distance to its nearest neighbour and assigns one of three levels.

The values below are an engineering starting point chosen to be conservative, not a measured result. The acceptance check at the end is how you confirm they fit the property — run it before committing.

Profile settings

Heuristic Tx Power. Distances are in metres. Power values are attenuation from full, not absolute dBm.

BandBy ChannelDistance (Low)Power (Low)Distance (Medium)Power (Medium)
2.4 GHzunchecked12-9dB (1/8)22-6dB (1/4)
5 GHzunchecked10-6dB (1/4)18-3dB (1/2)
6 GHzuncheckedleave blankleave blankleave blankleave blank

On dual‑band hardware the 6 GHz fields have nothing to act on. Leaving them blank is correct and is also the explicit way to say “no plan for this band” — see the note on blank fields below.

Channel Mapper. Leave the entire section empty on this profile.

FieldSet toWhy
Simulated Annealing Stepsblankfalls back to 10000; this field affects channel planning only, never power
Channel Mapper Telemetryuncheckedexists to feed observed scan data into channel planning — there is none on a non‑scanning site
Min 2.4 / 5 / 6 GHz Radio Distanceblankdisables radios that are closer together than the threshold. A de‑densification tool, not a power control, and not something you want firing as a side effect of power planning

What this produces at 15 m spacing

The profile is written in attenuation, but the value sent to the AP is an absolute dBm between 1 and 30, computed as base + attenuation. Both are shown, because the two are coupled and the attenuation alone does not tell you what the radio does — see the conversion base below.

Situation2.4 GHz5 GHz
setdBm @ base 24setdBm @ base 24
Typical AP — nearest neighbour ≈ 15 m-6dB18-3dB21
Tighter than planned — < 10–12 m (landings, lobbies, doubled‑up APs)-9dB15-6dB18
Edge or isolated — > 18–22 mFull24Full24

The thresholds deliberately straddle 15 m so the nominal case lands in Medium rather than at either extreme. That is what produces a spread instead of a uniform result, and it means the plan tightens by itself wherever the build ended up denser than the design intent.

2.4 GHz is cut harder than 5 GHz for two reasons: it has three non‑overlapping channels against 5 GHz’s dozen or more, so co‑channel reuse pressure is far higher; and it propagates further, so APs that are comfortably separated at 5 GHz are still interfering at 2.4. If the operator also wants to steer clients off 2.4, -12dB Low / -9dB Medium is a reasonable second step — but commit the conservative set first and look at the result.

Why “By Channel” is unchecked, even with a channel plan committed

The option changes “nearest neighbour” to mean nearest neighbour on the same channel. A good channel plan deliberately separates same‑channel APs, so at 15 m nominal spacing the nearest same‑channel neighbour is much further away:

BandNearest same‑channel neighbour at 15 m spacing
2.4 GHz (3 channels)every 3rd AP → ~45 m
5 GHz (8–12+ usable)often 100 m+, or nothing on the floor

When the planner finds no same‑channel neighbour it assigns Full. So enabling this option while using thresholds sized for 15 m yields a plan that is almost entirely Full — the feature appearing to do nothing, for a reason that is not visible in the output.

Thresholds could instead be sized to same‑channel reuse distance, but the profile would then depend on the channel plan’s reuse pattern and would behave differently at a property with a different usable‑channel count (DFS enabled or not, 40 vs 80 MHz). For a profile meant to be reused across installs, physical geometry is the stable input and the channel plan is not.

If it is enabled anyway, note that whether planned channels are used at all is decided by inspecting only the first AP in the list. If that one AP happens to have no committed channel plan, the whole run silently falls back to current channels.

The conversion base — a pending change

Status: planned, not yet in effect. Today the conversion uses a base of 30 dBm. The intended value is 24. That change alters radiated power on every deployed OpenWiFi AP, so it belongs in its own merge request with its own risk review rather than riding along with a profile recommendation.

The rXg stores power as attenuation from full and converts to absolute dBm for the AP as base + attenuation, clamped to 1–30. The base is a parameter of that conversion with a default of 30. A base of 30 asserts that Full means 30 dBm — 1 W conducted, which these radios do not do. That is the reason for the change: the top of the scale is currently fiction, not merely offset.

Why this matters for the profile above. The AP clamps a config value it cannot achieve down to its own maximum, in the region of 23 dBm. At base 30, every attenuation from Full to roughly -7dB converts to 23 dBm or more and therefore clamps to the same radiated power. The top third of the dropdown is inert, and the profile’s Medium and Full levels are indistinguishable on air.

AttenuationConfig @ base 30Radio, if max ≈ 23Config @ base 24Radio
Full (0)30~2324~23 unchanged
-3dB27~232121
-6dB24~231818
-9dB21211515
-18dB121266

So the base correction is not a tidy‑up that happens to accompany this profile — it is what makes the profile take effect. Until it lands, expect the plan to differentiate only the deeper levels.

Two things to settle before the change ships. First, 30→24 is a 6 dB reduction; if the intent is exactly 7, the base is 23. Second, the clamping behaviour above is inferred from the hardware’s capability, not measured. It is directly testable without any scanning: set one radio to Full and another to -6dB, then compare the radio_power_level each reports in telemetry. Identical readings confirm the clamp, and give the merge request an evidence base for its impact assessment — including the useful finding that APs at Full are expected to see no change at all.

Related, now fixed. The lower clamp in the conversion was dead code: the guard holding results at or above 1 dBm was written inside a tap block, and tap returns its receiver, so the block’s value was discarded and only the upper bound ever applied. This was invisible at base 30 — the deepest attenuation available still lands at 12 dBm, and Minimum returns early, so no valid input reached the guard. It would have become reachable with the base change: at a base of 17, -17dB and -18dB produce 0 and −1 dBm, and an AP rejects a configuration carrying an out‑of‑range power rather than clamping it, so the symptom would have been radios failing to come up rather than a quietly wrong power. Replaced with a single two‑sided clamp, verified to produce identical output for every reachable value at base 30 — so it carries no field impact on its own and removes the trap ahead of the base change.

Prerequisites

  1. Floorplan scale correct on every floor. This is the one input that silently invalidates everything downstream: it converts image pixels to metres, and if it is wrong every distance is wrong by a constant factor while the plan still completes and looks plausible. Verify against one known dimension — a corridor length — before trusting any plan.
  2. APs placed, meaning both an area assignment and x/y coordinates. Any AP missing a coordinate is skipped silently and simply receives no plan.
  3. Zone TX power optimization disabled for this site. It is a separate, measurement‑driven system that writes the same TX power columns and has no awareness of the committed plan, so leaving it enabled invites the plan to drift. On a non‑scanning site it has no data to act on regardless, but the toggle should be explicit.
  4. Profile named for the standard, not the property. The Default flag is a singleton, and any area with no profile attached inherits whichever profile holds it — so a property‑named profile carrying Default silently becomes the house standard for every future site.

Acceptance check — before you commit

Create the power plan, then inspect the planned level across the placed APs. This needs no scanning and no client traffic.

What you see on 2.4 GHzReading
Mostly Medium, some Low, a few Full at the edgesCorrect. Commit it.
Nearly everything LowThresholds too large — the whole site is being attenuated
Nearly everything FullThresholds too small or the floorplan scale is wrong

The all‑Full case is worth separating carefully. On a corridor build at 15 m it should not happen with these thresholds, so suspect the scale before adjusting the numbers — a scale error produces a credible‑looking plan computed from fictional distances, which is considerably worse than a plan that obviously does nothing.

Limits of this approach

Nearest neighbour only, three levels. The planner uses the single closest AP and assigns Full / Medium / Low. Aggregate density does not enter the calculation, so an AP with six neighbours at 15 m is planned identically to an AP with one neighbour at 15 m. On a regular corridor or room grid this is a reasonable proxy, because nearest‑neighbour distance tracks density closely when the layout is uniform — but that uniformity is the assumption the whole approach rests on.

Geometry only. No measurement is involved, so the plan cannot know about a lift shaft between two APs 15 m apart, a concrete core, or an adjacent property’s interference. Inter‑floor separation is not measured either — it is assumed at 3.5 m per floor — so vertical distance is a constant, not a site characteristic.

Static. Nothing re‑plans on its own once the zone optimizer is off. The standard needs an explicit trigger to re‑run: APs added or moved, layout changed, or a neighbouring property coming online.

Blank fields do nothing, rather than defaulting. A band needs a complete distance + power pair or it is skipped entirely, with no warning. A distance with no power, or a power with no distance, is a silent no‑op for that band — which is exactly why the 6 GHz row above is left wholly blank rather than half‑filled.