说实话写“LoRa (Part 2)”之前我心里还挺没底的。上一篇我们把LoRa的调制原理、扩频因子、带宽这些基础概念过了一遍讲的时候特别怕讲成教科书。但这篇不一样这篇我打算换个打法——直接聊实测、聊调板子、聊低功耗波形怎么看顺便把那些文档里根本不写的坑都翻出来。我玩LoRa也有几年了从最早的SX1276到后来的SX1262前前后后做过几版节点和网关。中间踩过的坑比某些教程写的步骤都多。这篇接着往下写适合两类人一是看完上一篇正准备自己画板子的二是板子画完了但死活调不通、功耗测出来不对劲的。如果你是纯小白建议先花十分钟把扩频因子和带宽的概念搞明白不然下面很多参数你会看得一头雾水。1. 先搞懂LoRa物理层参数组合不是越大越好1.1 SF、BW、CR一组互相拉扯的旋钮很多人把LoRa的灵敏度数据背得滚瓜烂熟比如SX1262能做到-137dBm但一到实际配置就乱了。原因在于SF、BW、CR这三个参数是互相牵制的不是单独调的。扩频因子SF决定每个bit用多少chirp符号表示带宽BW决定chirp扫频的速率编码率CR决定加多少纠错冗余。三者拧在一起才得到最终的数据速率和灵敏度。我的习惯是先定带宽再定SF最后看情况调CR。为什么带宽直接决定占用频段宽度在国内常用的470-510MHz频段125kHz带宽是有明确定义的250kHz和500kHz也能用但信道占得宽接收机底噪也会抬升灵敏度反而掉。所以低功耗广域网场景里125kHz是绝对主力。SF是距离和速率的主要调节旋钮SF7速率最高SF12灵敏度最好、速率最慢。CR影响相对小在信噪比环境差的场景里调高一点比如4/6、4/8能换回来一些可靠性。以前我做过一组对比实验同样的两个节点一个配SF7/BW125/CR4/5一个配SF12/BW125/CR4/8在同一个位置接收。前者速率大概是5.47kbps后者只有0.29kbps差了接近19倍。但后者的接收灵敏度比前者好约14dB。这意味着在强度较弱的边缘区域SF12能收到SF7就彻底没戏。所以每次有人问我“到底用SF几”我的回答都是先问需求你要传多大数据多久传一次如果每次只传一个温湿度一分钟一次那速率再低也无所谓直接上SF11、SF12换距离。1.2 前导码、同步字、CRC平时不起眼却决定成败的细节参数里除了SF/BW/CR还有三个细节特别容易被忽略但它们经常就是联不通的元凶。第一个是前导码Preamble。LoRa的前导码是接收机用来同步和锁频的发送端会在每个包前面自动发一串。SX126x默认的前导码长度是8个符号范围可以从6到65535。前导码太长空口时间就长接收机每个周期醒来扫描的时间也变长功耗直接上去太短的话接收机还没完成频率对齐数据就开始了。我自己在低功耗场景里一般用8个符号正好是接收机CAD模式能稳定检测到的最短长度。如果发现两个模块距离不远但一直丢包查一下前导码配置是不是被改成4或者更小了。第二个是同步字Sync Word。LoRa的同步字可以理解成一个网络的“暗号”只有发送端和接收端同步字一致接收机才会认定这是有效数据。SX127x系列默认是0x12SX126x系列默认是0x1424这是Semtech为了区分新旧芯片故意改的。很多人在SX1276和SX1262混用的时候翻车就是因为同步字不匹配。另外如果你在同一地方跑两套LoRa网络可以分别设置不同的同步字来物理隔离干扰。方法很简单但很多人不知道。第三个是CRC。LoRa的包头里有CRC校验分头部CRC和载荷CRC两级。SX126x配置里通常默认开。我曾经为了省几个字节把载荷CRC关掉结果就是信号一弱收到的全是乱码还排查了半天编码问题。CRC开销不大但能省掉的修复成本远超想象。结论就是CRC永远开着别关。2. 硬件布局与射频入门信号能不能发出去大半在板子上2.1 模块选型SX126x、SX127x与国产芯片怎么选写代码的人可能觉得芯片就是一堆寄存器的组合但实际画板子和选型的时候差别大到你怀疑人生。SX127x是Semtech的老一代产品FIFO管理比较繁琐发射电流偏高但好在资料多、例程多、社区成熟。SX126x是新一代最大的改进是用起来更顺手——支持DIO2控制射频开关、DIO3控制TCXO外部电路反而更简洁接收电流也低一些还在低功耗模式下多了不少细节优化。如果你正在设计新板子我建议优先上SX1262/1268别再用SX1276了。国产芯片这几年也追上来了比如ASR6501、LLCC68这种。ASR6501是集成MCU的方案省了一颗主控但外设和GPIO自由度有限适合功能固定的场景。LLCC68是SX1261的国产兼容版只有LoRa模式、不带FSK价格却低不少。我的态度是自己学习做项目可以用国产兼容的如果是产品化、跑量也可以用但必须先做完整的兼容性测试尤其是频率精度和发射杂散这两项部分国产模块做得很一般。2.2 布局、匹配电路与天线选择射频这部分水很深但基础要点就几条。第一晶振远离天线和射频走线。LoRa模块通常需要32MHz晶振和32.768kHz RTC晶振很多板子为了省面积把晶振紧贴天线区域结果就是频率被干扰、灵敏度掉几个dB。我的原则是晶振放芯片一侧天线走线放另外一侧中间用地过孔隔开。第二电源去耦必须跟上。发射电流峰值可以到120mA以上如果电源去耦不好发射瞬间电压跌落轻则频谱发散重则直接复位。按芯片手册来靠近VCC放100nF和10uF电容组合最好加一个磁珠再进芯片。天线这块是新手重灾区。模块厂商给的都是50欧姆特征阻抗的参考设计但如果你用PCB天线周围有没有铺地、有没有金属外壳、线路板层叠结构不一样天线的谐振点都会跑偏。实测经验同样是弹簧天线焊在板边和焊在板中间驻波比能差出一倍。方案上讲能外接SMA天线的最好外接空间实在不够再用PCB天线或弹簧天线。不管哪种调试时都要拿矢量网络分析仪或者频谱仪加反射桥看一下S11驻波比最好调到1.5以下。不要相信“天线随便焊一个就行”——通信距离少一半你都不知道输在哪。匹配电路上模块参考设计一般会留一个π型网络串联电感和两个并联电容。调匹配的时候哪怕你只有一个频谱仪也能用“信号源频谱仪”的办法粗调节点以固定包长持续发载波频谱仪看峰值功率然后微调匹配电容让峰值功率最大。这个过程虽然土但确实有效。我自己调过几块板调整一个2.2pF并联电容发射功率能差1.5dB左右接收灵敏度也跟着变。2.3 板级调试从串口到SPI再到频谱仪的排查顺序板子焊接完上电先别急着跑demo。我的调试顺序是固定的第一步量供电电压尤其是模块VCC和地之间的电压纹波第二步确认RTC晶振在跑看32.768kHz的波形或者看寄存器很多模块带时钟检测位第三步用SPI读芯片的版本寄存器能读出来说明SPI通信基本通了第四步再用官方工具发射单载波用频谱仪确认频率和功率正常。这套流程走下来至少能排除80%的硬件问题。3. 低功耗实测CAD模式的功耗波形怎么调3.1 发射、接收、睡眠三种状态的电流基线物联网节点尤其是电池供电的那种低功耗是胜负手。但很多人上来就问“SX1262睡眠电流是多少”这其实问错了方向。你得先知道自己系统的电流基线在哪里。这里给一组我实测的数据基于SX1262模块3.3V供电睡眠模式TCXO关闭、DIO3不供电电流约0.6uA接收模式电流约5.3mA发射模式电流和功率档位有关14dBm时约35mA22dBm时约115mA。注意这是模块本身的电流没算主控MCU的。设计低功耗节点时绝大部分时间必须待在睡眠状态。一个每天上报30次、每次空中时间0.5秒的节点如果发射时是110mA、睡眠时是2uA一天的功耗大头其实在发射和醒来后的MCU运行上。我见过不少板子MCU没做睡眠管理只是让LoRa模块睡了结果整机电流还有几百微安。这种节点用纽扣电池基本撑不过一周。3.2 CAD模式与功耗波形实测方法CADChannel Activity Detection是我觉得LoRa被低估的一个功能。它的意义在于用一个很低的功耗反复检测信道里有没有前导码信号一旦检测到就唤醒主控开始完整接收。相比一直开着接收机CAD能省掉大量监听功耗。实测下来一次CAD检测大概只持续几个毫秒电流和接收模式差不多5mA上下但占空比可以控制得很低整体平均电流能压到几十微安级别。那么怎么测功耗波形工具上我推荐两种一是精密万用表串联测平均电流适合粗看总量二是示波器电流探头适合看波形细节。没有电流探头的话也可以在电源输入端串联一个10Ω采样电阻用示波器测电阻两端电压。需要注意的是示波器探头本身有电容会影响高频电流读数所以测LoRa发射脉冲时最好用差分探头或电流探头别拿普通探头硬测。波形怎么看我找一台SX1262模块配置成“定时CAD唤醒”模式每500ms做一次CAD检测检测窗口约5ms检测到前导码后切到RX接收数据包。示波器上的波形应该是这样的一条接近0的基线每隔一段时间出现一个5ms宽的窄脉冲脉冲高度对应CAD电流随后如果检测到包会紧接着出现一个更长更高的脉冲接收模式再之后是发射ACK的脉冲。如果你看到CAD脉冲一个接一个没有间歇说明睡眠没生效或者配置的CAD周期太短了。3.3 周期与符号数对功耗和响应速度的影响CAD周期和CAD符号数是两个可以调的参数。CAD符号数决定检测一次前导码需要监听多长时间配置为2、4、8或更多。符号数越大检测可靠性越高但单次功耗也越高。前导码是8个符号的时候CAD配置4个符号通常就够用。CAD周期则决定每隔多久检测一次周期越短响应越快但平均功耗也越高。对大多数传感器场景CAD周期设300到500ms综合平衡比较好。这里有一个容易忽略的坑接收机在CAD模式下只是一个“盲扫”它并不知道包会在什么时候来。如果发送端一包发完就停了而接收端刚好在这一轮的CAD间隙这包就丢了。所以低功耗CAD唤醒方案对时延要求高的场景并不友好。我的建议是要么接受秒级时延要么用后文会讲的接收窗口机制。4. 距离与可靠性链路预算和实际调优4.1 链路预算的完整计算很多人觉得“LoRa能传几公里”是一个固定答案其实不是。通信距离取决于链路预算它等于发射功率加上天线增益减去接收灵敏度再扣除路径损耗。路径损耗和环境强相关。举一个实际例子节点发射功率14dBm天线增益0dBi接收灵敏度在SF12/BW125下是-136dBm那么最大允许路径损耗是14 136 150dB。在开阔地一个常用的简化模型是自由空间路径损耗公式L 32.4 20log10(频率MHz) 20log10(距离km)。以470MHz来计算20log10(470)大约是53.4那么150 32.4 53.4 20log10(距离)20log10(距离) 64.2距离大约是1621公里。这个数字明显不现实原因是自由空间模型在远距离完全失真真实地面环境下要额外加上地面反射的衰减实际距离会缩到几十分之一。这就是为什么“理论最大距离”没什么参考价值。更实用的做法是实测先在一片开阔地固定一个点另一个点沿直线往外走每100米测试一组丢包率画出一条丢包率和距离的曲线。城市环境里SF12/BW125在1到2公里就有明显丢包农村开阔地同等配置能跑到5公里以上有障碍物树林、建筑区时距离会急剧缩短到几百米。做项目时我一般按实际测试距离的一半作为设计指标留足余量。4.2 天线高度、地面反射和多径的玄学LoRa信号在真实环境里的表现比你在仿真软件里看到的复杂得多。影响最大的变量不是发射功率而是天线高度和地面反射。发射端和接收端都放在地面上比如各1米高地面的反射波会和直达波抵消反而形成一个“零陷”导致近距离通信比远距离还差。把天线升高到3米甚至5米通信距离能有质的提升。很多“奇怪”的丢包问题把天线往高处一挪就好了就是这么简单。多径衰落也是一个隐性杀手。LoRa本身因为用扩频技术对多径有一定抗性但如果在金属厂房、楼道这类环境反射严重时依然会看到一段路信号很好、两三米外信号骤降的现象。这种情况只能靠提高天线高度、调整节点安装位置来缓解纯靠加大发射功率效果有限。4.3 丢包排查从“玄学”到一查一个准丢包这事十次有八次不是LoRa本身的问题而是配置或环境问题。我整理了一个排查顺序照着做基本能定位第一检查频率。发射频点和接收频点是否一致晶振偏差大不大尤其用了便宜晶振的时候。SX1262支持通过寄存器校准晶振但很多模块的晶振精度就那样跨温度偏移几个kHz不奇怪。第二检查SF、BW、CR、前导码、同步字是否完全一致。这一条占了我遇到过问题的三成以上特别是混用不同厂家模块时。第三看频谱。如果附近有其他无线设备或同频LoRa节点干扰会导致随机丢包这种只能改频点或开跳频。第四检查天线。天线松动、馈线过长、天线贴着金属外壳都会带来莫名其妙的丢包。第五看供电。发射时电压跌落会导致发射功率不达标甚至掉线重启。经验之谈排查丢包问题时不要想着“加大功率”解决所有问题。在接收端用频谱仪看信号到底有多强、底噪有多高比在发送端瞎改参数管用多了。信号明明很强还丢包基本是配置问题信号弱到贴近灵敏度那才轮到提升功率。5. 多节点组网从点对点到一个小型网络的方案取舍5.1 星型加ALOHA最简单但别忽略冲突LoRa最常见的组网方式是星型一个网关集中器管一群节点。理论上每个节点直接给网关发数据就行但空中信道是共享的两个节点同时发就会冲突。最简单的解决办法是纯ALOHA每个节点想发就发发送前加一个随机延时。这种方案实现简单但信道利用率很低。在ALOHA协议下信道利用率上限大概只有18.4%意味着节点一多冲突重传就会占掉大部分信道。以前我做过一个16节点的传感器网络节点每30秒上报一次包长50字节SF10/BW125信道算下来已经比较拥挤了。一开始直接裸发网关收到的完整包率只有60%多大量重传。后来改成每个节点发送前随机等0到2秒丢包率明显下降。对于节点数少于20个、上报不频繁的场景随机退避够了不用复杂协议。如果节点数量再往上走就要考虑时隙同步。最简单的时隙方式是由网关定期广播一个beacon节点收到后按自己的时隙编号上传。这样没有突发冲突但需要所有节点都能收到网关的广播而且上行和下行时间要排好。这种方案实现起来比纯ALOHA复杂但可靠性和吞吐量都高得多。5.2 LoRaWAN的引入与选型时机当系统需要更多功能——比如自适应速率ADR、网络管理、多网关漫游、密钥管理——就得考虑LoRaWAN了。LoRaWAN本质是定义了一套MAC层协议和网络架构把LoRa物理层包装得更适合大规模部署。它支持Class A/B/C三种收模式Class A是节点发完上行后开启两个短暂下行接收窗口对电池最友好Class B在Class A基础上加了网关同步beacon支持定时下行Class C是持续接收适合有外电的网关或执行器。我的建议是如果只是自己玩或者做一个固定场景的小型项目LoRaWAN带来的复杂度不值得。但如果目标是产品化、多场地部署或者需要和云端平台对接那直接用LoRaWAN别自己造轮子。LoRaWAN的协议栈有现成开源实现比如ChirpStack做网络服务器SX1262节点端可以用Semtech的驱动加LoRaMAC-node框架。学习曲线有一些但文档和社区都成熟比自研协议靠谱得多。5.3 一个小型气象站网络的协议设计实例我举个实际案例我做了一个小型气象站网络一个网关6个节点每个节点每隔5分钟上报一次温湿度、气压、风速。节点使用SX1262SF10/BW125包长30字节上行后网关回复ACK节点收不到ACK就退避重发最多3次。所有节点都配置了CAD监听模式平时睡眠只在CAD检测到前导码后才醒来收ACK——这里有个关键设计ACK是网关在节点上行后的固定时间窗内发送的所以节点收完上行包后并不需要一直在RX而是切到CAD模式去等ACK节省不少电流。这套方案跑了一个多月整体丢包率控制在2%以内。功耗方面每个节点用两节18650电池平均电流约80uA预计能跑一年以上。如果要上生产可能再加一层LoRaWAN把数据推上云但物理层和低功耗设计思路是一样的。所以说组网方案的复杂度要跟着需求走别一开始就上重框架。6. 从项目角度补两个容易忽略的点6.1 频率规划与合规国内LoRa常使用的470-510MHz频段是微功率短距离设备的规定频段。做产品和做实验的差别在于产品要过型号核准、要按限定功率发射所以发射功率、占用带宽、杂散指标都要在规范范围内设计。自己diy做个demo无所谓但别拿demo直接去申请入网。选频点时也要避开广播、对讲机等常驻信号实际做法是先拿频谱仪扫一下现场的频谱环境选一个干净的频段再用。6.2 固件升级和调试日志LoRa节点一旦装箱放到现场最痛苦的是没法调试。我现在的习惯是每块板子都预留一个串口测试点固件里加上精简的日志输出用宏开关控制。同时在网关侧记录每个节点的接收信号强度RSSI和信噪比SNR这样不用到现场就能判断节点状态。特别是RSSI曲线能很直观地看出节点天线有没有松动、馈线有没有进水。这套东西一开始就要设计进去不然等现场出问题再拆机成本高到让你怀疑人生。调试时还有一个好习惯先用两个模块在桌面上跑通再挪到窗口测试距离最后再到复杂环境里验证。每一步记录好实际的RSSI和丢包率形成一份自己的环境衰减参考表。以后再做类似项目不用重复踩坑。LoRa这个技术物理层确实不复杂难的是把功率、功耗、距离、可靠性这些相互制约的指标在具体场景里平衡好。做板子、调波形、算链路预算这些都是水磨工夫。我在这个领域踩过很多坑上面写的算是比较核心的一部分。最后再分享一个小习惯每次调完一个参数我都会在代码注释里写清楚“为什么这么配”比如“SF12因为要让距离多1公里代价是速率低了20倍”。不然三个月后你再翻代码绝对想不起来当初为什么做这个决定。