Protocol Selection & Radio Coexistence on Embedded Systems Development

Wireless Protocol Selection Guide

Mon, 01 Jan 0001 00:00:00 +0000

Wireless Protocol Selection Guide#

Selecting a wireless protocol for an embedded product is a binding decision — it determines the radio silicon, antenna design, firmware stack, certification requirements, and ongoing infrastructure costs. Changing protocols after PCB layout means a board respin, new certifications, and months of rework. The right choice emerges from understanding the trade-off axes that differ across WiFi, BLE, Thread, Zigbee, Sub-GHz (LoRa, Sigfox, Z-Wave), and cellular (LTE-M, NB-IoT), then matching those trade-offs to the specific application’s constraints.

2.4 GHz Radio Coexistence

Mon, 01 Jan 0001 00:00:00 +0000

2.4 GHz Radio Coexistence#

The 2.4 GHz ISM band (2.400–2.4835 GHz) is shared by WiFi, BLE, Thread, Zigbee, proprietary radios, microwave ovens, and USB 3.0 interference. When a single product incorporates two or more 2.4 GHz radios — WiFi+BLE on an ESP32, BLE+Thread on an nRF5340, or all three on a SiLabs EFR32 — those radios must coordinate access to avoid mutual interference that degrades throughput, increases latency, and raises power consumption through retransmissions.

TLS & DTLS on Constrained Devices

Mon, 01 Jan 0001 00:00:00 +0000

TLS & DTLS on Constrained Devices#

Transport Layer Security (TLS) on a constrained microcontroller is a fundamentally different problem than TLS on a server or desktop. A server completes a TLS 1.3 handshake in under 1 ms with negligible memory impact. A Cortex-M4 at 120 MHz without hardware crypto takes 1–3 seconds for the same handshake, consuming 30–50 KB of RAM at peak — potentially half the available SRAM on a mid-range MCU. Every design decision in the TLS stack — cipher suite selection, certificate format, session management, buffer sizing — has measurable impact on performance, memory, and power consumption.