SDI-12 Sensor Network Best Practices

Learn what an SDI-12 network does, pros/cons, how to design and build your own sensor bus, and troubleshooting.

In this webinar, Chris Chambers, METER customer support expert, teaches the best practices for setting up SDI-12 sensor networks.  He discusses what an SDI-12 network does, the pros and cons of SDI-12, how to design and build your own network and sensor bus, and how to troubleshooting problems.

Next steps


Our scientists have decades of experience helping researchers and growers measure the soil-plant-atmosphere continuum.


Chris Chambers operates as the Environment Support Manager and the Soil Moisture Sensor Product Manager at METER Group, the world leader in soil moisture measurement. He specializes in ecology and plant physiology and has over 10 years of experience helping researchers measure the soil-plant-atmosphere continuum.


See all webinars

Soil hydraulic properties—8 ways you can unknowingly compromise your data

If your data are skewed in the wrong direction, your predictions will be off, and erroneous recommendations or decisions could end up costing you. Leo Rivera discusses common mistakes and best practices.


Soil Moisture Sensors in the Greenhouse For Better Yield and Quality

Dr. John Lea-Cox discusses how soil sensors lead to water savings, increased yields, improved quality, and a more efficient and profitable operation.


Methods of Sampling and Analyzing Soil Pore Solution

Leo Rivera and Chris Chambers teach different methods for sampling and analyzing soil pore solution.


Case studies, webinars, and articles you’ll love

Receive the latest content on a regular basis.


Good morning and welcome to today’s seminar titled Best Practices of SDI-12 sensor networks. Chris Chambers is going to walk through what that alphanumeric means and its applications in environmental monitoring. Before going forward, let me remind you that the seminar is under copyright. We want you to share this information with others that might find it useful. But please just write Chris an email to get permission to post it in a different location than where it’s going to be found on the website. That being said, you’re more than welcome to link to the archive of this seminar and its supporting material after we post it on the website. Chris is going to talk for about 45 minutes and leave 15 minutes after that for questions. We’re also going to have a new forum on SDI-12, where Chris will answer any additional questions you have. At the close of the seminar, a brief survey will pop up. At this time, you’ll have the option to request more information about Decagon SDI-12 sensors. And I’ll let it go to Chris Chambers. Thanks for attending today.

Thanks, Lauren. Well, I’d like to start out by, let’s just see how much experience people have with SDI-12 networks.

Okay, so here’s just a quick poll. Just please let us know, we’ll give you a couple of minutes, find out the experience of our audience, and see if we can tailor it somewhat to where you guys are.

Okay, we’re gonna close the poll and show it now. We got just, most of everybody responded. And here’s, so you should be able to see the results for it. So it looks like most people have some experience with it or are intending to use it, with a few of you just finding out some more information. Okay, thanks for sharing that. Now we’ll talk, I’ll just give you a brief introduction of what SDI-12 is, what the pros and cons are, and then we’ll talk about building some sensor networks, some of the things that need to go into the design of these networks, and in the end, we’ll talk about troubleshooting. SDI-12 stands for Serial Data Interface at 1200 baud. I highly recommend you check out the website,, where all of the standard communications are. You can find SDI-12 compatible devices there. It’s a great resource if you’re going to be using the standard communication protocol. It’s a three wire interface. And the basic idea is that you can put lots of smart sensors on a common data line. And I’ll talk more about this in a moment. I do want to mention the Decagon sensors. Decagon digital sensors have two modes of communication. Essentially, you will provide the sensor with power, and then. So this is one mode of communication. You give the sensor power and then it just spits out a serial string of data. And then after it’s given you its data, it enters SDI-12 mode.

So here’s kind of a schematic of what that looks like. In the first mode of communication and in many serial communication schemes, the sensor is just sending data to your data logger. In this way, you have one sensor on each data logger port. So for three sensors, you’ll need three different data logger ports. SDI-12 lets you put all three of those sensors onto one data logger port, and it’s a two way communication scheme. Sometimes this means you have to use a different port on a data logger, so it’s one thing to look into that’s dependent on your data logger. I mentioned that it’s a three wire interface. So what you have with SDI-12 is your data line, a ground line, and a 12 volt line. And each sensor requires a unique address or a name. This is how you can communicate with many sensors on the same line. So it’s two way communication between the logger and the sensor. What happens is the logger queries each sensor by its address, so the sensor wakes up and responds to a command from the data logger. There’s only one sensor active on the data line at any given time. All of the other sensors are acquiescent and basically just listening mode. Decagon has currently three SDI-12 sensors, the 5-TE, the 5-TM, and the MPS-2. It is a standard communication, so there are other sensors by other manufacturers that make SDI-12 sensors. We have two upcoming sensors that will also communicate in SDI-12. It’s our greenhouse sensor, the GS-3, and our ruggedized sensor, the RS-3.

