There is a brain-science post going around right now that says I am not imagining it. It walks through the Default Mode Network, the part of your brain that lights up when you stop concentrating, and it argues that your best ideas come from stepping away. The core of that post is real. I have lived it for a quarter century. The problem is the post gets the science wrong in five specific ways, and the wrong parts are the parts people are quoting.

So here is the honest version. The science is real. The magic numbers are not.

What is actually true

In the late 1990s, a neurologist named Marcus Raichle at Washington University in St. Louis noticed something odd in brain scans. A specific set of regions, the medial prefrontal cortex and the posterior cingulate and precuneus, got quieter every time a person focused on an external task, and lit right back up the moment the task stopped. He named the pattern in a 2001 paper in PNAS called “A default mode of brain function.” It became one of the most-cited neuroscience papers of the century.

That is the spine of the viral post, and it holds up. The discovery is real. The man is real. The paper is real.

The energy fact is real too, and it is the genuinely surprising part. Your brain is about 2% of your body weight, and it burns about 20% of your body’s energy. That is a textbook fact, well established for decades.

Where the post breaks

Now the five things the post gets wrong. I am not pointing these out to be the smartest person in the room. I am pointing them out because I almost reposted the thing myself before I had it fact-checked, and a junior engineer reading it would walk away repeating numbers that fall apart on inspection.

One. “The DMN uses 20% of your body’s energy.” No. The whole brain uses about 20% of your body’s energy. The Default Mode Network is one network inside that brain, not the whole thing. Handing the brain’s entire energy budget to one network is a category error.

Two. “60 to 80% of your brain’s energy goes to the Default Mode Network.” Mislabeled. Raichle’s real finding is that roughly 60 to 80% of the brain’s energy supports constant internal signaling, the activity he nicknamed the brain’s “dark energy.” That intrinsic activity is not the same thing as the Default Mode Network. The honest punchline is the opposite end of the same fact: the extra energy a hard task demands on top of that baseline is tiny. Task-evoked changes run under 5%, sometimes as little as half a percent. Your brain is not mostly reacting to the world. It is mostly running its own internal model, all the time.

Three. “A break makes you 40% more creative.” The 40% is real, and it comes from a good study (Baird, Smallwood, Schooler and colleagues, 2012, in Psychological Science). People who took a break doing a simple, undemanding task did about 40% better on a creativity test afterward. The internet keeps dropping the one detail that matters most: that boost only showed up for problems the people had already been working on. Brand-new problems got zero benefit. Incubation is not general creativity magic. It is your brain continuing to chew on something you already loaded in. Note also that the lead author is Baird, not Schooler. Credit goes where credit is due.

Four. “A 2025 review proved insight problems need the network on and analytical problems need it off.” I could not find that review, and the clean on-off story it tells is not what the real literature says. The honest answer is that the science here is messier than the post wants it to be. When a tidy dichotomy gets attributed to a paper you cannot locate, leave it out.

Five. “Insights disappear within 90 seconds.” Invented. There is no study behind that number. Writing your ideas down before they slip is good advice. Dressing it up with a fake stopwatch is not.

The rule that actually matters

Strip away the bad numbers and you are left with something sharper and more useful than the viral version. Incubation only works on a problem you have already fully loaded in. The walk does not generate the idea out of nothing. It finishes the work your focused brain started.

So the rule is simple. Load the hard problem first, then walk.

This is exactly how the best Wi-Fi design happens, and it is why I have trusted my shower for 25 years. A real design problem is never one variable. You have the client device mix, the application requirements, the data rates each application needs, the construction materials, the ceiling heights, the survey data, the co-channel contention you are trying to avoid, and the budget that says you cannot just throw more Access Points at it. You cannot hold all of that loosely. You have to sit down and engage it hard, deliberately, until the whole tangled thing is loaded into your head and you can feel where it does not resolve.

Then you step away.

You take the walk. You stand in the shower. You let the focused part of your brain go quiet and let the constant background machinery keep working the problem you fed it. And more often than I can count, the answer that would not come at the desk arrives somewhere a notebook cannot follow. The right place for that fourth Access Point. The channel plan that finally stops fighting itself. The reason the validation survey kept coming back wrong.

That is not magic. It is incubation working the way the research actually describes it, on a problem that was already loaded. If I had not done the hard, boring, focused loading first, the walk would have given me nothing. A blank mind on a walk stays blank.

I cannot tell you my walk proves the 40% number. It does not. One person’s experience never proves a number. What I can tell you is that the practice the corrected science points to is the practice I already live, and it has shaped some of the trickiest designs of my career.

Load the hard problem first. Engage it until it is fully in your head. Then go do something boring without your phone, and keep a way to capture whatever surfaces. The science behind the shower is real. The magic numbers are not, and you do not need them.

What is the last hard problem you solved away from your desk, and had you done the focused loading first, or did it surprise you?

I have scored real survey files to prove the point, and the numbers are blunt. Walk tight and the map is measurement. Walk loose and large parts of it are the software inventing whatever makes the gradient look smooth.

The map is interpolation, and you decide how much

Every survey tool builds its heat map the same way. It takes the points where you actually measured, then fills the space between them by interpolating. Close points mean short fills and a map that tracks reality. Wide points mean long fills and a map that invents whatever makes the gradient look smooth. That invented part is the software’s best guess, not your data.

This is the one thing you control in the field. Not the AP placement, not the client mix, not the building. The walk. You decide how much of the final map is real and how much is guesswork, and you decide it with your feet and your clicks.

I built a small scoring method to put a number on that decision. It looks at how you walked and grades the one thing that actually drives map accuracy: how close your points are to each other.

The math, in plain language

There are two honest halves to this, and I am only going to claim the one I trust.

The trustworthy half is spacing. Take every consecutive pair of points on your walk, measure the real-world distance between them, and look at the average. Then drop it on a simple ramp:

• Mean spacing of 3 m or less scores 100. A dense, continuous walk.
• Mean spacing of 8 m or more scores 0. Stop-and-go with wide gaps.
• In between, it slides straight down the line.

Those two anchors are not arbitrary. They come straight from my own field guidance on why you do NOT use a stop-and-go survey. A good continuous walk averages 3 to 4 m between points. A stop-and-go survey averages 8 m or worse. The ramp just turns that rule into a score.

A good average can still hide a few ugly gaps, so I also report the 90th-percentile spacing. That is the gap that 90% of your points beat. If your mean is a clean 3 m but your p90 is 12 m, you have sloppy stretches an average alone would paper over. The mean tells you the typical walk. The p90 tells you the truth about your worst stretches.

There is a second half, coverage density, that asks whether you actually covered the whole space or just walked tight lines down the middle. I am not going to dress that one up. It is not calibrated yet, so I leave it out and report spacing plus the distance you walked. When I say spacing is the trustworthy half, I mean the other half is honestly still in the shop.

Four real surveys, one floor, four very different walks

I ran four example survey projects through this. Same floor plan, same software, same physics. The only variable was the walk, and the scores split exactly the way the theory says they should.

Read that and the lesson writes itself. The RTLS survey was walked tight, 3.67 m between points across 7 sessions and about half a mile on foot, and it scores Excellent. The other three were clicked 6 to 9 m apart, and the score flags every one of them as wide sampling, which is its whole job.

