从物理层到应用层：WiMi-net有中心自组网协议栈拆解

WiMi-net 这个词，起初我以为是某家无线模块厂商业化了自有固件而已，无非是“串口转无线、配置下频点、两个模块互相透传”。但真正把它和普通 GFSK 透传模块放在一起对比，你会发现 WiMi-net 的层次感完全不同：它把物理层、数据链路层、网络层、传输层、应用层全部做成了一套完整协议栈，并且围绕“有中心自组网”这个场景做了非常工程化的调度设计。换句话说，它不是让你把无线当一根串口线用，而是让你把一个网络当作一台带调度器的无线总线来用。这篇就把这套协议栈的五层结构、有中心自组网的组网流程、节点休眠机制、容量规划和实测中容易踩的坑，结合我做无线采集项目时的理解，一次拆透。

1. 有中心自组网：WiMi-net 这套协议栈的切入点

1.1 为什么“有中心”反而是工程上的务实选择

一提到自组网，很多人的第一反应是“无中心、多跳、网状”。这类网络在无线传感器网络论文里很漂亮，但落到工业现场，问题会接二连三地冒出来：全网时间同步怎么做？隐藏终端导致的冲突怎么解决？路由表在低功耗节点上怎么维护？某个节点断电后拓扑收敛要多久？如果节点的 MCU 只是一颗 8 位单片机，Flash 只有几十 KB，这些问题几乎是无解的。

WiMi-net 选择了另一条路：有中心自组网。网络里必须有一个中心节点，它负责全网的时间基准、信道时分调度、节点入网登记、时隙分配和下行控制；外围节点则被设计成“按中心给的时隙工作，平时尽量休眠”。这种架构牺牲了一点点拓扑灵活性，换来了极强的确定性。

这个设计思路和很多工业总线很像，回到低速无线领域也一样：场景是固定的，传感器位置是固定的，业务是周期采集和小概率事件上报，这时候最需要的是“让每个节点在专属时隙里通信”，而不是让节点自由竞争。中心节点就是那个的裁判。

1.2 一个 WiMi-net 无线网络的基本组成

从工程视角看，一个 WiMi-net 网络通常包含三类角色：

• 中心节点（Coordinator/网关）：负责组网、分配短地址、维护时隙表、转发业务数据。它是整个网络的时钟源和调度器。
• 终端节点（End Device）：末端传感器、执行器，一般电池供电，按中心分配的时隙进行上行上报或下行接收。
• 中继节点/子中心（可选）：当网络需要做树形延伸时，中继节点可以承担数据转发，把覆盖范围扩展出去。

从部署形态看，中心节点可以做成集中器、DTU、网关，也可以直接挂在用户的 MCU/主机上通过 UART 通信；终端节点则通常是无线模块加传感器。需要注意的是，WiMi-net 的“中心”不是指硬件上必须单独做一个主板，而是协议角色上有主从关系。同一颗无线芯片，烧录不同固件/配置，就可以变成中心或终端。

1.3 有中心自组网与无中心 Ad Hoc 的本质区别

对多数物联网采集业务来说，确定性比“自愈能力”更重要。中心单点故障可以通过双中心、备用中心或中心设备的高可用设计去弥补，而节点之间无休止的冲突和重传往往更致命。这也是 WiMi-net 这类有中心架构能在工业无线、无线抄表、环境监测等场景占据位置的原因。

2. 五层协议栈逐层拆解：从底层看它的通信机制

2.1 物理层：频段选择、调制方式与链路预算

WiMi-net 的物理层设计思路和常见的 2.4GHz 物联网方案差异很大。它更多工作在 433MHz、470MHz 等低频 ISM 频段，部分模块支持 868/915MHz 或 2.4GHz。低频段的优势很直接：绕射能力强、穿透性好，在楼宇、厂房、地下管廊等环境中，链路损耗比 2.4GHz 低不少。

