I have a wall-powered embedded device that has several sensors. The MCU collects all sensor data, packages it and then sends it to an on-premise server through UDP. It is sending data every 100ms, which works fine.

A Python script is running in the server that collects sensor information, takes some decision and sends it to the cloud if necessary.

Now I have several of these embedded devices which need to do the same, send data to this server, every 100ms.

I am having some doubts about the UDP part. I needed a wired communication and UDP was easiest to implement. Now, as I am scaling I was wondering, considering my situation, if it was the right way to do it?

I looked up CoAP and MQTT, MQTT vs HTTP, but I don't have the right metrics to decide. I guess the question is: How do I decide what protocols I should use?


  1. The devices are not battery operated.
  2. The device to the server has to be a wired communication.
  3. The data I send from the device to the server is not more than 100 bytes. (The device is modular, I can plug-n-play sensor modules, so depending on the number of the sensor the payload might vary).
  4. I am sending data every 100ms. That's a hard requirement.

Any suggestions would be much appreciated.

  • \$\begingroup\$ UDP has no guarantee of delivery \$\endgroup\$
    – jsotola
    Jan 27, 2020 at 23:19
  • 2
    \$\begingroup\$ @jsotola Nothing has guarantee of delivery. TCP only promises to get it there a) if it's possible, and b) eventually. \$\endgroup\$
    – jonathanjo
    Jan 27, 2020 at 23:21
  • 2
    \$\begingroup\$ What’s wrong with UDP if it’s already running that way? Do you need additional security (authentication or encryption)? \$\endgroup\$
    – jcaron
    Jan 27, 2020 at 23:34
  • 1
    \$\begingroup\$ @FahadMirza ... I've updated my answer below to cover your comments. \$\endgroup\$
    – jonathanjo
    Jan 27, 2020 at 23:52
  • 1
    \$\begingroup\$ UDP is packet based TCP is stream based. For UDP you have to tolerate the possibility of lost packets if this were for example a temperature sensor and you were updating every so often who cares if every now and again one gets missed. For TCP you need to within the data being sent create a detectable structure, always assume TCP is a stream of bytes not packets so treat it like a fast uart and you have to take the bytes one at a time. so this creates more software on both sides. \$\endgroup\$
    – old_timer
    Jan 28, 2020 at 15:40

2 Answers 2


Choosing a transport protocol

The main issue with choosing a transport protocol is this:

What do you want to happen when a packet is lost/corrupted?

  • USE TCP If you want the protocol stack to fix it for you invisibly, you will increase jitter (TCP will time out and retransmit)
  • You can use an open/close per sample (simple but quite a lot of traffic)
  • Or open once and send many samples, close either never or infrequently (more complex and lost packet can delay many subsequent packets)
  • USE UDP If you want to keep the jitter down and just continue, you will have to accept the packet loss

Benefit of simplicity and one-way traffic

For many data collection projects UDP with a "transmit and forget" policy is the simplest and most reliable. Under some situations, it's good to broadcast so that the transmitter needs no packets whatsover from the receiver, not even ARP. If no packets are flowing from receiver to sender, then nothing the receiver does can cause a fault in the sender: this is an enormous advantage for embedded systems.

Syslog example

I normally use simple text over UDP; sometimes in SYSLOG format so I have easy tools for logging. Here are a couple of examples from different systems:

Typically SYSLOG messages are stored on the host with the host's timestamp and the hostname (or IP address) of the sender. I have the sensors use infinite-lease DHCP to decide their own IP address and the address to log to (and any other config such as log level), which makes my sensors identical. Logging includes hostname (from /etc/hosts, faster than DNS), which is the map between sensor and location. Many syslog daemons are very configurable all this, and it's easy to get accurate time with NTP.

One system is logging weather data, and its important to lock simultaneous measurements together.

temp=10.4C wind=1.9 m/s dir=194.0 RH=81.1% rain=0.0 mm/hr bar=992.6 hPa

Another is monitoring some water plant data:

datum valve31 0 state closed
datum valve54 1 state open
datum thing1watertemp 9.4 degC
datum thing2watertemp 9.2 degC
datum tankminsetpoint 200 mm
datum thing1offset 730 mm

UDP has a great advantage of being extremely easy to monitor too, because it doesn't have to be point-to-point. In the environment described, with configuration over DHCP, if you also have power over ethernet, you get the benefit of being able to power-cycle the sensors by control of the ethernet switch which then reconfigures the sensor.

SYSLOG has been extended since its origins and there are methods for structured data, but if you have that complexity you might consider something else. Here it's just a suggestion for getting the data off your sensors in a way that's easy to debug.


If your sensors and logger are only a few switches apart (ie, not the whole internet in between), your error packet rate is likely to be zero. With 5 sensors you have > 50 samples/second, your data rate is not going to be the top issue, but you might find that your receiver might not be able to open and close TCP connections at that rate, and so you might need complexity to work out when to close and reopen. If your clients are very small (such as Aduino ethernet with hardware TCP) you may find there is a very small number of TCP connections which can be open or half-open at any time. If you have 1000 sensors, scaling is definitely an issue with TCP and much easier with UDP, though you can't sensibly use broadcasts unless you design a particular VLAN structure (but if you do it's great). Some of my systems will log 300 events/second.

With embedded systems the dominant factor is simplicity and making sure that the unusual cases are just like the standard case. Carefully using protocols such as DHCP for configuration and simple SYSLOG or similar protocols radically affect debugging and deployment, which gives great longevity of the embedded unit.

  • \$\begingroup\$ Your assumption is correct, the server is only a few switches apart. \$\endgroup\$
    – Fahad
    Jan 27, 2020 at 23:37
  • 1
    \$\begingroup\$ It's an STM32 chipset, but I got the gist. \$\endgroup\$
    – Fahad
    Jan 27, 2020 at 23:51
  • 1
    \$\begingroup\$ Thank you for explaining elaborately. These are some great insights. The SYSLOG way of logging is a great idea. I will look into that too. \$\endgroup\$
    – Fahad
    Jan 28, 2020 at 3:04
  • \$\begingroup\$ Thanks for compliment. I've fleshed out the syslog and added dhcp, as the deployment issue is often more problematic than the transport. \$\endgroup\$
    – jonathanjo
    Jan 28, 2020 at 13:43

I'd seriously look into mqtt/udp. From the description of your project any old hack likely would work, but by using something like mqtt/udp your code/project would be reusable for other more sophisticated projects.


If you want this to run on a really, really small processor you may be able to reduce your network/mqtt stack significantly. 'Specially if you can hard-code things like ip numbers, etc.

  • \$\begingroup\$ MQTT/UDP is certainly excellent and lays down a good way to control the information complexity if you have high variation and want the interoperability. But I'd suggest that hardcoding IP addresses etc is an awful idea! DHCP/BOOTP takes the configuration off the embedded system into the networking, for easy deployment. \$\endgroup\$
    – jonathanjo
    Jan 28, 2020 at 1:30
  • \$\begingroup\$ Thanks, Tom. This looks interesting. \$\endgroup\$
    – Fahad
    Jan 28, 2020 at 3:06
  • \$\begingroup\$ I agree (hardcoding), but it depends on how much resources the chip your using has. I've rolled my own ip stack in cases where I'm counting bytes. \$\endgroup\$ Jan 29, 2020 at 23:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.