One thing I owe you before you react to those Poor scores. These four are Ekahau’s bundled demo projects, built to show off survey types, not to be careful production work. The wide spacing is exactly what you would expect from a demo, and the Poor scores are the method working, not a knock on anyone who touched those files. I am scoring the walks, not the surveyors.

Keith’s 7 rules, and the lever each one pulls

I have taught the same short list of survey rules for years. What I had never done until now is line them up against the scoring math and watch each rule move a specific number. Every one of them does. Follow them and the score takes care of itself.

Click when you start. That anchors the true beginning of the walk so the path does not guess its way back to wherever you last stood.

Click when you stop. That ends a walked segment cleanly, so the empty gap to your next starting point never gets counted as a measured stretch you didn’t actually walk.

Click when you change direction. Put a real point at every turn. Skip it and the tool draws a straight line through a corner you never walked, then interpolates data along a path your feet never took.

Walk both sides of anything you care about. Two passes double the real sampling around the things that drive decisions. That is coverage where it counts.

Check the known-important rooms. The CEO’s office. The boardroom. The one corner where a complaint will land on your desk by Monday. Walk those on purpose so the map shows measured data exactly where it would hurt most to be guessing.

The closer your data points, the more accurate the data. This one is the spacing sub-score stated out loud. Tighter points mean less interpolation, 3 m or under earns full marks, and there is no trick to it beyond clicking more often.

Click around a pause. This is the one that surprised me when I watched it in the math. Stop to talk, and click when you stop and again when you walk on. Here is why it works. When you stand in one spot and the tool logs several points within half a meter of each other, the method collapses that standing cluster into a single node before it does any spacing math. Standing still should never make your survey look denser than your feet made it. And clicking when you resume keeps your chat from fusing into one giant 30-meter leg that would read as textbook stop-and-go. The dwell-pause rule and the dwell-collapse math are the same idea seen from two ends, one in your hands and one in the score.

What a new surveyor actually needs to remember

You do not need the math. You need two habits. Click often and walk tight.

Click at the start, at every stop, at every turn, and the moment you pause or pick back up. Keep your lines close together and walk both sides of what matters. Do that and your average spacing drops under 3 m, the heat map becomes measured data instead of a smooth guess, and the score follows on its own.

The score was never the point. It is a mirror held up to your walk. A Wi-Fi survey is only as good as the walk that produced it, and now you know exactly how to walk one worth handing over.

Everything below is the US and the FCC.

The ceiling is per megahertz, not per channel

Going narrow in 6 GHz to get “cleaner” channels quietly throws away coverage. Drop from a wide channel to 20 MHz for less contention and your clients land weaker and roam later. That is a coverage decision, and most people make it without knowing they made it.

Here is why. In 6 GHz, EIRP is not a flat per-channel ceiling like the one you learned in the old bands. It is governed by power spectral density, a limit measured per MHz. Total radiated power scales with how many MHz you light up.

A narrow channel is legally quieter than a wide one at the same PSD ceiling. The gap between 20 MHz and 160 MHz:

10 · log₁₀(160/20) = 10 · log₁₀(8) ≈ 9 dB

That 9 dB is 8× less power radiated, the same 8× you saved in channel width, spent straight out of your link budget. Every doubling of width is worth 10 · log₁₀(2) ≈ 3 dB, and every halving costs you the same 3 dB.

Every doubling of channel width adds 3 dB to the ceiling, so a 20 MHz channel starts 9 dB down on a 160 MHz one before a single wall gets in the way. The gray part of each bar is the power you are allowed at any width. The green part is what the extra width buys you.

The same rule governs the access point, which is where the spec sheet starts misleading you. A Low Power Indoor access point on a 20 MHz channel cannot legally radiate 30 dBm. Its 5 dBm/MHz ceiling caps it at 18 dBm, a full 12 dB under the headline figure, and it reaches the 30 dBm cap only at 320 MHz. The “30 dBm access point” is a 320 MHz access point.

In 6 GHz, channel width is a coverage decision, not only a capacity one. Narrow when the airtime math demands it, but KNOW what the PSD ceiling charges you for it.

One more entry on the same ledger, and this one catches people who are trying to help: antenna gain counts against the EIRP cap. Bolt on a higher-gain antenna and the extra dB of gain comes out of your maximum EIRP, so the access point lowers its own transmit power to compensate. You buy reach and get a quieter radio.

The client transmits 6 dB below the access point

In 6 GHz, the client transmits up to 6 dB below the access point it is associated with. That is not a vendor default you can tune away. In the US it is written into 47 CFR §15.407, and it sets the real limit on the size of your cell.

Same 6 dB, two different mechanisms

Here is the part that trips people up. Low Power Indoor and Standard Power reach that 6 dB by completely different routes.

Standard Power is a live rule. The FCC requires the client to stay at least 6 dB below its access point’s AFC-authorized power. The Standard Power access point’s own ceiling is two numbers, 36 dBm EIRP and 23 dBm/MHz PSD. AFC can grant an access point less than the full 36 dBm at a given location, and when it does, the client tracks 6 dB below whatever the access point was actually cleared to use, and not 6 dB below the ceiling.

Low Power Indoor has no such clause. Its client cap is a flat −1 dBm/MHz and 24 dBm EIRP, sitting 6 dB under the access point’s flat 30 dBm. The gap is the same size, and there is no follow-the-access-point linkage behind it. Same number, different machinery.

Two panels, the same 6 dB, two different rules producing it. The bar that sizes your cell is the lower one in each panel.

Why the client and not the access point

6 GHz is shared spectrum. Licensed incumbents were there first, and unlicensed Wi-Fi has to stay quiet enough not to bother them.

The access point is the controlled element: fixed location, indoors for Low Power Indoor, AFC-coordinated for Standard Power. The client is the wildcard. It is mobile, there are a lot of them, and any one of them can end up parked at a window with a clean shot at a rooftop microwave dish or a satellite uplink. Capping the client bounds the worst case across the whole population of them at once.

What that does to your cell

Run a Low Power Indoor access point at its ceiling and your downlink is up to 6 dB hotter than anything the client can send back. The client hears the access point long before the access point can hear the client. Coverage is uplink-limited, so size the cell to the client’s power budget, 24 dBm EIRP for Low Power Indoor, and not to the access point’s.

The 6 dB is a transmit-power gap, and it is not a full 6 dB of lost range. The access point is the better receiver, with more antennas and a lower noise figure than any phone, so some of that transmit deficit gets clawed back on the receive side. The link will always be asymmetric. It is usually less asymmetric than the raw 6 dB suggests.

Remember, in Low Power Indoor the client is NOT tied to the access point’s Tx power. It is held against a fixed maximum of 24 dBm EIRP. Turn an access point down to balance the link and you have not raised the client by a single decibel. You have only made your own downlink quieter.

The client inherits the access point’s class

Your 6 GHz client never picks its own power. It inherits whatever access point it joins. Under 47 CFR §15.407(d)(5)(i), a 6 GHz client operates under the control of the access point it associates with. Every question about client power is an access point question.

Join a Low Power Indoor access point and the client is capped at 24 dBm EIRP with a −1 dBm/MHz PSD ceiling. Join a Standard Power access point and that ceiling rises to 30 dBm EIRP and 17 dBm/MHz, and the cell can go outdoors.