调制方式常见的是 GFSK/MSK 这类窄带调制，空中速率从几 kbps 到几十 kbps 可配置。不要嫌这个速率低，对传感器数据来说，几十上百字节的一次上报在几 kb 到几十 kb 的速率下也就几十毫秒。低速率的另一个好处是接收灵敏度可以做得很高，很多模块标称灵敏度能做到 -120dBm 左右，这比 2.4GHz 方案通常高 10~20dB。

链路预算可以用一个简单公式估算：

发射功率 + 天线增益 - 接收灵敏度 - 系统余量 = 允许路径损耗

举个例子：节点发射功率按 10dBm，接收灵敏度按 -120dBm，收发天线增益各 1dBi，系统余量留 15dB，则允许路径损耗约为 10 + 1 + 1 -（-120）- 15 = 117dB。在 470MHz 城区环境下，117dB 的路径损耗对应的覆盖半径大概能到 1~3km 不等，具体取决于楼宇密度和天线高度。实测中，开阔地拉距比这个远，室内和地下环境则可能快速衰减。

物理层还有一个容易忽略的点：射频前端和晶振精度。低频段模块的射频链路对天线阻抗匹配更敏感，天线长度、摆放位置、外壳金属件都会直接影响实际辐射效率。低速窄带通信对晶振频率偏差也敏感，中心与终端之间如果晶振偏差过大，会造成载波偏移，接收灵敏度急剧下降。WiMi-net 协议栈通常在 MAC 层做频率/时间同步补偿，但硬件上选用温补晶振（TCXO）的模块在恶劣环境下的稳定性会明显更好。

2.2 数据链路层：时隙调度、帧结构与确认重传

数据链路层是 WiMi-net 的核心。它采用以 TDMA 为基础的信道接入机制，同时在一些管理帧里配合载波侦听机制。

中心节点会定期广播信标帧，信标帧包含全网时间戳、帧序号、时隙分配表等信息。所有终端节点以收到信标为基准，对齐自己的唤醒时间和发送窗口。超帧通常被划分为多个时隙，每个时隙内可以有上行数据时隙、下行数据时隙、广播管理时隙等。

为什么 TDMA 比纯 CSMA 更适合这个场景？因为 TDMA 下每个节点在自己专属的时间窗口内发送，不会与其它节点碰撞。而 CSMA 的冲突会随节点数量增加而急剧恶化，且无法保证某节点“一定能在某个时刻发出去”。WiMi-net 的中心节点负责把时隙划分给不同节点，类似操作系统里的进程调度：周期性任务给固定时隙，事件型上报可以安排随机接入时隙或者动态请求时隙。

帧结构上，数据帧通常会包含前导码、同步字、帧头（帧类型、目的地址、源地址、帧序号）、负载、校验字段。确认机制上，单播数据帧需要接收方回复 ACK，发送方在给定超时时间内没有收到 ACK 就会重传。WiMi-net 在 MAC 层做了一定的重传次数限制和退避策略，避免在链路很差的节点上无限重传，把整个网络拖垮。

这里我特别想强调一点：TDMA 虽然避免了节点之间的同时同频碰撞，但千万不能想当然认为“数字时分系统不处理冲突”。入网管理、事件上报这类突发性业务往往使用竞争时隙，竞争时隙还是需要有效的随机退避。WiMi-net 在协议栈内部把静态调度和动态竞争结合得很紧，单纯从模块外部看，用户感知不到这些过程，但理解这一点对排查“为什么某个节点上报总是慢半拍”很有帮助。

2.3 网络层：节点地址、入网注册与路由维护

网络层解决的是“数据从哪来、到哪去、怎么走”。WiMi-net 的地址体系一般包含网络 ID 和节点地址两个层面。网络 ID 用于区分相邻空间里不同的 WiMi-net 网络，防止串扰；节点地址则是在入网时由中心动态分配或通过配置静态设定的。

有中心自组网模式下，网络层路由表主要维护在中心节点和中继节点上。终端节点通常不需要维护完整路由，只知道自己和中心（或上级中继）的绑定关系。这让终端节点的存储开销和运行功耗大幅下降，也降低了实现复杂度。

