The WiFi Bug That Almost Killed Our Booth Demo

Two days before a trade show, our robot’s built-in WiFi hotspot looked broken. The tools reported it was transmitting at 3 dBm, a level so low that a tablet a few feet away should barely see it. We nearly bought hardware to work around it. It turned out the radio was fine and the number was a lie. Here is the story, because you will hit this exact one.

Key Insights

• The tools reported the robot’s WiFi transmitting at 3 dBm, which looks like a crippling power cap
• It was a cosmetic reporting bug in the mt76 driver family, not a real limit; the radio transmitted at normal power the whole time
• We confirmed the real transmit power through the driver’s own debug interface: roughly 13 to 16 dBm while the tool said 3
• The lesson is to verify actual transmit power at the driver level before you conclude you have a hardware or firmware cap
• Believing the wrong number nearly cost us money and time on a fix for a problem that did not exist

The scare

The robot runs its own WiFi hotspot so a tablet can drive it and show its camera at a booth. During setup, every tool agreed the access point was transmitting at 3 dBm. That is roughly two milliwatts, and at a busy exhibition with hundreds of competing radios, it would mean the tablet loses the robot the moment you step back. Worse, trying to raise the power with the usual command did nothing: the setting refused to stick on readback, which is exactly what a firmware-locked regulatory cap looks like.

So the working theory became “this radio is region-locked to almost no power, we need a separate WiFi dongle or a travel router.” That is a real cost and a real point of failure to carry to a show. Before committing to it, we checked whether the number was even true.

The number was lying

The MediaTek WiFi driver family, mt76, has a known quirk: it does not always update the transmit-power value that the standard tools read back. So the tool reports whatever stale or default number it has, often a bogus low one, while the radio is actually transmitting at the correct regulatory power. The “won’t stick” behaviour when you try to set it is the same bug, not a lock.

We did not take that on faith either. The driver exposes the real per-rate transmit-power table through its own debug interface, and that is the number that reflects what the hardware is actually doing. It showed the radio transmitting at roughly 13 to 16 dBm across the relevant rates, while the standard tool insisted on 3. The radio was at normal power the entire time. The hotspot worked at booth range once we stopped chasing a cap that was not there.

The lesson

When a radio reports a suspiciously low or oddly unchangeable transmit power, do not believe it and do not buy hardware to fix it until you have checked the real value at the driver level. The reported number and the transmitted number are not always the same thing, and on this driver family they routinely are not. Verifying the truth takes minutes; acting on the lie costs days and sometimes a hardware order.

This is a small story with a large moral for anyone shipping on embedded WiFi: your telemetry can be wrong, and a wrong number that happens to match a scary explanation is the most dangerous kind. The habit that saves you is confirming the physical reality before you design around the readout.

If you are bringing up WiFi, or any radio, on a MediaTek Genio or another embedded platform and you want someone who has already met the driver’s quirks, that is the kind of thing we sort out quickly. Tell us what you are building. For the robot this came from, see the ROSOrin build overview.