简介lora_gateway-master.zip 是一份基于 Semtech SX1301 的 LoRa 网关完整源码工程面向物联网开发者、嵌入式工程师与 LPWAN 技术爱好者。该工程覆盖 LoRa 网关核心功能包括多信道数据接收、数据转发、LBT 频谱检测以及与网络服务器的对接并自带数据包记录、发射测试、频谱扫描等实用工具有助于快速搭建和调试自己的 LoRa 网关。压缩包共 65 个文件大小约 225KB其中 20 个 C 源码与 14 个头文件构成网关逻辑主体8 个 Makefile 支撑多模块编译3 个 hex 文件为 FPGA 配置固件另有 JSON 配置、Markdown 文档、Shell 脚本及 LICENSE 等目录按功能划分便于检索。通过研读源码可掌握 LoRaWAN 通信协议在网关侧的落地方式、射频板控制逻辑与信道参数配置对自建 LoRa 网络或进行协议二次开发极具参考价值。已有 626 人浏览下载适合希望深入理解 LoRa 网关工作原理并开展实际项目的读者。1. LoRa网关源码包一份能跑通的SX1301网关实现到底值多少拿到lora_gateway-master这套源码时多数人的第一反应是翻目录、找readme然后卡在“代码能编译但网关不工作”的尴尬上。实际拆过之后我的结论是这份资源真正的价值不在那几行Makefile而在它把SX1301基带芯片的驱动、FPGA固件、多信道配置、频谱扫描工具全部打包成了一个可闭环验证的系统。对正在选型LoRa网关方案、或者想用ASR6500/SX1301这类芯片自己攒网关的开发者来说它能省下好几周的底层调试时间。适合两类人一类是刚接触LoRaWAN、想看清楚网关内部怎么转发数据的入门者另一类是做产品原型、需要快速验证频点和信道规划的硬件工程师。2. 源码目录拆解libloragw核心库、调试工具链、FPGA固件的分工2.1 libloragw网关和SX1301之间的唯一通道整套源码里最重要的不是网关主程序而是libloragw这个静态库。它封装了所有对SX1301芯片的操作SPI读写、寄存器配置、数据包收发、定时器校准。网关的上层应用不直接操作芯片而是通过这个库的API完成初始化、配置和收包。核心API大致分三组初始化与复位lgw_reset()、lgw_connect()负责把SX1301从复位状态拉起来建立SPI连接。配置接口lgw_config()把信道频率、调制参数、扩频因子写入芯片寄存器。数据面lgw_receive()、lgw_send()轮询接收数据包或发送下行数据。在libloragw的inc目录里能看到lgw_hal.h和lgw_helpers.h两个头文件前者定义硬件抽象层后者封装了配置文件解析逻辑。调试时最常用的是lgw_receive()它返回一个struct lgw_pkt_rx_s结构体里面包含信道编号、RSSI、SNR、CRC状态、payload长度和内容。看timers子目录时容易被忽略。SX1301内部有个实时时钟网关依赖它校准收发时间戳。lgw_timers里实现了基于clock_gettime的软件校准机制如果目标平台没有高精度时钟上行包的timestamps会乱直接导致网络服务器无法计算星历时间。这个坑后面细说。提示libloragw默认编译成静态库链接时把libloragw.a和你自己的网关程序编在一起。如果想动态加载配置记得在编译时加上-DDEBUG_LOG之类的宏否则很多关键日志会被优化掉。2.2 util_*工具包每个工具解决一个现场问题这套源码里的工具链是真正值钱的部分。它们是调试网关时最趁手的武器README里没细写但实际用起来各有各的定位工具名用途适用场景util_spi_stress对SX1301做连续SPI读写压力测试排查硬件接线、SPI速率、电平不匹配util_pkt_logger持续监听所有信道打印收到的LoRa包验证网关能否收到节点数据看RSSI/SNRutil_tx_continuous连续发射LoRa信号测试发射链路、配合频谱仪看输出功率util_tx_test单次发送指定payload验证下行链路和节点接收util_spectral_scan扫描信道范围内的频谱能量分布现场选频、找干扰源util_lbt_testListen Before Talk测试验证LBT机制和信道空闲检测阈值故障排查时的标准路径一般是先跑util_spi_stress确认硬件通再用util_pkt_logger确认收包链路最后才轮到自己的业务代码。很多人一上来就编译主程序发现收不到包然后开始怀疑天线、芯片、供电其实util_pkt_logger跑两分钟就能定位问题出在哪一层。util_spectral_scan是最容易忽视的一个工具。它能扫描整个工作频段内每个频点的能量值输出按频点排序的表格。现场部署时这玩意比频谱仪还好使——网关自己就能当频谱仪用扫完一轮就知道哪个信道干净。2.3 fpga/目录与global_conf.json固件和配置怎么对应fpga/目录下有三个hex文件这是新手最容易踩坑的地方SX1301_FPGA_200K_NOTCH_LBT_SPECTRAL_SCAN_863_v33.hex SX1301_FPGA_200K_NOTCH_LBT_SPECTRAL_SCAN_915_v33.hex SX1301_FPGA_NOTCH_PROG_SPECTRAL_SCAN_v31.hex注意命名规律863 vs 915工作频段。863对应欧洲868MHz频段915对应北美915MHz频段。国内用470-510MHz的话这两个固件都不直接适用得找对应频段的固件或者改配置。200K_NOTCH200K带宽的陷波滤波器使能。如果你的网关用了8通道1个高灵敏通道的配置这个参数影响相邻信道抑制能力。v33 vs v31固件版本。v33较新修正了一些LBT模式下FPGA时序问题。SPECTRAL_SCAN支持频谱扫描功能。没有这个特性的固件跑util_spectral_scan会报错。固件和配置文件的对应关系是global_conf.json里指定了radio_0和radio_1的频率范围FPGA固件决定射频前端的工作模式。两者不匹配时表现是能初始化但收不到任何数据包。选固件的通用准则是先看你的目标频段再看是否需要LBT和频谱扫描最后选版本号高的。3. 编译与部署从Makefile到global_conf.json的落地步骤3.1 编译前的环境检查依赖、权限、udev规则这套代码的编译依赖很少核心就是gcc和make但它强依赖目标平台的SPI接口实现。两种常见连接方式一种是SX1301直接挂在CPU的SPI总线上另一种是通过FTDI的USB转SPI芯片连接。仓库里的99-libftdi.rules是给FTDI方案的udev规则负责给USB设备设置权限。编译前先确认三件事你的平台有没有libm、librt没有的话Makefile里要手动加-lm -lrt。编译工具链是gcc还是交叉编译器如果是交叉编译libloragw/Makefile里的CC变量要改成你的交叉编译器路径。SX1301的复位引脚接在哪个GPIO上这个不在代码里而在reset_lgw.sh脚本里。reset_lgw.sh内容大致是做三件事拉低复位引脚、等一段时间、拉高复位引脚。有的版本还包含SPI速率切换。这个脚本在每次网关启动前必须执行否则SX1301处于未知状态。注意如果你用的是FTDI方案的USB转SPI先把99-libftdi.rules复制到/etc/udev/rules.d/并重载udev规则否则非root用户跑工具会报Permission denied。3.2 编译libloragw与工具链的命令序列编译顺序有讲究先libloragw再工具链因为工具链全部链接这个静态库。正确顺序如下# 1. 编译libloragw生成libloragw.a cd libloragw make clean all # 如果目标平台是ARM先修改Makefile里的CC cd .. # 2. 编译util_pkt_logger cd util_pkt_logger make cd .. # 3. 编译util_spi_stress cd util_spi_stress make cd .. # 4. 编译util_spectral_scan cd util_spectral_scan make cd ..这里的make clean all是官方Makefile的约定目标先清理再编译可以避免旧编译产物干扰。交叉编译时重点检查libloragw/Makefile里的CFLAGS默认是-O2 -Wall如果目标平台是ARM Cortex-M系列建议加上-mfloat-abihard -mfpufpv5-sp-d16之类和硬件浮点单元匹配的选项否则SX1301的FFT运算性能会差很多。关于SPI速率SX1301支持最高大约8MHz的SPI时钟但实际能跑多快取决于你的线长、电平转换芯片和PCB布局。常见做法是先按1MHz调试确认没问题再逐步往上提。修改SPI速率一般在libloragw/src的spi相关代码里把SPI_SPEED_HZ宏改掉然后重新编译。3.3 写global_conf.json和local_conf.json的要点这套源码使用两个配置文件理解它们的优先级关系是能否跑通的关键global_conf.json定义radio硬件参数和默认信道组。local_conf.json覆盖global_conf里的部分字段通常用于部署时按现场环境调整。一个典型的global_conf.json核心字段如下{ SX1301_conf: { lorawan_public: true, clkout: 1, full_duplex: false, radio_0: { enable: true, freq: 868100000, type: SX1257 }, radio_1: { enable: true, freq: 868300000, type: SX1257 }, chan_multiSF_0: { enable: true, radio: 0, if: -500000 }, chan_multiSF_1: { enable: true, radio: 0, if: 700000 } }, gateway_conf: { server_address: 127.0.0.1, server_port_up: 1700, server_port_down: 1700, keepalive_interval: 10, stat_interval: 30, forward_crc_valid: true, forward_crc_error: false, forward_crc_disabled: false } }radio_0和radio_1是SX1301的两个物理射频前端每个前端可以承载多个虚拟信道chan_multiSF_*。if字段是中频偏移单位是Hz表示该信道相对radio中心频率的偏移量。gateway_conf里的server_address如果写的是127.0.0.1表示网关和网络服务器跑在同一台机器上。实际部署时改成服务器的局域网或公网IP。forward_crc_valid这个字段决定是否把CRC校验成功的包发给服务器调试时建议保持true上线前根据业务决定要不要转发错误包。local_conf.json的覆盖机制是这样的工具链启动时会先读global_conf.json再读local_conf.json如果local里出现了同名字段就覆盖global的值。调试时常用local把server_address临时改成测试服务器不动全局配置。3.4 启动网关与检查运行状态配置写好后启动网关的标准流程是# 1. 复位SX1301芯片 ./reset_lgw.sh start # 2. 用util_spi_stress验证SPI通信 ./util_spi_stress # 3. 启动数据包监听验证能收到节点数据 ./util_pkt_logger -c global_conf.jsonutil_pkt_logger跑起来后如果看到类似Received packet from radio的日志且后面跟着RSSI和SNR值说明链路已经通了。如果看到ERROR或超时类信息优先检查SPI连接和复位时序。关于util_pkt_logger的-c参数指定配置文件路径不指定的话默认读当前目录的global_conf.json。建议显式指定路径因为很多人会在多个目录间切换编译。提示跑工具前先确认当前用户对SPI设备节点有读写权限。Linux下一般是/dev/spidevX.0用ls -l /dev/spidev*查看FTDI方案则是/dev/ttyUSB0或/dev/ftdi*。权限不对时工具会报Cannot open SPI device但不会提示缺权限很容易误导排查方向。4. 避坑记录SPI通不上、固件烧错、配置覆盖失效的五条血泪经验这章写的是实际拆这套源码时踩过的坑。每一条都按“现象→原因→解决”的路径记录希望你能绕开。4.1 现象reset_lgw.sh执行后网关无响应跑reset_lgw.sh start后没有任何输出util_spi_stress直接报设备找不到。网上很多教程说的是“检查驱动”但实际原因往往更简单reset_lgw.sh里复位引脚拉低的时间不够。SX1301的复位时序要求复位信号保持低电平至少10ms然后拉高后至少要等50ms芯片才进入可配置状态。很多板子的参考脚本只等了5ms跨平台移植后时序更容易出问题。解决方案是修改reset_lgw.sh中的usleep和sleep参数把拉低时间改到20ms、拉高后等待时间改到100ms。改完再跑问题通常会消失。4.2 现象util_spi_stress连续报SPI超时SPI压力测试跑到一半报SPI transfer timeout时好时坏。原因是SPI时钟速率设置过高或者杜邦线连接过长导致信号完整性差。SX1301的SPI逻辑本身能跑8MHz但很多人用的是面包板加杜邦线的方式线长超过15cm后信号畸变就明显了。解决方法是把SPI速率降到1MHz或2MHz同时把线距压缩到最短。如果必须长距离走线需要加电平转换缓冲器单纯降速率是治标不治本。这个坑的判断标准很清晰降速率后症状消失升回去又复现那就是信号完整性问题。4.3 现象频谱扫描工具报固件不支持util_spectral_scan跑起来后报Firmware does not support spectral scan。原因是烧录的FPGA固件不支持频谱扫描功能。仓库里三个hex文件版本不同只有命名里带SPECTRAL_SCAN的固件才支持这个功能。v31和v33的主要差别就在LBT时序和频谱扫描的稳定性上。解决方法是改用v33版本的固件如果是863频段用863版本915频段用915版本。换固件的操作一般是把hex文件通过FPGA配置接口烧进去具体方式和你的板子有关。如果是自己画的板子检查FPGA配置引脚是否正确上拉到配置模式。4.4 现象local_conf.json改了不生效修改local_conf.json的频点后用util_pkt_logger查看实际工作频点没变改了个寂寞。原因是配置文件格式错误时代码会静默回退到默认配置而且不会报错。具体来说lgw_config函数在解析JSON时遇到未知字段或者类型不匹配的字段会直接返回LGW_CONFIG_ERROR但很多工具的main函数忽略了返回值导致配置加载失败后网关按默认参数运行。解决方法是每次修改配置后在工具源码的main函数里加上对lgw_config返回值的检查。关键是让配置错误“发声”而不是默默吞掉。这个习惯养成了能省掉大量排查时间。4.5 现象FTDI方案的网关在非root用户下跑不了用普通用户跑工具报Cannot open USB devicesudo跑能通。原因是99-libftdi.rules没有正确安装或者USB设备ID不在规则匹配范围。99-libftdi.rules的默认匹配是FTDI FT2232H/FT4232H这两颗常用芯片正确安装后设备节点会出现在/dev/下组权限是plugdev。如果自己的板子用的是FTDI的FT232H需要改规则文件里的idVendor和idProduct字段。注意FTDI芯片的假冒问题比较常见便宜的模块可能用的是国产兼容芯片这种在Windows下能用Linux下FTDI驱动不一定认。排查这类问题时可以用lsusb看设备描述符如果Vendor ID不是0403直接换模块。5. 进阶用法用util_spectral_scan做现场频谱勘测和LBT参数调优工具链里最容易被低估的是util_spectral_scan。大部分教程只讲怎么收包但网关部署最耗时的是选频点和验证干扰。这个工具能直接输出每个频点的能量分布比拿频谱仪跑到现场测量快得多。标准用法是把信道范围内的频段分成若干步长逐个扫描能量值# 扫描860-870MHz范围步长200kHz ./util_spectral_scan -c global_conf.json -f 860000000 -t 870000000 -s 200000扫描完成后输出一组按能量排序的频点。能量最低的频点就是最干净的信道优先把multiSF信道分配在这些频点附近。如果扫描结果里某个频点持续有高强度信号说明现场存在干扰源应该避开。LBTListen Before Talk模式是另一个值得深入的功能。在频谱资源紧张的场合网关在发射前会先检测信道是否空闲。util_lbt_test这个工具就是干这个的# 测试LBT机制设置空闲阈值-80dBm观察发射行为 ./util_lbt_test -c global_conf.json -r 0 -t -80这里的-r 0指定radio 0-t -80表示信道能量低于-80dBm才认为空闲。如果现场底噪偏高这个阈值要相应调高否则网关会一直认为信道忙下行包发不出去。调优时有个实用技巧先跑util_pkt_logger收集一段时间的RSSI数据统计底噪基线然后在此基础上把LBT阈值抬高6-10dB作为安全裕量。这样既保证不撞车又不会因为阈值太严而卡死发射链路。频谱扫描加LBT这两个工具组合起来基本能应对现场部署的选频和干扰排查需求。从那以后我每次部署网关都强制走一遍这三步先跑util_spi_stress确认硬件再用util_spectral_scan选频点最后用util_lbt_test验证发射链路。这套流程虽然简单但确实帮我避开了不少看似玄学、实为配置错误的坑。希望帮到你。本文还有配套的精品资源点击获取