入网注册是网络层最重要的过程之一。新节点上电后首先扫描信道（或监听信标），找到中心节点之后发起入网请求。中心收到请求后分配短地址，登记节点能力（是否支持休眠、是否支持中继、时隙需求等），再广播或单播入网确认。整个过程的目的是建立拓扑关系表，并在中心侧形成一张“网络成员列表”。

网络中继/树形扩展时，网络层还要处理子节点感知：中继节点需要向上级注册自己的存在，同时维护它的子节点列表。数据从终端上行时，中继节点判断目标地址不是自己，就转给上级；下行时，中心根据路由表将数据包转发到对应中继，中继再转给目标终端。路由表不是全网分发，而是每级节点只存必要信息，这种“分域路由”大大减少了路由开销。

在工程上，我建议把网络 ID 和频点当作整个项目的“基础配置”来做版本管理。尤其是当多个项目共用同一片区域时，网络 ID 冲突会制造出非常隐蔽的串扰故障，表现为偶发丢包、错包，但物理层 RSSI 看起来完全正常。

2.4 传输层：分片重组、可靠传输与流量控制

传输层解决的是“上层消息太大，而无线链路单帧承载能力有限”的问题。许多 WiMi-net 模块的射频单帧负载上限可能只有几十到两百字节，而用户的应用报文可能达到 1KB 甚至更大，这时候协议栈需要把应用报文分片成多个无线帧，接收端再按序号重组。

分片设计里的几个关键环节包括：分片序号精度足够的重传机制、接收端重组缓冲区管理、乱序和重复分片处理。如果协议栈没有做好的话，某个分片丢失后，接收端可能长时间等待超时，把整条消息丢掉，甚至导致缓冲区被占满。WiMi-net 的做法通常是在传输层头部记录分片序号和总帧数，并在收到全部分片后向上层提交。

可靠传输层面，传输层不是在每一帧做确认，而是以“完整应用报文”为单位做确认。举个例子，用户从主机下发一条 900 字节的升级配置到某个节点，传输层先把报文分成若干无线帧，逐帧发送。接收节点全部收齐后，组成完整报文，再回一个端到端的确认。这种设计比逐帧确认效率高，但也意味着单帧丢包会增加整条报文的重传成本，所以在链路质量差的环境中，适当调小应用报文长度会比无限重传更实用。

流量控制在实际项目中也很重要。中心节点一旦同时面对大量终端的上行数据，如果一直发，内存就会爆。WiMi-net 的传输层会在低速串口和无线高速链路之间做缓冲调度，同时通过滑动窗口或停等机制限制发送速率。对于应用层开发者来说，最直观的体感就是：大量并发上报时，主机的串口不会瞬间收到所有数据，而是会持续收到一段“数据流”，这正是协议栈在做缓冲和排队。

2.5 应用层：主机接口与协议封装

应用层是用户直接接触的一层。WiMi-net 的模块通常通过 UART 和主机 MCU 对接，主机向模块发送用户数据，模块负责组帧、加密/校验、分片、发送、重传、接收和重组。不同厂家的模块在接口 API 上可能有不同封装，但大体思路一致：一种是在模块上实现 AT 指令集，方便直接用配置工具和脚本控制；另一种是通过专用串口协议帧（地址字段、命令字段、长度、数据、校验）与主机通信，适合嵌入式系统直接解析。

这里的核心设计思想是：把无线协议栈的细节隔离在模块内部，主机侧只关心“发给谁、发什么数据、收谁的数据、什么时候收”。这样应用层开发周期会非常短。比如一个温湿度采集项目，主机 MCU 只需定期把传感器数据打包成应用数据帧交给 WiMi-net 模块，模块内部去完成入网保持、时隙同步、帧重传等动作；反过来，中心侧主机收到模块提交的数据时，数据已经是重组完成的完整报文，不需要自己做分片处理。