One of the advantages of SDI-12 is that it’s a cost effective way to put lots and lots of sensors on one data logger. Now the number of addresses that can be accepted by a sensor vary from sensor to sensor, or manufacturer to manufacturer. The Decagon sensors will accept 62 unique addresses. That’s zero to nine, then lowercase A to Z and then uppercase A to Z. It does simplify the programming in some cases. And basically you can have 60, basically 62 sensors on each port. So a logger with four communication ports can have more than 200 sensors on it. Okay, this is the setup. We’ve got an SDI-12 compatible logger here with two buses. On a logger like this, there are four communication ports. So normally without using SDI-12, you could put four digital sensors on here. And that’s it. This particular logger has 10 SDI-12 — or nine SDI-12 sensors running on it. Six sensors here going into column two, three sensors here going into column one. So you can effectively exponentially increase the number of sensors you can put on one data logger.

The disadvantages of SDI-12 are that if one sensor fails or is damaged, every sensor connected to that port can go down until the offending sensor can be removed from the data line. Now I’m sure everybody’s in their happy place right now, SDI-12, lots of sensors, yay. Nope, nope, come back from your happy place. If one sensor fails or is damaged, every sensor on that port will go down, just like your Christmas tree lights. So this is the trade off. If SDI-12 were a Faustian deal, this would be the part where you sell your soul to the devil. Okay, so I just want to, this trade off is the most important thing to consider when you’re thinking about implementing an SDI-12 network.

So when you’re actually networking, first you need to select an SDI-12 compatible logger. Your logger manufacturers, there are several out there now, they can help you out there. You’ll also need SDI-12 compatible sensors. And then you need to address your sensors. For example, all of the Decagon sensors leave the factory with a default SDI-12 address of zero. If you want to put 62 sensors on one port, you’re going to have to give each sensor on that port a unique address. This is easy to do with a ProCheck. That’s a handheld device that we make that, among other things, can address your sensors. You can also do it with a terminal program, or a terminal emulator if your data logger has one of those. And then the next thing you’re going to need to do is set up your bus. So it’s very impractical to cram 62 sensor leads into one terminal. And this is what the bus does. It’s just a way to expand that one port into 62 or 10 or however many. This is one of the ones I use all the time. It’s homemade. It has six places for six different sensors. Okay, so your bus construction is very important. Again, it’s just a way to get everybody to one place, right. You need a way to get all of your sensors into one port, so just like a bus, it will, you know, carry everybody where they need to go. But if your bus goes down, you’re done, right. That’s lots of data that you’re not getting. So spend some time on your bus construction.

Here’s the idea behind a bus. Here, we’ve got sensors one through nine, and then A, B, C, D, E. And they wire directly into your bus, and then you have your bus wiring directly into your data logger port. Here’s the one I was showing you earlier. Remember, SDI-12 is a three wire interface. So if you’re constructing your own bus, all you need to do is have the terminals go to a common line. So here we’ve got our red, this is a red wire, I think is right here. And this is what it looks underneath. All of the terminal posts for this bank of wire terminals here are soldered together on a common line, and that’s the red line going in here. Your ground line goes to the next one, and your white, your excitation line, goes in here. This is a pretty good setup, this bus works very well. Note, I want to point out this part right here where all these wires are crossing, this is fine. But if something moves in this, if this ground wire crosses with this bare part of the red wire, you’re gonna lose your bus. So even though this is a pretty good, this bus works pretty well, this is a warning flag right here. I don’t want these wires crossed, otherwise, it’s not going to make me happy. Here’s another homemade bus. Basically, anything that works, you can do for this. But you know, I don’t know if I want to put electrical tape out in a sensor network in the field. Changing temperatures do some pretty crazy things to tape, and if this bus falls apart on you, you’re gonna lose all of your data for that time period. So if you’re making a homemade bus, you want to make it to last. This looks ugly, but this is a really solid, strong bus. I would put this in the field anytime. Here you’ve got your white wires all going into a common bank here, your ground is in the middle, and here’s your data line.

