基于树莓派Pico与E22-900M22S的串口转LoRA透传单元实现

1. 项目概述与整体设计思路1.1 这是个什么项目解决什么问题串口转LoRA模块单元从名字就能看出来它干的事情就是把传统的UART串口数据通过LoRA无线链路发送到远端同时也能把远端回传的数据还原成串口数据。如果你手里有一堆只有串口输出的传感器、仪器仪表、单片机开发板想把数据传到几百米甚至几公里之外又不想布设线缆这个模块就是中间那座桥。我选型用的E22-900M22S是亿佰特家的LoRA模组工作在868/915MHz频段内置的射频芯片是Semtech的LLCC68很多人可能更熟悉SX1262LLCC68本质上就是SX1262的窄带版本最大发射功率22dBm约158mW接收灵敏度能到-137dBm左右这个参数在远距离低速率场景下非常能打。主控部分我选了树莓派Pico原因很简单——RP2040这颗芯片带两个UART价格便宜MicroPython开发效率高调试起来比裸机C舒服得多。这个单元做好之后典型应用场景包括农业大棚里的温湿度传感器数据采集传感器用485或者TTL串口输出LoRA模块把数据发回中控室工业现场的设备状态监测PLC或者仪表只有串口不方便走线的地方用LoRA透传临时部署的数据采集链路比如野外环境监测架好就能用不用考虑网络覆盖智能楼宇里各种串口设备的无线化改造。整个系统可以说是一个“数据搬运工”对数据内容不做任何解释只负责把串口上收到的字节原封不动地搬到无线链路上再从无线链路上原封不动地吐回串口。这也是LoRA模块最常见的用法——串口透传。1.2 为什么选E22-900M22S而不是其他模组市面上串口转LoRA的方案其实很多有直接用SX1268/SX1276自己画板的也有买现成透传模块的比如亿佰特E22系列、安信可的LoRa模块等等。我最后选E22-900M22S主要是从这几个角度考虑的首先是频段匹配。E22-900M22S工作在850~930MHz不同批次略有差异在这个频段国内使用不需要申请专门的频率许可前提是功率合规而且900MHz频段在城市环境下的绕射能力和穿透能力比2.4GHz好比433MHz带宽更宽、天线更短属于一个比较折中的选择。其次是模组本身的集成度。E22-900M22S内部已经把射频匹配、滤波、PA、LNA都做完了外部只需要接一根天线不需要自己画射频阻抗匹配。这个是新手最容易翻车的地方——433MHz或者915MHz的射频匹配板上走线稍微长一点寄生电容稍微大一点驻波比一上来发射功率直接打骨折。用模组就完全绕开了这个问题我只需要关心它暴露出来的接口引脚就行。再就是驱动方式灵活。E22-900M22S支持通过UART AT指令配置也可以配置成透传模式之后上电自动进入透传。这意味着我可以先用USB转TTL接电脑把参数配置好然后再接到Pico上运行调试路径非常清晰。1.3 树莓派Pico作为主控的过人之处树莓派Pico在这个项目里承担的角色是“串口桥接器 逻辑控制”。我需要它做以下几件事从某一个UART口接收外部设备比如传感器发来的数据把数据打包或者原样交给E22-900M22S通过另一个UART口发送反过来从E22-900M22S接收无线链路的数据再从另一个口吐出给外部设备顺便控制一下E22-900M22S的M0/M1引脚用于切换工作模式。这些活儿用STM32当然也能干但Pico有一个巨大的优势MicroPython环境下串口读写就是open、read、write这么简单不需要翻寄存器手册配置波特率、校验位、DMA也不需要处理中断优先级。对于这个项目的核心目标——快速搭建一个可用的串口转LoRA单元——Pico的开发效率是碾压级的。另外Pico的供电很宽松官方规格是1.8V~5.5V但实际用USB的5V供电或者3.3V的LDO都行配合E22-900M22S的2.3V~3.6V供电范围直接用Pico板载的3.3V输出给模组供电就行不用额外做电源轨省了不少事。2. 硬件准备与接线设计2.1 器件清单我自己做这个项目用到的全部物料如下表器件型号/规格数量备注主控板树莓派PicoRP20401带针脚版本更好接线LoRA模组E22-900M22S1亿佰特22dBmSMA-K接口天线868MHz/915MHz胶棒天线1增益2~3dBi即可USB转TTLCH340模块1调试阶段配置模组用面包板830孔1原型验证用杜邦线母对母、公对母若干若干建议不同颜色区分电源和信号稳压/供电5V USB电源或3.7V锂电池1便携场景建议锂电池电阻10KΩ上拉电阻2M0和M1引脚默认上拉这里面有一个容易被忽略的点E22-900M22S的M0和M1引脚不能悬空。这两个引脚内部虽然有下拉但官方推荐的可靠做法是外部加上拉电阻到VCC或者直接接高电平通过拉低来切换模式。我见过不少人把M0/M1悬空导致模组偶尔进入异常模式数据发不出去排查半天发现是模式引脚电平漂了。所以面包板上先把10KΩ上拉电阻安排上稳。2.2 引脚定义与接线表E22-900M22S的引脚不算多核心就是VCC、GND、TXD、RXD、M0、M1。它的TXD是模组发送数据给外部MCU的线RXD是模组接收外部MCU数据的线这俩和MCU的UART要交叉连接——MCU的TX接模组的RXDMCU的RX接模组的TXD这个基础接线问题是新手问得最多的问题每次都有人接成顺连然后问为什么收不到数据。树莓派Pico的GPIO0和GPIO1对应UART0的TX和RXGPIO4和GPIO5对应UART1的TX和RX。我这里的分配方案是Pico引脚功能接到E22-900M22S说明GPIO0UART0 TXRXD向模组发送AT指令/数据GPIO1UART0 RXTXD从模组接收数据GPIO2普通输出M0模式控制低有效GPIO3普通输出M1模式控制低有效3V3电源正VCC模组供电GND电源负GND共地必须连接无无AUX可选悬空或接GPIO用于状态判断如果你后续要把这个模块做成一个独立单元建议把UART1GPIO4/GPIO5留出来作为“外部串口”也就是说外部传感器的数据线接到Pico的GPIO4UART1 TX和GPIO5UART1 RXPico内部做数据搬运把UART1收到的数据通过UART0转发给LoRA模组。这样外部串口和无线链路就是物理隔离的两个通道逻辑更清晰。2.3 供电方案与注意事项E22-900M22S的供电范围是2.3V~3.6V这意味它不能直接吃5V。如果用USB给Pico供电Pico板载的3.3V LDO输出的电流足够驱动模组模组发射时的峰值电流在100mA~120mA左右Pico的3V3引脚可以承受所以直接VCC接Pico的3V3输出即可。但如果想用锂电池3.7V供电就必须注意3.7V锂电池满电时是4.2V直接进Pico的VSYS5V轨没问题但不要直接给模组的VCC供4.2V。要么经过Pico的板载稳压要么自己加一个低压差LDO比如ME6211或XC6206降到3.3V。我一开始图省事直接把电池正极接到了面包板的3.3V轨上结果LoRA模组偶尔重启后来查到是电压超规格了模组的内部保护电路动作。共用电源还有一个细节天线要远离电源走线尤其是模组发射瞬间电流变化大如果天线离电源线太近射频能量会耦合到电源上造成辐射杂散超标和数据误码。面包板原型阶段可能还好做成PCB之后这点尤其重要天线区域下方尽量不要走电源和地。3. 模组初始化配置与重要参数解析3.1 通过AT指令配置模组E22-900M22S上电默认是透传模式如果要改配置需要把M0和M1拉高进入AT模式。它有两种AT模式模式0M00, M10是透传模式也是正常工作模式模式1M01, M10是AT指令模式可以通过串口发送AT指令查询和修改配置模式2和模式3分别是“双唤醒”和“深睡眠”之类的这个项目用不上。我的建议是先用USB转TTL把模组单独接到电脑上用串口调试助手配置好参数然后再接到Pico上跑。这样配置过程所见即所得不用在MicroPython里写一长串AT指令然后猜测有没有生效。具体操作流程把E22-900M22S的M0和M1通过10K电阻上拉或者直接接VCC进入AT模式USB转TTL的TX接模组RXD、RX接模组TXD共地VCC接3.3V打开串口调试助手波特率选择9600出厂默认发送ATRX模组应该回复OK...之类的信息用ATADDR查询/修改设备地址用ATNETID设置网络ID用ATBAND设置频点用ATUART设置串口参数用ATPOWER设置发射功率用ATAIR设置空中速率配置完成后发送ATRESET让模组重启然后把M0/M1拉低进入透传模式。下面是这个项目我用到的几组核心配置指令注意不同固件版本的指令集可能略有差异具体以模组配套的数据手册为准指令含义我的配置说明ATADDR0001设置设备地址0001两个模块地址要一致才能互通ATNETID10设置网络ID10相当于虚拟信道隔离ATBAND915000000设置中心频率915MHz需要双边一致ATUART9600,8,1串口参数9600,8N1与Pico的UART配置一致ATPOWER22发射功率22dBm最大功率ATAIR19空中速率见下文需要双边一致3.2 空中速率、发射功率与通信距离的取舍E22-900M22S的空中速率Air Data Rate是一个关键参数它直接决定了吞吐量、接收灵敏度和通信距离之间的平衡。这个模组的空中速率可以设置在2.4kbps~62.5kbps之间不同版本可能更高速率越低接收灵敏度越好通信距离越远但同样大小的数据包在空中的占用时间越长。这里有个经验公式可以参考单包传输时间 前导码时间 数据负载时间。LoRA的机制决定了前导码是每一包都要带的而且前导码的时间在不同空中速率下差别很大。举例来说如果空中速率设为2.4kbps一个包含10字节有效数据的包加上必要的帧头、CRC、前导码在空中的时间可能接近80ms~100ms如果空中速率提到19.2kbps同样的包可能只需要15ms左右。所以在实际项目里怎么选传感器数据量小几十个字节、传输频率低一分钟一次优先选低速率比如2.4kbps~9.6kbps换更远的距离和更强的穿透力如果数据量稍大比如几百字节、实时性要求高一些空中速率可以设到19.2kbps以上但要做好通信距离相应变短的准备。我实测下来在空旷环境下22dBm发射功率 915MHz 2.4kbps空中速率 2dBi胶棒天线通信距离可以稳定达到2km以上同样条件下把空中速率调到19.2kbps距离会缩到1km左右。这个衰减是指数级的不是线性的所以千万别为了那点速率牺牲距离除非你真的需要。3.3 通信双方配置必须一致否则静默失败这是透传LoRA最容易踩的坑两边的地址、网络ID、频点、空中速率必须完全一致否则数据包直接丢掉没有任何提示。我自己调试时就遇到过A模块配置的是915MHzB模块配置的是868MHz两边串口都正常A发数据B收不到B发数据A也收不到用频谱仪一测才发现两个模块根本不在一个信道上。E22-900M22S本身有定频和跳频两种模式默认是定频所以频点不对就是完全隔离。另外一个容易忽略的是网络IDNETID。这个参数相当于逻辑信道隔离同一频点上不同NETID的模块互不干扰。如果你在一个区域部署了多组LoRA设备每组用不同的NETID可以有效防止串扰。但反过来说如果两边NETID不一致即使频点一致也收不到。所以我强烈建议配置完之后先用电脑上的串口调试助手做双向透传测试确认A→B和B→A都能通再接Pico。这个步骤只要花5分钟但能省掉后面一两个小时的排错时间。4. 树莓派Pico上的MicroPython代码实现4.1 代码逻辑与整体框架Pico端的功能非常单纯两个UART口一个接外部设备一个接LoRA模组中间做数据搬运。但搬运方式不同效果差异很大。最简单的做法是“裸透传”UART1收到一个字节就立刻从UART0发出去。这样延迟最低但如果外部设备发来的数据是分帧的中间间隔稍长LoRA会把每一小段当成独立的一包数据发送无线链路的利用率极低而且对端拼包会很痛苦。更好的做法是“分包透传”在内存里攒够一定字节数比如64字节或者128字节或者等待一定空闲时间比如50ms再一次性发给LoRA模组。这样做的好处是无线链路上每个数据包都接近模组的单包最大负载效率高对端也容易解析。我的实现方案是空闲超时分包from machine import UART, Pin import time import utime # UART0: 连接E22-900M22SLoRA模组 lora_uart UART(0, baudrate9600, txPin(0), rxPin(1), bits8, parityNone, stop1) # UART1: 连接外部串口设备 ext_uart UART(1, baudrate9600, txPin(4), rxPin(5), bits8, parityNone, stop1) # M0和M1引脚拉低进入透传模式 M0 Pin(2, Pin.OUT) M1 Pin(3, Pin.OUT) M0.value(0) M1.value(0) BUF_SIZE 128 IDLE_TIMEOUT_MS 50 rx_buf bytearray() while True: # 从外部串口读取数据 if ext_uart.any(): rx_buf ext_uart.read(ext_uart.any()) # 如果缓冲区满立即发送 if len(rx_buf) BUF_SIZE: lora_uart.write(rx_buf) rx_buf bytearray() # 如果缓冲区非空且达到空闲超时则发送 if rx_buf and (utime.ticks_diff(utime.ticks_ms(), last_rx_time) IDLE_TIMEOUT_MS): lora_uart.write(rx_buf) rx_buf bytearray() # 从LoRA模组读取数据转发到外部串口 if lora_uart.any(): data lora_uart.read(lora_uart.any()) ext_uart.write(data) last_rx_time utime.ticks_ms()4.2 代码逐段拆解上面这段代码有三个关键点值得展开讲。第一个是UART初始化参数。这里波特率设9600、8位数据、无校验、1位停止位这是最常见的串口参数E22-900M22S出厂默认也是9600 8N1。但注意LPUART和普通UART在这颗芯片上的波特率误差不一样Pico的UART0和UART1都是普通UART9600波特率下偏差在0.2%以内任何情况下都不会出问题。如果你用其他主控比如STM32的LPUART低速时钟源可能导致9600波特率在低温下偶发误码这个细节值得留心。第二个是M0/M1引脚的拉低时机。我在代码里把M0和M1都设为0这是透传模式。但有个细节E22-900M22S的模式切换不是瞬间生效的手册里说配置切换后需要等待至少100ms让模组内部的射频状态机完成切换。所以如果你的代码里需要动态切换AT模式和透传模式在拉高/拉低之后最好加一个utime.sleep_ms(200)的延时否则模组可能还在上一个模式里响应产生意想不到的结果。第三个是空闲超时逻辑。这里的核心是用utime.ticks_ms()记录最近一次收到外部数据的时间然后不断比较间隔是否超过50ms。这个50ms的取值是经验值——如果外部设备的数据帧间隔小于50ms它们会被合并成一包发送如果间隔大于50ms就会被拆成两包。具体取多少取决于你的数据源特性GPS模块的NMEA数据是一秒一帧50ms足够某些高速传感器的数据间隔可能只有几毫秒这时可以缩短到10ms如果数据是频繁不定长上报建议把超时调到100ms左右宁可延迟一点也要保证一包数据的完整性。4.3 一个更稳健的带ACK可选项版本如果你担心无线链路丢包LoRA本身有前向纠错FEC和CRC校验在多数场景下误码率已经很低了不需要额外做ACK确认。但如果你的应用对数据完整性要求很高比如控制指令下发可以考虑在协议层加一个轻量确认机制。一个最简单的做法是CMD_REQ bREQ: CMD_ACK bACK: def send_with_ack(data, timeout_ms1000): lora_uart.write(CMD_REQ data) start utime.ticks_ms() while utime.ticks_diff(utime.ticks_ms(), start) timeout_ms: if lora_uart.any(): resp lora_uart.read() if resp.startswith(CMD_ACK): return True return False发送方在发出数据后等待对端的ACK超时则重发。这个方案在“点对点确认”场景下够用但要注意LoRA是半双工的对端在收到数据后不能立刻回ACK因为无线信道还需要处理收发切换所以ACK的超时时间至少要留200ms以上否则对端根本来不及回复。5. 关键指标实测与性能测算5.1 单包传输时长与吞吐量上限设计串口转LoRA单元之前最好先算一笔账你期望的通信频次和数据量是多少LoRA链路能不能承载我以实测配置为例空中速率19.2kbps10字节有效负载。通过逻辑分析仪抓取E22-900M22S的TXD引脚可以看到从发送数据进入模组到数据从天线发射出去整包耗时大约15ms~20ms。如果按20ms估算单包空中占用时间占20ms理论上一秒最多发50包一包10字节吞吐量上限就是500字节/秒。如果把空中速率降低到2.4kbps同样的10字节数据包空中时间会膨胀到约80ms一秒最多12包也就是120字节/秒。这个数字对于大多数传感器上报场景一分钟一包、每包二三十字节完全够了但如果你打算传音频流或者高速采样数据LoRA这条链路就远远不够。建议在实际设计时把最大单包长度、空中速率、发送频次三个参数做一张兼容性检查表确保不超出链路能力。5.2 通信距离实测我在一个城郊开阔地进行过简单测试环境是草地少量低矮树木天线高度约2米手持配置为22dBm发射功率、915MHz、空中速率9.6kbps、2dBi胶棒天线距离结果备注500m稳定RSSI约-75dBm偶发丢包但重传后恢复1km稳定RSSI约-95dBm数据延迟约80ms1.5km临界RSSI约-110dBm丢包率升高到10%左右2km基本不可用天线高度降低后完全断连这个结果说明一点天线高度对通信距离的影响是决定性的。同样的发射功率和接收灵敏度把天线从2米抬到5米通信距离几乎翻倍。如果你要固定部署尽量把天线架高、避开金属遮挡效果远好于加大功率。LoRA的接收灵敏度曲线在接近极限时会快速恶化不是线性衰减。所以设计链路预算时建议按“比模组标称灵敏度多留10dB余量”来做否则到了现场会因为天气、电磁干扰、天线方向性等因素频繁丢包。5.3 功耗与供电余量E22-900M22S的规格书标注发射电流约110mA22dBm接收电流约5.5mA睡眠模式更低。如果系统由电池供电要重点考虑发射功耗。举个例子10秒上报一次数据每次发射50ms平均电流就是110mA × (50ms/10000ms) 0.55mA加上接收待机电流约5.5mA再加上Pico本身的运行电流RP2040跑MicroPython大约20mA~30mA总平均电流大约30mA。用一节2000mAh的18650锂电池理论续航约60小时实际打个七折大约40小时。如果想提升续航可以让Pico进入睡眠模式定时唤醒发送数据平均电流可以降到几毫安续航就能拉长到一周以上。6. 常见问题与调试技巧实录6.1 数据发不出去或收不到从哪查起这个项目最典型的故障是“两边串口都通了但LoRA之间不通”。我的排查顺序是固定的第一步确认模组供电和天线。用万用表量VCC对GND电压是否稳定在3.3V天线是否拧紧SMA头是否完全到位。很多人天线没拧紧射频能量反射回功放不仅发射不出去还可能烧模组。第二步确认M0/M1模式。用万用表量一下这两个引脚的电压透传模式应该是低电平0V。如果测量到高电平检查上拉电阻是不是接错了或者GPIO初始化时是否先设置了高电平导致模组开机瞬间进入了AT模式。第三步确认两边参数一致。通过串口调试助手对每个模块执行ATRX之类的查询指令对比地址、频点、空中速率、NETID。特别注意空中速率的单位——有些固件显示的是kbps有些显示的是索引值不要被表面数字骗了。第四步用频谱仪或者第二个接收模块做空中抓包。如果没有频谱仪最简单的方法是准备第三个E22模块设置成与发送方相同参数接在电脑上用串口助手看能不能收到数据。如果第三方能收到说明发送方空中链路正常问题出在接收方的串口或者接线。6.2 串口数据乱码乱码的原因通常是波特率不匹配。排查时用示波器测一下发送端TXD引脚的波形量一下一位的脉宽用1除以脉宽就是实际波特率。比如量到104微秒那就是9600波特率如果量到52微秒实际上是19200。另一个容易忽略的是电平标准。E22-900M22S和Pico都是3.3V TTL电平但如果外部设备是5V的串口直接连接可能把模组或者Pico的引脚打坏。这种情况下需要做电平转换用两个MOS管搭的简单双向电平转换电路就可以或者直接买现成的电平转换模块。6.3 距离拉不远距离拉不远最可能的原因是天线问题。做一个简单的驻波比测试把天线拆下来接上一个50Ω的假负载如果发射电流基本不变说明模组输出正常如果接天线和接假负载时的电流差别很大说明天线和模组之间阻抗不匹配。此外还要检查天线是否在正确的频段上。E22-900M22S默认是915MHz如果配了一根868MHz的天线虽然中心频率差得不远还能凑合用但效率会打折扣如果是433MHz的天线插上去那基本就是废的。6.4 干扰与串扰问题915MHz附近有一些其他的无线设备比如部分航空导航系统、工业设备在城市里还可能遇到运营商的某些频段干扰。我在调试时遇到过一次数据时不时丢包用频谱仪一看某个信道一直有一个-90dBm左右的窄带干扰信号后来把频点往上偏了2MHz问题就消失了。所以在正式部署时建议用频谱仪扫一下现场电磁环境选一个干净的频点。如果条件不允许优先选择厂家预置的非默认频点减少和周围其他同频设备冲突的概率。6.5 一个容易被忽略的坑模组AUX引脚的用法E22-900M22S有一个AUX引脚用于指示模组的收发状态。在实际调试时这个引脚非常有用当模组正在通过无线链路发送数据时AUX引脚会输出低电平数据发送完成、模组空闲时AUX是高电平。如果在发送完数据后立即让MCU进入睡眠或者立即切换M0/M1模式必须等待AUX引脚拉高否则模组可能正在忙指令会丢失。我的建议是在代码里把AUX接到Pico的GPIO6每次往模组写入数据后轮询AUX直到拉高再执行下一步AUX Pin(6, Pin.IN) def wait_lora_free(): while AUX.value() 0: utime.sleep_ms(1) lora_uart.write(rx_buf) wait_lora_free()这个技巧在低功耗场景下尤为重要——如果没有等待AUX就休眠模组发送到一半突然断电不仅当前这包数据会丢还可能导致模组内部状态机错乱下次上电后无法正常工作。7. 项目后续扩展思路7.1 双向数据通道带优先级控制简单的透传模式下数据是“谁先来谁发送”的FIFO方式。但如果你既要传输传感器上行数据又要偶尔下发控制指令可以考虑在协议层做优先级控制指令优先发送、传感器数据排队等待。具体做法是在Pico代码里维护两个缓冲区一个高优先级控制指令一个低优先级传感器数据每次从LoRA模组读取数据后优先处理高优先级缓冲区的发送任务。LoRA是半双工机制无法同时收发所以高优先级指令必须等待当前发送完成但可以做到“一旦空闲就立刻插队”在多数场景下这个响应速度足够。7.2 多节点组网E22-900M22S本身是点对点或者广播模式不支持复杂的Mesh组网。如果你有多个节点需要汇聚到一个网关可以做星型拓扑所有终端节点配置同一个频点但不同的地址网关端用一个地址接收通过数据内容中的源地址字段区分是哪个节点发的。这种方案的好处是简单可靠缺点是网关端如果同时向多个节点下发指令需要做好时分调度不能同时发两个指令否则目标节点中的另一个会被误触发。7.3 与云平台的对接串口转LoRA单元最常见的扩展方向是加一个4G Cat.1模块或者WiFi模块让网关把LoRA汇聚上来的数据转发到云平台。我在实际项目中这么做过网关端用Pico接收LoRA数据再通过一个串口4G模块比如EC800M把数据以MQTT协议发布到物联网平台。这样整体链路就是“传感器 → 串口 → LoRA → 网关 → 4G/WiFi → 云”传感器端完全不需要接入互联网功耗低、成本低非常适合户外部署。这个扩展的难点在于4G模块的AT指令解析和MQTT报文构造但好消息是这类模块厂商一般都会提供现成的SDK或者参考例程在Pico上只需要处理好串口之间的数据流转即可。7.4 低功耗唤醒模式如果整个单元需要电池供电且长期无人值守E22-900M22S的低功耗模式值得研究。它支持定时唤醒和外部唤醒两种方式定时唤醒模式下模组定期进入接收窗口发射端在发数据前先发送一串唤醒码等接收端醒过来再发正式数据。树莓派Pico本身也有休眠模式可以把RP2040的功耗控制到µA级别配上LoRA的低功耗接收窗口整个系统的平均功耗可以压得很低。我测试过一组方案30s上报一次、每次发射100ms两节AA电池理论上可以工作半年以上。当然低功耗设计的代价是实时性下降——接收端不是一直在线指令下发可能有几十秒甚至更长的延迟。需要权衡好你的应用场景是“定期采集”还是“实时响应”再把省电策略做进去。8. 写在最后的调试心得做串口转LoRA模块单元这类项目最怕的不是不会写代码而是遇到问题没有系统性的排查思路。我个人的经验是任何无线项目的调试都要遵循“先有线再无线先单点再组网”的原则先有线——确保两个串口外部设备到Pico、Pico到LoRA模组的数据收发都是通的用一根杜邦线把TXD和RXD短接做回环测试能收到自己发的数据就说明串口链路没问题再无线——通过串口助手直接在两个模组之间做透传测试确保空中链路通最后才是组网和协议层面的调试。这样做每一步出现问题都很容易定位不至于一堆问题纠缠在一起无从下手。另外一点心得是E22-900M22S这类模组官方的数据手册里其实已经把大多数注意事项写得明明白白关键是调试时愿不愿意静下心去查。比如我前面说的模式切换需要延时、AUX引脚要用起来、天线频段要匹配这些在手册里都有提及但新手往往忽略掉等到现场排查才追悔莫及。如果你准备复刻这个项目我建议你把前面的硬件接线、AT配置、Pico代码三步走通之后先做一个小实验两个模块一个接Pico一个接电脑USB转TTL中间隔着几百米用手机和电脑配合测试一下双向收发延迟和丢包率。这个实验做完你对LoRA这套链路的能力边界和调参方向会有一个非常直观的认知远比看十篇教程有效。