The headline is “+6 dB.” That number is honest only on the widest channel.

Why “+6 dB” undersells it

The EIRP ceilings are 6 dB apart: 24 against 30. The PSD ceilings are 18 dB apart: −1 against 17. That second gap is the whole story.

Work each width through the same rule that governs both clients, the lower of the EIRP cap and the PSD ceiling plus the width term, and the two classes separate:

The Standard Power line is flat and the Low Power Indoor line climbs. That divergence is the product being sold: 6 dB at 320 MHz, 18 dB at 20 MHz, and the biggest numbers land on the narrow channels where most clients sit.

“+6 dB” is the minimum, and it shows up only at 320 MHz. Standard Power’s biggest gift to the client lands exactly where Low Power Indoor is most PSD-starved, on the 20, 40 and 80 MHz channels most 6 GHz clients use. Narrow the channel and Low Power Indoor bleeds power fast, while the Standard Power client holds its full 30 dBm.

Standard Power’s 30 dBm is only a ceiling

If AFC authorizes the access point to only 30 dBm at that location, the client sits at 24 dBm, dead even with a Low Power Indoor client. Authorize the access point lower and the Standard Power client drops below a Low Power Indoor client. The gain is real, and it is conditional on what AFC actually grants at that address.

The client also has to support Standard Power at all. Many first-generation Wi-Fi 6E clients shipped Low Power Indoor only. Deploying Standard Power access points does not hand every associated client the 30 dBm ceiling. The client needs the capability too.

A fourth class, running the same client rule

In January 2026 the FCC authorized a fourth class of unlicensed 6 GHz device, Geofenced Variable Power, and the client rule inside it says the client’s ceiling sits 6 dB below the access point’s authorized power, not the power the access point happens to be sending right now.

That is the same design law I keep coming back to: plan to the client, and plan to what the access point is permitted to do, never to what it is doing this second.

GVP is rules on paper. The order took effect April 27, 2026, and no geofencing system has been approved, and no GVP access point or client has been certified or shipped.

The numbers

GVP is authorized in U-NII-5 (5.925 to 6.425 GHz) and U-NII-7 (6.525 to 6.875 GHz), the same two sub-bands as Standard Power.

The GVP access point may transmit up to 24 dBm EIRP and 11 dBm/MHz PSD. The GVP client may transmit up to 18 dBm EIRP and 5 dBm/MHz PSD, with its ceiling pinned 6 dB below its access point’s authorized power.

The one line to memorize

Here is where the FCC pre-empted the mistake nearly everyone makes. The client’s ceiling is 6 dB below the access point’s maximum permitted power, not 6 dB below what the access point is transmitting. The order says it plainly: when a GVP access point runs below its maximum, the client’s limit is still figured from the maximum permitted level, and not from the reduced transmit level.

When geofencing caps the access point below its maximum inside an exclusion zone, the permitted ceiling itself drops, and the client tracks 6 dB below that reduced permitted level. Cap the access point at 14 dBm and the client is held to 8 dBm.

Read the access-point-to-client row straight across. Standard Power and GVP tie the client to the access point’s authorized power, Low Power Indoor’s 6 dB is two fixed caps that happen to land 6 dB apart, and VLP has no split at all. The GVP column is a rule, not hardware you can order.

What “geofenced” actually means

This is what makes GVP a fourth class rather than a flavor of the other three. A GVP access point has to know where it is and be told what it may do there.

It carries built-in geolocation to find its own coordinates. Before it transmits, it registers with and is authorized by a geofencing system. It refreshes that frequency information at least once per day.

AFC assumes a fixed, registered address. Geofencing is built for a device that moves, and the logic may even run on the device itself, which AFC never allows. Read GVP as AFC without the fixed address, the first 6 GHz power class designed for Wi-Fi that moves, outdoors, at real power.

Every Very Low Power device is held to 14 dBm EIRP and −5 dBm/MHz PSD, the lowest ceilings of the four classes. That PSD is NEGATIVE, where the GVP client above sits at a positive 5 dBm/MHz. Once approved systems and certified hardware arrive, GVP will fill the gap VLP cannot reach: higher power than VLP, outdoors, without a fixed AFC registration.

Standard Power buys its power by spending channels

Standard Power buys power by spending channels. At 20 MHz in the US it reaches 41 of the 59 channels Low Power Indoor can use, with 18 dB more power. At 160 MHz it reaches 4 of 7, with 9 dB. Widen the channel and both halves of that trade move against you at once.

The trade, in numbers

Standard Power is authorized in 5.925 to 6.425 GHz and 6.525 to 6.875 GHz. Low Power Indoor is authorized across 5.925 to 7.125 GHz, the entire band. What Standard Power loses is the middle and the top. U-NII-6 sits between the two ranges it keeps, and U-NII-8 sits above them. No Standard Power channel may span the 100 MHz hole at 6.425 to 6.525 GHz, so every channel has to fit whole inside one range or the other. That fit is imperfect even at 20 MHz, and it gets worse as channels widen.

The white gap in the Standard Power row is the argument. U-NII-6 sits between the two ranges Standard Power keeps, so no Standard Power channel may straddle it. The counts in the table are what the rules permit at each width, not what a particular site will be granted.

Put the two halves together and the decision takes a shape. Narrow channels are where Standard Power’s power advantage is largest and where it keeps the largest share of the grid. Wide channels are where it is weakest on both counts.

Where the restriction comes from

The labels U-NII-5 through U-NII-8 appear nowhere in Part 15. They are FCC order and industry shorthand. Part 15 grants rather than prohibits, so the accurate phrasing is that the Standard Power authorization does not extend to U-NII-6 and U-NII-8.

The FCC described those two sub-bands as the ones where “many of the incumbent operations are mobile.” AFC cannot protect what it cannot look up. A transmitter that moves has no location on file, so there is no exclusion zone to compute around it. Standard Power exists only where AFC can work.

And channel counts are IEEE, not FCC. The rules define frequency ranges and power limits, never channels. Lay the 6 GHz channel grid over the authorized ranges and two edges come up short.

One product behavior to ask about

At least one vendor ties an access point configured for Standard Power with Low Power Indoor fallback to the Standard Power channel list in both modes, so it gives up U-NII-6 and U-NII-8 even while running as Low Power Indoor. That is sound engineering, since the access point never has to change channel when the grant lapses. It is also a product decision rather than a rule, so ask your vendor which way theirs behaves.

Before your next 6 GHz design

Four checks, and you can run all of them against a design you already have:

• Pick the channel width before you pick the power, and price the width in dB before you price it in airtime.
• Size the cell at the client’s ceiling: 24 dBm for a Low Power Indoor client, and 6 dB under whatever AFC actually granted for a Standard Power one.
• Count antenna gain against the EIRP cap rather than on top of it, and expect the access point’s transmit power to drop when you add gain.
• Ask your vendor whether an access point in Low Power Indoor fallback still honors the Standard Power channel list.

All four cost you a conversation and a spreadsheet column, and all four are cheaper than a validation survey that comes back short on uplink.

Settle the width first

