A Hamina Clip gives an iPhone or iPad Wi-Fi radios Apple keeps away from apps, and 4 apps from 2 vendors can use it today. On one job that means a passive survey, live scanning, a validation walk and a packet capture, all from gear you already carry. If you do Wi-Fi for a living and you work on Apple devices, the Clip goes in your backpack and stays there.

I’ve been lucky enough to have been given the opportunity to use a Clip since the first beta runs… and it has been lovely. I’ve had chances now to use it from when it was wired only, to wireless connectivity. From when it only ran on Hamina Onsite… to now when it also runs Adrian’s great tools, WiFi Explorer Pi and Airtool Pi.

We enjoyed it so much we purchased five more to add to our WLAN Pros Troubleshooting course instructor kit to help give our students hands on experience with the tool.

What the Clip Is

The Clip is a battery-powered sensor with 2 Wi-Fi 7 tri-band Wi-Fi radios. It weighs 282 grams and rides on a belt clip or a backpack strap. Hamina’s own description of the size is “think Nokia phone from 2005,” and anyone old enough to have carried one knows exactly what they mean. And it just FEELS GOOD. Like it was professionally designed and produced for real professionals to use.

It connects to the host over Bluetooth Low Energy (BLE) with no pairing in Settings, or over a USB-C cable. The host needs Bluetooth 5, so older iPads with Bluetooth 4.2 use the cable. If you have an old Lightning-only device… you might need to get yourself an upgrade! (Or you’ll need Apple’s USB Camera Adapter)

Hamina’s product page rates the battery at 6 hours. It charges over USB-C PD and keeps running while it charges, so a full day in the field comes down to the size of your power bank.

Wireless First: The Clip on Your Belt

Everything in this section runs over Bluetooth, with the phone in your hand and nothing plugged in. (Personally I have a MagSafe adapter on my personal Clip so it attaches under my iPhone – designed by Robert Boardman and printed on my own 3D printer with very strong MagSafe magnets) – but sometimes I prefer to use the standard belt clip to leave it on my belt or backpack strap.

Scan Where iOS Won’t Let You

Intuitibits sums up the problem in one line: “Apple does not provide apps on iOS with access to Wi-Fi information.” The Clip gets around it.

Adrian Granados added Clip support over BLE to WiFi Explorer Pi in version 1.2, on July 31, 2026. The cable path has been there since February. With the Clip on your belt you get live scanning and beacon analysis anywhere in the building. That covers the daily troubleshooting questions:

• Who else is on my channel?
• Which DFS channels are in use?
• What is the SNR where the complaint came from?
• Which AP is loudest in this room?

All of which used to mean opening a laptop.

One tip before your first walk: if WiFi Explorer Pi tells you the Clip’s firmware needs an update before it will scan over Bluetooth, do the update first, and you’ll need a USB-C cable for the firmware update.

Passive Surveys and AP-on-a-Stick

Hamina Onsite is the Clip’s home app. Over BLE you run passive surveys (point, line or continuous), watch the realtime view, and build heatmaps on a floor plan, or on a LiDAR scan from a Pro iPhone or iPad. The same kit handles AP-on-a-stick: an AP on a stand, the Clip on your belt, and Onsite recording what that AP covers before anybody pulls cable.

Know which radio is doing which job. An active survey (throughput, ping) runs on the phone’s own Wi-Fi connection. Hamina’s docs say an active survey “connects a standard Wi-Fi adapter to the network.” The Clip handles the passive side, and the phone’s radio handles anything that requires an association.

A Validation Walk With Checklists

WiFi Explorer Pi added Checklists in version 1.1. You define what the network has to meet, walk the floor with the Clip on your belt, and export a PDF report. Checklists travel as .checklist files, so a team can share one standard across every site. Intuitibits credits the idea to “the community-driven Wi-Fi validation framework developed by WLAN Professionals and its contributors.” (Thanks for the shout out Adrian!)

Why does that matter on a job? You leave the building with a PDF measured against a standard the customer agreed to.

Roaming

The Clip hears every BSSID around you. A roam, though, is something a client does, so the roam events come from the phone. Onsite detects roaming on the phone’s own connection, and the Clip shows you the BSSIDs the phone could have roamed to.

When You Plug In

Packet capture is a wired job. The Airtool Pi app requires a wired connection, so use your USB-C cable:

