How it works

The problem with Wi-Fi apps

Every Wi-Fi analysis app runs inside an operating system that decides how much of the radio it is allowed to see — and the answer keeps getting smaller.

An app on a phone or laptop doesn't talk to the radio. It asks the OS, and the OS answers with a summary: a list of networks, a signal bar, sometimes a channel number. It cannot ask how long the radio had to wait before it could transmit, because nothing in the API exposes that. On iOS, a third-party app cannot enumerate nearby networks at all. On modern Android and Windows, scan rates are throttled and results are cached.

So an app is not measuring the air. It is reporting what the platform is willing to tell it — and two apps on two phones will disagree, for reasons neither can see.

Your phone is the screen. The instrument is the thing with the radios in it.

Two radios, two jobs

Wireless Toolbox carries two independent radios so that talking to you never interferes with measuring the air.

The built-in radio hosts a small private network called Toolbox. That is the link your phone joins, and the only thing it ever does is carry the web interface. It is fixed on one channel and it stays there.

The measurement radio — a MediaTek MT7612U, the part that actually does the work — is never used for that. It scans, beacons, hops channels, and sits in monitor mode, without the control link ever noticing. This is why the page keeps updating live while a sweep is running: the two radios are not sharing anything.

Measuring from the access-point side

For throughput tests, the appliance becomes the access point — so the authoritative numbers are counted at our end, not asked for at yours.

When Wireless Toolbox tests a channel, it beacons as an AP, lets a client associate, and counts acknowledged bytes on its own side of the link. It reads channel busy-time straight from the radio's own counters via iw dev survey dump — the same registers the MAC uses to decide whether the medium is clear.

Neither number depends on the client understanding the question. A phone that reports signal strength in vague bars, or refuses to scan at all, is still a perfectly good load generator — and the measurement is taken here.

The metric: measure the consequence, not the cause

Instead of trying to identify what is interfering, we measure what interference actually costs you.

A spectrum analyser classifies energy — that is its job, and Wireless Toolbox includes spectrum tools for exactly that. But for the question “which channel should I use?”, classification is the long way round. You would have to detect the energy, identify it, and then estimate its effect.

The metric we use, IMMI, skips to the effect. It puts a standard 802.11 radio on a channel and measures how long that radio's own collision-avoidance logic makes it wait before it can put a fixed payload on the air. More interference means the radio defers longer, which means fewer bytes per second. Normalise that against a clean-environment reference and you have a score:

The strength of this is that it does not care what is causing the problem. A crowded neighbouring network, a microwave oven, a cordless phone, a wireless video sender — anything that makes the radio hold off shows up automatically, because the radio holding off is the measurement. Nothing has to be recognised first.

IMMI is an implementation of US Patent US8488478B1, Indirect Measurement of Microwave Interference, by Steven Leytus — the founder of Nuts About Nets — ported onto the appliance's hardware.

A diagnostic platform, not a single instrument

Everything above describes Wi-Fi measurement — but almost none of the machinery underneath it is specific to Wi-Fi.

What was actually built is a diagnostic platform: something acquires samples from an instrument on a timing-critical path, something streams those samples out while they are still arriving, and a browser draws them live. Wi-Fi is one instrument plugged into that. It was never the only one.

The proof is that instruments of quite different kinds already run on the same plumbing. USB Wi-Fi radios, a spectrum analyser on a serial link, and a software-defined radio dongle all share one acquisition-to-browser path — and every tool on the appliance pushes its data through the same streaming layer, including the menu itself.

That matters beyond Wi-Fi. Anything a Raspberry Pi can read — an environmental sensor, a power monitor, a vibration probe — can reach a browser as a live chart by the same route, without a client application, on whatever device the person happens to be holding. Today the platform does RF diagnostics because that is the problem we know best. The architecture is not what limits what comes next.

What this buys you