Why I Use UDP for Sensor Streaming (And When I Don't)
TCP's reliability guarantees can become a latency problem in real-time systems. Here's how I approached protocol decisions while building a motion capture pipeline with ESP32-S3, UDP, TCP, and Node.js diagnostics.
When I first wired up motion sensors to an ESP32-S3 and tried to stream quaternion data to a laptop over Wi-Fi, I reached for TCP. It felt safe. Reliable. The right choice.
It was not always the right choice.
The Problem with TCP at High Sample Rates
When a system is sending sensor readings continuously, every delayed packet matters. TCP guarantees reliable, ordered delivery, but that guarantee comes with overhead. If packets are delayed or retransmitted, the visualizer can end up processing stale data instead of the latest position.
For real-time motion capture, the most important requirement is not always perfect delivery. Often, it is recency.
A dropped reading is usually less disruptive than a delayed reading.
The UDP Approach
For the real-time sensor stream, UDP made more sense. The receiver could process the newest packet available without waiting for older packets to arrive in order.
The system used UDP for low-latency sensor streaming and TCP for more reliable command/control communication. That split made the architecture easier to reason about:
When TCP Still Makes Sense
UDP is useful for real-time streaming, but TCP is still the better choice when reliability matters more than latency.
I use TCP-style reliability for things like:
The lesson is not “UDP is better than TCP.” The lesson is that each protocol solves a different problem.
Building Diagnostic Tools
One of the most useful parts of the project was building a Node.js CLI diagnostic tool. It helped with:
That tooling made the system easier to troubleshoot across hardware, networking, backend processing, and browser visualization.
Conclusion
Real-time systems require trade-offs. For motion capture, low latency and recent data were more valuable than perfect delivery. For configuration and control, reliability mattered more.
The best protocol is the one that fits the actual system requirement.