Indoors, Standard Power is a narrow-channel reach tool and Low Power Indoor is a wide-channel capacity tool. Settle the width first and the power class then follows. That ordering holds for the geofenced class as well, since GVP is authorized in the same two sub-bands as Standard Power and inherits the same hole in the middle.

Then size the cell to the client. The access point’s number is the one you can read off a spec sheet. The client’s number is the one that has to answer back, and in 6 GHz it is the smaller of the two by rule.

Which do you settle first on your next indoor 6 GHz design, the channel width or the Tx power?

You do not need to read the 30-tip viral thread. There are about a dozen Google privacy settings worth your time, every one of them real, and you can change them in an afternoon. Turn off the three Activity Controls, set auto-delete to 3 months, delete the history you have already piled up, kill ad personalization and voice retention, and tighten a couple of phone permissions. Do those and you have addressed 90 percent of what those threads are shouting about, without any of the made-up dollar figures they pad the list with.

I am a Wi-Fi guy, not a privacy crusader. I spend my days measuring what radios actually do, and that habit carries over: when a viral thread tells me a setting “tracks you” or “sells your data,” I want to know what is real, what is folklore, and what is just a screenshot dressed up to go viral. Most of these Google threads turn out to be more accurate than the battery ones riding alongside them. The settings are real. The settlements are real. The price tag some of them slap on your data is invented. Here is the honest short list.

The settings that actually matter

Open myactivity.google.com on a signed-in account and you will see Google has kept a running record of your searches, your location, your YouTube history, and your voice activity. That part is true, and it is the part worth acting on. The rest of the privacy menu is mostly noise once you have done these.

Turn off the three Activity Controls:

• Web & App Activity stops Google logging your searches and the things you do across its apps and sites.
• Location History stops the running map of everywhere you have been.
• YouTube History stops the watch-and-search log that feeds recommendations.

Those three switches do the heavy lifting. Everything below is cleanup and reinforcement.

Set auto-delete to 3 months. For whatever activity you decide to keep, Google offers a 3, 18, or 36 month auto-delete window. Pick 3. There is no reason a search you ran last spring should still be on file.

Delete the history you have already accumulated. Pausing collection going forward does nothing about the years already stored. My Activity lets you delete across all time. Before you do, run Google Takeout and pull a full export if you want your own copy. Export first, delete second. Measure twice, cut once.

Turn off Ad Personalization at myadcenter.google.com. This is the toggle that stops Google building an ad profile out of everything above.

Turn off Voice & Audio Activity. When this is on, Google can retain actual audio snippets of your “Hey Google” requests. Off means it stops keeping the recordings.

Turn off Gmail and Workspace smart features. Gmail has a smart-features toggle, and there is a separate Workspace switch most people never find. Both let Google read your mail content to power “helpful” features. If you do not want that, turn them off. Note the phone app manages this setting separately, so flip it in both places.

Delete your Gemini Apps Activity. Google states a sample of Gemini conversations is reviewed by humans. If you have been typing things into Gemini you would not want a stranger reading, clear that history.

Then two phone-permission moves that matter more than most of the menu toggles:

• Revoke Bluetooth from non-audio apps. A weather app or a retail app asking for Bluetooth is usually after beacon proximity tracking, not your headphones. If it does not play audio, it does not need Bluetooth.
• Tighten Location to “While Using” or “Never.” Far too many apps default to “Always.” Almost none of them need it.

If you are on Android, do one more: delete the Advertising ID, do not just reset it. Android 12 and later let you remove it entirely, which is the stronger move.

Last one, with a caveat. Review your Maps Timeline. It is real, and you can disable it. Google is mid-migration to storing Timeline on-device for new accounts, so the exact menu path may have moved by the time you go looking. Check it live rather than trusting any screenshot, including this article.

Why this is worth an afternoon

Here is the part the threads get right, and it is the reason I bothered writing this down.

The seductive claim in some versions, that your data is “worth 460 dollars a year to Google,” is garbage. There is no primary source for it. It gets falsely pinned to a Trinity College Dublin study that measured how much data your phone sends, in megabytes, not what that data is worth in dollars. When a privacy tip reaches for a precise dollar figure on your personal information, that is the moment to stop trusting it. I will not repeat a number nobody can source.

The legal record, though, is real, and it is bigger than most people realize:

• A 391.5-million-dollar settlement across 40 states in 2022, over Google continuing to track location even when users believed Location History was off.
• A 1.375-billion-dollar settlement with Texas in 2025, covering biometric and location-tracking claims.
• The Incognito case, Brown v. Google, where Google agreed to destroy or de-identify billions of records it had collected from supposedly private browsing.

Read those three together and the picture is plain. The reason “turn off Location History” made it onto every one of these threads is that turning it off was not enough, which is exactly what the 40-state settlement was about. The companies that hold your data have been told, in court, with real money attached, that they crossed lines. The settings above are your half of the response. They are not paranoia. They are hygiene.

What I would actually do

You may want to read every privacy tip on the internet, but you must do the handful that work. Here is the whole list, in order:

• Turn off Web & App Activity, Location History, and YouTube History.
• Set auto-delete to 3 months.
• Export with Takeout, then delete your history across all time.
• Turn off Ad Personalization and Voice & Audio Activity.
• Turn off Gmail and Workspace smart features.
• Delete your Gemini Apps Activity.
• Revoke Bluetooth from non-audio apps and set Location to “While Using” or “Never.”
• On Android, delete the Advertising ID.
• Review your Maps Timeline, checking the live menu path.

That is an afternoon, once, and most of it stays done. Everything else in those viral threads is either a restatement of these or a dollar figure someone made up. Take the settings that matter, ignore the price tag on your data, and verify any menu path live before you trust it, because Google moves the furniture more often than anyone publishing a screenshot bothers to mention. Which of these settings did you assume you had already handled, and how long had it actually been on?

The most-shared phone battery thread of the season has the single most important setting backwards. It tells you to turn OFF “5G Auto” to save your battery. 5G Auto is the battery-saver. Apple built it to fall back to LTE on its own whenever 5G adds nothing, which is most of the time. The thread’s villain is the actual hero. That is the problem with viral battery tips: one or two are genuinely useful, and the rest are folklore wearing a lab coat.

I spend my days measuring what radios actually do. When a tip says a toggle “broadcasts a signal” or “keeps the modem firing,” that is not magic to me, it is a measurable behavior with a known cost. Some of these tips are right. Some are right for the wrong reason. And a few are wrong in a way that, if you follow them, makes your phone worse. Here is the honest scorecard: the settings that earn their place, then the ones you are wasting your attention on, then why I refuse to print the numbers everybody else is printing.

The real wins

Start with the one myth that matters most, because almost everyone has been taught it wrong.

Stop force-quitting your apps. Swiping every card out of the App Switcher feels productive. It does nothing good for your battery. Apple’s own software chief, Craig Federighi, was asked directly whether you should quit apps to save power and whether doing so helps battery life. His answer was “no and no.” A suspended app sitting in the background costs almost nothing. Relaunching it from a cold start costs MORE energy than leaving it alone. The ritual you have performed for years is, at best, a placebo, and at worst a small net loss. Stop swiping.

