RS-485 Modbus
soil sensor wiring.

If you're building a sensor node for an orchard, a vineyard, or any high-value crop where the sensor cable will run more than a few metres along a drip line, RS-485 is the right physical layer. It is differential, low-impedance, electrically robust against the noise that fertigation solenoids and irrigation pumps inject into nearby cabling, and it allows a single twisted pair to carry a multi-drop bus of dozens of sensors.

The vast majority of Chinese in-soil sensors — ZTS, JXCT, JXBS, Renke, SN-3000 series, DFRobot SEN0600 series — ship with RS-485 as the default electrical interface and Modbus RTU as the default protocol. Once you accept that, the design problem stops being which sensor talks which protocol and starts being how do I wire 4 or 5 of them off one bus, supply 12V cleanly, and handle termination.

This page documents the wiring, electrical, and software conventions that have worked across multiple sensor families on the Sankhya Intelligence v4 carrier board. The goal is to save you a week of bench-debugging.

Almost every RS-485 Modbus soil sensor in this category ships with a 4-conductor cable, colour-coded as follows. The colour convention is consistent across ZTS, JXCT, Renke, and SN-3000 — verified on bench. Do not assume the convention holds for sensors from other suppliers without checking.

Some Renke variants substitute green for yellow and white for blue. The shield, if present, is connected to GND at one end only — the controller end.

RS-485 is a multi-drop bus. The correct topology is a single trunk cable with short stubs to each sensor, terminated with 120 Ω at the two electrical ends of the bus. The most common installation mistake is to wire each sensor as a long radial branch from the controller, creating reflections and intermittent CRC failures that only show up at certain baud rates or temperatures.

In practice, in an orchard installation where sensors are co-located with drip emitters along a row:

• Run one trunk pair down the row.
• T off into each sensor with a stub no longer than about 30 cm.
• Place a 120 Ω terminating resistor across A and B at the controller end (built into the v4 carrier board, switchable).
• Place a second 120 Ω across A and B at the last sensor of the bus. If the bus is short (under about 30 m) and noise is not observed, you can often omit the far-end terminator.

Cable choice matters. Use a twisted pair, ideally with an overall foil shield, characteristic impedance around 120 Ω. CAT5e UTP is acceptable for runs under about 50 m; for longer runs or noisier electrical environments, use proper RS-485 cable such as Belden 3105A or its inexpensive Chinese equivalents.

The protocol on top of RS-485 is Modbus RTU. Default baud rate across the sensor families above is one of 4800 or 9600. ZTS and SN-3000 typically ship at 4800; JXCT and Renke typically ship at 9600. Both are slow enough that even noisy cable runs rarely cause framing errors.

Every sensor on the bus must have a unique slave address. Sensors ship with a factory default of 0x01. If you have more than one sensor on a bus you must change the address of each one with a per-sensor write before the bus comes up — most vendors include a small Windows utility for this, but the address change is also a Modbus write to a known holding register, so it is scriptable.

Reads use Modbus function code 0x03 (Read Holding Registers). The register map varies between families and is the part of the integration that takes the most time. The Sankhya Intelligence sensor library at /sensors documents register maps for 21 verified sensor variants across the major families.

A typical 7-in-1 sensor (EC, pH, moisture, temperature, N, P, K) returns 7 consecutive 16-bit registers starting at 0x0000. Moisture is typically scaled ×10 (so a raw value of 278 = 27.8 %), EC in µS/cm direct, pH ×10 (a raw value of 62 = 6.2). Temperature is signed, ×10, in °C. Always read the vendor manual before trusting these.

The Sankhya Intelligence v4 carrier board powers the sensor bus from a 12V rail switched by a TPS1H100B integrated high-side load switch. The switch is controlled by an ESP32-S3 GPIO and is energised only during the sensor read window — typically about 5 seconds per hourly cycle. This achieves three things: it cuts average current draw by roughly two orders of magnitude versus continuous power, it allows a hard power-cycle of a misbehaving sensor without intervention, and it isolates the sensor bus from the controller during deep sleep.

