企业官网建设流程全解析

物联通信圈子里，LoRa 一直是个绕不开的话题。很多人第一次接触它，是被超长距离和低功耗吸引，可真要自己动手组网的时候，却容易卡在一个问题上：LoRa 到底该怎么组网？芯片手册上只写了物理层的收发，项目却需要多节点、多网关、甚至协议栈，这时候该选什么方案？

先说一个基本判断：LoRa 本身只是一层调制技术，它管的是“怎么把一个字节可靠地发出去”，至于“谁发给谁、什么时候发、发完怎么收”，这属于组网协议该管的事。所以“LoRa 组网”实际上包含两个层面：一是用什么样的拓扑把设备连起来，二是用什么协议约定通信规则。前者是架构问题，后者是代码问题，很多人混淆了这两件事，导致项目迟迟无法落地。

这篇文章我打算从组网的本质出发，把最常见、最简单、成本最低的几种组网方案全部摊开比较，然后结合我在实际项目里踩过的坑，给出一套可执行的选型和实现路径。无论你是只打算做两个传感器的点对点通信，还是规划几十上百个节点的采集网络，下面的内容都能对得上号。

1. 组网之前，先把 LoRa 的物理层特点摸透

不谈物理层直接谈组网，就是耍流氓。LoRa 组网方案的选择，很大程度上是被它的物理特性绑架的。你只有先弄清楚 LoRa 在真实环境里的脾气，才知道为什么没有一种“万能协议”能适配所有场景。

1.1 传输速率和距离之间的取舍，是最核心的约束

LoRa 用的是 Chirp 扩频技术，跟 WiFi、蓝牙那种窄带通信完全不同。它的核心优势是接收灵敏度极高，可以做到 -137dBm 甚至更低，这意味着发射功率只有 20dBm 左右时，空旷环境下能轻松跑出几公里通信距离。

但代价也很明显：速率极低。LoRa 的空中速率从理论上的 0.3kbps 到 27kbps 不等，实际项目里常用的配置下通常只有几百 bps 到几 kbps。你可能觉得这个速度太寒碜了，但它就是靠牺牲速率换来了链路余量。这里有一个很关键的参数链需要理解：扩频因子 SF、带宽 BW、编码率 CR，三者共同决定了实际吞吐量。

• 扩频因子 SF 越高，信号越抗干扰，灵敏度越好，但速率越低。SF7 和 SF12 之间，灵敏度差距大约有 10 多 dB，对应的单包空中时间也能差好几倍。
• 带宽 BW 越大，速率越高，但灵敏度变差，抗干扰能力也下降。
• 编码率 CR 则是纠错冗余，冗余越多越抗突发干扰，但有效载荷率降低。

在实际项目中，我经常看到有人把 SF 调到 12 来追求最远的距离，结果节点一多，信道被占得满满当当，反而导致严重的丢包。组网时对 SF 的选择不能只考虑单点性能，还要考虑整个网络的容量和时延。这是后面选协议时绕不开的基本盘。

1.2 半双工是硬限制，通信靠“轮”不靠“同时”

LoRa 芯片本质上是半双工的，同一时间只能收或者只能发。这个特性对组网模式影响巨大。你没法像 WiFi 那样做载波侦听多址，也没法做全双工的中继，所有通信必须按照某种时序规则来排队。

一提到排队规则，就不得不面对一个现实：LoRa 的“排队”意愿和效率都不如蜂窝网络。LoRa 没有内建的冲突避免机制，多个节点同时上行，在网关看来就是一阵噪声。所以真正好用的组网协议，都要在 MAC 层解决这个冲突问题，或者用非常严格的调度策略来避免两个包同时到达。

理解了这一点，你就能明白为什么市面上的 LoRa 组网方案里，星型拓扑占绝对主流，而不是像 Zigbee 那样到处是网状网。因为星型拓扑只有一跳，节点直接和网关通信，网关负责调度，逻辑最简单，实时性也可控。而网状网意味着多跳，每跳都要占用信道时间，时延呈指数级累积，还要处理路由维护、拓扑变化，对 LoRa 这种半双工、低速率信道来说，代价实在太大。

