What Is SDI-12 and How Does It Work for Environmental Sensor Networks?

Detailed Explanation

SDI-12 stands for Serial Digital Interface at 1200 baud. It's a communication standard developed in the 1980s for the environmental monitoring industry and maintained today by the nonprofit SDI-12 Support Group, whose current specification is version 1.4. Unlike RS-485 or I2C, which serve general-purpose industrial and embedded use, SDI-12 was purpose-built for one job: letting a single battery- or solar-powered data recorder pull measurements from a handful of sensors scattered along a cable in a field, a well, or a weather station mast, without keeping the whole bus powered up between readings.

That narrow original brief still shapes every design decision in the protocol today. Soil moisture probes, tipping-bucket rain gauges, water-level and water-quality sondes, and weather-station sensor suites overwhelmingly use SDI-12 as their digital output, because it solves the specific problem those devices have: long cable runs to a remote logger, infrequent measurements, and a hard requirement to draw almost no current while idle.

Electrical basics: three wires, one shared data line

An SDI-12 bus uses three conductors: a switched power supply line (commonly referred to as the "12 V" line, though the specification permits the data recorder to supply anywhere from 9.6 V to 16 V, measured under a sensor load of up to 0.5 A), a ground reference, and a single bidirectional data line shared by every sensor on the bus.

That single data line is what makes SDI-12 a half-duplex, single-wire protocol: only one device (the data recorder, or the one sensor it has addressed) drives the line at any moment, and every other sensor's data pin sits in a high-impedance state until it hears its own address. This is a different wiring model from RS-485, which uses a differential pair (A/B) specifically to reject common-mode noise over long cable runs. SDI-12 instead relies on a single-ended line, kept practical by the protocol's low 1200 baud signalling rate and typically shorter, more controlled field cable runs than a plant-wide RS-485 backbone might see.

Per the specification, the data line uses two defined voltage bands: a "marking" (logic 1, idle) state between roughly -0.5 V and 1.0 V, and a "spacing" (logic 0, active) state between roughly 3.5 V and 5.5 V, with the region between undefined. Framing is 7 data bits with even parity and one stop bit, at a fixed 1200 baud. There is no baud-rate negotiation or configuration step: every compliant sensor and recorder uses the same fixed rate.

Addressing and multi-drop bus topology

Every SDI-12 sensor on a bus is assigned a single-character address from the set 0-9, a-z, and A-Z, giving a theoretical maximum of 62 sensors sharing one cable, per the specification's addressing rules. In practice, deployments are usually much smaller (a handful of sensors per cable is typical), because the address space is rarely the limiting factor; the recorder's power budget and cable voltage drop usually are.

The recorder is the only bus master: it initiates every transaction, and a sensor only ever speaks when its address has been called. This master/slave structure is conceptually similar to a Modbus RTU network on RS-485, where one controller polls addressed devices in turn, but SDI-12's addressing is baked directly into every command as the first character, rather than sitting in a separate protocol layer on top of the wire format the way Modbus's device address field does on RS-485.

Command and response timing: wake, ask, answer

Because SDI-12 sensors are expected to sleep between measurements, every transaction begins with a wake-up sequence rather than jumping straight to a command. The recorder pulls the data line into the spacing (active) state for a break period, then releases it to marking (idle) for a defined interval before sending the first command character. Sensors are given a bounded window (on the order of 100 ms per the specification) to wake from sleep and be ready to receive a command after the break. If a sensor sees roughly 100 ms of continuous idle (marking) time with no activity, it's expected to return to its low-power sleep state. Overall SDI-12 timing tolerance is tight: the specification allows only about ±0.4 ms of variation on most timing intervals, which matters if you're bit-banging the protocol on a general-purpose GPIO rather than using dedicated hardware.

Commands and responses are short ASCII strings terminated with ! for commands and a carriage-return/line-feed for responses. The two commands every implementation needs to understand are:

• aM! (start measurement), sent to address a. The sensor responds with atttn, where ttt is the number of seconds (up to 999) the sensor needs before the measurement is ready, and n is the count of data values (0-9) that will be available. A response of a0000 or similar means the reading is ready immediately.
• aD0! (send data), sent after the measurement delay has elapsed, or after the sensor signals it's ready with an unsolicited service request. The addressed sensor returns the actual measured values as ASCII text.

This two-step measure-then-retrieve pattern exists specifically so the sensor can power up whatever internal sensing element it needs (a TDR pulse generator for a soil moisture probe, for example), take the reading, and go back to a low-power state while the recorder waits out the ttt interval, rather than holding the bus and drawing power the whole time. Later versions of the specification (from v1.3 onward) added an optional CRC and higher-throughput commands (aC! for concurrent measurements across multiple sensors, and aHA!/aHB! for high-volume ASCII/binary transfer in v1.4) for applications that need more data per transaction, but the basic aM!/aD0! pair covers the overwhelming majority of field deployments.

Sleep current and why it matters for field deployments

The reason SDI-12 dominates environmental sensing has less to do with its data format and more to do with its power model. A data logger in a remote field location commonly runs from a small solar panel and battery, taking a reading every few minutes to every hour, then sleeping the rest of the time. An SDI-12 sensor is expected to sit at very low quiescent current whenever it isn't actively addressed. As one concrete example, METER Group's TEROS 12 soil moisture sensor is specified with a typical sleep current on the order of tens of microamps, rising to a few milliamps only during the brief measurement window itself, according to the manufacturer's integrator documentation. That combination of near-zero idle draw, addressed-only wake-up, and a bounded active period is what lets a battery-and-solar system support several sensors and years of unattended operation.

