Your wireless system passed validation. Your latency looks stable, and the throughput seems fine. But the moment you take your system out of the controlled environment and into the real world?
Suddenly you’re dealing with:
- latency spikes beyond control limits
- packets arrive too late to be useful
- connections degrade under load
Probably every embedded engineer has seen this pattern. And our first instinct is usually to blame the hardware.
Well, what if we told you that the data showed us something else?
At DEWINE Labs, we tested four of the most popular BLE modules under real-world conditions and found that this is not primarily a hardware problem. It is a firmware behavior problem.
The test setup
Having run into these issues ourselves, we wanted to understand what’s actually going on, not in theory, not in clean lab conditions, but in environments that reflect real-world use.
So instead of running another benchmark under ideal conditions, we built a setup that mirrors the harsh realities of production.
Because let’s be honest: real environments are messy. Think: Wi-Fi-dense factory floors, moving machinery, and a crowded 2.4 GHz spectrum.
To simulate this, we built a simple control loop and ran it across multiple UART-over-BLE stack implementations – all based on Nordic hardware.
The parameters were intentionally straightforward:
- 1 BLE central, 1 BLE peripheral (~1 meter distance)
- 100-byte payload every 100 ms
- 100-byte acknowledgment in return
- Real-time requirement: ≤ 30 ms one-way latency
- Any packet exceeding this threshold = failure
And the devices we tested:
- Nordic nRF52840 (HCI UART)
- Ezurio BL654
- Würth Proteus-III
- u-blox NINA-B112
- LinkBlu RT (deterministic firmware on Nordic hardware)
At this point, one thing was already clear: this wasn’t a throughput problem. It was a timing problem.
When reality hits
In a clean RF environment, everything behaves exactly how you’d expect: Packets arrive. Latency stays within bounds. Nothing looks out of place. Every system appears stable. Predictable. Production-ready.
And that’s the trap, because this is the moment where most validation processes stop. So we ran the same test again (same setup, same parameters) this time under heavy Wi-Fi interference.
That’s when things started to diverge. Not because packets suddenly stopped arriving, but because timing became unpredictable.
Under interference, delays start pushing packets beyond the 30 ms threshold. And that’s where the differences became impossible to ignore.
Here’s what the delay of these one-way packets under heavy interference looks like:
Why this happens
Here’s the uncomfortable truth: standard BLE firmware was never designed to guarantee timing.
It’s built on a best-effort communication model. That works perfectly fine… or at least until your system actually depends on when data arrives, not just if it arrives.
Once interference enters the picture, things start to unravel:
- Retransmissions increase
- Buffers begin to fill
- Packets get queued in ways you can’t predict
And suddenly, your system isn’t failing in an obvious, dramatic way. It’s failing quietly.
Because technically, everything is still “working.” The packets are still being delivered. They’re just… too late. And in real-time systems, late data isn’t degraded performance: it’s invalid data.
This is the key distinction most benchmarks miss. They measure throughput. Maybe packet loss, or the occasional average latency. But they don’t measure determinism. And that’s exactly where things break for real-time applications.
Latency spikes aren’t random. They’re not bad luck. And they’re usually not even RF issues. They’re a scheduling problem.
What LinkBlu RT does differently
Instead of treating communication as best-effort, LinkBlu RT treats it as what it actually is in real-world systems: time-critical infrastructure.
That fundamentally changes how the system behaves.
Rather than allowing packets to move through the system whenever resources happen to be available, LinkBlu RT enforces structure:
- Bounded latency — by design. LinkBlu RT enforces an upper bound on latency. A packet either arrives within the defined window or it is dropped. No stale packets. No buffer clogging. The control loop stays predictable.
- Dual-channel isolation. Real-time traffic (control signals, safety data) runs on a dedicated channel, isolated from logs, diagnostics, and bulk transfers. Standard BLE mixes all traffic in a single queue — which is why a spike in data traffic directly causes latency spikes in control signals. LinkBlu RT eliminates that coupling.
- Adaptive interference handling. LinkBlu RT monitors link health continuously and adapts its behavior. When interference increases, the firmware compensates. Standard BLE firmware is essentially a black box — no diagnostics, no adaptation, no feedback.
In other words, it removes the “we’ll get there eventually” mindset from BLE communication. Because “eventually” is not a valid timing guarantee.
Under interference, this difference becomes visible immediately.
While standard BLE stacks start to drift (accumulating delays, building up queues, and violating timing constraints), LinkBlu RT maintains consistent behavior. And it’s not because interference disappears, but because the system is designed to handle it without losing control over time.
The takeaway
If your system uses standard BLE firmware on Nordic Semiconductor hardware and needs to operate in a real industrial environment, you cannot guarantee real-time behavior unless the firmware enforces bounded behavior.
If your system depends on real-time behavior, you don’t have a wireless problem.
You have a timing problem.
And timing problems don’t show up in clean lab environments. They show up where it matters:
- On the factory floor
- In shared spectrum
- Under load
This is why so many systems pass validation and still fail in production.
Because the question isn’t: “Does it work?”
The question is: “Does it still work when timing actually matters?”
What we did next
This benchmark only shows the surface:
- how latency distributions change
- where packets exceed real-time thresholds
- how systems behave over time under sustained interference
The full breakdown (including latency histograms, system behavior over time, and architecture details) is in the technical whitepaper.
