0
\$\begingroup\$

I am working on a project that I would like to send and receive data between a microcontroller (ESP32) and a PC. The microcontroller supports both Wifi and Bluetooth. If I send one single data point (4 bytes) in stead of a big packet over a wireless medium, which medium provides me the smallest data transmission overhead?

For example, I am trying to send a sampled data (4 bytes each) at the rate of x Hz from a microcontroller to PC and from PC to the microcontroller. I would like to have my PC to be part of my real-time (50Hz with lowest latency) control loop. Theoretically, Which one among WIFI, Bluetooth, and Zigbee has the highest possible x Hz and lowest latency (These two are probably related)?

In Wifi, I know that TCP/IP has very high throughput compared to Bluetooth or Zigbee, and it is due to the ability to send big packets at certain rate. However, I would like to send very small packet at very fast rate (Overhead problem). I also know that UDP allows me to send small packets at faster rates than TCP/IP but it does not care about the packets loss. This is ideally what I want, since I only care about a single data sending at the fastest rate possible. However, I am not sure how UDP is compared with Bluetooth and Zigbee.

I was not able to find much information regarding this particular case, since most comparisons are about throughput and latency, which most likely depends on packet size, distance, how many devices are currently connected, etc.

Thank you in advance.

\$\endgroup\$
  • \$\begingroup\$ Welcome. As far as I know 5 GHZ WiFi moves about 5 megabytes per second, so it is good for streaming video. Look for single IC solutions that handle packet level stuff internally, and handle IP and MAC address as well. This way all of the legal issues are taken care of. Max range with good antenna is ~100 meters, line-of-sight. It will cost more than Bluetooth or Zigbee. \$\endgroup\$ – Sparky256 Mar 21 at 3:19
  • \$\begingroup\$ Likely none of the above are suitable. These protocols are built for throughput not for low latency - confusing the two is a common mistake. You've also neglected to consider missed packets, which are certain to occur. Realistically speaking, you should move the entire control loop to the embedded side; use the radio to configure it and report on its behavior with multi-sample packets sent a bit after the fact. \$\endgroup\$ – Chris Stratton Mar 21 at 3:25
  • \$\begingroup\$ You can't even run a process with a 50 Hz loop on a pc, because each timeslice for user processes is 20 ms. You'd need to write a device driver for that. I suggest you explore other options to get a stable process frequency. \$\endgroup\$ – Jeroen3 Mar 21 at 7:18
  • \$\begingroup\$ My fear has come true. I believe that there must has been a wireless real-time communication medium out there for this type of problem. Maybe it is not Wifi, Bluetooth, or Zigbee, but someone has implemented a wireless real-time communication network from one server (PC) to multiple clients (says 20 microcontrollers). Could anyone provide a more definite direction that I can look into? Thanks \$\endgroup\$ – Khoily Mar 22 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.