This is a sketch, this is something we’re thinking about doing, just as a potentially commercially available bus. I don’t know if you’re familiar with Decagon’s stereo connectors, but this is one idea for a 10 sensor bus. I think we’ll be producing these in the not too distant future. This is going to have some pros and cons in it as well, where you just plug your stereo line in, your stereo connector in here. You can have 10 different ones coming in, if you need to troubleshoot if you just pop it out really quickly, and plug it into your ProCheck or whatever. But I really want to just illustrate with this that there’s lots of different bus designs. I’ve seen some that have screw terminals that are just connected by a jumper wire. I think soldering is a good way to go. Make sure you have good soldering practices. And I’ll talk about troubleshooting a little bit later on.

So we showed you the one with all of the sensors going into one bus. Here’s another potential idea. This has some advantages and disadvantages. If you’re going to have several smaller nodes of sensors, it’s not a bad thing to bring them in sequentially. There’s a couple of situations where this might be good. If you’re troubleshooting and you have a data logger that you can take to each node and plug in and each node, you can start excluding entire banks of sensors. This is going to be a pretty good design if you’ve got sensors that are dispersed along a transect or in small plots or something like that. And a good way to troubleshoot with this would be to go to your — you’re gonna start here or start here, connect another logger with the test program, and see what sensors you get. Now remember say a sensor nine goes out, none of these sensors are going to be able to report. So you can check here. If you connect it here, you would get three good sensors. If you connect it here, you would get six good sensors. If you connect it here, then all of a sudden none of your data is going to come through. So you know, the problem is right here. You can start on either end or you can split things. But this is just one way to work on finding a problem sensor faster. Because you can imagine the more sensors you have on one data line, the harder it’s going to be to find the one sensor that goes down. It could have gotten chewed halfway through by a rodent, it could have just had a problem.

Okay, so cabling. I want to touch on this briefly. There are practical limits to how far you can run cables, and it is a consideration if you’re going to be spreading sensors all over the landscape and bringing them into one data logger. In SDI-12, you can have approximately 1000 meters of cables in a network. That’s just a rule of thumb, it can go longer, maybe shorter if you’ve got lots of long cables. And cables are expensive too. So just because you can put 62 sensors on one logger doesn’t necessarily mean that it’s going to save you a lot of money because you don’t have to buy other loggers. So this is something I do recommend thinking about. Look at the cost of cable, look how far you’re gonna have to spread things out. Okay, here we go. Now, this is a case where you can also set up your design to minimize cabling. If you have a separate cable running from each of these — from this bank, to this bank, to this bank into your data logger, or into another bus or a node, they’re going to have longer cables, and it’s going to, you know, it’s just going to add the time it takes for a signal to go all the way down here and all the way down here because keep in mind when they’re trying to wake up a sensor, it’s talking to the entire network. Say it’s trying to find sensor C, right, so the signal’s going through the entire network simultaneously. So you do want to consider your cable links when you’re designing your sensor network.

Okay, so spread the risk is one recommendation, I think, that I try to get across to customers that are using it, that are going to be using SDI-12. Just because you can put 62 sensors in one port doesn’t mean you have to. If you have four available ports, spread them to every port, it just minimizes the damage it will do if one sensor goes down. Now you need to think about troubleshooting as well because sensor failures do happen. Rodents chew cables, we have about a one to one and a half percent failure rate here with Decagon sensors, so if you’re putting 100 sensors out, odds are you’re going to have a problem with one sensor, and that can be a big deal in SDI-12. I recommend that you have an independent way to test sensors. If you’re using Decagon sensors, I highly recommend a ProCheck. I would give these things to everybody that has a large SDI-12 network if I could, but we will give you a discount if you have larger sensor networks. So please check into a ProCheck if you’re using Decagon sensors in SDI-12. Try to find some way of independently reading sensors if you’re not using Decagon sensors, preferably portable. It’s nice to just be able to go out, unplug one sensor, and test it and make sure it’s doing what it is supposed to be doing. Also test your bus. One way to do that as a continuity check. And so any multimeter can do it. This is one of the fancy ones that one of our electrical engineers use. Right here he’s got it set to resistance. So what you’re looking for is a high resistance or someplace where you’re just not getting good contact between the sensor port and your line. And you’ll want to go through and check each individual port. So check this terminal. Check all six of these. Make sure they’re getting good continuity with the full data line. Just remember that a problem in one of these ports could be a problem for all of them.