需要留意的坑是：应用层报文格式和模块的串口协议格式是两回事。前者是业务自定义数据，后者是模块管理通道。很多开发者在调试 AI/AT 配置和透传数据时会混淆，把配置指令和业务数据混在一个通道里发，导致模块状态机被搅乱。正确做法仍然是按厂家协议把管理帧和业务帧分开，至少通过帧头、帧类型或命令字区分。

3. 一次完整通信的生命周期：从入网、休眠到数据上报

3.1 节点首次入网的过程

新节点上电后，第一步是信道扫描/信标搜索。如果网络中已经有中心节点在广播信标，节点会锁定该信标，并读取中心下发的同步信息。此时节点处于未入网状态，中心不会为它分配任何定时任务。

接下来节点在指定竞争时隙里发送入网请求帧，请求中会携带节点的能力参数，比如是否支持休眠、期望的上行周期、是否承担中继任务等。中心收到请求后，根据当前网络容量决定是否接受。如果接受，中心就分配一个短地址和一组时隙参数下发给节点，并同步到自己的时隙调度表中。节点收到入网确认后，进入已入网状态。

从工程角度，入网过程的时长并不固定。如果网络规模大、竞争时隙拥塞，或者节点距离中心太远导致入网请求多次重传，入网时间可能从几百毫秒延长到几十秒。因此在上电自检、工程测试环节，要给入网过程预留足够超时时间，不要一上来就判断“模块坏了”。

3.2 休眠策略与唤醒窗口

有中心自组网里的休眠策略比无中心网格好做得多。中心知道每个节点的时隙安排，它可以在时隙表中分配“唤醒窗口”和“睡眠窗口”。节点平时时钟停在低功耗模式，快到自己的唤醒窗口时，通过内部定时器起振，短暂开启射频接收信标或数据，然后在没有任务时继续睡下去。

这里的难点是时钟漂移。低功耗 MCU/射频芯片内部时钟的精度一般也就几个 ppm 到几十个 ppm，温度变化还会进一步漂移。长时间睡眠之后，节点自己的时间基准可能和中心已经偏了不少。解决方式是周期性校准：节点在每个唤醒窗口都会重新接收中心信标，根据信标里的时间戳修正本地时钟。如果某次唤醒后没有收到信标，节点通常会继续监听一段时间，或者等待下一个周期重试，而不是立即上报故障。

休眠不是“睡越久越好”，而是要在功耗和实时性之间找平衡。如果应用要求 10 秒级响应，节点最好每 1~2 秒唤醒一次维护同步；如果只是每天上报一次，那中间大部分时间都可以睡。WiMi-net 的中心节点会把这些参数配置成不同的工作模式，工程人员需要按业务需求选择。

3.3 上行数据与下行命令的时隙处理

上行数据通常发生在专用上行时隙。节点在唤醒窗口内收到信标，发现自己本周期内分配到上行时隙，就等时隙到来时发送数据。发送完成后，节点继续监听一个短窗口等待 ACK，收到 ACK 后可以重新进入休眠，也可以继续保持短时接收窗口等待下行数据。

下行命令的处理更依赖中心调度。中心有数据要发给某一节点时，它不能像对讲机那样“想喊就喊”，它必须等该节点处于接收窗口。所以中心侧会把下行数据先缓存，等到该节点的下行时隙/唤醒窗口到来时再发送。这个设计对电池供电终端尤其重要：终端不需要长时间开着接收机，只需要在约定的短暂窗口内监听即可。

理解了这一点，就能解释很多无线模块常见的“怪现象”：终端上报可以很快，但是中心要下发控制命令到终端时，时延有时长有时短。这未必是链路卡了，而是下行调度窗口还没到。如果业务对下行实时性有硬性要求，就需要把唤醒周期缩短，或者让模块支持“事件唤醒”的下行机制，比如节点上报后强制监听一段较长时间，中心只能利用这个时间窗下发命令。

4. 工程选型与网络规划：参数怎么定才不会踩坑

4.1 网络容量：一个中心节点到底能挂多少节点

