If you’re retrofitting a legacy PLC with wireless connectivity, you’ve probably chosen a protocol the way most people do: by picking the fastest option, the one with the longest range, or the easiest to implement based on your previous experience. Latency and throughput get the attention. Energy consumption is usually an afterthought— something you check once the architecture is already locked in.

A recent study from Széchenyi István University in Hungary suggests this approach is backward. Korpai, Szántó, and Monek set up a testbed to compare five communication stacks—ESP-NOW, BLE, Bluetooth Classic, MQTT over Wi-Fi, and the wired Siemens S7 Protocol—with an emphasis on energy use rather than speed. The main takeaway isn’t that one protocol is always best. Instead, the best choice changes depending on how much data you send, and sometimes the top performer for small payloads is the worst for large ones. If you’re designing an IoT gateway for industrial retrofitting, this isn’t just a minor detail. It’s the main factor in your design decision.

Testing low-power wireless stack

The testbed, built at the Laboratory of Cyber–Physical Manufacturing Systems at Széchenyi István University, centers on two Siemens S7-300 PLCs — one sending, one receiving — each wired to its own ESP32-based M5Stack Core2 gateway. The gateways are hardwired to their PLCs but communicate with each other wirelessly; that link is what the study measures. An HMI handles measurement control over a separate wired connection, kept apart from the data path itself.

Each gateway – highlighted as an IoT device – is powered and measured using an Otii Arc Pro, with accuracy of ±(0.1% + 50 nA) and ±(0.1% + 1.5 mV). GPIO signals mark the exact start and end of each transmission, feeding into the profiler so active transaction energy can be cleanly separated from standby draw.

Each protocol was tested using its default configuration with four different payload sizes: 50, 500, 5,000, and 15,000 bytes, chosen to span the range from small periodic telemetry to bulk diagnostic transfers.

Evaluation findings worth paying attention

BLE and Bluetooth Classic trade places as payload grows.

When the payload is 50 bytes, BLE and Bluetooth Classic use almost the same amount of energy: 5.65 mJ and 5.62 mJ per transaction. At that size, you could treat them as interchangeable. However, with a 15,000-byte payload, Bluetooth Classic becomes 2.4 times more efficient, using 173.84 mJ compared to BLE’s 412.97 mJ.

The mechanism is straightforward once you see it: BLE’s connection is capped by a tightly constrained MTU (the study used the legacy 23-byte ATT_MTU default, yielding a 20-byte payload), which forces large datasets to be split into many small fragments — each with its own header and inter-frame overhead. Bluetooth Classic, by contrast, streams continuously once the connection is established. At small payloads, that architectural difference barely registers. At large payloads, it dominates.

ESP-NOW is excellent — until it isn’t.

ESP-NOW is the clear winner for small telemetry, using just 1.64 mJ to transmit a 50-byte payload — the most efficient and most stable result in the entire dataset. But the protocol’s v1.0 frame limit caps payloads at 250 bytes, meaning anything larger has to be fragmented at the application layer. At 15,000 bytes, that overhead catches up: specific energy consumption actually climbs to 62.91 µJ/byte, reversing the trend every other protocol in the study shows as payload increases. Speed and low-level efficiency stop being the same thing.

Standby power is its own decision, separate from active efficiency.

The study’s fourth research question, which is often overlooked in protocol comparisons, asked how important standby (idle) consumption is compared to active transmission. The answer is that it matters a lot, and the difference between interfaces can be huge. BLE uses very little power in standby mode (85 mW when receiving), while the wired S7/Ethernet interface uses about 913 mW just to keep the link active, even when not transmitting.

The actual insight: it’s a duty-cycle problem

Put those three findings together, and a clearer principle emerges. The right low-power wireless stack isn’t a fixed answer — it’s a function of your duty cycle. How often you transmit, and how much data each transmission carries.

• Infrequent, small telemetry (a status update once a minute): standby power dominates the energy budget. A protocol with aggressive sleep states and low idle draw — BLE, in this study — wins even if its active transmission isn’t the fastest.
• Frequent, small packets: ESP-NOW’s low per-transaction cost and stability make it hard to beat, as long as payloads stay under its fragmentation threshold.
• Bulk, infrequent transfers (diagnostics, OTA updates): Bluetooth Classic’s streaming architecture scales better than anything else in the comparison, dropping to 11.59 µJ/byte at 15,000 bytes.
• Cloud-integrated gateways needing TCP/IP flexibility: MQTT is the most overhead-heavy option at small payloads (3,389 µJ/byte for a 50-byte receive) but becomes more reasonable at scale — the cost you’re paying is for network-layer maintenance, not the data itself.

None of this is visible if you look only at a single payload size, or if you benchmark speed and range while treating energy as something you’ll deal with later. It’s also not visible without instrumentation precise enough to catch a 0.03 mJ difference and trust that it’s real rather than noise — which is the quieter point this study makes just by being methodologically rigorous enough to publish.

Research takeaway: How do you pick a low-power wireless stack for retrofits?

Before defaulting to whatever protocol seems fastest or most familiar, it’s worth asking three questions about your actual deployment:

1. What’s the expected duty cycle — is this device reporting once a minute, or streaming continuously?
2. What’s the typical payload size, and does it sit near a fragmentation threshold for the protocol you’re considering?
3. Is this deployment standby-sensitive — battery-powered, thermally constrained, or otherwise penalized for idle draw?

The answers will differ for a vibration sensor that reports once per shift versus a gateway that streams real-time diagnostics. The best low-power wireless stack isn’t universal — it depends on your specific device profile. A few measurements will quietly show you which one.

Reference: Korpai, R., Szántó, N., & Monek, G.D. (2026). Energy Efficiency-Driven Selection of Wireless Communication Stacks for Industrial Retrofitting Applications (https://www.mdpi.com/2504-4494/10/6/209)