Okay, I want to stress how important it is to have an independent way to test your sensors. I already mentioned the ProCheck, this is what the screen looks like. Again, it’s great for for changing addresses in SDI-12 as well, you plug your sensor into this, here’s your default zero, this one’s being changed to one — that’s all you do is you select the number or letter that you want to change it to and hit enter, and it’s done. And it also tests the sensors in SDI-12. So if the sensor is working on the ProCheck, it’s communicating in SDI-12. This, I want to show this because these are some of the things that can happen with a bad bus. Before I made the bus I showed you earlier with the six sensor bus, this is some data in SDI-12 from a sensor network on a homemade bus that I made that was not well constructed. And you can get some odd things. Notice here that this would be where your water content numbers are. It’s not coming up as anything, but you are getting data. So there’s a sensor here that is getting a signal through, it’s hard to tell exactly what the problem is with this bus, whether it’s not getting power, but notice a temperature reading is coming through here. So you can get some very odd readings. You know, it looks like it’s almost working, and I tested all these sensors later, put them on a good bus, and they all ran fine. So putting a good bus out in the beginning is important, but also being able to test it and test your sensors individually is also very important.

Okay, some questions to ask before you go into SDI-12 to find out if it’s going to be right for you. Is it hard to access your data or your field site? You need to be able to get a keep a close eye on your data. How bad is it to not have data if you can’t get to your field site for a few days, and you have a sensor problem? How important is it going to be to lose all the sensors on that port for that problem? If every single piece of data you have is critical, SDI-12 might not be the best plan for you. And again, how hard will it be to find a problem if one arises? Are you going to have hundreds of sensors with a full kilometer of cables going out? You know, SDI-12 might not be the best option. And I don’t want to discourage anyone from using SDI-12. It’s a great protocol. We have lots of customers that use it and use it successfully, but there are alternatives and some places the alternatives are better than SDI-12. Say you have a highly displaced network of plots, there’s a lot of good wireless networking options out there right now. Lots of data logger companies are getting into that right now. So you can probably find a wireless option if you’ve got highly dispersed sensors. Multiplexing is also an option in many different systems, where each sensor is read individually, and they’re not on a common data line. So some cases, that might be the best option for you, particularly if you’re not going to be able to check your data frequently, or if your data, the most data is very important. So if you can’t afford to lose any data, you might consider multiplexing or having more loggers out on the landscape.

Okay, I believe in quizzes. So question number one, and we’ll set this up as a poll again. SDI-12 lets you put 62 sensors on one port and greatly reduces the investment in data loggers required for large sensor networks, True or false? 100% true, so far. Okay. The answer is true. And this is the big advantage of SDI-12. It lets you put lots of sensors on one logger, and it reduces your investment in loggers.

Next question. One shorted sensor on a bus of 62 sensors will bring down the entire bus. True or false? I’ll give you guys a few seconds to answer this. Oops, sorry, I just went back there. Okay, this is true. One sensor failure will bring down all of your sensors. Looks like we had a few people answer false here, about 20%. So come away from your happy place. Remember, one failed sensor can actually make you lose all of your data. And this is the big trade off. So this is, you know, lots of sensors on one bus versus losing all of your data for that bus if one sensor goes down. Okay, it’s probably the most important thing to think about when you’re considering using an SDI-12 network.

And one more question, a great SDI-12 application will be to put 62 sensors out in a remote location on one bus and not check them for a year. True or false. Okay, just see the results from that. Almost everybody got that one right. You know, I would reconsider using SDI-12 in this application. You’ve got a lot of sensors out there. In the course of a year, you don’t know what’s going on out there.

So again, back to our take home points. If you use SDI-12, check your data often. Be able to get to your sensors quickly if there is a problem. And the third one, look for a good troubleshooting scheme. I would not recommend SDI-12 In this scenario. Okay, that’s pretty much, that’s all I’ve got. I will take some questions. You have a chat option in which you can type in some questions. Feel free to email [email protected] if you have any questions. I have a forum post started, so if you want to visit our forums, go to the soil moisture section, and there’s a topic for SDI-12. I’ll probably head up there right after this presentation, so if you have any more questions there, feel free to post them. And I want to reiterate that it’s it’s it’s a great protocol, there’s a lot of things you can do with it, but just keep in mind that there are trade-offs, and there are some things that you should consider when using SDI-12.

Okay, now questions we have. One good question is, how hard is it to pinpoint a faulty sensor? This is where your network planning comes in. You know, if you’ve got 60 sensors and no independent way to test them and no way to isolate the sensors, then it can be tricky. If all you have is the data logger, and you’re certain that data logger is working well, then I think the place to start for sensors on one bus is to keep your program running or have a test program that you can load to your data logger and just unplug one sensor at a time. Unplug one sensor at a time, do a scan, and when you’ve removed the bad sensor, if there’s only one bad sensor, then your network will come up. Now you can imagine if you’ve got, say, 50 sensors on one port and you’ve got two failed sensors, this troubleshooting problem isn’t, this isn’t going to work troubleshoot it this way. So this is where I highly recommend having an independent reader. If you’re using Decagon sensors, the ProCheck is indispensable. So please, please, please if you’re buying lots of sensors, purchase a ProCheck as well.

