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.
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.