这是我在实际项目里被问得最多的问题。答案不取决于“协议栈上限支持多少”，而取决于“单节点业务周期、数据长度和时隙安排”。

做一个简化估算。假设空中速率是 10kbps，一个 50 字节的上行应用数据帧加上帧头、分片头、MAC 帧头等开销，大约需要发送 70 字节，即 560bit。以 10kbps 发送，再加上收发转换、同步唤醒、保护间隔，单个时隙保守估计需要 80~100ms。如果采用 2 秒超帧，一个中心节点在一个周期内可以安排约 20 个这样的时隙。如果一个节点 10 秒上报一次，那 2 秒超帧只分配其中一部分时隙给节点，其他节点可以错开，这样单个中心就能挂载更多节点，比如 50~100 个量级。

数据上报越频繁、单包越长，容量下降越快。如果每节点每秒上报一次 200 字节的数据，即使空中速率提高，单中心能带的节点数可能也只有几个到十几个。所以做网络规划时，一定要把“单节点最终的真实业务模型”列出来，而不是只按“支持几百节点”的参数来选型。

实际项目里，我习惯先用一个容量表预估：

• 节点数 N
• 上报周期 T
• 单次上报应用数据长度 L
• 空中速率 R
• 协议开销系数 O（一般取 1.3~2，视帧结构而定）

占用率估算公式：N × L × O × 8 / (T × R) × 100%

这个占用率最好控制在 50% 以下，剩余容量留给重传、入网和事件上报。超过 70% 之后，一旦出现链路干扰和重传，网络就会迅速恶化。

4.2 时延预算：从终端采集到中心收到数据需要多久

有中心 TDMA 网络的时延主要由三部分组成：终端等待时隙的时间 + 无线传输时间 + 中心排队与串口上报时间。

终端等待时隙的时间是最大变量。如果终端刚错过自己的上行驶时隙，它要等下一轮超帧。假设超帧是 2 秒，这就意味着最坏情况要等接近 2 秒。当然，实际协议栈可能有下一时隙抢占或动态时隙分配机制，但做产品设计时，时延指标不能只看理想情况。对 10 秒级周期上报业务，2 秒超帧完全没问题；如果是秒级联动控制，就需要把超帧缩短，或者启用事件型快速通道。

传输时间本身不大。几百字节的包在 19.2kbps 下只有几十毫秒。真正的延迟大头在调度等待和排队。所以在项目需求阶段，不要笼统地问“延迟多少毫秒”，而要问“在什么负载和什么周期下，95% 数据的时延是多少”。

4.3 与 LoRa、Zigbee、私有 GFSK 方案的对比

从这张表可以看出，WiMi-net 的核心竞争力不在“远”或者“快”，而在“低频物理层穿透优势 + 有中心协议栈的确定性调度”。它在 470MHz 这类频段上做低速率高可靠传输，尤其适合对实时性和可靠性要求较高的工业数据采集。

选型建议很简单：如果只是点对点收发几米距离，直接搞透传模块就行；如果要做多节点组网、电池供电、低功耗和可靠上报，WiMi-net 这种完整协议栈的价值立刻就体现出来了。但如果业务需要大带宽视频传输、或者高速移动的车间 AGV 通信，那它不是合适的方案。

5. 调试与排查：实测中最容易踩的几个坑

5.1 节点“掉线不回来”的第一排查顺序

很多人在项目测试里遇到“节点用着用着就消失了，要重新上电才恢复”，第一反应是射频问题，其实最常见的是同步丢失和时隙超时。排查顺序应该是：

1. 查供电：电池电压是不是已经跌落到模块最低工作电压以下？节点在峰值发射时电流可能到几十毫安，如果电池内阻大，会瞬间把电压拉低到复位阈值。
2. 查唤醒窗口：长时间休眠后，节点是否还能稳定收到中心信标？用串口日志看节点有没有周期性的“信标同步失败”记录。
3. 查 RSSI：中心侧看该节点最后一次上报的信号强度，如果接近灵敏度门限，说明处于覆盖边缘。
4. 查网络 ID/频点：是不是两个网络或设备配置混用了，导致节点频繁离网。