1.3 功耗和供电方式，决定了协议栈的奢华程度

LoRa 节点的功耗通常分三档：电池供电、太阳能供电、外部电源常供电。这三类节点的协议设计逻辑是完全不同的。

电池供电的节点，一年甚至几年不换电池，这类节点必须最大化休眠时间，通信模式天然倾向于“醒来发一次、发完就睡”。这就决定了它不可能长时间监听网关的下行指令，所以协议必须支持异步上行。太阳能供电的节点逻辑类似，但能支撑稍微活跃一点的通信。而外部电源供电的节点，比如采集终端接的就是 220V 电源，那它完全可以一直监听，协议可以复杂一些，实时性也更好。

所以你会发现，LoRaWAN 这种标准协议把节点分成 Class A、Class B、Class C，本质上就是给不同供电条件设计的三种通信行为。而很多简单的私有协议根本不区分这些，因为它们的主要服务对象就是“定时唤醒上报”的场景。组网协议的设计起点，其实是“你的节点多久才需要说一次话”。

2. 最无脑的组网方式：点对点透传，其实是最实用的入门方案

很多人一提到组网，就默认是“多节点+网关+服务器”的大系统。但实际上，在接近一半的真实项目里，你需要的只是让两个 LoRa 设备互传数据。点对点透传就是这么一种最简单的组网形态，简单到你甚至可以说它不算“组网”，但它的实用性极高，是所有 LoRa 项目的良好起点。

2.1 点对点的本质，就是把 LoRa 当一根无线串口线

点对点透传模式下，两个 LoRa 模块之间建立一个固定频率、固定扩频参数的信道，一端发、一端收，数据格式完全透明。你用串口发什么，对端就从串口收到什么，中间不做任何封装。

这种模式用起来就像把一根串口线变成了无线链路。两个设备分别配置好相同的频率、相同的 SF、相同的带宽、相同的编码率，然后一个置为发送模式，一个置为接收模式，或者都使用连续接收模式，就完成组网了。

实际项目中，点对点模式最常见的场景是两个串口设备之间的数据互联，比如：

• 现场仪表通过 RS485 走 LoRa 传输，把数据送到几十米外的采集电脑，省去拉线的麻烦。
• 遥控器与设备本体之间的指令通道，替代原来几百米就不行的 433MHz 遥控模块。
• 两个 PLC 控制器之间的数据交换，再也不用凿墙埋线。

实现这种模式只需要一块带 AT 指令控制的 LoRa 模块，或者直接使用裸串口模块，把配置写死后互相通信。几乎没有学习成本，硬件成本也不高。对个人开发者来说，可能一个小时就能从零跑通收发链路。

2.2 适合用点对点的几个具体反面案例

我之所以说点对点“实用”，是因为它同时在安全和容量上都有不可忽视的限制，如果你没识别出自己的需求属于这几类，就会掉坑：

第一，单向点对点没有任何应答机制。发完就完，接收方到底收到没有，发送方完全不知道，只能靠业务层确认。如果项目里有“必须确保送达”的指令，那么点对点透传模式就不够用，你得在上层自己实现重发逻辑。

第二，点对点信道是共享的。如果有第三个设备也在同一频率、同一 SF 上发射，就会发生碰撞。所以点对点模式天然只适合“1 对 1 通信”，或者说，适合“同一时刻只有一对在通信”的场景。一旦节点数超过两个，你还是得考虑其他组网方式。

第三，点对点模式没有加密。LoRa 射频链路本身是明文，任何人拿一个接收模块调到同一频率就能监听。如果数据是明文传输，很多行业应用是不可接受的。你以为传的是仪表读数，实际上等同于在广播。

所以我的建议是：如果你的项目只有两个节点，且数据不需要强加密，直接上手点对点透传模式，不要犹豫。这也是 LoRa 组网里成本最低、实现最快的一条路。

2.3 点对点模式如何快速验证

一个新项目拿到手里，不要急着写协议，先把点对点链路跑通。这不仅是验证硬件，也是在真实环境里测试参数配置是否合理。