Leave 5G Auto on. Apple calls the underlying behavior Smart Data Mode. With 5G Auto, the phone uses LTE whenever 5G would not actually improve what you are doing, and only reaches for 5G when 5G helps. That self-throttling is the whole point. The setting that keeps the 5G radio lit no matter what is “5G On,” and that is the one that costs you. Forcing the phone all the way down to LTE only helps in a genuinely weak-5G spot where the radio would otherwise sit there hunting. For almost everyone, 5G Auto is already the smart choice. You find it under Settings, Cellular, Cellular Data Options, Voice & Data.

Use Low Power Mode when you need the runtime. This is the single most effective toggle on the list. It throttles background work, dims the display, and trims the things that quietly eat your charge. On the iPhone it is one switch in Settings, Battery. macOS has its own Low Power Mode you can set to kick in on battery. When you are watching the percentage tick down before a flight, this is the one to reach for. It works, and it works more than any single toggle the viral threads obsess over.

On a Mac, check “Wake for Network Access.” This setting lets a sleeping MacBook wake periodically to check the network, which can nibble battery overnight. The effect is bigger on older Intel machines and smaller on Apple silicon. If your Mac loses more charge asleep than you expect, turn this off under Battery options and see if the overnight drain stops. Real mechanism, easy to test on your own machine.

Switch low-priority Mail accounts from Push to Fetch. Push holds a connection open so mail arrives the instant it lands. For accounts you do not need that fast, Fetch (or Manual) means fewer radio wake-ups. The gain is modest, but it is real, and it costs you nothing except a few minutes of delay on email you were not refreshing for anyway.

Trim Background App Refresh for apps that do not need it. This is honest housekeeping. Some apps have no business updating themselves in the background. Turn them off and you cut a little needless work. The gain is small. It is also free, and it is real, which is more than I can say for half the thread.

Turn off Always-On Display extras (iPhone 14 Pro and up). The Always-On Display is a dimmed panel refreshing slowly, so it does use a little power. Turning off the wallpaper and notifications on it, or turning the whole feature off, trims a sliver. Small, but real, and yours to decide.

Turn off Sound Recognition if you do not use it. This is one of the rare “always-on” features that genuinely keeps the microphone analyzing audio continuously, listening for alarms, doorbells, and the like. That is a real ongoing cost, unlike most of the mic scare stories. If you turned it on once to try it and forgot about it, switch it off under Settings, Accessibility, Sound Recognition.

The placebos: stop wasting your time

Now the part the viral threads get wrong, and get wrong with confidence. These toggles run on dedicated low-power coprocessors, the silicon built specifically so these jobs cost almost nothing. Turning them off to “save battery” buys you essentially nothing:

• Step and motion counting runs on a low-power motion coprocessor, not your main chip. It is effectively free.
• “Hey Siri” always-listening runs on a dedicated always-on processor built for exactly that one job. The “your mic is draining your battery” claim does not match how the hardware works.
• Keyboard haptics fire the Taptic Engine for a few milliseconds per keystroke. The cumulative battery cost is trivial.
• Significant Locations is computed opportunistically from location the system already has. It is a fine privacy toggle if you want it off. It is not a battery move.
• Analytics and diagnostics uploads happen opportunistically, usually on Wi-Fi while charging. Negligible.
• Live Activities and lock-screen widgets are budget-throttled by iOS, not free-polling every few seconds the way the threads claim.

Some of these are still reasonable privacy choices. None of them are battery choices. Turn them off because you want them off, not because some thread promised you an extra hour.

And one tell worth knowing: if a tip arrives wrapped in an “an Apple Genius told this man” story, that framing is the giveaway. Real settings do not need a campfire story to sell them.

Why I will not give you the percentages

You may have noticed I have not handed you a single number. No “12 to 18 percent.” No “1.8 to 2.4 hours.” No “30 percent overnight.” That is deliberate.

Every one of those figures floating around these threads traces back to content farms, not to Apple. I went looking for a primary source on each, and there is not one. The direction of every tip above is solid, I can stand behind which way each setting pushes your battery. The precise percentages are invented, and I will not print a number I cannot source just to make the advice feel more scientific.

That is the difference between a tip from someone who measures this stuff and a tip written for reach. The reach version needs a big number to earn the share. The honest version tells you the direction, tells you the mechanism, and trusts you to decide.

Stop force-quitting your apps, because it never helped. Leave 5G Auto on, because it is the battery-saver the thread told you to kill. Reach for Low Power Mode when you actually need the runtime, and skip the step-counter and the “Hey Siri” toggle, because they run on chips built to cost you nothing. The rest is rounding error dressed up as a revelation. What is the one battery tip you followed for years before you found out it did nothing?

The one that stings

Ping Sweep scans a network segment and tells you which devices are alive and answering. It was calling dead ones alive. A device that was actually down and unreachable came back as responsive.

Think about what you do with that. You trust the tool, you cross the device off the list, you skip the investigation, and you go looking somewhere else while the thing you needed sits offline. A tool meant to keep you out of trouble could have walked you straight into it.

The fixed tool reports how many hosts answered on the port it probed, and when none of them do, it says so and refuses to draw the conclusion for you. Hosts that are ICMP-only, or that firewall the port, will not appear. Silent hosts may still be up. A scanner that cannot see a host has no business calling it alive, and it has no business calling it dead either.

The app argued with itself about your signal

This one is quieter and it goes deeper.

Our analyzer graded your RSSI on one set of thresholds. Our own Signal Thresholds reference screen showed you a different set. The same dBm reading got two different grades depending on which screen you happened to open.

At -73 dBm, the reference screen told you the signal was fair and usable. The analyzer, looking at the identical number, told you the signal was weak, that you were at the edge of coverage, and that no faster internet plan was going to touch it. One of those answers sends an engineer up a ladder to move an Access Point that was fine where it was.

The reference screen carried values I had reviewed and corrected myself. The grading constants behind the verdict engine were never updated to match. Nothing in the code tied the two together, so nothing ever complained. Both surfaces now read from one shared source, and a test fails the build if they ever drift apart again.

That is the finding I would want a working engineer to take from all of this. An app that contradicts itself about the same measurement cannot be used as a reference, and being a reference was the entire job.

We showed our work, and our work was wrong

A handful of tables in the app named their sources right there on the screen. Those turned out to be among the most wrong things in the product. One printed its standards document under the data, and its numbers did not match the document it cited.

A citation nobody pins to the value it justifies does not make the data right. It makes the data look right, and it stops the next person from checking. Ours had exactly that effect for the life of the product.

The mechanism is the part worth taking back to your own work. The numbers were not invented. Every one of them was a real published value, correct for a different input than the one printed beside it. Every sanity check we knew how to run came back clean, and internal consistency was preserved by the very nature of the bug.

A number can be self-consistent and still be a lie.

The only check that catches that is a comparison against an external primary source at a named input. It was the one check we did not have. We have it now, and we went through the rest of the reference tables and corrected what we found there.

The tests were green, and they could never have caught it

We had a large test suite and it was all green.

Our tests were generated from the code. They proved the port was faithful, that the app computed what its own source data said it should. They could not prove the source data was ever right, and the source data was wrong.

The signal-grading tests were the purest version of the problem. They derived the dBm values they expected from the very constants they were testing. A test built that way cannot fail. It can only agree with you.

I was double-checking. I was checking the wrong thing.