如果是覆盖边缘问题，单纯抬高发射功率往往帮助不大。更有效的做法是增加中继节点缩短末级链路距离，或者换高增益定向天线。不要盲目调大重传次数，重传多了会把整个时隙占满，反而影响其他节点。

5.2 重传率高：链路余量不足的隐形信号

有时中心软件上看每个节点都连上了，但整体成功率只有 80%，大量报文在重传。这时候最容易犯的错误是盯着“调制频率”和“重传次数”调参数。实际上，需要先看每个节点的 RSSI 和 LQI（链路质量指示）。如果某些节点的 RSSI 在 -105dBm 以下，灵敏度余量已经很低，偶发多径衰落就会造成周期丢包。

处理方法包括：调整天线位置使其避开金属遮挡，把终端天线从贴着板子平放改成垂直地面竖放，检查天线馈线接头是否虚焊，给接收机留出适当增益余量。必要时可以降低空中速率，因为低速 FSK 通常比高速 FSK 灵敏度更高，还能顺便改善穿透效果。

另外要检查发送节点的功率是否真的达到了配置值。如果电池电压不足，部分模块会因内部 DC-DC 升压能力不足而实际发射功率下降，表现为“配置 20dBm，实际只有 8dBm”。这种故障不会在射频仪器里暴露，只有在整机上才会显现。

5.3 中心节点负载与流量风暴

有中心架构里，中心节点是整个网络的单点。当大量终端同时上报时，中心节点的处理能力会迅速饱和。现象是中心串口出现数据堆积、回应 ACK 变慢、部分节点上行重传。

这里要区分是无线链路拥塞还是中心串口瓶颈。如果是中心串口速率设得太低（比如 9600bps），即使无线侧吞吐量还有余量，数据也会堵在串口。这时候提高串口速率，或者让主机采用更高优先级中断接收，往往立竿见影。

如果确认是无线侧拥塞，就要回到网络规划：减少每个超帧内的节点数、拉长上报周期、或者拆分为多个互不干扰的子网频点。不要在同一个网络里堆太多节点，物理规律摆在眼前，协议栈再强也不能无中生有地扩容。

5.4 调试工具与测试方法

WiMi-net 设备商一般会提供配套的 RF 测试和网络管理软件。调试时建议把中心节点的日志和终端节点的日志同步抓出来，重点对比信标接收、时隙分配、ACK 收发和重传次数。

如果没有现成工具，可以从射频信道占用和时间域测量下手。用频谱仪看频点附近的底噪和突发占用；用逻辑分析仪/示波器抓模块的 UART 时序，对比无线事件日志，就能定位很多“看不见”的问题。

还建议做一次长时间稳定性测试：把节点放到实际部署环境，连续运行 48 小时或一周，记录丢包率、重传率、中心重启次数。只做实验室无干扰测试很容易漏掉低频段无线环境里的偶发干扰，比如附近对讲机发射、电力载波设备、甚至环境温度变化导致的晶振漂移。

5.5 不要把模块当黑盒：协议栈理解越深，问题越少

用了这么久的 WiMi-net，我的体会是：这类带完整协议栈的无线模块，最大的价值不是“开箱即用”，而是它帮你把无线网络里最困难的协议问题解决掉了。但它并不能替你规划网络部署，也不能替你理解无线传播规律。把协议栈当黑盒、不做链路预算也不想时隙管理的项目，后期问题一定不少；反过来，如果把五层协议栈的工作原理、有中心调度的机制和底层射频特性看明白，即使遇到问题，也能在几分钟内定位方向。

从一个实际项目的经验来看，最后往往不是射频模块本身出问题，而是供电、天线、网络规划、业务模型和协议栈配置之间没有对齐。与其说这是在调试无线协议，不如说是在调试整个系统的工程设计。