The high-side switch was a deliberate revision from earlier prototypes that used a discrete N-channel MOSFET as a low-side switch. The low-side topology has a subtle problem: the sensor GND floats up off true ground when the switch is open, which on some sensor families causes leakage current paths through the RS-485 transceiver. The integrated high-side switch eliminates this.

For more on the power architecture and the v3-to-v4 revision history, see ESP32-S3 solar sensor node design.

The minimal sequence on the ESP32-S3 carrier board to read a single sensor at slave address 0x01, baud 9600, looks like the following. The example assumes the standard 7-register read for an EC/pH/temp/moisture/NPK sensor.

// Power on the sensor bus via the high-side load switch
digitalWrite(PIN_SENSOR_EN, HIGH);
delay(2000);  // allow sensor to boot

// Modbus request: addr=0x01, fc=0x03, start=0x0000, count=0x0007
uint8_t req[] = { 0x01, 0x03, 0x00, 0x00, 0x00, 0x07, 0x04, 0x08 };
// last two bytes are CRC-16/Modbus (little-endian)

// Drive RS-485 transceiver into TX mode
digitalWrite(PIN_RS485_DE, HIGH);
Serial1.write(req, sizeof(req));
Serial1.flush();
digitalWrite(PIN_RS485_DE, LOW);  // back to RX

// Read 19 bytes back: 1 addr + 1 fc + 1 bytecount + 14 data + 2 CRC
uint8_t resp[19];
size_t got = Serial1.readBytes(resp, sizeof(resp));

// Power off the bus until next cycle
digitalWrite(PIN_SENSOR_EN, LOW);

// Decode (big-endian 16-bit per register, scale per vendor)
uint16_t moisture_raw = (resp[3] << 8) | resp[4];   // ×10, % VWC
uint16_t temp_raw     = (resp[5] << 8) | resp[6];   // ×10, °C (signed)
uint16_t ec_raw       = (resp[7] << 8) | resp[8];   // µS/cm
uint16_t ph_raw       = (resp[9] << 8) | resp[10];  // ×10, pH units

The library we ship in production wraps this with CRC checking, retry logic, and a per-sensor calibration offset, but the above is the irreducible minimum.

EC interference with moisture and pH. Above about 1.8 to 2.0 mS/cm, the moisture and pH readings on most low-cost capacitive in-soil sensors start to diverge from reality. This is a fundamental sensor limitation, not a bus problem. Flag readings taken during high-EC fertigation events and exclude them from any longitudinal analytical layer.

Sensor boot time. Most sensors need 1.5 to 2 seconds after power-on before they will respond on the bus. Hitting them too early returns silence and looks like a wiring fault. The high-side switch in the v4 design pays for itself partly by making this boot delay explicit and reliable.

Address conflicts. Every sensor ships at address 0x01. Add a second sensor to the bus without re-addressing it and both will reply at the same time, corrupting the response. Always re-address each sensor before adding it to a multi-drop bus.

Bus-power versus sensor-power. Some installers run 12V down the trunk along with the differential pair. This works for short runs but causes voltage drop on long runs — at 80 mA per sensor and a 0.5 mm² conductor, you lose about 1V per 30 m. For long rows, supply 12V locally at each sensor cluster from a small DC-DC and only run RS-485 + GND on the trunk.

Termination over-eagerness. Putting a 120 Ω terminator at every sensor (instead of only at the two electrical ends) loads the bus down so heavily that some transceivers cannot drive it. Symptoms: works at 4800 baud, fails at 9600.

If you are designing your own sensor node, the companion pages below cover the rest of the system: the carrier board's power and MCU choices, the JLCPCB ordering process, and how the sensor data is converted into irrigation decisions once it lands on the server.

For the full compatibility matrix across all 21 verified RS-485 Modbus sensors, see /sensors. For the production Gerbers and BOM of the v4 carrier board, see /open-hardware or the GitHub mirror at github.com/shsa1984/sankhya-node-hardware.