Which protocol is the best?
People may wonder, why use SDI12 when there are other protocols with far wider adaption than SDI12? Two commonly encountered ones are Modbus (in its many varieties such as Modbus-ASCII, Modbus-RTU, Modbus-TCP) and NMEA-0183 There are others like Profibus, HART and Fieldbus (widely used in process control applications), CANBus (automotive), DNP3 (for wide area telemetry), I2C and SPI (used between sensor chips and controllers, especially Arduino, Raspberry Pi) and even discrete I/O (4-20mA, 0-20mA, 0-1V, 0-10V, relay outputs, etc). There is an unlimited variety of proprietary protocols developed by individual sensor manufacturers, to be considered. This is a never ending topic, so for simplicity, this post will focus on SDI12, NMEA0183, Modbus and proprietary protocols as these are the most commonly used in environmental monitoring applications. Data-loggers, RTU’s and PLC’s commonly support these protocols.
SDI12 was designed from the ground up by the USGS to suit hydrographic applications. You can view the full history of development on the SDI-12 support organizations history page. The main goal was to standardize the interface and move away from discrete analog and proprietary serial protocols so that field wiring (and programming) was simplified by standardization
- Long cable runs: The protocol communicates at the slow 1200 baud rate because the volume of data is so low, and running at a slow baud rate allows long cable runs.
- Multiple sensors per port: Addressing is built into the standard so multiple sensors can connect onto the common 3-wire bus.
- Low power: The protocol is designed for remote environmental monitoring so in-between the measurements (typically >10s or slower), the sensor is allowed to sleep, with a wake command supported. Upon waking, an instrument tells the datalogger when to expect the new measurement. Sleep mode often allows instruments to operate in the mA or uA range
- Error checking: CRC error checking is supported to ensure data accuracy.
- Sensor interchangeability: A level sensor may be changed with another, and provided they have the same address, you can swap an instrument with another of the same model (without worrying about sensor calibration) and sometimes swapping one from another manufacturer (if the parameters are in the right order).
- Human readable: An output string of “0+11.6+0.003+18.7+4710+5383+3.00” can be diagnosed if you know the sequence. In this case 11.6V from the power supply, 18.7oC temperature, 0.003m water level, etc.
- Full Definition: Everything is defined, the transport layer and the data structures
- Sensor Options: The main limitation is that it is not widely supported for sensors not commonly used in environmental applications, especially when compared to abundance of Modbus based sensors.
- RTU/PLC Options: Similarly to the sensor options, many industrial controllers do not support SDI12 inputs, or require additional input card modules.
- Price: Because the environmental market is far smaller than the industrial, automotive, process control or even marine markets, the cost of SDI-12 sensors may be significantly higher than the same equivalent Modbus or NMEA sensor. Compared to IoT applications which commonly use I2C and SPI, the price difference is orders of magnitude.
- Definition of the data: An output string is often as simple as “0+11.6+0.003+18.7+4710+5383+3.00”. Only with reference to the product manual, do you know which value corresponds to which parameter. Version 1.4 of the standard seeks to improve this.
Designed in the 1970’s by Modicon, Modbus has the advantage of being the most widely supported digital protocol, to the point that some consider it a defacto standard. Modbus as a term typically covers the generalities of the distinct subsets – Modbus ASCII, Modbus RTU and Modbus TCP. Modbus moved from proprietary, to royalty free, to now being an open standard. Modbus is used between RTU/PLC controllers and SCADA, as well as between RTU/PLC controllers and instruments. The main difference between Modbus ASCII and Modbus RTU is that Modbus RTU is in binary format.
- Faster: While not fast compared to profibus, it is far faster than SDI12 and designed to be always on so sensors do not sleep like SDI12.
- Bidirectional: The communications is master-slave but data objects may be read or write, allowing control, whereas SDI12 is conventionally used to read data from sensors only
- Error checking: CRC error checking is supported to ensure data accuracy.
- Addressing: Addressing is supported where the physical layer supports it. RS485 supports addressing
- Distance: RS232 is limited to around 10m in most practical applications. RS485 can run for km!
- Variations: Modbus is actually many standards (ASCII, RTU, PLC) as well as having many transport layer standards (RS232, RS485-2wire, RS485-4wire). What may seem compatible is often not.
- Data types: Being developed in the 70’s means that modern data types such as higher resolution binary objects are not supported.
- Power: Always on and fast equals high power which is a problem for solar applications. Modbus can from industrial control where power was not as limited as the environmental field.
- Addressing: Yes, this was a feature, but as many environmental systems only support RS232, addressing is not supported. Tx/Rx (2 lines) is twice as many data ports as SDI12 (a single data bus)
- Readability: Messages are in ASCII which can be read once the data structure is understood
- Error checking: Checksum error checking is supported to ensure data accuracy
- Price: Widely supported in the marine industry which can result in cheaper sensors than the environmental market due to the volume of the market and differences in accuracy requirements.
- Not addressable: One Talker, Multiple Listener. Data from a single instrument may be decoded by multiple listeners, but in most environmental monitoring systems, the opposite is preferred, multiple instruments to one listener.
- Licencing: According to Wikipedia, “The NMEA standard is proprietary and sells for at least US$250 (except for members of the NMEA) as of June 2013”
A proprietary protocol is one which has been designed to suit a particular manufacturer. With serial instruments, it is often used to lock together the sensor and the datalogger (not going to mention any names here) so that a premium can be charged. Alternatively, it may be used for its low cost to develop. Plug & play networks or low cost sensors are two potential “features” but please pay close attention to the disadvantages. Rarely is a proprietary protocol as suitable as an existing standard.
- Far greater development time
- Potential need to reverse engineer the protocol
- Addressing rarely supported
- Depends on transport layer but often limited to RS232 distances around 10m
- Rarely do proprietary protocols support error checking (CRC/Checksum)
There is no such thing as a perfect protocol, but it is clear that the advantages of each protocol suit the industry from which they came. Environmental applications need simple field wiring, potentially long cable runs (i.e. to a point in a river), need to run from very low power, and keep it simple for field staff from a non electrical/electronics background. Modbus is the de-facto standard so at some point you are probably going to need to use it. NMEA is a requirement when it comes to GPS particularly, and may be useful to find cheaper weather and hydrographic instruments but otherwise provides no advantages over the others. Proprietary protocols should be used only when a standardized one is not supported. Proprietary protocols need to be evaluated from a total cost of ownership perspective. It will almost always be the most difficult to develop and maintain and therefore the most expensive over the long run.
We would love to hear your thoughts, so please be constructive!