验证的方法很简单：准备两个模块，一个接电脑串口，一个接 USB 转串口，都打开串口调试工具。确认两个模块的频点一致、SF 一致、BW 一致、CR 一致、发射功率设定合理，然后一端发“123456”，另一端能收到“123456”，链路就通了。

这里有个细节容易踩坑：某些模块默认开启了数据白化或校验模式，导致收到的数据后面多几个字节。如果出现这种情况，先检查是否打开了 OTA 头、CRC 校验这类开关。必要的时候可以把所有可配置项先恢复默认值，再从发送模式测试，就能一步步定位问题。第一次做 LoRa 通信的人，有相当大比例的时间是花在这个“对着参数表找差异”的过程里，把链路跑通之后，后续组网时的信心会足很多。

3. 多节点组网的轻量级方案：自定义星型私有协议

当你的节点数变成 5 个、10 个、甚至 30 个的时候，点对点模式就撑不住了。这时大多数人会走第二条路：基于 LoRa 模块，自己写一套简单的星型私有协议。这种方案处于“比透传稍复杂、比 LoRaWAN 简单得多”的中间位置，是很多中小规模项目的选择。

3.1 为什么星型是私有协议的最优拓扑

前面我提到，LoRa 的物理层不支持同时收发，所以任何多节点访问信道的行为，都需要在链路层约定出先后顺序。星型拓扑下，所有节点都直连网关，不中继、不路由，天然比网状结构简单得多。

星型拓扑里，网关是唯一的中心。所有节点只和自己的网关通信，节点之间没有任何直连关系，这也意味着节点之间不需要维护路由表。LoRaWAN 也是星型架构，这并非偶然，而是 LoRa 物理特性下的最优解。

星型还有一个非常大的好处：网关可以掌握全局调度权。它知道当前有哪些节点、哪些节点在线、上次通信是什么时候，这种集中式控制对实现可靠传输非常有利。如果你想做主动下发指令、远程升级这种功能，一个拥有完整状态信息的网关是基础。

相比之下，Mesh 网状网在 LoRa 里很少被用到。Mesh 的关键价值是扩展覆盖范围，但付出的代价是整个网络的时延和非确定性大幅增加。每一跳都在消耗本来就稀缺的空中时隙，而且 Mesh 路由协议本身的复杂度就要占掉很大一部分内存和算力。对于大多数数据量和实时性都不高的物联网场景来说，星型+较远距离的单跳，远比 Mesh 多跳可行。

3.2 私有协议的三要素：地址、帧格式、调度策略

写一套自己的星型协议，设计上绕不开三个事情。

第一是地址分配。每个节点要有唯一的设备地址，用来标志数据的来源和去向。这个地址可以是 1 字节（支持 256 个设备），也可以是 2 字节（65536 个）。简单的私有协议里，通常用一个字节的设备地址就足够，数据帧里第一个字节就是地址域。

第二是帧格式设计。数据帧至少需要包含：前导码、同步字、帧头（包含目的地址、源地址、帧类型、长度）、数据载荷、校验字段。这套格式不需要完全照搬 LoRaWAN，而是根据具体业务来裁剪。比如你可以定义一个非常简单的帧：

设计帧格式时不用过度设计，够用就好。但有一点要提醒：千万别设计出一个没有帧长度字段的格式。LoRa 的空中包不像串口数据那样自带边界，你必须显式告诉接收方载荷有多长，否则解析起来会非常痛苦。

第三是信道访问策略，这是最难的部分。节点多了之后，同一时间多个节点同时发数据，网关侧的冲突几乎是必然的。在 LoRaWAN 里，这靠 ALOHA 协议解决：节点随时发，冲突了就随机延迟重发，是一种概率性靠运气的方法。私有协议里，你可以做得更确定一点：

• 轮询式：网关逐个点名，节点被叫到才发。这种方式最可靠，没有碰撞，但实时性差，节点多了以后巡检一轮时间变长。
• 时间片式：给每个节点分配固定的时隙，节点在自己的时隙里发。适合节点上报节奏固定、全网时钟同步的场合。
• 事件驱动+随机退避式：节点有数据就发，发现发不上来就随机退避重试。这是 LoRaWAN 的思路，简单但靠运气，场景空旷时够用，节点多了就够呛。

