A client came to me with a clear requirement: “low latency wireless.” He had a remote motor control system in development and was convinced that the wireless link was the thing standing between him and a working product.

Three weeks later we had the communication link running at 15 ms round-trip. Perfectly acceptable for most applications. The motor still felt sluggish. Not because of wireless latency: because the motor’s mechanical time constant was around 300 milliseconds. You could have commanded that motor over smoke signals and gotten the same result.

That conversation comes up often. “Low latency” is one of those specs that gets written down without being measured.

Start with your system, not your radio

Before you pick a wireless protocol, measure what your system actually needs. A motor with a 300 ms time constant does not benefit from a 1 ms radio link. A video shutter sync needs sub-millisecond precision. A drone flight controller sits somewhere in between.

The number to find is your system’s natural response time: the time constant of a physical actuator, the frame rate of an imaging pipeline, the control loop period of your embedded firmware. That number gives you your latency budget. Any wireless link tighter than that budget is performance you are paying for and never using.

Latency and jitter are not the same thing

Most engineers think about average latency. Experienced engineers think about jitter.

Latency is the average delay. Jitter is the variation around that average. For real-time systems, jitter is often the constraint that actually matters.

Here is why: if your control loop runs at 100 Hz, you have a 10 ms window per cycle. If your wireless link has 5 ms average latency but jitter of ±6 ms, your loop occasionally misses its window by 1 ms, then waits 11 ms for the next packet. A system that was controllable on average becomes unpredictable in practice.

The rigorous way to specify jitter is with sigma levels. 3-sigma captures 99.73% of events: acceptable for most applications. 6-sigma captures 99.9999998% of events: relevant when a single late packet causes a safety event or a failed cut. If you are designing a medical device or a high-speed machine, you need to know which sigma level your system requires, then measure that your hardware meets it before you ship. Most wireless stack datasheets do not publish jitter at 6-sigma. You have to measure it yourself.

Technology trade-offs

The range of wireless options is wide, and “low latency” means different things across protocols.

BLE (Bluetooth Low Energy) has connection intervals as short as 7.5 ms, which puts the minimum round-trip latency at around 15 ms in practice, often higher with stack overhead. Good for battery-powered devices; jitter is moderate; not the right tool for deterministic real-time control.

Proprietary 2.4 GHz or sub-GHz links can reach 1-5 ms round-trip with low jitter if you own the full stack. No coexistence guarantees in crowded RF environments, but in a controlled setting they perform well.

Wi-Fi can hit 1-5 ms on a clean channel, but the jitter profile is poor. Background traffic, channel contention, and power-saving modes all introduce spikes. Not my first choice for tight control loops.

5G URLLC promises sub-millisecond air interface latency. The problem is infrastructure dependency. Unless you are deploying a private 5G cell, you are subject to network conditions outside your control.

Mesh protocols (Zigbee, Thread, Matter) add hop-based latency. Each hop adds roughly 5-30 ms. If your sensor is three hops from the gateway, budget accordingly.

The question nobody asks until it is too late

Wireless links fail. Not often, not for long, but they do. Interference, physical obstruction, RF noise from a nearby drive or heater: momentary dropout is a statistical certainty over time.

The question to answer at design time is: what happens when the link drops?

A remote motor controller that loses its wireless connection for 200 ms: does it stop the motor? Hold the last command? Enter a safe state? Return to home? These are engineering decisions, not implementation details. They need to be in the spec before you pick a radio.

In every wireless system I have built, designing the degraded mode took at least as much work as the nominal path. The projects that went smoothly were the ones where the failure behavior was agreed on before any code was written. The ones that went sideways were the ones where it came up at integration.

A note on propagation delay

One thing that surprises people: electromagnetic waves travel at roughly 3x10^8 m/s in air, essentially the speed of light in a vacuum. That sounds fast until you do the math. A 300-meter link introduces about 1 microsecond of propagation delay. For most applications that is negligible. For precision time synchronization or sub-millisecond control specs, it is worth knowing that the physics imposes a floor, even before your radio stack adds its own overhead.

The actual job

The next time a brief says “low latency wireless,” push back with a number. What is the system’s time constant? What jitter level is acceptable, and at what sigma? What happens on dropout?

Those three questions will tell you more about which radio to pick than any datasheet comparison.