The new tests assert against the standards documents and the manufacturer datasheets, never against us. And one of them now checks the two signal screens against each other, so the app can no longer disagree with itself in silence.

The good, and the platform that is still broken

We published exactly what was wrong. No burying it in a vague “performance improvements” note, no spin. If a number was broken, we said so, and we said by how much.

The corrections are live on iPhone, Mac, and Android.

They are not on Windows. Our Windows build machine was reimaged and the build key went with it, and we cannot rebuild that platform until I am physically back at the machine. Windows users are running the pre-audit build right now: the scanner that calls dead hosts alive, the grading that argues with itself, all of it. There is no version of that sentence that sounds good, and I am not going to dress it up. We are telling you instead of letting you find out.

Why we are opening the whole thing up

We are going a step further. We are relicensing the entire app under AGPL-3.0 and opening the source. That decision is made and the license is already committed to the code. What is left is cleaning up the repository history, and then it goes public. Two reasons, both about you.

First, you should never have to just take our word for it. Once the source is public, anyone can look inside and check our numbers for themselves. Trust you can verify is worth more than trust you are asked to assume.

Second, AGPL keeps the Toolbox free and open for the working professionals who use it, including in their paid work. A “non-commercial” license would have locked out our own audience, the exact people this was built for. And it makes sure any improvement anyone makes stays open for everyone else too.

The one we missed

Then, on the night before this article was meant to publish, I found a worse one. On my own phone.

I was on cellular. No Wi-Fi at all. I opened Test My Connection, the tool at the front door of the app, the one somebody reaches for first when their internet feels slow. It showed me a Wi-Fi signal card with a green LIVE badge. It showed a Wi-Fi data rate of 29 Mbps. And it handed me this verdict:

“Your internet can carry more than your Wi-Fi link is passing. Boost the Wi-Fi signal to raise the ceiling.”

It told a man with no Wi-Fi to go improve his Wi-Fi.

The 29 Mbps was a real number once. It was the last reading that phone ever took, from the last time it had been on a network. The app kept showing the last number it had ever seen, and it put a LIVE badge on it.

The cause was a gate. The honest “You are not connected to Wi-Fi” state only appeared for someone who had never captured a Wi-Fi reading at all. Once you had seen one, dropping to cellular did not clear it. The intent was kind. Do not blank out a user’s data over a brief signal drop. The effect was dishonest. The app presented a number it did not have.

Two things about it are worse than the bug.

It was not new. It shipped in earlier releases, which means it was live on our own front page the whole time we spent auditing ourselves and feeling good about it.

And our own audit missed it. The audit swept reference data, the tables and formulas sitting behind every number the app prints. This was a state bug, a different animal. A state bug is about what the app does when the thing it is measuring is not there. Our audit asked whether our numbers were right. It never asked the harder question: is the app honest when it has no number at all?

We fixed it. And we held this article until the corrected build was live, because publishing “we audited ourselves and fixed it” on top of a live bug on our own front page would have been the exact behavior this piece argues against.

What this comes down to

We say we care about accuracy, and we say we care about this community. Anyone can say that. This is what it looks like when you mean it and nobody is forcing your hand. You audit your own work harder than anyone else would. You admit what you find. You fix it in public. And you hand people the tools to check you.

The Toolbox is not perfect today, and we are not going to pretend it is. An entire platform is still running the broken build and we just told you which one. The audit was not a thing we did once and finished. We are still looking, and we expect to keep finding.

When a tool hands you a result, how do you know you can trust it?

Vote for Prague 2026

I walk the same 12 checks every time, bottom-up the stack. Each one proves a single thing, and each one depends on the one before it. Skip a step and you end up guessing. Run them in order and the failure tells you exactly where it lives.

Here is the ladder.

Step 1: Can the client see all SSIDs being broadcast?

Before anything else, prove the client can hear the network. If the target SSID does not show up in the scan, nothing downstream matters. You have an RF visibility problem, not a network problem.

On 6 GHz this looks different than it used to. A Wi-Fi 6E or Wi-Fi 7 client does not blindly scan every 6 GHz channel. It learns about the 6 GHz AP out-of-band, through a Reduced Neighbor Report from the 2.4 or 5 GHz radio, and through preferred scanning channels. The mechanism got smarter. The check did not change. Can the client see the network it is supposed to join? Yes or no.

Step 2: Associate to the target SSID

Seeing the SSID and joining it are two different events. Association is the client and the AP agreeing to talk. If the client sees the network but cannot associate, you are looking at the AP, the band, or a client-capability mismatch, not RF coverage.

Step 3: Complete SSID authentication

Association gets you in the door. Authentication proves you belong. This is where a wrong PSK, a misconfigured RADIUS server, or a 802.1X failure stops the client cold.

The methods behind this step advanced since the card was first drawn. WPA3-Personal with SAE and WPA3-Enterprise are mainstream now, and 6 GHz mandates WPA3. Open networks and legacy WPA2 are not allowed on 6 GHz at all. So if you are testing a 6 GHz join and the client is trying to authenticate with anything below WPA3, the failure is by design. The step is identical. The security baseline underneath it moved up.

Step 4: Receive an IP address via DHCP

Authenticated and on the network, the client now needs an address. No IP, no Layer 3. If authentication passed but DHCP did not deliver an address, the radio side is healthy and your problem is upstream, in the DHCP scope, the VLAN, or the relay.

Step 5: Receive default gateway and DNS

An IP address alone gets the client nowhere useful. It needs to know where to send traffic, the default gateway, and how to resolve names, DNS. DHCP hands these over with the address. Confirm the client actually received them. A missing or wrong gateway looks like a dead connection even though association, authentication, and addressing all passed.

Steps 6 through 9: Ping the path, then read it correctly

Now you prove reachability, in widening circles:

• Ping the default gateway. Can the client reach its own first hop?
• Ping DNS. Can it reach the resolver it was handed?
• Ping a remote IP address. Can it reach off the local network?
• Ping a remote DNS name. Does name resolution plus routing work end to end?

This is the part of the card that needs modern interpretation, and it is the most important thing to internalize about ping in 2026.

Ping still proves Layer 3 reachability, and it is still a fine first cut. A failed ping is a strong negative. If you cannot reach the gateway, you have found your problem and you stop here.

But a passing ping is no longer a verdict. ICMP, the protocol behind ping, is now routinely rate-limited, deprioritized under QoS, or blocked outright on modern networks. That means a ping can come back slow, or with loss, on a connection that is actually fine, because the network is throttling ICMP on purpose while real application traffic sails through untouched. It also means a ping can pass while the link underneath it is garbage.

Treat ping as a reachability gate, not a performance measurement. Use it to answer one question: is the path open? Yes or no. The moment you start reading ping latency as your connection’s speed, the network’s QoS policy is lying to you and you are believing it.

For the performance picture, you do not look at ping. You look at the next three steps.

Step 10: Check the client MCS

MCS, the Modulation and Coding Scheme index, is the radio reporting the link quality it actually negotiated, independent of whether any traffic is flowing. It is the RF-layer truth. A low MCS on a client that should be close to the AP tells you the RF conditions are worse than the signal bars suggest.