我在项目里常用的组合是：以轮询为主、主动上报为辅。网关每隔一段时间轮询一遍所有节点获取实时状态，节点同时也允许在告警事件发生时主动上报，冲突通过随机退避缓解。这种方式确保了基础数据的时间确定性，也兼顾了事件响应的及时性。

3.3 私有协议的优势和代价，基本是一体两面

私有协议最直观的好处是可控性。所有格式都是你自己定的，没有晦涩的标准协议细节，代码量可以压得很低。在一颗 8 位 MCU 上，私有协议的协议栈代码通常只占很小的一部分，留给业务逻辑的空间很宽裕。而且不会出现 LoRaWAN 里加入网络时那种繁琐的入网流程，通电、配好地址、直接发数据。

代价则是非标准化和重复造轮子。如果你今天用私有协议 A，明天做另一个项目又用私有协议 B，那么每套系统都要重写一遍驱动和测试代码。更现实的问题是：私有协议只能和自己私有的网关配合。如果你想让设备接入其他厂商的网关，私有协议基本走不通。

所以做私有协议前一定要想清楚边界：项目规模固定、设备不会轻易换网关、协议栈只服务单一产品线。只要满足这几个条件，私有协议就是性价比很高的选择。尤其在一些工业采集项目中，网关和节点都是自己控制的，私有协议能让你快速迭代，出问题也好排查。

4. 不自研协议栈的成熟方案：跳到 LoRaWAN 这个行业标准

如果说私有协议是“自己做饭”，那 LoRaWAN 就是“点外卖”。它是一套定义完整的网络协议标准，涵盖了从物理层到应用层的整个堆栈，专门解决多节点、远距离、低功耗组网问题。它最大的价值，是让你不必关心底层那些繁琐的组网细节，专注于应用层数据的处理。

4.1 LoRaWAN 体系结构，一句话就能讲明白

LoRaWAN 的体系由三部分组成：终端节点（Node）、网关（Gateway）、网络服务器（Network Server）。

终端节点就是那些采集数据的传感器，它们内置 LoRa 模块。网关负责在 LoRa 射频和 IP 网络之间做桥接，把终端上传的数据打包成 IP 包发给云端服务器。网络服务器是大脑，负责处理终端入网、管理密钥、转发数据给应用服务器，并决定是否需要向终端发送下行指令。

在这个体系里，终端和网关之间的空中接口是 LoRa，网关和服务器之间的回程通常走以太网、4G 等。这就是为什么 LoRaWAN 的扩展性非常好：你可以在任意位置部署网关，只要网关能连接服务器，这个区域的终端就有网络覆盖。这早就不是简单的星型拓扑了，而是“星型中的星型”，很多网关挂在同一个网络服务器下，组成一个逻辑上统一的虚拟网络。

4.2 三种终端工作模式，理解它们就能理解 LoRaWAN

LoRaWAN 里规定了几种终端工作模式，我强烈建议你在用 LoRaWAN 之前，把其中的核心概念搞清楚，因为它们直接决定了你的系统能做什么、不能做什么。

Class A 是最常用的模式，也是最省电的模式。终端平时一直在睡觉，只有在主动上报数据时才会醒来，发完数据后开启一小段时间窗口监听网关的下行。这种模式适合上报型应用，比如温湿度采集器、土壤墒情传感器。缺点是网关想主动给终端发指令，必须等终端下一次醒来上报之后才能“顺带”下发。

Class B 模式可以让终端按固定周期打开接收窗口，网关以信标同步所有终端，然后在下行时隙下发数据。这种模式适合需要周期性接收下行指令的设备，代价是功耗比 Class A 高，终端必须定期同步信标。

Class C 是始终监听的模式，终端基本不睡，网关随时可以下发。这种模式适合供电充足的设备，比如电表、路灯控制器。代价是功耗很大，电池场景基本不考虑。

实际选型时，你不需要每类模式都用上。大多数传感器项目，Class A 完全够用。只有确认需要“网关主动通知节点”，才考虑 B 或 C。

