SensorRig

HC-12 vs WiFi for Remote Sensor Nodes: What 433 MHz Actually Buys You

3 August 2026 · 3 min read

Every home-monitoring tutorial assumes WiFi reaches your sensor. Mine didn’t. Two masonry walls and a steel-reinforced floor between the Pi and the pump room meant an ESP32-C3 that associated fine on the bench and dropped every 40 seconds in place.

The fix was to stop fighting 2.4 GHz and drop to 433 MHz with a pair of HC-12 modules. Here’s the honest comparison after running both.

The tradeoff in one table

WiFi (ESP32-C3 native)HC-12 @ 433 MHz
Wall penetrationpoorvery good
ThroughputMbit/s~1–5 kbit/s usable
Power per readinghigh (assoc + DHCP + TLS)low (UART burst)
Infrastructure neededAP in rangenone, point-to-point
Debuggabilityexcellentpainful
Cost per node€0 (built in)~€5

The headline: you trade bandwidth you don’t need for range you desperately do. A temperature reading is 20 bytes. Spending a WiFi association on it is absurd.

Why 433 MHz wins through walls

Path loss scales with frequency. Dropping from 2400 MHz to 433 MHz is roughly a 15 dB free-space advantage before you account for material absorption — and building materials absorb 2.4 GHz far more aggressively, because the wavelength (12 cm) is close to the scale of the reinforcement mesh and water content in the structure. At 433 MHz the wavelength is ~69 cm and the wall is electrically “thinner”.

In my install: the WiFi node showed RSSI of -89 dBm and constant reassociation. The HC-12 pair, same positions, delivered packets with zero loss over 24 hours.

The settings that actually mattered

HC-12 modules are configured over AT commands with the SET pin pulled low.

AT+B9600      # UART baud toward the ESP32-C3 / Pi
AT+C001       # channel 1 (each channel is 400 kHz apart)
AT+FU3        # transmission mode 3 — the sane default
AT+P8         # max transmit power (~100 mW)

Three things cost me an evening each:

  1. AT+B sets the UART baud, not the air rate. In FU3 the over-air rate is fixed at 15 kbps regardless. Setting a high UART baud does not make the link faster and will overflow the module’s buffer if you stream.
  2. Both ends must match on channel and FU mode. Mismatched FU modes fail silently — you get nothing, with no error anywhere.
  3. The module needs a real antenna. The spring antenna is not optional decoration. Without it, range collapsed to under three metres and I briefly concluded the modules were dead on arrival.

The failure modes nobody warns you about

Power sag on transmit. At AT+P8 the HC-12 pulls ~100 mA in bursts. On an ESP32-C3 running from a marginal LDO, the transmit burst browned out the MCU, which reset, which retransmitted, which browned out again. A 470 µF electrolytic across the HC-12 supply pins ended a week of “random” resets.

No addressing, no CRC, no ACK. HC-12 is a dumb serial pipe. Anything on the same channel within range lands in your UART. You must frame your own packets. Mine is deliberately boring:

<NODE_ID>,<SENSOR>,<VALUE>,<CRC8>\n

Without the CRC I was logging temperatures of 8523 °C whenever a neighbouring 433 MHz doorbell fired.

Duty-cycle rules. In the EU, 433 MHz ISM carries duty-cycle limits. Reading once per 30 seconds with a 20-byte payload is nowhere near the limit; streaming continuously is both illegal and antisocial to everyone else on the band.

Would I do it again?

For anything outdoors, through walls, or battery-powered — yes, immediately. For a node sitting two metres from the access point, WiFi is less work and gives you OTA updates, which HC-12 can never do.

The rule I settled on: WiFi where you can, HC-12 where you must, and never argue with a concrete wall.