做LoRa网关这么久最常被合作方问的一句话是网关正在往下发指令的时候会不会把节点上报的数据顶掉以前我的回答是“会所以要错开时间”。直到接手参考设计项目后才真正把这句话改成了“可以同时收”。这次要分享的就是Semtech官方全双工网关参考设计Full Duplex Gateway Reference Design的架构思路、实测过程以及我们在落地时踩过的坑。如果你正在做网关产品或者终端节点数量多到对下行时延敏感这篇文章里的硬件选型、隔离度计算和联调方法应该能帮你少走不少弯路。先说清楚这里的LoRa是Semtech的低功耗广域网扩频调制技术跟AI绘画、大模型微调里那个LoRA模型只是名字有点像完全不是一回事别一搜资料就跑到模型训练那边去了。1. 全双工网关到底解决了什么问题1.1 半双工网关的“盲区”下行发送时丢上行在传统LoRaWAN网关里单板收发链路是共用的发送下行数据包时接收通路被切走这段时间里节点上报的任何LoRa数据包网关都听不见。这个“盲区”持续多久呢取决于下行包的长度和扩频因子。我们实测过一个典型的20字节下行指令用SF10、125kHz带宽空中时间大约在50到100毫秒。如果网关要下发成百上千个节点的轮询指令盲区会不断累积节点重传概率直线上升。半双工看似只是“错过几十毫秒”但在高密度场景里就是实实在在的丢包。更麻烦的是Class B模式。Class B要求网关周期性发送beacon同时在beacon后的ping槽下发指令。半双工网关在发beacon那一刻上行链路是中断的如果刚好有节点在那个时间点上报数据这一帧就没了。我们在项目里遇到过水表集抄场景网关每天早上集中下发校准指令结果同时段的上行抄表数据总有零星丢失查了半星期才定位到是下行发送窗口和上行采集窗口撞上了。这也是我下决心折腾全双工参考设计的原因。1.2 全双工之后的变化全双工网关本质上是把“下行发送”和“上行接收”两条射频链路彻底分开各自独立工作。参考设计里接收链路始终停留在上行频率持续监听所有协议规定的信道下行链路只在需要发送时工作不会把接收通路打穿。收益非常直观下行指令无论怎么密集发送上行窗口都不会被挤占。实测下来在每2秒一次下行指令的负载下半双工网关的上行丢包率在10%到15%换成全双工参考设计后丢包率降到接近0上行节点的RSSI也没有因为同时发射而明显恶化。这里要强调一下并不是所有LoRa应用都需要全双工。如果只是传感器每隔10分钟上报一次网关几乎不主动下发半双工完全够用。全双工的价值主要集中在两类场景一是下行指令频繁且要求上行数据不能丢二是Class B网络需要周期性发beacon又不能牺牲上行容量。所以先评估自己项目的实际负载再决定要不要上全双工别盲目追新。1.3 为什么说“参考设计”而不是自己硬做参考设计Reference Design这个词在国内厂商眼里容易有点“纸上谈兵”的意思但Semtech这套全双工参考设计是完全可生产的。它把射频链路预算、PCB布局、滤波器选型、天线隔离方案都做成了一套完整方案硬件厂商照着画板子就能做出全双工网关。自己从头拼模块不是不行但射频全双工调试难度很高后面日志计算、隔离度测试、杂散调优这些工作没有几个月的射频经验很难啃下来。直接用官方参考设计相当于把最大的坑先填平了我们只需要关注适配频率和天线部署。2. 全双工参考设计技术原理拆解2.1 自干扰全双工最难过的坎任何无线设备要实现同时收发首先要面对的就是“自己打自己”。网关在发射时发射信号功率可能是14dBm接收机能解调的最小信号却是-137dBmSF12、125kHz。一个14一个-137两者相差151dB。也就是说发射信号即便只泄漏一小部分到接收链路也足以直接淹没正常的上行信号。相当于你在一个很吵的房间里一边用喇叭播放音乐一边要听清几米外朋友的低语任何一个环节处理不好对话就全废了。LoRa虽然扩频增益高但它不是万能药发射信号落到接收机前端也会造成饱和LNA线性度再好的芯片也扛不住这种冲击。所以全双工实现的关键不是芯片有多强而是把发射到接收的泄漏抑制到接收机噪声底以下。参考设计里用到的组合拳是频率分开、滤波阻隔、天线空间隔离、屏蔽腔体。每一项单独拿出来都不稀奇组合在一起从14dBm到-137dBm的151dB差距才真正被填上。2.2 参考设计的核心架构双射频链路Semtech全双工参考设计的硬件架构本质上就是“一发一收”两条独立链路。接收链路用一片SX1302基带芯片加SX1250射频前端专门处理8个上行信道的解调发送链路用另一片SX1302加SX1250射频前端只负责下行数据包的发射。两条链路有各自的天线、滤波器、电源网络共用一颗GPS时钟做PPS同步。为什么用两套完整的SX1302而不是一套芯片内部做收发切换因为SX1302虽然支持多通道解调但单片在同一时刻还是典型的半双工行为在同一瞬间既接收又发射会让基带处理负担过重而且芯片内部的射频开关隔离度有限不如直接用两套硬件物理隔离。参考设计选择“双板”方案虽然成本高一些但性能稳定调试也简单很多。实际项目里我们用两块独立的核心板一块跑接收进程一块跑发送进程互不干扰效果很清晰。2.3 关键指标隔离度、灵敏度和输出功率参考设计文档里有一张链路预算表做了几千次计算后我们能简化成一句经验全双工网关的隔离度预算至少要按“发射功率接收灵敏度10dB余量”来估算。14dBm发射-137dBm接收灵敏度再加上10dB系统余量总隔离需求大概是160dB级别。这个数字靠天线隔离提供一部分靠滤波器带外抑制提供一部分靠屏蔽结构提供一部分各司其职。在实际调测中我们并没有追求把隔离度做到160dB以上的理论值因为发射频段的宽带噪声和杂散远小于主信号功率真正要在意的是“到达接收机输入端的有效干扰功率”只要低于灵敏度加上干扰余量就可以了。但做一个项目级判断时仍然建议把天线端口之间的隔离度目标定在60dB以上再加上接收链路的带通滤波器方案才会稳。灵敏度方面全双工配置下尽可能接近单收链路的标称值如果差得超过3dB就要怀疑发射链路是否泄漏进来了。2.4 为什么不能用普通点半双工网关加一个外部滤波器糊弄有人说半双工网关加个滤波器把上下行频率错开不也能“同时收发”吗理论上行得通但问题是普通半双工网关的射频开关、基带调度和协议栈都是按收发分时设计的。你就算给发射通路加滤波器接收链路在发送瞬间依然会被基带切断软件层根本不给你机会同时收发。此外天线没分开发射信号会通过天线反射回接收端口反射信号和直射泄漏叠加情况更难控制。参考设计的价值就在这里它从软硬件一体角度彻底解决了调度和射频隔离问题而不是靠小打小闹的外围修补。3. 从零搭建全双工网关硬件与关键参数3.1 硬件选型主控、射频板和物料清单如果你不想买现成的全双工整机而是要自己参考官方设计打板物料清单需要认真核对。我们这次搭的是基于SX1302核心板的方案带两套独立射频通路。主控用了树莓派4B系统是Raspberry Pi OS 64位跑lora_pkt_fwd两个实例后来觉得树莓派IO有点紧张换成i.MX8MM开发板才算彻底舒服。物料数量说明SX1302核心板2块一块做RX一块做TXSX1250射频前端4颗每块核心板配2颗用于宽频带接收主控板Linux1块树莓派4或i.MX8MM即可GPS模块1个输出PPS保证双板时间同步腔体带通滤波器2个RX和TX各配1个抑制带外信号限幅LNA1个放在RX前端保护接收链路收发天线2根垂直隔离部署推荐间距≥1米12V/24V电源模块1套给核心板和功放供电纹波要小SX1302相比老款SX1301功耗低了不少抗干扰能力和时钟管理也更好做全双工这种长年状态机切换的场景更合适。SX1250是SX1302配套的收发前端4颗可以覆盖上下行频段。选滤波器时建议选带外抑制60dB以上的腔体滤波器频段要覆盖上下行同时注意插损别让发射功率在滤波器上损失过多。3.2 频率规划上下行信道怎么分配全双工的第一步就是上下行频率必须有足够的间隔。如果上下行用同一个频率点隔离需求几乎无解必须用FDD的思路。参考设计在EU868频段上的做法是让接收链路停在8个常规上行信道比如868.1MHz、868.3MHz、868.5MHz、868.7MHz、868.9MHz、869.1MHz、869.3MHz、869.5MHz下行则单独占用一个频率比如869.525MHz或者870.3MHz和最近的接收信道间隔3到4MHz。间隔越大滤波器的效果越明显我们最终选了870.3MHz做下行实测接收链路受发射影响很小。国内LoRa常用470-510MHz频段配置思路一样在一个授权频段内把上下行分成两个频段中间留出足够保护带宽。特别是CN470有80多个信道可以很从容地划出两块区域。频率规划时还要注意LoRaWAN服务器配置里的tx_freq要和参考设计里发射板的radio频率一致否则协议层会对不上。3.3 天线布局与射频隔离实操天线是参考设计里最容易踩坑的地方。我们一开始把收发两根天线捆在一起结果TX一开RX链路直接饱和上行信息全部CRC错误。后来用网分实测S21参数发现两米内的天线隔离度只有25dB左右远低于需求。调整方案是将RX天线和TX天线垂直分开间距1.5米以上同时把两天线极化方向错开一个垂直极化一个水平极化再在机箱内加一块金属挡板天线隔离度才做到47dB勉强达到设计目标。如果项目现场空间有限两副天线实在没法分太远一定要在RX前端加强带通滤波器和限幅LNA牺牲一点灵敏度的代价换取抗饱和能力。面板上用SMA连接器时注意屏蔽层接地要短不能形成地环路。射频线尽量用质量好的同轴电缆减少外部耦合。我在测试时发现同轴线缆若没有固定牢发射时线缆抖动反而会引起接收端频谱毛刺这些都是非常容易被忽略的细节。3.4 系统同步GPS PPS的重要性LoRaWAN网关普遍依赖GPS PPS来做时间同步全双工网关因为有两套独立SX1302只要有一块板时间漂移上下行时隙就会出现偏差。参考设计里会要求把GPS的PPS信号分发给两块SX1302核心板同时软件里也要配置好时间同步参数。我们最开始只是把GPS串口接到RX板TX板靠NTP对时结果Class B beacon发出去后节点经常收不到因为TX板PPS和RX板对不上。后来从GPS模块把PPS用一对同轴线同时接到两板问题才解决。实际部署时在网关开机后等GPS锁定通常30秒到1分钟再启动两个LoRa进程如果不锁定时间源不准全双工时隙会整体漂移。为了省成本想用网络时间同步替代GPS从工程角度看并不推荐PPS精度是毫秒级LoRaWAN beacon对时间同步要求很高网络对时抖动太大会直接影响下行时隙。4. 软件配置与联调实录4.1 HAL软件环境搭建软件上我们跑的是Semtech官方sx1302_hal。流程是拉代码、编译、改配置。主控系统建议用标准Linux发行版树莓派OS或Ubuntu Server都行先把依赖装好再编译。git clone https://github.com/Lora-net/sx1302_hal.git cd sx1302_hal make -j4编译成功后重点修改包里的global_conf.json.sx1250.EU868。这块文件配置了radio_0、radio_1的频点、带宽和收发模式。在全双工架构里接收板的radio_0和radio_1都用于接收发送板的radio配置则要单独设置一个固定发射频点。把下行频率填成我们规划好的870.3MHz并设置对应的发射参数{ SX1302_conf: { radio_0: { enable: true, freq: 870300000, bandwidth: 125000 } }, gateway_conf: { tx_freq: 870300000, lora_multi_sf: true } }这里要特别注意发送板的radio_0和接收板的radio_0不是同一个硬件配置时要分开修改不能直接拷贝同一份JSON。改完保存后用./lora_pkt_fwd -c global_conf.json分别启动两个进程。4.2 两个进程怎么配合RX板和TX板是硬件上完全独立的两块SX1302各自挂SPI、各自跑一个lora_pkt_fwd实例。RX板进程监听上行把收到的数据通过Semtech UDP协议发给LoRa服务器TX板进程负责从服务器的下行队列里取数据再通过射频发射。为了操作方便我用两个systemd服务管理systemctl enable lora_rx systemctl enable lora_tx启动顺序要注意先等GPS锁定再启动RX最后启动TX。如果TX先启动发射链路在一开始就把接收链路压住后面RX启动后灵敏度会很低而且日志里看不到明显报错很容易误判成硬件问题。我们在调测时吃过这个亏花了半天才发现启动顺序影响了接收性能。4.3 下行与上行并行测试测试方案我们做了两层。第一层用一个LoRa节点每5秒上报一次位置网关同时每2秒发一次下行指令观察上行上报是否丢失。第二层用Class B设备网关持续发送beacon同时让节点在任意上报窗口上传数据看beacon是否影响上行接收。实测数据对比如下表所示环境为室内单网关节点距离网关50米左右节点使用SF10测试场景半双工网关全双工网关每2秒发送1次下行上行丢包率10%15%0%1%每10秒发送1次下行上行丢包率3%5%0%连续发送下行上行RSSI变化波动大偶发饱和稳定波动小于1dB全双工模式下下行发射频率是870.3MHz上行接收频率在868.1MHz附近两者的频率间隔明显减轻了接收链路压力。测试时我们同时用频谱仪观察接收前端信号确认发射信号没有导致接收饱和。4.4 下行指令测试脚本网关和服务器之间跑的是Semtech packet forwarder协议。测试下行最简单的方式是在本地写一个小脚本向网关的1700端口发一条PULL_RESP消息里面带上TXPK字段。不过协议报文封装比较容易出错我的建议是先用ChirpStack网关桥把网关接入ChirpStack Server然后用ChirpStack提供的MQTT接口下发一个Uplink测试包网关收到后就会转换成下行射频包发出。脚本级别就不放完整代码了但核心思路很清晰通过MQTT往application/xxx/device/yyy/command/down主题发一条JSON包含fPort、data、confirmed等内容网关桥会自动转成下行包。我们用这个方法很快验证了全双工模式下多个节点同时收下行指令、同时上报上行数据的行为。5. 实际过程中踩过的坑与排查方法5.1 发射一开远端节点上报全丢这是最经典的自干扰症状。现象是半双工模式下一切正常一旦把发送链路打开接收链路好像“瞎了”。排查时先用频谱仪看RX天线口的接收信号频谱如果发现发射频率附近有强信号泄漏进来基本就是隔离度不足。我们当时把收发天线从0.5米拉开到1.5米再加了一块金属挡板问题明显缓解。如果天线怎么调都没用就要检查RX滤波器是否选型不对带外抑制不够。5.2 下行指令发出去节点收不到节点能上报却收不到下行这种问题的原因往往在发射链路配置。我们在测试中发现发送板radio的tx_freq配置被default模板覆盖成869.5MHz而服务器下发的下行频率写的是870.3MHz两边对不上节点自然收不到。排查方法是先在网关上用频谱仪确认发射中心频点再对照LoRaWAN服务器里的下行频率两边必须一致。还有一种情况是PPS未锁定导致时隙漂移beacon和ping发射的时间点和节点期望对不上。我们最终确认GPS锁定后再启动发送进程问题才消失。5.3 上行接收灵敏度比单收低了很多全双工配置下接收灵敏度比半双工恶化3dB以上我建议先检查发射通路是否引入了噪声。测试方法将发射通道关闭测量接收灵敏度再开启发射同样测一遍。如果恶化明显把发射功率降一些再看如果RSSI恢复说明是发射功率泄漏导致了接收机饱和。进一步的方案是提高天线隔离度或者在RX链路前端加一个带通滤波器但要注意滤波器插损不能太大否则灵敏度反而受伤。5.4 双板时间不同步导致的Class B异常使用Class B网络时网关需要周期性发送beacon。我们试过没有把GPS PPS同步到两块SX1302板结果beacon和节点的接收窗口一直在微秒级漂移节点入网后经常掉线。解决方式就是前面说的将同一路PPS同时接到两块板确认锁定后再启动LoRa进程。另外建议网关接入服务器后查看服务器的网关统计信息如果出现很多CRC错误或时间戳异常大概率是时间同步问题。5.5 常见问题速查表问题现象可能原因检查与解决上行全部丢失发送时有强干扰收发天线隔离度不足增加天线间距、金属挡板测S21隔离度节点能上报但收不到下行频率配置不一致核对tx_freq与服务器下行频率接收灵敏度比单收低3dB以上发射泄漏导致接收饱和检查RX滤波器、限幅LNA、天线隔离Class B beacon漂移GPS PPS未同步到双板等GPS锁定PPS接到两块SX1302进程启动后接收异常启动顺序不对先GPS锁定再RX最后TX发射功率偏低滤波器插损太大换低插损腔体滤波器检查线缆损耗6. 扩展应用与个人体会6.1 哪些场景值得上全双工全双工网关最打动我的场景是工业协议转换。现场仪表通过Modbus网关接入LoRa网络控制器需要实时下发指令同时传感器又在上报运行状态。半双工网关遇到一次下行发送丢一个上行帧控制逻辑就可能误判设备状态。全双工方案下下行指令和状态上报可以并行系统实时性提升非常明显。另一个典型场景是中继或星型级联。如果网关同时还要承担转发功能半双工时隙一旦被打满网络吞吐量直接下降。全双工参考设计让中继在接收上一级指令的同时仍可向下一级节点发送下行数据整个网络的时延降低不少。6.2 成本与性能的平衡建议全双工不是白拿的。两块SX1302核心板、双天线、双滤波器BOM成本比普通半双工网关贵了不少调试时间也会增加。我的建议是项目初期先做时域分析和负载模拟如果半双工网关的下行盲区累积后丢包率能控制在目标范围就不必上全双工如果丢包率超标或者Class B网络下beacon发送频率太高再考虑全双工方案。6.3 参考设计落地后的一点个人体会最后分享一个很实际的建议不要一上来就按参考设计画12层PCB先买两套第三方的SX1302核心板或者官方开发套件把默认固件跑通把全双工的链路预算、频谱、隔离度都量一遍再决定要不要自己开板。全双工网关留给我们的容错空间没有半双工那么大任何改动都建议一次只动一个变量别同时改频率、天线、滤波器和供电。在我自己踩过这么多坑之后最大的感受是LoRa全双工并不是什么黑魔法它就是“频率规划、滤波隔离、天线布局、时间同步”这四件事的组合。参考设计把这些办法的框架给定死了剩下的工程化功夫还得靠自己做。当前这套方案在项目里用了将近一年运行很稳定也让我对LoRa网络的实时性信心提升了一大截。如果你正准备做全双工网关建议先把隔离度预算算清楚再动手能省一半调试时间。