Read the ceiling correctly for the generation you are on. The original card came from the 11ac era, where MCS topped out near MCS 9 with 256-QAM. A modern client can report up to MCS 11 with 1024-QAM on Wi-Fi 6, and MCS 12 or 13 with 4096-QAM on Wi-Fi 7. On a Wi-Fi 7 link the label carries a prefix, EHT-MCS, where Wi-Fi 6 says HE-MCS and 11ac said VHT-MCS. Same index concept, generation-stamped name.

One thing to know before you call a low number a fault: 4096-QAM, MCS 12 and 13, needs roughly 42 dB of SNR and is an optional Wi-Fi 7 feature. Not seeing MCS 12 or 13 is very often correct behavior, not a problem. The client is telling you the honest truth about its RF conditions, which is exactly why this check earns its place.

Step 11: Check the client Tx data rate

This is the single most useful line on the card. The negotiated Tx data rate is the actual speed the radio achieved, the real number, before any application ever sends a byte. Modern ceilings are far higher than the card’s era, 320 MHz channels and 4096-QAM and MLO on Wi-Fi 7 push the top end way up, so “what good looks like” is a bigger number now. The act of reading the client’s real Tx rate is unchanged, and it is the truth a speed test only approximates.

Step 12: Complete a network speed test

Last, and only last, run the speed test. This is the application-layer consequence of everything above it. By the time you get here, you already know the RF link is good, because you read the MCS and the Tx rate. The speed test confirms the end-to-end experience matches the link you measured. When the Tx rate is high and the speed test is low, your bottleneck is not the Wi-Fi, it is somewhere upstream, and you have just saved yourself from blaming the radio for the internet’s problem.

That ordering is deliberate. Read the negotiated rate the radio actually achieved first, then run the application speed test. The Tx rate is the RF truth. The speed test is the downstream result. Never invert it into “just run a speed test and see,” because a speed test alone cannot tell you where a slow result was born.

Why bottom-up, every time

The 12 checks isolate where a connection breaks by walking the stack from the radio up: RF visibility, association, authentication, addressing, reachability, PHY-rate quality, then end-to-end throughput. Each step proves one thing. The first step that fails is your answer. You stop guessing the moment the ladder stops climbing.

Test from the client device, in order, from the radio up. Read ping as a gate and not a stopwatch, read the Tx rate as your truth, and let the speed test confirm what you already measured. Do that and you will know where every broken connection actually breaks, instead of arguing with a controller dashboard about a problem the user is living and the dashboard cannot see.

The WLAN Pros Toolbox is now free on all five platforms: iPhone, iPad, Mac, Android, Windows, and the web. No account, and nothing to buy.

I built it because I was tired of carrying a separate app for every calculation I do on a job. Now it’s one app, 173 tools, on every device you own.

Inside you’ll find:

• RF and Wi-Fi calculators: antenna length, EIRP, free-space path loss, link budget, Fresnel zone, dBm to watts, and more
• Live Wi-Fi analysis: RSSI, noise, SNR, data rate, channel, width, and band, plus a Test My Connection tool that tells you whether the slow Wi-Fi is the Wi-Fi or the internet feeding it
• Network utilities: ping, traceroute, DNS lookup, subnet and CIDR math, HTTP status codes
• Field and Trade Reference, new in this release: electrical and cabling references for the job site, plus interactive decoders that read a NEMA plug code or a vendor model number back to you
• Reference: a 92-term glossary with both IEEE and Wi-Fi Alliance names, laminated PDF cards, curated educational resources, and a spectrum-analysis reference module

Every calculation runs on your device. The privacy label reads “Data Not Collected,” and it’s honest. Turn off your radio and the calculators still work.

Download it free:

• iPhone and iPad: https://apps.apple.com/app/id6775594754
• Android: https://play.google.com/store/apps/details?id=com.wlanpros.wlan_pros_toolbox
• Windows: https://apps.microsoft.com/detail/9NCVHM6ZL4X0
• Mac: https://toolbox.wlanpros.com/
• Web, no install: https://toolbox.wlanpros.com/app

The live tools, Check My Connection and Wi-Fi analysis, run in the native apps where they can reach your radio; the web version gives you every calculator, reference, and the glossary, fully offline.

Put it on your home screen. The next time you’re on a job and need a fast EIRP check, or want to prove where a slowdown actually lives, it’s right there.

Then tell me which tool we should add next.

Putting one Access Point in every classroom does not make a school’s Wi-Fi better. It makes it worse. More APs packed close together is not more capacity, it is more co-channel contention, and contention is the thing that slows a network to a crawl the day the students actually show up with their devices. I wrote that in 2014. After running the full design process through more than 4,000 classrooms since, I have not found a single reason to change the verdict.

Capacity is a frequency-reuse problem. It has never been an AP-count problem. When the frequency is full, no more traffic flows, no matter how many Access Points you bolt to the ceiling.

The “1:1” confusion that started it

K-12 schools moved to 1:1 initiatives: at least one device per pupil. Then Bring Your Own Device piled on top, so even young children show up with a phone or tablet in the backpack. The demand is real. A district has to plan for a lot of clients.

Somewhere in the rush, “one device per pupil” got quietly swapped for “one Access Point per classroom.” Those are not the same statement. One is a demand estimate. The other is a Bill of Materials dressed up as a design.

I have seen RFPs written by people who do not work in RF or 802.11 drop “one AP per classroom” straight into the requirements, because another district did it and the phrase was easy to copy. It is our job as Wireless LAN Professionals to design correctly, even when that means educating the customer before we quote the work.

Let me be clear about what I am not saying. If you run a proper design process and the answer genuinely comes out to one AP per room, fine. That is a design conclusion. What I am against is starting with the formula and skipping the design.

Design is a process, not a formula

In any real WLAN project we follow five steps:

• Define. Collect the requirements: device counts, area, growth over time, density, the applications actually in use. Andrew Von Nagy has a great process for the definition stage, presented at #WLPC, the Wireless LAN Professionals Conference.
• Design. Use RF fundamentals, antenna principles, and how 802.11 actually behaves. Pick AP count, power settings, antenna types, and placement so they work together to meet every requirement from the Define stage.
• Install. Usually the easiest step. Pull Category 6 or better cable to each location, certify the runs, confirm switch-port config, mount the APs, test the wired side.
• Validate. Prove the design met the requirements with a site survey, then watch performance during school hours. This is the step most people skip, which is exactly why they never know how their APs behave with each other.
• Remediate. Fix what is wrong. Move APs, change channels or power, and yes, sometimes remove APs or turn off radios.

“One AP per classroom” does none of that. It is a shortcut people use to charge full-scope prices for partial-quality work. It is easy to understand, easy to build a Bill of Materials from, easy to install, and easy to sell, precisely because it requires no knowledge of how 802.11 works or how RF propagates. That is its appeal, and that is its defect.

Promoting “one AP per classroom” as a design is lazy, ignorant, and greedy. The “1 for 1” is a marketing campaign meant to sell Access Points. It is not a Wireless LAN design methodology.

Why capacity is about frequency, not Access Points

Every Wi-Fi device follows the same rule. It listens on its channel, waits a defined slice of time to confirm the channel is clear, then transmits. All devices on the same frequency, APs and laptops and tablets and phones alike, share that one frequency and take turns.

Coverage is the easy requirement. Want more coverage? Turn up the power or add an AP. Done. But coverage is rarely the problem in an otherwise well-designed network.