RS-485 and Modbus don't build this behaviour into the protocol itself. An RS-485 transceiver and its associated microcontroller can certainly be put to sleep between polls, but that's a design choice each manufacturer makes independently, not something the bus specification requires or standardises. SDI-12's break/wake sequence and defined sleep timeout make low power a first-class part of the protocol, which is a large part of why a device built for continuous-duty industrial equipment (a VFD, a PLC I/O module) is a poor power-behaviour fit for a soil probe that needs to run for a season on a coin-cell-adjacent power budget.

SDI-12 vs RS-485/Modbus for environmental monitoring

Both are multi-drop, address-based, single-master protocols, and it's fair to ask why the environmental industry didn't just standardise on RS-485 and Modbus like most of industrial automation did. The answer comes down to what each protocol optimises for:

RS-485's differential signalling is the better choice when a bus needs to run fast, run long, and shrug off heavy electrical noise from motors and switching equipment: the industrial automation environment it was built for. SDI-12 trades some of that noise immunity and speed for a protocol-level sleep/wake model that suits a sensor sitting at the end of a cable for months at a time on a small battery. Neither is a strict upgrade over the other. They were built to optimise for different constraints, and the environmental monitoring industry settled on SDI-12 because power budget, not bus speed or industrial noise immunity, is usually the binding constraint in that application.

Practical Examples

A soil moisture monitoring network for irrigation scheduling uses a battery-and-solar-powered data logger to poll four SDI-12 soil moisture probes buried at different depths along a 30 m cable run, plus a separate SDI-12 rain gauge tipping-bucket interface. The logger wakes once every 15 minutes, sends a break and aM! to each sensor address in turn, waits out each sensor's reported ttt delay, retrieves the readings with aD0!, and returns to sleep. Because every sensor and the logger itself spend the vast majority of their time in a sub-milliamp sleep state, the system runs for an entire growing season on a modest battery topped up by a small solar panel.

A groundwater monitoring well uses a submersible SDI-12 water-level sensor connected to a telemetry-equipped data logger over a cable run of roughly 60 m. The logger takes a reading every hour and transmits the result over a cellular connection once per day, illustrating a common pattern: SDI-12 handles the local sensor-to-logger link, while a separate wireless or wired backhaul (cellular, LoRaWAN, or Ethernet) carries data from the logger to a central database.

Design Considerations

• Choose a data recorder with confirmed SDI-12 support and enough sensor power budget. Not every microcontroller-based logger implements SDI-12 in hardware; some bit-bang it on a GPIO, which works but needs careful attention to the ±0.4 ms timing tolerance the specification calls for. Confirm the logger can supply the combined sleep-plus-active current of every sensor on the bus within its 9.6-16 V supply rating.
• Use appropriately shielded, direct-burial-rated cable for field runs. Environmental SDI-12 cables are frequently buried, run through conduit near irrigation equipment, or strung along a weather mast, all environments with real risk of moisture ingress, rodent damage, and induced noise from nearby AC equipment or lightning. Grounding the cable shield at the data recorder end only (not at both ends) avoids ground-loop currents on the shield.
• Verify sensor voltage and logic compatibility before mixing brands on one bus. Most SDI-12 sensors expect the 9.6-16 V supply convention, but a small number of low-power or 3.3 V/5 V-native devices exist with different power requirements. Check each sensor's datasheet rather than assuming every SDI-12-labelled device shares identical electrical requirements.
• Budget the measurement window, not just the sleep current, into the battery calculation. A sensor's ttt response tells you how long it needs before data is ready. That window is the sensor's active current draw, and it's the dominant term in the power budget even though it happens for only a small fraction of the duty cycle. See how to calculate battery life for the general duty-cycle-weighted approach to combining active and sleep current into a runtime estimate.

If you're building an environmental monitoring product from scratch, spanning sensor selection, data logger firmware, and the telemetry backhaul that gets readings off-site, Zeus Design's embedded firmware team can implement the full SDI-12 master stack, including wake/timing-compliant bit-banged or UART-based drivers and the power-management logic around them.

Common Mistakes

• Treating SDI-12 like a simple half-duplex UART link and skipping the wake sequence. A command sent without the preceding break and marking period will be ignored by a sleeping sensor, and the transaction will silently time out. The wake sequence isn't optional framing overhead; it's how the protocol tells every sensor on the bus "wake up and listen for your address."
• Assuming the 62-address space is also the practical sensor limit for one cable. The address space is rarely the binding constraint. Total sensor current draw against the data recorder's supply rating, and voltage drop over a long cable run, typically limit a real bus to far fewer sensors than 62 long before addressing becomes the problem.
• Wiring SDI-12 sensors onto an RS-485 bus, or vice versa, expecting compatibility because both are "multi-drop serial." The two protocols use incompatible electrical schemes: single-ended versus differential, different voltage conventions, and different timing. They need separate physical interfaces or a purpose-built bridge, not a shared cable.
• Polling sensors faster than their reported ttt measurement delay allows. Sending aD0! before the sensor's reported preparation time has elapsed returns stale, incomplete, or garbage data rather than a fresh reading. Always wait out the full ttt interval (or wait for the sensor's own service request signal, where supported) before requesting data.
• Skipping cable shielding and grounding on outdoor runs and blaming the protocol for intermittent faults. SDI-12's low baud rate makes it fairly tolerant of noise compared to high-speed buses, but a field cable exposed to lightning-induced transients, nearby motor starters, or moisture ingress at a poorly sealed connector will still produce intermittent read failures. Diagnose these as a wiring/grounding problem first, not a protocol limitation.