去年冬天在做一个土壤墒情站的数据接入，现场有十几支土壤三参数传感器要挂在一根三芯电缆上，供电靠一块 12 V 蓄电池，采集器要连续工作一个生长季。选来选去还是绕回了 SDI-12——这个 1988 年定稿、至今仍在 1200 波特上跑的总线。它慢得让人心急，却在低功耗、长线缆、多节点这三件事上做到了几乎没有替代品。

真正动手之后才发现，SDI-12 的难点不在命令集（命令加起来不到十条），而在**毫秒级的时序纪律**和**一个容易写错的 CRC**。这篇文章把这条链路从头拆一遍：电气层、帧格式、时序账本、CRC 校验、可运行的 Python 实现，以及我实际踩到的三个坑。

---

## 一、物理层：三根线，一套反过来的逻辑

SDI-12 只用三根线：

| 线 | 作用 | 说明 |
|---|---|---|
| +12 V | 传感器供电 | 通常 9.6–16 V，总线同时给所有节点供电 |
| GND | 地 | 既是电源回路，也是数据信号的参考地 |
| Data | 双向数据 | 单线半双工，空闲时为 marking 态 |

数据线是**准双向**的：主机和传感器分时驱动，谁不发就放手。所以它必须靠上拉电阻维持空闲电平，任何一方强行驱动都会造成总线争用（bus contention）——规范里把 bus contention 明确列为需要重试的异常之一。

最反直觉的是电平定义。SDI-12 的逻辑是**反的**：

| 逻辑值 | 状态名 | 电压范围 |
|---|---|---|
| 1 | marking | −0.5 V ~ 1.0 V（低） |
| 0 | spacing | 3.5 V ~ 5.5 V（高） |

也就是说，空闲时数据线停在低电平，起始位是一个**上升**沿。这和标准 UART 的"空闲高、起始位下降沿"完全相反。

记住这一点，后面所有的坑都能解释。

---

## 二、为什么不能直接把传感器插到 USB-TTL 上

这是新手最容易栽的第一个坑。手上有个 CH340 或 CP2102 的 USB 转串口模块，看着传感器三根线，很自然就想接上去。接上去之后收到的是乱码或者什么都没有。

原因有三层，缺一不可：

1. **逻辑反相**：TTL 串口空闲为高，SDI-12 空闲为低。直连等于把整帧数据反相，接收端永远解析不出起始位。需要一级反相（74HC14 之类的施密特反相器最常用）。
2. **供电**：传感器不靠数据线取电，它需要独立的 9.6–16 V。USB-TTL 只给 5 V，传感器根本不会醒。
3. **break 信号**：这是最硬的一条。SDI-12 靠一段**至少 12 ms 的连续 spacing**唤醒传感器。普通 USB 转串口芯片在 1200 波特下，一个字符 8.33 ms，很难精确地拉出一段 12 ms 的低电平——多数芯片的 break 实现是"发一个全 0 字符"，宽度只有 1 个字符时间，达不到 12 ms。

所以工程上有两条现实路径：

- **路径 A：用专门的 SDI-12 转 USB 适配器**。适配器内部已经处理了电平反相、12 V 供电和 break 时序，PC 侧看到的是一串 ASCII 命令。这条路对软件最友好，我后面给的 Python 代码就是按这个假设写的。
- **路径 B：自己用 MCU 做主站**。GPIO 控制 break 宽度，硬件做反相，固件里管理 15 ms / 87 ms 这些窗口。灵活但工作量大。

如果只是想拿数据，别自己造轮子，路径 A 够用。

---

## 三、帧格式：那个 8.33 ms 是怎么来的

SDI-12 的字符帧是 **1 起始位 + 7 数据位 + 偶校验 + 1 停止位**，也就是常说的 **7E1**，共 10 个 bit。

波特率 1200，所以：

```
单字符时间 = 10 bit / 1200 bps = 8.3333 ms
```

这个 8.333 ms 在规范里反复出现，几乎所有时序参数都是它的整数倍或分数：

- 字符之间允许的 marking 间隔上限：**1.66 ms**（约 1/5 字符）
- 收到 break 后必须先检测到 **8.33 ms** 的 marking 才去找地址（正好 1 个字符时间）
- 传感器发响应前先拉 **8.33 ms** 的 marking

顺便算一下：break 最短 12 ms，在 1200 波特下只有 **1.44 个字符时间**——而规范同时规定"连续 spacing 小于 6.5 ms 时传感器不认为这是 break"。也就是说 break 的有效判定窗口只有 6.5 ms 到 12 ms 之间，约 0.78 到 1.44 个字符宽度。