The hard requirement is the opposite: controlling coverage so you can reuse the scarce frequencies you have. Andrew Von Nagy reframes this nicely as “co-channel contention” rather than the older “co-channel interference,” and he is right, because contention is what is actually happening. Call it CCI or CCC, it is the same enemy. Marcus Burton wrote a great white paper on the 802.11 contention process if you want the protocol detail.

Here is the part people fight. When two APs are on the same channel and can hear each other above a threshold, they share that frequency. So do all their clients. This is not a guess. It is hard-coded in the 802.11 protocol, in the Access Points, and in every client radio.

In 2.4 GHz in North America we have three non-overlapping channels. Channels 1, 6, and 11. That is it. Pack one AP into every classroom and you have all but guaranteed that same-channel APs hear each other, defer to each other, and split the airtime down to a fraction. More devices plus more APs on the same channel equals lower throughput. When you run out of channels, stop.

Some people answer, “we will let the vendor’s automated radio management turn the 2.4 GHz power down.” In doing validation surveys in hundreds of schools, I have yet to personally see that fix an over-dense design on its own. Others just switch off two-thirds of the 2.4 GHz radios. Think about that. You paid the capital cost, the install cost, the cabling cost, and the switch-port cost for every one of those APs, then you turn off half of them.

What about 5 GHz? And now 6 GHz

In 2014 I told people 5 GHz looked roomy on paper, up to 22 channels, but many K-12 client devices could not use UNII-2 or UNII-2e, so you were realistically designing on the eight UNII-1 and UNII-3 channels. That constraint has eased a lot.

6 GHz changed the math. In the US, Wi-Fi 6E and Wi-Fi 7 add 59 more 20 MHz channels across the full 1200 MHz of new spectrum, with room for fourteen 80 MHz channels, seven 160 MHz channels, and three 320 MHz channels on Wi-Fi 7. The “we are starving for clean channels” premise is far less binding when your clients can reach 6 GHz.

One caveat before you celebrate. That channel bounty is a US figure. The EU allocates only 5925 to 6425 MHz of 6 GHz, far fewer channels. Design to the spectrum your region actually licenses, not the headline number from an American slide deck.

More spectrum changes the budget. It does not repeal the principle. Frequency reuse still wins or loses the design. Throw enough APs at any band and you will fill the frequency and stall, in 6 GHz the same way as in 2.4 GHz, just with more channels to burn through first.

The seductive part: it works at install

Here is the trap that keeps this bad approach alive. After you install one AP per classroom, the network actually works.

It works not because the design is good, but because of the resilience built into 802.11. A lightly loaded over-dense network looks fine on day one, before the 1:1 and BYOD clients arrive. Many early adopters bought into “one AP per classroom” before their campuses were full of devices, so of course it looked good. Right up until the load arrived and the CCI/CCC bit down.

When I go back to those same schools after the device counts climb toward 1:1 and beyond, the network has gotten slower. Much slower. The fix? Remove Access Points. Lower the co-channel contention and the throughput goes up. The same lesson hospitals learned the hard way after stuffing APs into hallways.

So ask the honest question. If a system you overspent on works in the short term, was it still a good financial decision?

The cost argument got stronger, not weaker

In 2014 the waste was straightforward: you bought, cabled, powered, and switched more Access Points than the design needed, and those costs dwarfed any design fee on all but the smallest schoolhouse.

In 2026 that waste is bigger. Every over-deployed AP today is a Wi-Fi 6E or Wi-Fi 7 AP with multiple radios, a 6 GHz radio, and a multi-gig uplink. Those APs commonly need 802.3bt power, Type 3 at roughly 51 W or Type 4 up to 90 W at the device, not the 25.5 W an older 802.3at port delivered. Underpower a modern AP and it sheds a radio or drops spatial streams.

Read that back. Each extra AP you did not need now also drags a heavier switch port and a multi-gig uplink behind it. Over-deployment costs more in 2026 than it did in 2014. The marketing pitch that you are “future-proofing” by buying double the APs is exactly backward. You are pre-paying for power and uplink capacity to run radios you will end up turning off.

Association is not the constraint. Airtime is

There are two numbers in AP client capacity, and people confuse them constantly.

The first is associations. A phone sitting in a pocket during class is associated, has an association ID, sits in the AP’s table, and does almost nothing. Modern enterprise APs handle hundreds of associations without breaking a sweat. That number is not your bottleneck.

The second is the devices actively transmitting and receiving. Those are the ones in the contention domain, taking turns, sharing the frequency. That is the number that matters for a 1:1 design.

People assume every student device in adjacent classrooms will hit the network in the same instant. They will not. Network timing runs in milliseconds and smaller, so “at the same time” almost never means what the worried administrator thinks it means. The telephone industry has predicted this kind of behavior for a century with the Erlang function. The phone company does not run a trunk line for every apartment on the assumption everyone calls at once. They design for a normal day. We design Wi-Fi the same way: for a realistic set of simultaneous transmitters, not for every device in the school keying up in the same millisecond.

I have personally run more than 180 phones streaming the same multicast video from a single radio with frequency utilization under 40% and retry rates under 2%. At another school, 150 Chromebooks ran a full day of teacher training on a single AP because the big array meant to load-balance them had quietly been switched off and nobody noticed. The critical factor is frequency utilization, also called airtime. Keep it under 50%.

How to prove it: the validation test

This is easy to measure, and someone qualified should do it at every install.

Run a passive survey of the school across all APs on all channels. Then plot everywhere you have more than two APs above the same-channel threshold. By definition, that area is co-channel contention. Every AP that hears another on its channel has to defer, which means they share the frequency, which cuts throughput.

Keith’s note on the number: I use stronger than -80 dBm on the same channel as the trigger in the field, and some use -85 dBm. The real value is the Clear Channel Assessment threshold in the device, which some vendors let integrators tune by lowering the AP’s receive sensitivity. The point holds regardless of the exact dBm. In a one-AP-per-classroom building, the co-channel contention region is large and obvious, and you can predict the throughput loss directly from it.

One related correction worth keeping straight: backup coverage is not “overlap” measured in percent. Your second-AP coverage target is a dBm figure, something like -70 dBm or better, not a percentage of floor area. You cannot measure overlap in percent. You can measure backup coverage in dBm. Design and validate to the number you can actually read off an instrument.

Design the network. Do not count the rooms

When you build Wi-Fi for a K-12 1:1 program, do the work. Define the requirements, design to meet them, install, validate that it met them, and remediate what did not. Do not reach for the easy way out. There is a right way and a wrong way to design a Wireless LAN, and one AP per classroom is the wrong way.

If your provider makes real design services sound too expensive to bother with, they are doing the district a disservice. Design is supposed to be the “value add” in Value Added Reseller. Plenty of skilled Wireless LAN Professionals are available. Resorting to a formula instead of hiring one is disingenuous to the customer who is paying for it.

More than 4,000 classrooms in, the verdict has not moved. Capacity comes from frequency reuse, not from the AP count. When the frequency is full, no more traffic flows, no matter how many Access Points you throw at it.

So the question for any district holding an RFP with “one AP per classroom” in it: what design requirement, written down and measurable, says you need that AP, and how will you validate it after install?