4.3 激活方式与角色划分，选错了会卡住整个项目

LoRaWAN 还有两个概念，很多刚开始做的人容易忽略，但在实际部署时非常关键：一种是 OTAA 激活，一种是 ABP 激活。

OTAA 就是终端首次上电时，通过一个预设的 AppKey 向网络服务器发起入网请求，服务器审批后分配设备地址和会话密钥。这种方案的好处是安全性和便捷性都高，设备出厂只需要烧录 AppKey，不需要知道网络里实际分配的地址。日常开发用 OTAA 很有优势，也方便批量生产。

ABP 则是预先在设备里写死网络地址和会话密钥，开机直接联网，不需要入网握手。好处是入网快、逻辑简单，坏处是密钥固定，一旦泄露整个网络都面临被伪造的风险。两种方式各有适用场景，调试阶段 ABP 更省事，正式部署尽量用 OTAA。

此外，LoRaWAN 里区分了设备角色：单播、组播。大多数时候你用单播就够了，只有在做远程升级这种需要同时给一批节点下发固件的场景，才需要设置组播地址。很多刚接触的人看到组播参数就直接懵，我建议先不碰它，等系统稳定后再扩展。

4.4 LoRaWAN 的部署门槛，藏在哪里

LoRaWAN 虽然标准化程度高，但“协议标准”和“能用起来”之间还有一段距离。实际项目里最麻烦的往往是这么几件事：

第一，网络服务器部署。你可以使用现成的 LoRaWAN 网络服务器软件，也可以自己照着协议栈实现一套。前者省事，后者灵活。很多人一开始高估了自己的需求，自己去造 LoRaWAN 服务器，结果发现调度、MAC 命令、重传、激活管理这些功能牵扯大量精力，最后要么买商业套件，要么回归开源方案。

第二，网关的配置。LoRaWAN 网关并不是一台 LoRa 模块就能充当的。它通常需要支持 8 个或更多信道同时接收，还要具备较强的处理能力来吞吐多个节点的数据包。市场上成熟的网关硬件方案不少，但配置起来涉及频率计划、网络 ID、服务器连接方式等不少细节。

第三，频率和运营限制。不同国家和地区对 LoRa 的使用频段及占空比有限制，国内应使用当地允许的合规频段及功率要求。项目部署前必须确认这一点，尤其是跨区域部署时，频率计划不能照搬。

5. 从零开始跑通一套最小 LoRa 组网系统

理论部分讲了一大堆，接下来我说一下最落地的实操过程，怎么从零开始跑通一套最小系统。这里假定你选择的是“自建私有星型协议”方案，因为它在理解成本、代码量、成本三方面比较均衡，改造起来也容易。

5.1 硬件选型三件套和参数配置

硬件方面，最简单可靠的是使用现成的 LoRa 模块方案。我对新手的建议是：不要用裸芯片自己搭射频电路，直接买带射频前端和天线接口的成熟模块，省掉大量 RF 调试工作。

主控端用常见的 MCU，比如 STM32 系列或 ESP32，通过 SPI 接口控制 LoRa 模块。SPI 是指令通道，而射频收发逻辑全在模块内部，主控只负责填寄存器、发数据、读数据。

参数配置是一个关键环节。我们以一个典型的 470MHz 频段的项目为例，常用的配置如下：

• 中心频率：486.5MHz（具体频点必须按当地法规要求选择）
• 带宽：125kHz
• 扩频因子：SF9（兼顾距离与速率）
• 编码率：4/5
• 发射功率：19dBm 左右
• 灵敏度目标：-130dBm 级别

你可能会问，为什么中心频率选一个奇怪的小数点？这是因为不同信道的中心频率往往带有偏移，加上 LoRa 通常按信道做多路规划，频点不会落在整数的 1MHz 或 2MHz 网格上。实际操作时，你只需要保证所有模块共用同一个频点即可。

