DEV Community

fluidwire
fluidwire

Posted on Originally published at fluidwire.com

Why Wi-Fi Uses 2.4 GHz: The Microwave Oven Band

Every Wi-Fi router, every Bluetooth earbud, every Zigbee smart bulb and a huge share of the world's IoT sensors all crowd into the same narrow slice of radio spectrum: 2400 to 2483.5 MHz. It is the most congested unlicensed band on the planet.

It got that way because nobody wanted it. 2.4 GHz was the junk band — the frequencies regulators had set aside for machines that spray radio energy as a side effect of doing something else. Machines like your microwave oven.

The ISM bands were a place to put the noise

In the 1940s, international regulators faced a problem that had nothing to do with communication. Industrial heaters, medical diathermy equipment and, shortly after Percy Spencer's 1945 discovery at Raytheon, microwave ovens all emitted substantial RF energy. That energy was the point of the device, not a transmission, but it still leaked into the air and interfered with anyone trying to use those frequencies for radio.

The solution was zoning. The ITU designated a set of ISM bands — industrial, scientific and medical — as the places where this kind of RF-emitting equipment was allowed to operate. Anyone using an ISM band accepted that it would be noisy by design. 2.4 GHz was one of them, and microwave ovens settled at 2.45 GHz, right in the middle.

Worth killing a myth here, because it comes up constantly: 2.45 GHz is not the resonant frequency of water. Water has no meaningful resonance there. Microwave heating is broadband dielectric heating — polar water molecules being jostled by an alternating field — and it works across a wide range of frequencies. 2.45 GHz was chosen for practical reasons: it was an available ISM allocation, magnetrons for it were cheap to manufacture, and the penetration depth is right for cooking food through rather than searing the surface.

1985: the FCC opens the junk band

For decades that was the end of the story. Then in 1985, the FCC issued a ruling that turned the noisy leftovers into the most valuable spectrum in consumer electronics: it authorised unlicensed spread-spectrum communication in several ISM bands, including 2400–2483.5 MHz.

The reasoning was elegant. Spread-spectrum techniques — frequency hopping and direct-sequence — smear a signal across a wide band instead of concentrating it on one frequency. That makes the transmission robust against the kind of narrowband interference an ISM band is full of, and it makes the transmitter itself look like low-level background noise to everyone else. Devices could share the band without a licensing regime deciding who got what.

No licence meant no application, no fee, no spectrum auction, no waiting. Any manufacturer could ship a radio. And because ISM allocations were broadly harmonised internationally, a product designed for 2.4 GHz could be sold in most of the world without a different radio for every market.

That is why, when IEEE 802.11 arrived in 1997 and Bluetooth followed in 1998, both landed on 2.4 GHz. Zigbee and 802.15.4 did the same. Thread did the same. The band nobody wanted became the default.

The bargain: no protection from interference

Unlicensed spectrum comes with a condition that engineers deploying connected devices live with daily: you get no protection from interference. You may not cause harmful interference to licensed users, and you must accept any interference you receive. There is no regulator to complain to when the band gets crowded.

In a real deployment, "crowded" means: neighbouring Wi-Fi access points, every phone and laptop in the building, BLE beacons, wireless keyboards and mice, cordless phones, video senders, and yes — a microwave oven, whose leakage is small but sits directly on top of Wi-Fi channels 8 through 11.

For a shelf of consumer gear, that is an annoyance. For an IoT fleet, it is a design constraint with real consequences.

What this means when you deploy IoT

The ESP32 and similar Wi-Fi microcontrollers that anchor most connected-device projects are 2.4 GHz radios. They inherit every bit of this history, which shapes how a deployment should be engineered:

  • Channel planning is not optional. In 2.4 GHz Wi-Fi, only channels 1, 6 and 11 are genuinely non-overlapping. Surveying the site before installation, rather than after complaints start, is the cheapest reliability work available.
  • Budget for retries and gaps. Interference is intermittent by nature. Firmware should assume packets will be lost, buffer readings locally, and reconcile on reconnect. A sensor that drops data because the microwave ran for ninety seconds is a firmware problem, not a radio problem.
  • Watch the physical environment. In factories, hospitals and commercial kitchens the interference sources are industrial-scale, and they were there first — legally speaking, that is exactly what the band is for.
  • Consider whether 2.4 GHz is the right band at all. Sub-GHz options like LoRa trade bandwidth for range and penetration in a much quieter part of the spectrum. For low-rate telemetry across a campus or farm, that trade is often the right one.
  • Range is a promise you should measure, not read off a datasheet. Published figures assume clean air. Real sites have concrete, metal racks and neighbours.

None of this makes 2.4 GHz a bad choice. It is free, globally available, supported by cheap silicon, and it penetrates walls better than 5 GHz. It is simply a band with a specific character, and that character comes straight from the fact that it was zoned for ovens before it was zoned for networks.

The pattern is older than the technology

The 2.4 GHz story is a recurring one in engineering: a resource is written off as worthless, someone finds a technique that works despite the drawback rather than around it, and the worthless resource becomes essential. Spread spectrum did not clean up the junk band. It made the junk irrelevant.

If you are planning a connected-device deployment and want the wireless design pressure-tested before hardware is ordered — band selection, site survey, firmware behaviour under packet loss — get in touch with the Fluidwire team. Getting the radio decisions right early is considerably cheaper than sending a technician to every install site later.

Top comments (0)