• Airtool Pi on an iPhone or iPad captures frames through the Clip over USB-C and saves them on the device as pcapng. Share the file to your laptop and open it in Wireshark.
• Airtool 2 on a Mac captures on up to 2 channels at once through the Clip, with frame slicing, file rotation and live captures straight into Wireshark.

Both come from Intuitibits.

The cable also wins in a busy RF environment. Hamina’s docs say: “In very busy or noisy RF environments, you can use a cable to connect the Hamina Clip to your iPhone, iPad, or Apple Silicon MacBook.”

What It Won’t Do

Plan around these limits before you get to the site:

• No spectrum analysis.
• Apple hosts only. No Android or Windows apps, which suits this Apple fan boy fine.
• Hamina doesn’t publish a BLE range. Keep the Clip on you, close to the phone.
• Whether 2 apps can share one Clip at the same time isn’t documented. Quit one app before you open the other.
• The battery won’t cover a full day on its own. (But it does work longer than I do… it’s not like anyone works straight for 6 hours without a break) Carry a USB-C PD power bank, or charging setup.

Who Supports It Today

These 4 apps name the Clip in their own vendor’s release notes or docs:

Hamina’s product page also lists WiFi Explorer Pro on the Mac and the MetaGeek app. As of this writing neither app’s own release notes or product page mentions the Clip, so check with those vendors before you plan a job around them.

3 of the 4 confirmed apps come from Adrian Granados at Intuitibits. I’ve personally been using Adrian’s tools since his very first iteration and think he makes some of the most valuable apps there are for Wireless LAN Professionals around the globe.

An Open Invitation to Jussi and the Hamina Team

Jussi Kiviniemi is Hamina’s founder and CEO, and this section is for him and his team.

The Clip listens to the air. The job it leaves to the phone is the phone’s own connection: the network it joined, and how that connection behaves as you walk. That is the half our WLAN Pros Toolbox works on. Put the two side by side and a Wi-Fi pro standing in a problem room sees both the air around them and the connection in their hand, on one device.

Adrian’s apps show what a partner can build on the Clip. If there’s room on that list for one more app, we would love to be on it.

Why It Stays in the Backpack

In one day the Clip can run a passive survey in Onsite, a Checklists walk in WiFi Explorer Pi, and, once the cable goes in, a frame capture in Airtool Pi or Airtool 2, all on Apple gear you were already carrying. Keep the Clip in the backpack with a USB-C cable and a power bank beside it.

You turn on rate limiting in an attempt to stop one heavy user ruining the network for everybody else. That is a reasonable thing to want. The limit is set in megabits per second, checked in megabits per second and reported in megabits per second, so megabits are the unit everyone ends up reasoning in.

That is the wrong unit, and using it hides the entire efficiency penalty.

A WLAN does not spend megabits. It spends airtime, and airtime is consumed per transmission, not per byte. The question is not how fast a client is allowed to go. It is how much data the access point carries each time it takes the medium.

I measured that on a UniFi Express 7, on 5 GHz and 6 GHz, six repetitions of every condition, with the capture taken on the access point itself.

Aggregation does not shrink. It stops.

An access point pays the same fixed cost every time it transmits. It contends for the medium, sends a preamble and a header, delivers the payload, and collects an acknowledgment. That cost does not shrink when the payload does.

Frame aggregation exists to spread that overhead cost. The radio gathers whatever frames are waiting and sends them all under one preamble, so one trip to the air carries many frames of data in a single Transmission Opportunity – or TxOP.

With no rate limit applied, 99.7% of the access point’s downlink frames went across the air in an aggregated frame, sharing a trip with sixteen others on average.

At a 2 Mbps rate limit, only 3% did.

The other 97% each took the medium alone. One contention win, one preamble, one acknowledgment, for one frame.

A limit set in megabits per second did not make the radio send smaller aggregates. It made the radio stop aggregating.

Most of the cost arrives at a setting most would call generous

Count every transmission and divide by the data delivered, and you get trips per megabyte.

The data was 620 Mbps – yeah measured in Mbps. With no limit it needed about ten trips to move a megabyte. By turning on a 100 Mbps rate limit, which most engineers would call generous, it needed a hundred and twelve trips!

Making the rate limit more constrained doesn’t make it any better. At 2 Mbps the same megabyte took more than eleven hundred trips.

Switching the feature on costs you, and tightening it costs you again. There is no setting at which rate limiting improves RF airtime, none.

