2、网关系统架构：LoRa网关的硬件组成与软件分层
好，咱们接着聊。上一章我们把LoRa网关的定位和基本概念理清了。这一章，我带你拆开网关看看里面到底有什么，以及这些硬件是怎么协同工作的。
说白了，网关就是一个“翻译官”加“快递员”。它要把LoRa终端那些微弱的、低速的信号收上来，然后转成咱们熟悉的以太网或者4G信号，发到云端去。反过来也一样。所以它的硬件和软件设计，都得围绕这个核心任务来。
2.1 硬件组成：三大核心模块
一个典型的LoRa网关，硬件上可以分成三块：主控、射频模块、回传模块。我习惯把它们比作“大脑”、“耳朵”和“嘴巴”。
2.1.1 主控：网关的大脑
主控芯片负责调度一切。它要跑Linux系统，管理射频模块，处理网络协议栈，还得跑你的业务应用。
常见选型：
- ARM Cortex-A系列：比如NXP的i.MX6ULL、TI的AM335x。性价比高，生态成熟。我个人比较喜欢i.MX6ULL，功耗低，做单通道网关绰绰有余。
- ESP32：适合极简的、实验性质的网关。但说实话，它的处理能力和内存跑完整协议栈有点吃力，我一般只用在原型验证阶段。
- 树莓派：开发调试神器。但工业场景下，它的稳定性和宽温范围是个问题。我见过有人拿树莓派做产品，结果夏天户外一晒就死机。
2.1.2 射频模块：网关的耳朵
这是LoRa网关最核心的部分。它负责接收和发送LoRa信号。
关键器件：
- SX1301/SX1302/SX1308：这是Semtech公司的LoRa基带芯片。它才是真正的“多通道”核心。SX1301是经典款，SX1302是升级版，功耗更低，灵敏度更好。我最近的项目都换SX1302了。
- SX1255/SX1257：这是射频前端芯片，负责把基带信号变频到射频。通常一颗SX1301配两颗SX1257，实现8个通道同时接收。
- 功率放大器（PA）和低噪声放大器（LNA）：PA负责发射，LNA负责接收。嗯，这里要注意，发射功率不是越大越好。国内法规限制，LoRa的发射功率一般不能超过17dBm（约50mW）。
为什么需要8个通道？ 你想想看，如果只有一个通道，那同一时间只能处理一个终端的数据。如果几百个终端同时上报，不就堵死了吗？8个通道可以同时监听8个不同的频率，大大提升了网络容量。
2.1.3 回传模块：网关的嘴巴
网关收到数据后，得想办法传到服务器。这就是回传模块的工作。
两种主流方案：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 以太网（RJ45） | 稳定、带宽大、延迟低、成本低 | 需要布线，部署位置受限 | 工厂、仓库、楼宇等有网线的地方 |
| 4G/5G模块 | 部署灵活，不受地域限制 | 需要SIM卡、有流量费、延迟稍高 | 野外、农业、油田等无网线场景 |
我个人建议，设计网关时最好同时保留以太网和4G接口。以太网作为主链路，4G作为备份。一旦网线断了，自动切换到4G。我在一个智慧农业项目里就这么干的，客户说“这功能救了大命了”。
2.2 软件分层：从底层到应用
硬件搭好了，就像盖好了毛坯房。软件就是里面的装修和家具。一个好的软件架构，能让你的网关稳定、易维护、可扩展。
我习惯把软件分成三层：驱动层、协议栈、应用层。每一层各司其职，层与层之间通过标准接口通信。
2.2.1 驱动层：让硬件“动”起来
驱动层是软件和硬件之间的桥梁。它负责初始化硬件、收发数据、处理中断。
主要工作：
- SPI驱动：主控通过SPI总线与SX1301通信。需要配置时钟、极性、相位。我记得第一次调SPI驱动时，因为时钟极性搞反了，读回来的数据全是0xFF，折腾了一整天。
- GPIO驱动：控制射频模块的复位、使能引脚。
- USB驱动：如果4G模块是USB接口的，需要驱动USB子系统，并让系统识别出4G模块为网络设备。
- 网络接口驱动：驱动以太网PHY芯片，比如LAN8720。
在Linux下，这些驱动通常已经在内核里了。你需要做的就是配置设备树（Device Tree），告诉内核你的硬件是怎么连接的。
// 一个简化的设备树片段，描述SPI连接的SX1301
&spi1 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi1>;
sx1301: sx1301@0 {
compatible = "semtech,sx1301";
reg = <0>;
spi-max-frequency = <20000000>; // 20MHz
reset-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
};
};
spi-max-frequency不要设得太高。SX1301的极限是20MHz，但实际布线不好时，10MHz都可能出错。我一般保守地设成8MHz，稳定第一。
2.2.2 协议栈：让数据“通”起来
驱动层之上，是协议栈。它负责把LoRa的原始数据包，封装成符合LoRaWAN标准的帧格式，并处理MAC层的各种逻辑。
核心功能：
- LoRaWAN MAC层：处理Class A/B/C的时序、确认重传、信道访问等。这部分很复杂，但好消息是，你不用自己写。Semtech提供了开源的LoRaWAN协议栈，比如
lora-gateway和packet-forwarder。 - Packet Forwarder：这是网关上的核心程序。它负责把射频模块收到的LoRa数据包，通过UDP协议转发到网络服务器（比如ChirpStack、TTN）。反过来，也把服务器下发的数据包转发给射频模块。
- Semtech UDP协议：这是网关和网络服务器之间的标准通信协议。它定义了数据包的格式、端口号、心跳机制等。
说白了，Packet Forwarder就是一个“二传手”。它自己不解析数据内容，只负责搬运。数据内容由网络服务器和应用服务器去处理。
2.2.3 应用层：让业务“跑”起来
最上层是应用层。这里才是你发挥创造力的地方。
你可以做的事情：
- 本地数据处理：比如，对传感器数据进行简单的过滤、聚合、阈值判断。如果温度超过50度，直接本地报警，不用每次都上报云端。
- 本地配置管理：提供一个Web界面，让用户可以配置网关的WiFi、4G参数、修改服务器地址等。
- OTA升级：实现远程固件升级功能。我做过一个项目，网关部署在深山老林里，没有OTA的话，升级一次得开车跑几百公里。
- 边缘计算：在网关上跑一些轻量级的AI模型，比如设备故障预测。当然，这对主控的性能有要求。
应用层通常用C、Python或者Node.js来写。我个人偏爱Python，开发效率高。但如果是性能敏感的场景，比如实时控制，那还是得用C。
好了，这一章我们拆解了网关的硬件和软件架构。下一章，我会带你亲手搭建一个最小系统，把Packet Forwarder跑起来。到时候你就知道，这些理论知识是怎么落地的了。