前两年接手一个水库大坝安全监测项目，渗压计要布在坝肩两侧的山坡和河谷里的测压管中，一共24支。开工前我信心满满，觉得现在4G覆盖这么好，数据回传根本不是事。等实地踏勘才发现，河谷两岸有好几个点位一格信号都没有，手机彻底失联。这个场景在行业内太常见了：渗压计这类设备偏偏要布在最偏远的地方，测的是坝体浸润线、边坡孔隙水压力这些直接关系到安全的指标，你却连不上它。后来我们上了北斗短报文加4G双模通信方案，才算是把这条数据链路真正打通。这篇文章就把这个方案从选型、设计、实施到排障整个过程完整讲一遍，给同样在搞大坝、边坡、尾矿库监测的同行一个参考。
1. 渗压计的监测需求与“无信号”场景的真实面貌
1.1 渗压计测的是什么，数据为什么不能断
渗压计，也叫孔隙水压力计，是岩土工程安全监测里最常用的传感器之一。它埋在坝体、坝基、边坡土体或者挡土墙后面，测量的是土体孔隙里的水压力。这个数值换算成水位以后，就是设计单位最关心的浸润线高程和渗透压力水头。大坝管涌、滑坡失稳、基坑突涌这些事故，都有一个共同的前兆——孔隙水压力出现异常变化。所以渗压计不是测着玩的，它是安全预警最底层的数据来源。
工程里最常见的是振弦式渗压计。它的核心是一根张紧的钢弦，水压力变化让弦的张力变化，弦的自振频率跟着变。用线圈激励弦，再拾取频率信号，就能反算出压力值。振弦式的优势是长期稳定性好、零点漂移小，特别适合大坝这种动辄监测几十年的场景，不像一些压阻式传感器用两三年就容易出现温漂。数据那边，一支振弦式渗压计一次读数需要采集压力、温度、电池电压这几个参数，满打满算几十个字节，数据量并不大。
但它的连续性要求极高。大坝安全监测对浸润线观测有明确的频次要求，汛期要加密到一天几次，边坡和尾矿库的预警更看重趋势变化。如果数据断了一个星期，等到发现异常再去补测，早过了预警窗口期。说白了，渗压计的数据是典型的“量小但不能断”，这对通信链路的要求其实非常苛刻。
1.2 为什么偏偏这些地方没信号
先说一个很多不搞监测的人不知道的事：4G覆盖率是个宏观统计数字，到了山区，实际覆盖远没有看上去那么乐观。渗压计的布设位置有它自己的工程逻辑——最深的山谷、最陡的边坡、最偏的坝肩，这些地方要么是运营商基站覆盖的死角，要么信号被山体遮挡，RSRP值极低。我实测过不少点位，手机显示有几格信号，但到了数据面就是拉不起来，时通时断，丢包率感人。这些都是我们nlp的“伪覆盖”区域。
拉有线也不现实。一个项目动辄十几二十个监测点，分散在几条山谷里，敷设光缆或电缆的成本、施工难度都极高，而且架空和直埋线路在雷雨多的山区风险很大，雷击打坏采集设备是常有的事。所以行业主流做法是用DTU走运营商网络，但必须承认它存在覆盖盲区。这个矛盾，就是北斗短报文加4G双模方案要解决的核心问题——主用4G，尽量便宜；4G不可用的时候，北斗短报文顶上，保证数据链不断。
2. 北斗短报文与4G双模方案的设计思路
2.1 北斗短报文到底是个什么机制
北斗短报文是北斗卫星导航系统区别于GPS、GLONASS的一项特色功能，正式名称叫 RDSS，无线电测定业务。GPS那种系统是单向的，只广播定位信号，用户收得到星，但卫星不知道你的存在。北斗不一样，它是双向的：用户终端可以把一段短报文发到卫星，卫星转发给地面运控中心，再由地面链路送到接收方手里。这个过程完全不依赖地面的通信基站，只要终端能看见头顶的北斗卫星，哪怕在深山老林、荒漠无人区也能把数据送出来。
代价也很明显。民用短报文单条长度有限，常规终端一条报文通常只有几十字节，具体长度跟用户卡等级和系统状态有关；发送速率也有限制，不适合做高频次、大流量传输；最关键的是它按条计费，用得越多越花钱。这些限制决定了北斗短报文只能当“兜底通道”，不能当主用通道。
2.2 4G承当主通道，北斗用于兜底
双模的逻辑其实不复杂：正常情况下，4G能连则连，因为4G带宽大、套餐便宜，平台随时可以拉流，远程调试、数据补传都很方便；一旦终端判断4G不可用，或信号强度低于设定阈值，自动切换成北斗短报文通道，把关键监测数据压缩成一条短报文发出去。等4G恢复，再自动切回4G，同时把北斗通道期间缓存在本地的数据用4G补传上去。
这套设计解决了两个问题：一是不依赖单一运营商网络的覆盖，毕竟有的河谷里联通没信号但移动有，有的正好反过来；二是把北斗的报文费用压到最低，只有4G真正断了才花钱走卫星。实际运行中，有些点位一年也就用几次北斗通道，但就是这几次，保住了汛期最关键的数据。
2.3 为什么不用卫星电话、LoRa或者自建专网
做方案时，我们认真比过其他几条路。卫星电话成本高，一次通话几十块，且无法自动上报，总不能每天派人在坝上拿着卫星电话念数据给平台听。高低轨物联网卫星，比如那些窄带星座，覆盖和资费目前都不理想，国内用的人还少，生态不成熟。LoRa和自组网只能解决几百米到几公里的传输问题，监测点分布跨几条山谷时根本够不着，除非加中继塔，施工量不比铺光缆小多少。自建专网更不用提，每个点位一套微波或光纤，造价远超监测设备本身。
所以北斗短报文几乎是唯一能在国内全覆盖、不需要地面基础设施、资费可控的卫星回传手段。加上它在安防应急、水利等行业已经用了很多年，模块和平台都很成熟，跟4G做双模，工程上完全可行。
3. 终端设备核心构成与参数设计
3.1 终端整机组成与模块选型
一台典型的渗压计双模终端，内部大致分成这么几块：
- 数据采集单元：负责给渗压计提供激励信号、拾取频率，并换算成压力和水位值
- 主控MCU：负责任务调度、数据处理、通信链路切换逻辑
- 4G通信模块：走运营商网络，最常用的是移远、广和通、有方这几家的工业级模组
- 北斗RDSS模块：走短报文通道，国内主流是和芯星通、中科微这些厂家的产品
- 电源管理单元：负责电池充放电管理和各模块独立供电
- 天线系统：4G天线和北斗天线分开，北斗天线对安装位置要求高
选型上有几条硬性标准。4G模组必须选工业级的，工作温度范围至少覆盖-40℃到80℃，要支持标准AT指令，方便主控直接通过串口控制。北斗RDSS模块不是有硬件就能用，必须配北斗用户卡，也就是常说的SIM密钥，得找授权运营商提前申请开通，卡的类型决定了报文长度和发送频率上限，这个手续周期比较长，项目启动时就要去办。
顺便说一句，如果图省事想拿市面上的4G路由器方案改，比如qca9531那类低成本路由器的固件调优再挂传感器，我劝你谨慎。路由器方案在定时唤醒、低功耗睡眠、串口采集这些环节上非常别扭，而且固件稳定性参差不齐，野外环境不像客厅里吹着空调，还是专用DTU架构靠谱。
3.2 数据帧格式与北斗短报文压缩
渗压计的数据量小，反而更要把帧格式设计好。我们项目的数据帧大致是这样：
| 字段 | 长度 | 说明 |
|---|---|---|
| 帧头 | 2字节 | 固定0xAA55，用于同步 |
| 站点编号 | 2字节 | 点位ID |
| 渗压/水位 | 4字节 | IEEE754浮点数，单位米 |
| 温度 | 2字节 | 有符号短整型，单位0.1℃ |
| 电池电压 | 2字节 | 单位0.01V |
| 信号状态 | 1字节 | 当前走哪条通道 |
| CRC校验 | 2字节 | CRC16 |
一条数据帧总共15个字节。我们把3个相邻点位的读数打包，加上报头、用户卡号、时间戳，仍然能塞进一条北斗短报文里。给报文加一个序号字段，接收端按序号做去重和组帧，就能还原出一整组数据。
AA 55 00 17 42 C8 00 00 00 1E 00 0C 01 12 34上面是一帧的示例，前两字节是帧头，中间是水位和温度，最后两字节是CRC。帧格式定下来以后，主控的固件和平台的解析代码同时按这个协议走，后面调试会省很多事。协议里还留了扩展位，方便后续挂降深、雨量等别的传感器。
3.3 功耗与供电策略设计
野外无人值守，最怕断电。渗压计现场一般是太阳能板配蓄电池，设计目标是连续阴雨天7天依然能工作。要让这个目标成立，必须把平均功耗压到很低。
功耗大头是通信模块。4G模组发射时瞬间电流可以到几百毫安甚至上安，北斗模块发报瞬间电流也不小。我们的策略是终端按采集周期定时休眠唤醒，默认10分钟一个周期，采集和发送只在唤醒窗口内完成，完事后立即回到睡眠状态。4G模组用低功耗模式挂网，北斗模块平时完全断电，需要发报时才上电。
简单算一笔账：假设采集加发送需要15秒，平均电流按250mA算，一天采集144次，等效工作时间是144乘以15秒等于2160秒，也就是0.6小时，这部分的占空比只有2.5%，对应电量约0.15Ah。加上MCU待机、传感器静态耗电和天线放大器，整个终端一天大概在0.5Ah以内。配一块50Ah的12V蓄电池，常规天气下完全够用，遇到连续阴雨天撑一两周问题不大。
4. 现场实施与调试要点
4.1 天线安装的讲究
这是整个项目里最容易翻车的地方，没有之一。北斗短报文依赖“看到”卫星，天线周围如果被山脊、树木或者大体积结构物遮挡，报文上星成功率会明显下降。我们在河谷测点安装时，把北斗天线用支架抬高，避开山体遮挡，再用角度尺确认天线的仰角视野，保证朝上的大半个半球没有遮挡物。4G天线的方向性不强，但尽量朝向运营商基站的方向，效果会好不少。找基站有个土办法——用望远镜在附近山头上找铁塔，然后把天线方向对准塔的大致方位。
两个天线之间要注意隔离。4G天线和北斗天线不能靠太近，装在一起的时候实测过，靠得近会出现发射功率相互压制，定位和通信性能同时下降。安装时尽量拉开距离，垂直方向和水平方向都错开。外壳的防水密封也要做到位，最好用成套的户外终端箱，防护等级IP65以上，天线引出口用防水的航空接头，不要图便宜开孔穿线后随便拿玻璃胶糊一下。
4.2 云端平台的双链路对接
双模终端在云端看来是“两张嘴”：4G通道走MQTT或HTTP直接上云，北斗通道走运营商的地面转发中心，再通过公网API或专线推到监测平台。平台侧必须同时接两条链路，按照设备号和报文序号去做匹配和去重。
这里有个坑必须提醒：北斗通道返回的报文序号是全局递增的，如果一个项目里多个站点共用同一套号段，会出现序号变化规律不一致，导致上位机把不同站点的报文误判为重复报文丢掉了。我们的解决办法很简单——所有判断都以报文内容里的站点编号和时间戳为准，序号只用来检测丢包，不做身份判断。如果监测点还挂了视频监控，摄像机到平台的GB28181心跳周期也要同步调优，不然4G链路偶尔抖动，摄像头连不上平台，画面在那转圈，这跟数据链是同一个道理，别忽视。
4.3 双模切换策略的实测调优
切换阈值不能拍脑袋定。我们最初按RSRP一个指标来切，结果发现现场情况远比指标复杂。有些点位RSRP在-108dBm上下，平时看起来信号很差，但实际TCP建链和数据传输都正常；反而有些点信号看起来不差，一旦下雨或者天气变化，衰减非常明显。最后我们用了“RSRP值加上连续失败次数”的组合判断：连续三次4G拨号失败，或者RSRP长期持续低于指定阈值，才切换北斗；4G恢复后再延迟一段时间，确认稳定，才切回4G。
阈值设得太灵敏，终端会在两个通道之间来回横跳，白烧北斗报文费用；设得太迟钝，又会在需要切换的时候不切，造成数据缺口。这个参数没有统一答案，跟现场地形、运营商网络都有关系，建议按不同点位单独做两天实测再固化参数。我们几个站点就调过两轮，第一轮太灵敏，一晚上烧了二三十条报文；第二轮收敛阈值后，整个汛期北斗通道一共才用了几十条。
5. 常见问题与排查经验
5.1 北斗短报文丢包和延迟怎么查
北斗短报文不是实时的。从终端发报到地面中心收到，正常情况下要几秒到几十秒，赶上系统繁忙时段可能要几分钟。这是系统机制决定的，不用慌，设计上按分钟级延迟考虑就行。
真正要查的是丢包。最常见的三个原因：天线视野被挡、模块供电不足、发送间隔太密被系统限流。排查手法很直接：终端发完报文后，北斗模块会回一个带系统时间戳的回执，如果连回执都没有，大概率报文根本没上星，先去看天线安装；如果有回执但地面中心没收到，多半是用户卡状态或转发链路的问题，找授权服务商查卡的状态和转发日志。
5.2 野外环境下4G模块真的容易坏吗
这个问题很多同行会问。我的结论是：4G模块本身相当皮实，坏的多是“连带伤害”。雷击浪涌把模组电源打穿的、防水没做好进水短路腐蚀的、天线接头松动导致驻波比过高烧了功放的，这些我都见过，但纯属模块自身失效的反而少。所以野外防护要按工程标准做：电源入口加防浪涌保护，正确接地；天线进线口做密封，有条件加防雷器；外壳选有野外经验的成品机壳，不要自己焊铁皮盒子。
5.3 冬季低温导致的掉线
高海拔点位冬季气温到-20℃以下很常见。锂电池在低温下容量骤降，早上太阳没出来那段时间电压掉得飞快，终端供电不足就直接掉线。对策是把蓄电池换成铅酸或磷酸铁锂，电池箱做好保温；更稳的做法是“小电池配大太阳能板”，白天多充电，晚上靠电池容量硬扛。我们把电池容量从50Ah降到40Ah，太阳能板从50W加到80W，冬季掉线问题反而解决了——关键在于充得进，而不是存得久。
5.4 巡检时快速判断链路状态
现场巡检不能光靠肉眼看指示灯。我们在终端上加了本地状态指示，一个双色灯，常绿表示4G在线，慢闪表示正在走北斗通道，快闪表示故障，看一眼就知道链路状态。云端平台上也能查心跳，4G在线时心跳间隔短，通常一分钟内；北斗通道时因为报文频率受限，心跳只能按十几分钟甚至更长的轮询来。看到心跳节奏变了，就知道当前走的是哪条通道。
为了方便排查，我把常见现象整理成了下面这个速查表：
| 现象 | 可能原因 | 处理方法 |
|---|---|---|
| 北斗报文长时间无回执 | 天线被遮挡、模块供电弱 | 检查天线仰角视野，确认供电 |
| 有回执但平台收不到 | 用户卡状态异常 | 联系服务商查卡状态和转发日志 |
| 4G时断时续 | RSRP处于临界值 | 调整切换阈值，增加连续失败判断 |
| 平台重复收到数据 | 站点序号冲突 | 解析时以站点编号加时间戳为准 |
| 冬季频繁掉线 | 锂电池低温容量骤降 | 换磷酸铁锂，加大太阳能板 |
| 下雨后数据断 | 天线接口进水或松动 | 检查防水接头和天线驻波 |
这几年做下来，我的体会是：没有哪种通信方式是万能的。4G在地下峡谷里没有信号，北斗短报文又在资费和频次上限得死死的，双模的意义不在于炫技，而在于给“数据断链”这个最坏情况留了一条保底路。对一个渗压计项目来说，哪怕一年里只有几次真正用到北斗通道，它也值回了那点设备成本。最后再分享一个小技巧：设备装完别急着走，拿着手机在测点周边走一圈，测各个方向的信号强度，找一个“4G能通且北斗天线朝天无遮挡”的位置再固定死。这个位置多花半小时找，后面一整年都能少跑好几次巡检的路。