这个窗口窄得有点离谱，这正是 USB-TTL 玩不转的根本原因：软件层面的 `sleep(12)` 受调度抖动影响，很容易超出容差（规范给的容差是 ±0.40 ms）。

---

## 四、一次完整的对话

SDI-12 的命令集非常小。所有命令以地址字符开头，以 `!` 结尾；所有响应以地址开头，以 `<CR><LF>` 结尾。

| 命令 | 响应 | 含义 |
|---|---|---|
| `?!` | `a<CR><LF>` | 查询地址（总线上只能挂一支时可用） |
| `a!` | `a<CR><LF>` | 确认在线 |
| `aI!` | `allccccccccmmmmmmvvvxxx` | 读标识（ll=协议版本，如 13 表示 v1.3） |
| `aM!` | `atttn<CR><LF>` | 启动测量 |
| `aMC!` | `atttn<CR><LF>` | 启动测量并要求 CRC |
| `aC!` | `atttnn<CR><LF>` | 并发测量（两位数据个数） |
| `aCC!` | `atttnn<CR><LF>` | 并发测量 + CRC |
| `aD0!` | `a<值1><值2>...<CRC?><CR><LF>` | 取数据 |
| `aAb!` | `a<CR><LF>` | 把地址 a 改为 b |

几个必须注意的细节：

**1. `atttn` 里每一段都有含义。** `a` 是地址，`ttt` 是三位十进制秒数（测量就绪还需多少秒），`n` 是一位数据个数。比如 `00013` 表示：地址 0、还需 001 秒、会返回 3 个值。注意 `n` 是一位数，所以 `aM!` 最多回 9 个值；要更多值必须用 `aC!`（两位，`nn`）。

**2. `aM!` 和 `aC!` 的差别不只是数据个数。** `aM!` 测完后传感器会发 service request 主动通知；`aC!` 不发，主机必须老老实实等满 `ttt` 秒。多节点场景下用 `aC!` 才能让多支传感器同时测量，否则总时间是线性叠加的。

**3. 数值一定带符号。** 响应里的每个值都以 `+` 或 `-` 开头，这个符号同时充当分隔符。所以解析不能简单按 `+` 切——负数开头也是 `-`。这是我最开始写解析器时踩的坑，`0-0.512+12.3+5.02` 用 `split('+')` 会切出一堆垃圾。

**4. 地址范围是 62 个。** `0-9`、`A-Z`、`a-z`，大小写敏感。出厂默认一般是 `0`。多节点部署前必须先逐个改地址——WET150 这类传感器出厂都是地址 0，十支挂上去会一起应答，总线直接撞死。

---

## 五、时序账本

把规范里的毫秒数整理成一张表，调试时对着看会省很多时间：

| 参数 | 数值 | 说明 |
|---|---|---|
| break 宽度 | ≥ 12 ms | 连续 spacing；< 6.5 ms 不识别 |
| break 后 marking | ≥ 8.33 ms | 传感器检测满这么久才找地址 |
| 唤醒时间 | ≤ 100 ms | 传感器从 standby 醒来并能识别起始位 |
| 响应起始窗口 | ≤ 15 ms | 命令最后一个停止位之后，响应起始位必须在此之内开始 |
| 字符间 marking | ≤ 1.66 ms | 无容差，超了就按重试处理 |
| 释放总线 | ≤ 7.5 ms | 双方发完最后一字符后必须放手 |
| 睡眠阈值 | 100 ms | 总线 marking 持续这么久，传感器回 standby |
| 重试等待 | 16.67 ~ 87 ms | 无响应后在此区间内重发（不带 break） |

