4. 通信链路可靠性测试：LoRa/4G/5G通信压力测试、数据丢包率测试、通信延迟测试

通信链路，说白了就是农业洪水预警系统的「神经」。传感器采集的数据再准，传不回来也是白搭。我在好几个项目中都吃过通信的亏——明明现场数据都对了，结果因为链路不稳定，预警愣是没发出去。嗯，今天咱们就专门聊聊这块怎么测。

4.1 为什么通信链路测试这么重要？

农业洪水预警的场景很特殊。你想想看，传感器分布在田间地头、河道堤坝，有的地方连手机信号都弱。而且洪水一来，环境极其恶劣——暴雨、大风、甚至雷电。这时候通信链路要是断了，后果很严重。

我个人习惯把通信链路测试分成三个维度：

• 压力测试：看看系统在极限负载下会不会崩
• 丢包率测试：数据到底能传回来多少
• 延迟测试：从采集到接收，到底慢不慢

这三个维度缺一不可。我曾经在一个项目中只测了丢包率，没测延迟，结果上线后发现数据虽然都到了，但延迟了十几分钟——预警早就过了时效。

4.2 LoRa通信压力测试

LoRa的特点是低功耗、远距离，但带宽极低。很多新手以为LoRa随便用，其实它的信道容量非常有限。

4.2.1 压力测试方法

我建议这样测：

1. 单节点压力：让一个LoRa节点以最快速率发包，持续30分钟。看它会不会掉线或重启。
2. 多节点并发：同时启动10个、20个、50个节点，模拟真实场景下的多传感器同时上报。
3. 网关负载：观察LoRa网关的CPU占用率和内存使用情况。

4.2.2 我踩过的坑

我曾经在一个项目中，把50个LoRa节点放在同一个信道里。结果呢？网关直接「罢工」了，丢包率高达40%。后来我才意识到，LoRa的扩频因子和信道规划必须提前做好。说白了，你不能让所有节点都在同一个频率上「吵架」。

4.3 4G/5G通信压力测试

4G和5G带宽大，但问题在于基站覆盖和信号稳定性。尤其是在农村和野外，4G信号时好时坏是常态。

4.3.1 压力测试方法

测试项	方法	通过标准
上行压力	连续发送1MB数据包，持续10分钟	不掉线，速率不低于标称值的80%
下行压力	同时接收10个终端的指令	响应时间不超过3秒
信号切换	在弱信号区和强信号区来回移动	切换时间不超过5秒

我个人习惯用iperf3工具来做4G/5G的压力测试。命令很简单：

# 服务端（放在云端服务器）
iperf3 -s -p 5201

# 客户端（放在4G/5G终端上）
iperf3 -c 192.168.1.100 -p 5201 -t 600 -i 10

这个命令会持续发10分钟的数据包，每10秒输出一次结果。你想想看，如果中间出现断流或者速率骤降，那基本就能定位问题了。

4.4 数据丢包率测试

丢包率是通信链路最直接的「健康指标」。对于洪水预警系统，丢包率超过1%就已经很危险了。

4.4.1 测试方法

我常用的方法是「回环测试」：

1. 发送端给每个数据包打上唯一序号（比如从1到10000）
2. 接收端收到后，检查序号是否连续
3. 丢包率 = (丢失包数 / 总发送包数) × 100%

代码实现也很简单：

# 发送端伪代码
for i in range(1, 10001):
    packet = create_packet(seq_num=i, data=sensor_data)
    send(packet)
    time.sleep(0.1)  # 每100ms发一个

# 接收端伪代码
received_seqs = []
while True:
    packet = receive()
    if packet:
        received_seqs.append(packet.seq_num)

# 计算丢包率
lost = set(range(1, 10001)) - set(received_seqs)
loss_rate = len(lost) / 10000 * 100
print(f"丢包率: {loss_rate}%")

4.4.2 不同通信方式的丢包率参考

通信方式	理想丢包率	可接受丢包率	不可接受
LoRa	< 0.5%	< 2%	> 5%
4G	< 0.1%	< 0.5%	> 1%
5G	< 0.01%	< 0.1%	> 0.5%

你看这个表，LoRa的丢包率天生就比4G/5G高。这不是设备问题，是技术特性决定的。所以我在做LoRa方案时，一定会加数据重传机制。

4.5 通信延迟测试

延迟，就是数据从传感器到云端的时间。对于洪水预警，延迟超过30秒基本就失去意义了。

4.5.1 测试方法

我习惯用「时间戳法」：

1. 发送端在数据包里写入当前时间戳（精确到毫秒）
2. 接收端收到后，立即记录当前时间戳
3. 延迟 = 接收时间 - 发送时间

这里有个坑——发送端和接收端的时间必须同步。我一般会用NTP服务器统一对时，误差控制在1毫秒以内。

4.5.2 延迟测试的代码示例

# 发送端
import time
import struct

def send_packet_with_timestamp():
    timestamp = int(time.time() * 1000)  # 毫秒级时间戳
    packet = struct.pack('!Q', timestamp) + sensor_data
    send(packet)

# 接收端
def receive_and_calc_delay():
    packet = receive()
    recv_time = int(time.time() * 1000)
    send_time = struct.unpack('!Q', packet[:8])[0]
    delay = recv_time - send_time
    print(f"通信延迟: {delay}ms")

4.5.3 不同场景下的延迟要求

场景	最大允许延迟	推荐通信方式
水位实时监测	10秒	4G/5G
雨量数据上报	30秒	LoRa/4G
预警指令下发	5秒	5G（必须）
历史数据回传	5分钟	LoRa即可

你看，不同场景对延迟的要求差别很大。我见过有人用LoRa做预警指令下发，结果延迟了1分钟——这显然不合适。说白了，选通信方式得看场景，不能一刀切。

4.6 综合测试方案建议

我个人习惯把这三项测试放在一起做，因为它们是相互影响的。比如压力大了，丢包率和延迟都会上升。

一个完整的测试流程应该是：

1. 基准测试：在理想环境下测出丢包率和延迟的基线值
2. 压力测试：逐步增加负载，观察丢包率和延迟的变化曲线
3. 极限测试：找到系统的「崩溃点」——比如丢包率超过10%时的并发数
4. 回归测试：优化后重新测，确保问题已解决

好了，通信链路可靠性测试就讲到这里。下一章咱们聊聊传感器本身的可靠性测试——那又是另一番天地了。