这里有个经验：在开阔环境下，SF9+125kHz 带宽的配置通常能达到 1-2km 的可靠通信距离。如果距离不够，优先提 SF，而不是盲目提高发射功率。提高 SF 对链路预算的增益在某些情况下比加功率更划算，因为它同时改善了接收灵敏度，还不那么容易让接收端因邻近强干扰而饱和。

5.2 最小系统代码框架

自己写私有协议，代码不需要多复杂，但框架必须清晰。一个最小系统通常分为四层：

• 驱动层：封装 LoRa 模块的 SPI 读写、寄存器配置、中断处理。
• 链路层：实现帧的组包、解包、CRC 校验、ACK 重传。
• 网络层（可选）：管理设备地址、信道分配、入网登记。
• 应用层：编写业务逻辑，比如定时采集、数据解析、告警判断。

以网关侧为例，它的主循环逻辑一般是：

1. 初始化 LoRa 模块，设置为接收模式。
2. 监听空中信号，收到完整一帧后解析出源地址和载荷。
3. 根据源地址在本地维护一张节点状态表。
4. 如果需要应答，给节点回一个 ACK 帧。
5. 如果应用层队列里有下发给某个节点的指令，就把指令打包发送。

以节点侧为例，它的逻辑更简单：

1. 初始化 LoRa 模块和传感器。
2. 进入低功耗模式。
3. 定时器唤醒，采集数据。
4. 组包、发送、等待网关 ACK，超时则重发。
5. 检查是否有网关下行指令，有则处理，然后继续睡眠。

这两段逻辑看起来简单，但实际写起来需要处理很多边界条件。比如：网关发送 ACK 时，节点正好没有在接收？这属于 ACK 超时重传的范畴。又比如：节点刚开机时，网关还没建立状态表，节点发的第一帧会不会被当成垃圾数据？这时候需要设计一个“注册帧”或者带“状态查询标志”的上报帧，网关收到后先响应，再登记。这些都属于协议细节，但它们决定了一轮通信是否可靠。

5.3 现场调试要关注的三件事

跑通最小系统的过程中，最难的部分往往不在代码逻辑，而在“你根本不知道数据到底传没传出去”。现场调试时我的习惯是先做三件事：

第一件事，先拨掉天线，检查发送是否真的发生。很多新手发现数据传不出去，第一反应是去调参数或者怀疑硬件坏了，其实最常见的原因是模块根本没有进入发送状态。接一个调试串口，打印模块状态寄存器的值，确认发送标志位置位。

第二件事，使用频谱仪检查射频输出是否正常，中心频率和带宽是否正确。如果没有频谱仪，就用接收模块反复测试，确认参数完全一致。

第三件事，建立日志机制。无论网关还是节点，所有发送的数据帧都加一个单调递增的序号，并且打印帧内容。这样即使隔着几公里看不到设备，只要网关日志里有对应序号上涨，就说明链路是通的。如果序号跳变，说明有丢包；如果序号重发，说明 ACK 没收到。这一套排查方法几乎能解决 90% 的通信问题。

6. 常见故障排查实录：这些坑，几乎每个人都会踩一遍

做了几年 LoRa 项目，各种怪问题都遇到过。每次排查到最后，原因往往令人哭笑不得。下面我把最常见的几类问题整理成速查表，你在做项目时可以直接对照。

6.1 参数不匹配导致的“能发不能收”

这是最最常见的现象。同样是买了一堆模块，硬件一样、代码一样，但制定连接的两个人各自设置了不同的参数，结果就是发端显示发送成功，收端却毫无反应。参数不匹配包括频率不同、SF 不同、带宽不同、CRC 设置不同、同步字不同等。

排查思路很直接：把所有模块统一恢复出厂默认参数，然后在一个固定频点上做收发测试。确认通了之后，再逐个参数做改动，每改一个参数就收发一轮。这个过程的本质是控制变量，看上去繁琐，但保你不再掉进同一个坑。

6.2 同一频段下的串扰和信道占用

当网内有多个 LoRa 信道时，相邻信道的信号可能互相干扰。特别是带宽设成 250kHz 时，信道间隔必须足够大，否则邻道信号会把接收滤波器搞得很糊涂。