![SDI-12 一次完整通信的时序](https://developer.qcloudimg.com/http-save/yehe-1418908/4d4de7745a8e43bb981f472c754bee88.png)

有两条容易忽略但会致命的规则：

**规则一：换地址或者总线空闲超过 87 ms，下一条命令前必须补一个 break。** 因为传感器已经睡了。很多人写轮询程序时会"复用"上一次的唤醒状态，间隔一长就收不到数据，原因就在这里。

**规则二：至少有一次重试要发生在 break 下降沿之后 100 ms 以外。** 因为传感器最多需要 100 ms 才能完全醒过来。重试太快等于对着一个还没醒的设备喊话。

规范要求单条命令至少重发两次（也就是连发三次仍未成功），之后整套序列——包括最前面的 break——还要再重复至少两轮，才允许报错。

---

## 六、CRC-16：算法不难，覆盖范围才是坑

v1.3 之后的传感器必须支持 CRC。命令是在测量命令后面加一个 `C`：`aM!` → `aMC!`，`aC!` → `aCC!`。

CRC 参数：**多项式 0xA001（0x8005 的反射形式），初值 0x0000，不取反，不异或输出**。逐字节异或后右移 8 次。

关键在覆盖范围。规范的原话是：

> for each character beginning with the address, up to but not including, the carriage return

也就是 **从地址字符开始，到 CR 之前为止**——不含 CR，也不含 LF。这一点和很多 Modbus 实现的习惯不同（Modbus RTU 的 CRC 是整个帧），照搬会全校验失败。

算出来的 16 位值要编码成 3 个可打印字符，每 6 位加 `0x40`：

```
第1字符 = 0x40 | (crc >> 12)
第2字符 = 0x40 | ((crc >> 6) & 0x3F)
第3字符 = 0x40 | (crc & 0x3F)
```

编码出来的字符会落在 `@` 到 `_` 以及部分可打印符号上，看起来像乱码，但都是合法 ASCII——这也解释了为什么 CRC 帧里会出现 `qZ`、`Ipz` 这种尾巴。

### 用规范样例对拍

写完实现别急着上现场，先拿规范里的样例对拍。这一步能省掉几天排查：

![CRC 与规范样例对拍](https://developer.qcloudimg.com/http-save/yehe-1418908/d3ecf6ffbbfe7dcaf60781e987e7a3e1.png)

```
payload='0+3.14'                期望='OqZ' 计算='OqZ' crc=0xFC5A PASS
payload='0+3.14+2.718+1.414'    期望='Ipz' 计算='Ipz' crc=0x9C3A PASS
```

两个样例都过，基本可以确认算法无误。再补一个篡改测试（把 `2.718` 改成 `2.719`，模拟单字符误码）：

```
原始: 0+3.14+2.718+1.414  CRC=Ipz
篡改: 0+3.14+2.719+1.414  CRC=Epj  -> 收到 Ipz ≠ 计算 Epj，检出
```

单个数字位翻转能稳定检出，说明校验链路是通的。

---

## 七、Python 实现

下面是可以直接跑的版本。为了只讲协议本身，串口部分抽象成"发一行命令、收一行响应"，底层接 SDI-12 适配器还是自建 MCU 主站都不影响逻辑。

### 7.1 CRC 与编码

```python
def sdi12_crc16(payload: str) -> int:
    """对 '地址..最后一个数据字符'（不含 CR/LF）计算 CRC-16/ARC。"""
    crc = 0
    for ch in payload:
        crc ^= ord(ch)
        for _ in range(8):
            if crc & 1:
                crc = (crc >> 1) ^ 0xA001
            else:
                crc >>= 1
    return crc & 0xFFFF


def sdi12_crc_encode(crc: int) -> str:
    """16 位 CRC -> 3 个可打印 ASCII 字符（每 6 位 + 0x40）。"""
    return "".join(chr(0x40 | ((crc >> s) & 0x3F)) for s in (12, 6, 0))
```

### 7.2 响应解析

```python
class CRCError(ValueError):
    pass


def parse_response(line: str, with_crc: bool = False):
    """解析 aD0! 响应，例如 '0+3.14+2.718+1.414Ipz'。"""
    line = line.strip("\r\n")
    addr, body = line[0], line[1:]

    if with_crc:
        if len(body) < 3:
            raise ValueError(f"帧过短: {line!r}")
        data, given = body[:-3], body[-3:]
        calc = sdi12_crc_encode(sdi12_crc16(addr + data))
        if calc != given:
            raise CRCError(f"CRC 不匹配: 收到 {given!r}, 计算 {calc!r}")
        body = data

    # 数值以 +/- 开头，符号本身就是分隔符，不能用 split('+')
    values, buf = [], ""
    for ch in body:
        if ch in "+-":
            if buf:
                values.append(float(buf))
            buf = ch
        else:
            buf += ch
    if buf:
        values.append(float(buf))
    return addr, values
```

注意 `body[:-3]` 这里：CRC 是对"地址 + 数据"算的，所以校验时要把地址拼回去（`addr + data`），不能只对 data 算。

### 7.3 采集流程

![SDI-12 采集状态机](https://developer.qcloudimg.com/http-save/yehe-1418908/065125c0f3fc51b0156bad5fd2c9beeb.png)

```python
import time


def read_sensor(link, addr="0", retries=3):
    """一次完整读取：唤醒 -> 启动测量 -> 等就绪 -> 取数 -> 校验。"""
    for attempt in range(retries):
        # 1) break 唤醒（由适配器或 MCU 层完成），然后发带 CRC 的测量命令
        reply = link.command(f"{addr}MC!", expect_prefix=addr)

        # 2) 解析 atttn：ttt=秒, n=个数
        if len(reply) < 5 or not reply[1:4].isdigit():
            continue
        wait_s = int(reply[1:4])
        n_vals = int(reply[4])

        # 3) 等测量就绪。等多久由传感器自己报，不要写死
        time.sleep(wait_s)

        # 4) 取数据。可能分多帧（aD0!, aD1! ...）
        got = []
        idx = 0
        while len(got) < n_vals:
            line = link.command(f"{addr}D{idx}!", expect_prefix=addr)
            try:
                _, vals = parse_response(line, with_crc=True)
            except CRCError:
                break            # 交给外层重试
            got.extend(vals)
            idx += 1
            if idx > 9:
                break

        if len(got) >= n_vals:
            return got
        time.sleep(0.02)          # 落在规范要求的 16.67~87 ms 重试窗口内
    raise TimeoutError(f"地址 {addr} 连续 {retries} 次未取到有效数据")
```

两个细节值得单独说：

- `time.sleep(wait_s)` 里的秒数来自**传感器自己报的** `ttt`，不要写死。不同测量集、不同传感器的 `ttt` 不一样，WET150 的默认测量是 1 秒，测别的参数集可能要几秒。
- 重试间隔控制在 16.67–87 ms。这个区间是规范给的，太短会在传感器还没发完响应时就插话，太长会超过 87 ms 需要重新补 break。

### 7.4 如果是原生串口直连

用自己搭的 MCU 主站或者支持 break 的串口卡时，串口参数必须设成 7E1：

```python
import serial

ser = serial.Serial(
    port="COM3",
    baudrate=1200,
    bytesize=serial.SEVENBITS,      # 7 数据位，不是 8
    parity=serial.PARITY_EVEN,      # 偶校验
    stopbits=serial.STOPBITS_ONE,
    timeout=0.1,
)
```

默认的 `8N1` 是收不到东西的。这是第二个高频坑——因为绝大多数串口设备都是 8N1，很少有人会想到去改数据位宽度。

---

## 八、实测：一条响应里的三个物理量

拿一支符合 SDI-12 v1.3 的土壤三参数传感器（这台是 WET150）做实际验证。它的默认测量返回 3 个值：

```
主机: 0M!
响应: 00013            <- 地址 0，1 秒后就绪，3 个值

主机: 0D0!
响应: 0+36.54+284.5+18.66
```

三个值依次是：**相对介电常数 ε′、体积电导率 ECb（mS/m）、温度（°C）**。

`0+36.54+284.5+18.66` 解析出来是 `[36.54, 284.5, 18.66]`。这里有个容易被忽略的事实：**传感器直接给出的不是体积含水率**，而是介电常数。含水率要靠介电常数转出来，而且转换依赖介质类型（矿质土、有机土、椰糠、岩棉的标定参数完全不同）。用通用经验式粗算：

```
θ = -0.053 + 0.0292ε - 0.00055ε² + 4.3e-6ε³     (Topp, 1980)
```

代入几个典型值做个合理性检查：

![介电常数与体积含水率的对应关系](https://developer.qcloudimg.com/http-save/yehe-1418908/0c6953cd0ed95d23734e178425187ef3.png)

| ε′ | θ（m³/m³） | 对应场景 |
|---|---|---|
| 3.20 | 3.49% | 风干土 |
| 12.00 | 22.56% | 偏干 |
| 20.50 | 35.15% | 田间持水量附近 |
| 36.54 | 48.94% | 接近饱和 |
| 55.00 | 60.47% | 饱和 / 有机质高的介质 |

实测那条 `36.54` 对应约 49% 体积含水率——对于一次灌溉后的表层土，这个数在物理上说得通。**这条检查很重要**：如果算出来 120%，说明标定参数选错了介质，或者把 ECb 当成含水率读进去了。

ECb 那个 284.5 mS/m 折合 2.845 mS/cm，属于偏盐渍的水平，和含水率高的样本吻合（盐分随水走）。温度 18.66 °C 也在合理区间。

三个值互相印证，才能确认整条链路（时序、CRC、解析、量纲）都是对的。

---

## 九、三个必踩的坑，总结一下

**坑一：串口参数用成 8N1。** SDI-12 是 7E1。现象是"能收到字节但全是乱码"，或者干脆收不到。改 `bytesize=SEVENBITS` + `parity=PARITY_EVEN`。

**坑二：以为能直接接 USB-TTL。** 三层原因——逻辑反相、需要 12 V 独立供电、break 宽度做不到 12 ms。要么用现成适配器，要么自己做反相 + MCU 主站。

**坑三：CRC 覆盖范围算错。** 从地址字符开始，到 CR 之前结束，不含 CR/LF，校验时要把地址拼回去。照搬 Modbus 的"整帧 CRC"习惯必然全错。

再补一条隐性坑：**多节点不改地址**。所有传感器出厂都是地址 0，挂两根以上就会同时应答，总线上出现两个响应的字符交错，CRC 必错，现象看起来很像是"线太长信号不好"。先把地址改完再上线。

---

## 十、小结

SDI-12 值得写这么长，是因为它把复杂度全压在了时序上。命令集十分钟能背完，但 break 的 12 ms、响应的 15 ms、重试的 87 ms、睡眠的 100 ms 这几个数字，构成了一个几乎不允许软件抖动的时间窗。理解了这套账本，剩下的就是老老实实按规范来：

- 电气层：反相逻辑 + 12 V 供电 + 真正的 break，别偷懒
- 帧层：7E1，单字符 8.33 ms，字符间隔不超过 1.66 ms
- 校验层：CRC-16/ARC，覆盖"地址到 CR 前"，先拿规范样例对拍
- 应用层：等传感器自己报的 `ttt`，重试落在 16.67–87 ms，换地址或空闲超 87 ms 必须补 break

这套东西跑通之后，一条 200 m 的电缆挂十支传感器、靠一块 12 V 电池撑一个生长季，是完全做得到的。慢，但可靠——对野外设备来说，可靠比快重要得多。

---

**参考资料**

1. SDI-12 Support Group, *SDI-12 A Serial-Digital Interface Standard for Microprocessor-Based Sensors*, Version 1.4（2023-02-20）
2. SDI-12 Support Group, *SDI-12 Specification Version 1.3*（2016-01-28）
3. Topp, G. C., Davis, J. L., Annan, A. P. (1980). *Electromagnetic determination of soil water content: Measurements in coaxial transmission lines.* Water Resources Research, 16(3), 574–582.
4. Delta-T Devices, *WET150 Sensor SDI-12 Programmer's Guide*


去年冬天在做一个土壤墒情站的数据接入，现场有十几支土壤三参数传感器要挂在一根三芯电缆上，供电靠一块 12 V 蓄电池，采集器要连续工作一个生长季。选来选去还是绕回了 SDI-12——这个 1988 年定稿、至今仍在 1200 波特上跑的总线。它慢得让人心急，却在低功耗、长线缆、多节点这三件事上做到了几乎没有替代品。

SDI-12 协议实战：1200 波特上的时序、CRC-16 与一次完整的数据采集实现

SDI-12 是 1988 年定稿的环境监测单线总线，至今仍在 1200 波特上运行。本文从电气层讲起——反相逻辑、12 V 独立供电、12 ms break 为什么不能直接用 USB-TTL 造出来，再拆帧格式与毫秒级时序账本，给出 CRC-16 的完整实现与规范样例对拍，最后用一支土壤三参数传感器的实测响应把整条链路串起来：时序、校验、解析、量纲。

人工智能

**SDI-12协议实战：1200波特时序、CRC-16校验与完整Python采集实现**  
深入解析SDI-12总线物理层反相逻辑、7E1帧格式、break唤醒时序及CRC-16覆盖范围，提供可运行代码与WET150实测数据。避开8N1误配、USB-TTL直连、CRC计算等高频陷阱，实现低功耗多节点土壤传感器稳定采集。

代码解释

Python

2026上云采购 | AI焕新·智启新局

iot-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

**SDI-12协议实战：1200波特时序、CRC-16校验与完整Python采集实现**  
深入解析SDI-12总线物理层反相逻辑、7E1帧格式、break唤醒时序及CRC-16覆盖范围，提供可运行代码与WET150实测数据。避开8N1误配、USB-TTL直连、CRC计算等高频陷阱，实现低功耗多节点土壤传感器稳定采...

SDI-12 协议实战：1200 波特上的时序、CRC-16 与一次完整的数据采集实现-腾讯云开发者社区-腾讯云

SDI-12 协议实战：1200 波特上的时序、CRC-16 与一次完整的数据采集实现

SDI-12 协议实战：1200 波特上的时序、CRC-16 与一次完整的数据采集实现

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