Okay. If we don’t want to build our own bus, where can we purchase one? Actually, that’s a great question. I don’t know of any — just because I don’t know doesn’t mean they’re not out there. But I don’t know of a commercially made bus, like a three wire bus that specifically has three separate banks of terminals with common lines on them. We’re going to make one for, it’ll only be used for our sensors. Most data logger manufacturers that I’ve talked to have recommendations. So I do recommend that you talk to your manufacturer. Probably one of the easiest ways to make a bus is to have independent screw terminals and put a jumper between them. That’s pretty good way to go. But there probably are some out there. Ask your data logger manufacturer first.

Okay. So, one question, is there any way to let the user know as soon as the network fails? There are some things you can do. With our, again, I would check with your data logger manufacturer. There are some programs that you set up. Again, this is dependent on the data logger, but there are some programs that you can set up that will notify you. If you have communication, if you have your logger connected to the internet or a cell network or satellite network, you can design some programs to send up red flags or send you alerts if you do have a problem. That would be a great way to go. If not, just check your data every day if possible, or weekly, or whatever basis you need on the scale that you cannot lose data.

Can SDI-12 protocol be used in a wireless application between a powered bus and a data logger? That’s interesting. I’m not familiar with the powered bus idea very well. I imagine that you can run your sensors off of a separate power source. I haven’t done that before. I think I would want to play around with it before I committed too much to that, but the wireless application is going to mostly, you’re going to have to have some kind of data logger or data reader there. I’m not familiar with any of those, but I suppose you mean in a wireless sensor node. Gosh I would think you would need a data logger in these applications and then if you wanted a wireless option that would have to have a wireless capability.

Okay, what were the sensors available from Decagon and the application for each? Our current SDI-12 sensors are soil moisture sensors. They have soil moisture and temperature, soil moisture and electrical conductivity and temperature, and our latest one is water potential but they are soil moisture sensors.

Question, is there a priority in placing instruments in a bus for example, the first instrument to be read need to be placed first in the bus etc. No, there is no priority as far as the system working. But for troubleshooting, I highly recommend that you have some kind of late sensor labels or position in the bus so that you know which sensor goes where and which sensor has which address. That will make your troubleshooting much easier.

Could you not use a small household electrical panel such as a sub panel as a bus? Sure. You know as long as it has a common line for all of your sensor terminals, you can use pretty much anything you want. You could actually solder all of your red and white and ground lines together if you wanted to. I do not recommend doing that though. But sure that there’s a lot of flexibility in what you make as your sensor bus.

Can we connect two parallel data loggers to 62 sensors? Oh, boy. I am not sure. You know what, if you want to post that on the forums, I will check with a couple of our engineers and some of our people who do a little more technical things with data loggers and check with them on that. But I’m not sure about the answer to that one.

So it looks like we’re getting to most people’s questions. Oh, here’s another interesting one. Could you have more than one type of SDI-12 sensor on the same port? Yes, you can actually. I’ve done this, it works. The main issue you need to consider here is data storage. So say one sensor I’ve used sends back three readings. Another sensor I used sent back five readings. They were both on the same port, they had different SDI-12 sensors. One of these were actually a tensiometer, an SDI-12 tensiometer and one of our sensors. And yes, you can use more than one sensor. You’re going to have some data storage issues, but that’s the main problem you need to work out. And keep your troubleshooting in mind when you do this.

So I think I’m going to sign off there. Thank you for attending. I’m going to give it back to Lauren here for just a minute. And we will, feel free to visit the forums or send us an email at [email protected]. Thanks.

Thanks again everybody for attending. And thanks Chris for doing this virtual seminar today. This is a really new — well, it’s new to Decagon at least in the past couple of years. And we’re having a lot of fun with this protocol. We’re learning a lot about it. We hope that you guys use it in the right applications and call us if you have questions about if your application is the right one or not, if you still have questions after the seminar. After this, if you have any questions or you want some more information about our sensors, the survey is going to ask about that. That’s all the survey asks. So if you don’t have sensor questions, don’t worry about it. You can write Chris directly at [email protected] with additional questions or just post them on the forum. Or you can call us at 1-800-755-2751. Thanks again and I hope we see you again at the next seminar.

icon-angle icon-bars icon-times