处理办法：规划信道时留足间隔，尽量使用 125kHz 带宽并错开相邻频点。另一招是采用不同 SF 来隔离信道，因为 SF7 和 SF12 的信号是互不干扰的。这在 LoRa 里叫“正交扩频因子隔离”，是一种很实用的调度手段：让不同业务类型用不同 SF，等于把网络分割成多个逻辑信道。

6.3 占空比限制导致的低频监管问题

很多 LoRa 芯片在固件层面会让你设置占空比上限，某些国家的规定要求设备在某个频段上的发射占空比不超过特定比例。如果你把占空比设置成无限制，可能无法通过认证，也可能在正规网络里被视为违规设备。这在正式产品部署前必须确认清楚。

6.4 天线不匹配的隐性损耗

LoRa 模块的射频输出端口一般要求 50 欧姆阻抗匹配。如果使用了错误频段的天线，或者 SMA 接头虚焊，SWR 很高，发射功率会有很大比例被反射回来，效果可能还不如短接一根导线。测量天线驻波比是很有必要的。我在一次现场测试中出现“换了天线信号反而变差”的现象，最后用驻波比表一测才发现，原来那根天线的频段是用在 900MHz 的，用在 470MHz 上效率自然很低。

6.5 ACK 超时和重传的边界情况

私有协议最简单的问题是：节点把 ACK 等超时了，然后重传，但上次的包其实已经到达网关，网关也回了 ACK，只是 ACK 在空口丢了。这样网关会收到两个一样的包，业务层会重复计数。

解决方案有两种。一种是在帧里加序号，网关记录最近收到的序号，重复数据直接丢弃。另一种是应用层做去重，但这要求网关和节点都记录各自状态。强烈建议在链路层就加上去重逻辑，这是最省心的方法。

6.6 环境遮挡和法拉第效应

LoRa 虽然号称穿墙能力强，但那是相对而言。在密集的城市环境中，一栋楼就能让信号衰减很多。以我的一次测试经验：两个节点直线距离 500 米，中间隔了 3 栋楼和一条河，结果完全不通。后来把天线高度从 1.5 米提到 6 米，同一条链路立刻通了。天线高度对 LoRa 的影响比功率还大。现场布点时要尽量提高天线架设位置，减少遮挡，不要过度依赖发射功率去硬扛环境损耗。

7. 最终选型建议：不要被协议堆成山吓住

很多刚入行的人面对 LoRa 组网方案的多样性，第一反应是慌。实际上，选型的逻辑可以收敛得很简单。

如果你只有两个节点、只传简单数据、没有入网概念，那就用点对点透传，几分钟跑通，一个晚上交付原型。这种场景下的过度设计是最大的浪费。

如果你有多个节点，但节点数量在几十个以内、网络封闭、数据是周期性上报，那就用自研星型私有协议。你完全不需要理解 LoRaWAN 那些复杂的入网机制和 MAC 命令，一晚上就能把核心框架写出来，调试也更方便。

如果你的节点数量可能很大、网络要接入平台或第三方系统、后续还有设备远程升级、多区域扩展这些需求，那就直接选 LoRaWAN。它帮你解决了很多你自己短期内无法克服的问题，包括可靠的入网机制、设备生命周期管理、多网关漫游等。它的协议栈确实复杂，但标准化的价值远超过学习成本。

我个人在新项目里的默认偏好是：科研验证和快速原型选择私有协议，产品化和规模化选择 LoRaWAN。这倒不是瞧不起私有协议，而是毕竟产品要考虑后续几年的人员维护成本和生态兼容性。用 LoRaWAN，至少不会因为最早写协议的人离职，整个项目就变成没有人敢碰的黑洞。

最后分享一个技巧，也是我踩过很多次坑之后才总结出来的：无论是私有协议还是 LoRaWAN，链路层都单独写一个“打点函数”。在关键事件发生点上打时间戳，在收包、发包、ACK 超时的时候都记录一次。这个日志平时不开，但只要出问题，远程开启日志，隔天就能定位到问题在哪一跳。这比在代码里堆一堆调试串口有用得多，也是调 LoRa 网络最舒服的一种状态。