METER SDI-12 best practices

METER SDI-12 best practices


An SDI-12 sensor bus is a serial network of sensors that share a common power, data, and ground line in order to communicate with a single data recorder.

Figure 1. Sensor bus

Setting up an SDI-12 sensor bus so that it can read the sensors is pretty straightforward, but what happens if something goes wrong? Inevitably electronics will wear out, short, or fail via some other means. When a sensor fails, it can short the signal lines so that other sensors on the bus stop communicating. Only when the faulty sensor is removed or replaced will all the sensors start communicating again. Without feedback from the working sensors, tracking down a faulty sensor can be extremely time consuming. This document is intended to be used as a guideline for good bus design and management techniques to ensure the quickest recovery time if a sensor bus goes down. Consider the following questions before creating an SDI-12 bus:

  1. How often do you need to check the data on your SDI-12 bus? If the data are extremely time sensitive, sensor failure must be detected as soon as possible. This can be accomplished by an automated SDI-12 system which is capable of sending a message when a sensor is failing or reading out of range. For non-automated systems, check sensor outputs on a regular basis to reduce the possibility of lost data.

2. How is the data delivered to the end user? The more convenient it is to check sensors, the sooner problems can be detected. Direct connection to a PC is ideal for buses that are in close proximity to a workstation. Telemetry via radio, Bluetooth or internet delivery are examples of quick and efficient ways of obtaining data from remote locations.

3. If a sensor fails, how do I determine if it’s a firmware problem? The advantage of using digital sensors is that they can be reset by cycling the power. If using METER’s SDI-12 sensors, turn off the bus power for approximately 5 to 10 seconds, and then turn the power back on. If all the sensors are working, then the problem was probably a firmware malfunction. Occasionally, firmware failures can be caused by lightning strikes or other electrical events. It’s a good idea once the sensors are up and running again, to verify that the sensors are all reading reasonable values.

4. How easy is it to isolate a faulty sensor? Most often, if a sensor becomes faulty it will scramble or short the SDI-12 data line so that all the sensors on the bus will stop communicating. The more sensors that are on a bus the more likely this will happen. The best practice is to keep the number of sensors on a bus to a manageable size.

To isolate a faulty sensor on a heavily loaded bus, it’s best to switch off groups of sensors at once. This can be accomplished by incorporating switches into the design so that banks of sensors (or even individual sensors) can be selectively shut off. Once a group of sensors is shut off, try communicating to the powered sensors on a bus with the SDI-12 recorder. If the powered group works, rule it out and narrow down the search. In addition to using an SDI-12 recorder to test for faulty sensors, a ProCheck can be used to check each sensor individually. Because the ProCheck uses a wildcard ‘?’ character to address the sensor connected to it, it can only be used with a sensor whose data line is isolated from the bus.

5. Anything else I should keep in mind? When dealing with multiple sensors (especially if the sensors are buried in the ground), it is imperative to label sensors. Keep a record of which sensor matches each address, and label each sensor cable near the bus junction box with a tag identifying the sensor type, depth (if applicable), and the address it is using.

For more best practices, watch this video.

  1. Go back to SDI-12 main page
Less work. More plug and play.

Less work. More plug and play.

The EM60G’s seamless system doesn’t require any integration. The hardware, software, connectivity, and firmware all work together automatically. So you get the data you need, in the format …