Every routine check says the network got healthier

This is the part to remember next time you are troubleshooting.

As the rate limit tightened the penalty to airtime efficiency climbed, yet the retry rate fell, on both bands, roughly by half.

Signal does not move. Channel does not move. Client count does not move. Retry improves. Every box an engineer would tick after enabling a rate limit gets ticked.

You might reach for channel utilization, which is the one field that may have shown this. On the access point I tested it sat flat much of the time, since we had only one client on that access point doing mostly downstream iPerf testing, so there was very little contention for the medium and thus the channel utilization number was not at all instructive.

Nothing on the dashboard reports the TxOP penalty that got dramatically worse.

Two clients, one radio, one instant

The obvious objection to any before-and-after test is that something else changed in between. So I ran two clients against the same access point at the same moment, for 45 seconds, six times, and took both out of a single capture. One was rate limited to only 10 Mbps. The other was not rate limited at all.

99.9% aggregated against 42.7%, in the same air, in the same instant.

There is a trap in the same data. The cell average across both clients was about 16 frames per transmission, because the unlimited client dominates the total. An engineer reading a per-radio summary would see a healthy number and conclude the limit cost nothing. Report by receiver address, not by average mixed between rate limited and non-rate limited client devices.

6 GHz helps, and it is not a way out

The obvious question is whether a newer band behaves differently. Same access point, same client, same night, both bands at 80 MHz.

6 GHz gives up slightly less, and that is the extent of the good news. 6 GHz holds its aggregation a little better through the middle of the range, and by 2 Mbps that advantage is gone.

Moving to 6 GHz buys you a great deal. It does not buy an exemption from this TxOP inefficiency penalty.

The rate limit was not enforced where its name suggests

On this platform the downlink limit is written onto the client’s user group, which reads as though it travels with the wireless client.

It does not. It is enforced at the gateway, on the routed path.

On a switched path between two hosts on the same subnet, a 2.5 Mbps limit delivered 495 Mbps, a factor of 198 over its setting. Put your load generator on the same VLAN as the client and you will build a rate-limited test that is not rate limited, with nothing in the output to tell you.

What this does not establish

We did not measure the total physical airtime using clock time. Trips per megabyte is a count of transmit opportunities. We priced the total penalty based on how many TxOP opportunities were needed to send a fixed amount of data. Control and management overhead airtime per megabit rose by up to 168 times, which is real measured time, and it still is not the total. A hundred times the trips is not a hundred times the airtime, and nobody should quote it that way.

I measured the rate limit penalty as waste. Nothing here puts a number on what this costs the users of a busy cell. On a radio with idle time to spare, the waste comes out of capacity nobody was using that second.

One access point, and one model of it. Whether this appears on other UniFi models, let alone other vendors, is not established by this work.

The same limit does not cost the same. On identical hardware the result varied by about half again between sittings, tracking the retry rate. Any result reported without its retry rate cannot be compared against these.

What to do about it

Stop rate limiting your Wi-Fi.

A rate limit controls megabits. An access point never runs out of megabits. It runs out of airtime, and a feature that makes the radio take the medium once per frame is spending airtime on overhead instead of on delivering data in a timely manner.

I do not have a better answer yet, and I am not going to pretend I do. The reason you turned the limit on has not gone away. One client really can take more than its share of a medium everybody has to take turns on, and something should deal with that. What I can tell you is that this seemingly benign rate limiting setting does not achieve its goal without a huge penalty. And yet, that penalty is totally invisible on every screen Wi-Fi professionals would think to check.

What to use instead is a real question and it needs its own measurements, not merely these results from my testing. I am still working on this issue.

If you are going to turn on rate limiting, do it knowing the penalty you are inflicting on your airtime. Do not trust any dashboard to tell you how it went, because it will tell you the opposite. Measure the share of frames still being aggregated, by receiver address, which is the clearest single indicator and sits in any capture taken at the access point. NOT over the air packet captures – since they are also flawed when compared with what the access point actually transmitted.

Run these tests on your own gear and tell me what you find, especially if you disagree.

The full white paper, with the complete method, the raw numbers and every caveat stated, is available as a PDF.

So here is what I would like to know: if you rate limit clients on your network, what made you choose the number? And has anyone ever gone back and measured what it bought you?

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?

Keith Parsons, CWNE #3. WLAN Pros. Figures by WLAN Pros. US FCC rules throughout.

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.