从串口到LoRA手把手做一个基于树莓派Pico和E22-900M22S的无线透传单元串口转LoRA模块单元乍一听像个“小众玩具”实际上只要做过一次无线数据采集或者远程设备调试你就会发现这玩意儿是刚需。单片机采集到的传感器数据靠Wi-Fi太费电靠蓝牙距离太短靠4G要插卡还要流量费这时候LoRA几乎是唯一一个能在“低功耗”和“远距离”之间取得平衡的方案。而我这次选用的组合——树莓派Pico加亿佰特E22-900M22S模组可能是这个需求下性价比最高的搭法整套物料成本不到五十块钱却能轻松跑出几百米到两三公里的稳定通信距离取决于天线和环境。E22-900M22S这颗模组用的是Semtech SX1262方案工作在Sub-GHz频段输出功率最高22dBm内置了完整的LoRA协议栈和串口透传固件。也就是说我们不需要自己处理扩频调制、CRC校验、空中速率配置这些底层细节只要把它当做一个“带天线的无线串口”来用就行。树莓派Pico负责的则是把业务数据从传感器、仪表或者其他串口设备里抽出来按E22的帧格式打包然后喂给它发出去收到数据时再做反向的解析和转发。说白了这个项目的核心就两件事把串口数据转换成E22能认识的格式再把E22收到的数据重新还原成串口数据。听起来简单但里面涉及电平匹配、帧格式、超时计数、电源纹波、天线布局这些问题任何一个坑踩进去都够你调一整天的。这篇文章会把整个设计过程完整捋一遍从硬件选型到电路接法从协议分析到代码实现最后再把调试中遇到的各种坑和排查思路整理出来。不管你是做物联网毕设、农业环境监测、还是想给家里的老旧设备加个无线远程控制这套方案都可以直接抄作业。1. 整体方案设计为什么是Pico加E22而不是现成的串口LoRA板1.1 先搞清楚E22-900M22S到底是什么角色很多人第一次接触E22-900M22S容易把它当成一个“需要自己写LoRA协议”的模组这是最大的误解。这颗芯片内部其实是双MCU架构一颗负责射频收发另一颗负责串口协议解析和应用逻辑。对用户来说它就是一个支持AT指令的UART从设备。你把要发的数据通过串口发给它它自动完成组帧、CRC校验、扩频调制和射频发射反过来它收到空中数据后自动解调、校验再通过串口把有效负载输出。这种设计最大的好处是开发门槛极低。你不需要了解LoRA的带宽、扩频因子、编码率怎么配置才算最优因为模块出厂时固件已经内置了一套默认参数而且支持通过AT指令动态调整。E22-900M22S默认的串口波特率是96008N1空中速率对应的配置也匹配好了。对Pico来说它只需要把E22当成一个普通的外置串口外设来处理即可代码复杂度和操作一个GPS模块没什么区别。但注意E22默认参数不一定适合你的应用场景。比如你要传较大的数据包默认的空中速率可能偏慢你需要更远的通信距离可能需要调低空中速率换取灵敏度你有多组设备在同区域工作还要考虑地址和信道的区分。这些都可以通过AT指令在初始化阶段配置后面会详细说。1.2 树莓派Pico在这个项目里的定位和优势树莓派Pico使用的RP2040芯片虽然主频不高默认125MHz但对串口透传这种任务来说完全够用。它有2个UART外设UART0和UART1每个都支持独立的波特率配置、FIFO缓冲和中断正好满足我们这个场景的需求一个串口接业务设备传感器、仪表等另一个串口接E22模组。选Pico而不是Arduino或者STM32有我的实际考量。首先是价格Pico原版板子在国内渠道不到二十块钱比大部分STM32最小系统板还便宜其次是开发环境MicroPython固件支持下写个串口收发逻辑大概二十行代码就能跑通非常适合快速验证方案第三是双核架构理论上你可以在Core0上跑协议解析在Core1上跑数据转发实现并行处理当然这个项目用不到这么复杂但留有余量总不是坏事。还有一点容易被人忽略Pico的GPIO是3.3V逻辑电平和E22模组正好匹配。如果换成5V的Arduino还得在TX、RX线上加电平转换电路否则长期运行有可能损坏E22的引脚。Pico在这个项目里几乎就是为E22量身定做的搭档。1.3 方案替代项对比为什么不自制射频电路可能有人会问既然E22内部有MCU为什么不直接用E22模块本身做数据处理非要再加一块Pico这取决于你的业务复杂度。E22模组内部虽然有MCU但它的固件专注于射频协议栈并没有开放用户编程接口。你没法在模组里写业务逻辑比如解析Modbus报文、存储传感器历史数据、做本地阈值判断。这些任务必须交给外部主控。另一个可选方案是直接买市面上现成的“串口转LoRA数传模块开发板”比如亿佰特自家的E22-900M22S_DTU或者第三方做的LoRA网关板。它们的好处是免接线、带外壳、有指示灯但坏处是价格贵、灵活性差、而且多数不自带USB转串口调试功能不适合嵌入式工程师做底层学习。自己用Pico做一块电路板所有信号都拉出来测试你能真正搞清楚LoRA透传的每个环节是怎么回事这个学习收益是现成模块给不了的。所以这个项目的整体架构就是Pico作为主控和数据中转站一端通过UART0连接外部业务设备另一端通过UART1连接E22-900M22S模组E22再将数据通过内置天线发到空中。数据流向是双向的既可以本地设备远程发起查询也可以远端设备主动上报本质是一个透明传输通道。2. 硬件连接与关键电路设计这些坑你迟早会遇到2.1 引脚分配和接线表先说引脚分配。Pico的UART0默认映射到GPIO0TX和GPIO1RXUART1默认映射到GPIO4TX和GPIO5RX。我实际使用时把业务串口放在UART0GPIO0/1把E22模组放在UART1GPIO4/5。为什么这样分因为Pico板载的USB转串口芯片连接的是UART0这样插上USB线就能通过板载芯片直接看到业务串口的数据调试起来非常方便。E22则用独立的UART1避免调试数据和业务数据混在一起。完整接线如下Pico引脚连接目标说明3V3(OUT)E22-VCC供电最大峰值电流约120mAPico板载LDO可承受GNDE22-GND共地必须接否则通信不稳定GP4 (UART1_TX)E22-RXPico发送到E22GP5 (UART1_RX)E22-TXE22发送到PicoGP6E22-M0模式控制引脚低电平为正常透传模式GP7E22-M1模式控制引脚低电平为正常透传模式E22的M0和M1是两个模式选择引脚组合方式有四种00是正常透传模式01是唤醒模式WOR10是省电模式11是配置模式。做透传时把两个引脚都拉低即可。我用GPIO控制而不是直接接地是为了后续可以在程序里动态切换模式比如需要远程修改参数时切到配置模式平时保持透明传输。实际焊接时如果不想接这两个引脚直接接地也能用但不推荐因为你后续想用AT指令调参就得拆板子。2.2 E22天线的布局问题板载天线不能乱画E22-900M22S默认带的是IPEX天线座或板载PCB天线不同批次可能不一样。如果你买的是板载天线版本PCB上天线区域会有一块L形的铜箔这块区域对周围的覆铜、走线和元器件非常敏感。我在第一版画PCB时贪图布线方便在天线下方走了一根较长的信号线结果实测通信距离从能跑800米直接掉到不到100米。后来查资料才知道900MHz频段的波长大约是33厘米板载天线的辐射场对附近金属和走线极其敏感。你把天线区域周围铺了完整的地或者走了高频信号线等于帮天线“吸收”了能量辐射效率自然变差。正确做法是天线下方和周围至少5毫米范围内不能有覆铜最好挖空处理天线净空区域的投影范围内不要走任何信号线天线要尽量靠板边放置让天线主体伸出PCB边缘最好。用EDA软件画PCB时把天线区域设置为禁止覆铜区Keepout并加一条丝印标注“ANTENNA CLEARANCE”提醒自己后面不要改动这个区域。如果你用洞洞板飞线焊接那这个问题不大但注意E22模块外露的天线部分不要贴着金属外壳或杜邦线捆在一起。2.3 电源设计发射瞬间的压降会害死你E22-900M22S在22dBm发射时的峰值电流大概在120毫安左右虽然持续时间很短但如果电源的瞬态响应能力差电压跌落会导致模块复位或者发射失败。树莓派Pico板载的RT6150B Buck-Boost芯片理论上能提供充足的电流但如果你同时给其他外设供电比如传感器、OLED屏幕、舵机总线电流一旦超过500mAPico板载电源就吃紧了。我测试时遇到过一种很隐蔽的现象单独接E22时一切正常一旦把舵机接上同一个3.3V电源LoRA通信距离明显变短偶尔还出现数据完全发不出去的情况。用示波器一看E22发射瞬间的3.3V上叠加了一个约300mV的负向毛刺舵机转动时的电流冲击把电压拉低了E22内部射频PA供电不足输出功率直接塌掉。解决办法有三层第一尽量给E22用独立的LDO供电比如从USB的5V经过一个HT7333或ME6211稳压到3.3V再单独供给E22不要和Pico共用第二在E22的VCC和GND之间加一个100μF的电解电容和一个0.1μF的陶瓷电容电解电容提供低频能量储备陶瓷电容滤除高频噪声第三如果实在没法分离电源就在Pico的3V3输出端加大电容容值至少220μF。实测下来加了独立LDO和双电容之后舵机转动时E22的供电电压纹波从300mV降到了50mV以内通信距离恢复正常。3. 软件设计与核心代码实现从透传到协议一步步跑通3.1 E22的帧格式解析E22模组的串口数据帧格式和常见的AT指令模块不太一样。它没有用AT开头而是用两个字节的帧头(0xC1 0xFC)或(0xC1 0x00)来区分数据帧和配置帧。在透传模式下你发给E22的所有串口数据会被原封不动地打包进一个LoRA数据帧里模组自己加上帧头、地址、信道、CRC等信息发出去。接收方E22在收到空中数据后会把有效载荷部分重新通过串口输出。具体的帧格式为前两字节是帧头固定0xC1 0x00或0xC1 0xFC第三字节是数据长度只计算数据域和校验和不含帧头后面是数据域和校验和。但这里有个容易误解的点E22在“透传模式”下并不会把内部协议帧原样丢给MCU而是自动剥离了协议头只输出数据域。所以对MCU来说你在透传模式下看到的串口数据就是纯粹的原始数据没有额外的协议头。只有在配置模式下E22才使用带帧头的AT指令格式。这意味着我们平时写程序只需要做普通的串口收发根本不用关心E22的内部帧怎么组织它自己会处理好。如果你需要动态配置模组参数比如切换信道、修改空中速率那就要在配置模式下发送特定格式的帧。配置帧结构如下帧头0xC1 0xFC长度1字节表示数据域加校验和的长度数据域包括配置命令字、参数区域校验和数据域各字节之和的低8位比如要设置E22的地址为0x0001配置命令字是0x00参数写入的帧就是C1 FC 04 00 00 01 00 01其中04是后面数据长度00 00 01 00共4字节最后的01是校验和0x000x000x010x000x01。3.2 MicroPython核心代码发送和接收双向透传用MicroPython写这个逻辑非常简单主要就是两个UART的初始化和一个主循环里的数据搬运。以下是我测试通过的完整代码from machine import UART, Pin import time # 初始化业务串口 UART0连接外部传感器/设备 uart_business UART(0, baudrate9600, txPin(0), rxPin(1), bits8, parityNone, stop1, timeout200) # 初始化E22模组串口 UART1连接LoRA模块 uart_lora UART(1, baudrate9600, txPin(4), rxPin(5), bits8, parityNone, stop1, timeout200) # 模式控制引脚M0GP6, M1GP7都拉低为正常透传模式 m0 Pin(6, Pin.OUT) m1 Pin(7, Pin.OUT) m0.value(0) m1.value(0) # 可调变量 BUFFER_SIZE 128 last_time time.ticks_ms() # 业务串口 - LoRA def business_to_lora(): if uart_business.any(): data uart_business.read(uart_business.any()) if data: uart_lora.write(data) print([TX] {}.format(data.hex())) # LoRA - 业务串口 def lora_to_business(): if uart_lora.any(): data uart_lora.read(uart_lora.any()) if data: uart_business.write(data) print([RX] {}.format(data.hex())) while True: business_to_lora() lora_to_business() # 简单防抖降低主循环空转频率 time.sleep_ms(10)这段代码的核心逻辑就是轮询两个串口的接收缓冲区一边有数据就往另一边搬。MicroPython的uart.any()返回当前接收缓冲区中的字节数read(n)读取最多n个字节。需要注意timeout参数它表示接收不到完整数据时的超时时间单位是毫秒。设置成200毫秒意味着如果一帧数据分两次到达第二次到达距第一次超过200毫秒就会返回已收到的数据。如果业务设备发送的数据帧比较大或者发送间隔不稳定这个超时时间需要适当调大。3.3 接收超时判断串口转无线最容易遇到的“拆包”问题用上面这段代码做透传时第一个遇到的问题就是串口数据的“拆包”。比如你用一个串口调试助手给Pico发了一帧60字节的数据MicroPython的UART可能在第一次read()时只读到了30字节剩下30字节还在路上。如果你此刻立刻把这30字节传给E22E22会认为这是一次完整的数据包打包发到空中接收端拿到的就是前半截数据后半截30字节到达后又触发一次发送接收端再收到后半截结果就是完整数据被拆成了两帧。解决拆包问题的标准做法是“超时组帧”即收到第一个字节后启动一个定时器如果连续N毫秒没有新的数据进来就认为当前帧结束再把这批数据一起转发出去。上面的代码之所以能工作靠的是timeout200这个超时参数但这样做的问题在于如果业务设备持续以稳定的间隔发送数据比如每100毫秒发一帧200毫秒的等待时间会导致每帧数据延迟200毫秒才被转发实时性受影响。更好的做法是用中断加计时器实现精确的超时判定。我最终用的方案是from machine import Timer rx_buffer bytearray() frame_ready False def on_uart_data(uart): global rx_buffer, frame_ready while uart.any(): rx_buffer.extend(uart.read(1)) # 重置定时器 timer_frame.deinit() timer_frame.init(period20, modeTimer.ONE_SHOT, callbackframe_timeout) def frame_timeout(t): global frame_ready frame_ready True # 定时器初始化 timer_frame Timer(-1) # 中断注册 uart_business.irq(handleron_uart_data, triggerUART.IRQ_RX)这样当最后一个字节到达后20毫秒内没有新数据就认为当前帧接收完毕置一个frame_ready标志。主循环里检测到frame_ready为True时再把rx_buffer里的完整数据一次性发给E22。如果收到的帧很长可以在“轮询超时”和“最大缓冲长度”之间做一个折中比如超过256字节的帧就直接按256字节切分。LoRA的空中包长一般建议不超过200字节所以这个限制并不算苛刻。3.4 模式切换与AT指令配置不要让E22一直跑默认参数E22-900M22S默认的工作参数不一定适合你的场景至少有三项需要确认串口波特率、空中速率、信道。默认串口波特率是9600空中速率也偏低如果你需要传较大的数据块建议通过AT指令把它调高。E22支持的最大串口波特率是115200对应的空中速率可以通过参数组合设置。在代码里动态切到配置模式的流程是def enter_config_mode(): m0.value(1) m1.value(1) time.sleep_ms(100) # 等待模块进入配置模式 def exit_config_mode(): m0.value(0) m1.value(0) time.sleep_ms(100) # 等待模块进入正常透传模式 # 示例设置E22信道为28 enter_config_mode() uart_lora.write(bytes.fromhex(C1 FC 04 00 00 1C 00 1C)) time.sleep_ms(200) exit_config_mode()这里C1 FC 04 00 00 1C 00 1C的解析是帧头C1 FC长度04配置命令字00表示写寄存器寄存器地址00信道信道值1C十进制28保留字节00校验和1C。不同版本的E22固件命令字和寄存器地址可能略有差异具体以亿佰特官方手册里的“寄存器映射表”为准。切到配置模式后发送的数据是ATE格式正常模式下再发同样的数据就会被当业务数据发出去了所以配置完成后一定要切回正常模式。另外我踩过的一个坑是频繁切换模式时如果两个模式切换之间间隔太短小于100毫秒E22还没来得及完成内部状态机迁移你发的AT指令会直接丢失。解决方案是模式切换后至少等200毫秒再操作串口。4. 实测效果与应用场景这玩意儿到底能跑多远、能干什么活4.1 拉距测试记录与参数解读硬件和代码都准备好了最关键的问题是到底能传多远我在一个周末做了两组实测一组在市区公园一组在郊外空旷河堤。测试条件如下两端都是E22-900M22S板载天线版本串口波特率9600空中速率默认配置发送端用Pico每秒发送一帧20字节的数据接收端用USB转串口接到笔记本电脑用串口调试助手看数据市区公园测试结果距离200米内丢包率0%400米左右开始出现零星丢包大概不到1%500米后丢包率上升到5%左右。这个结果在预期之内因为公园里树木密集LoRA虽然抗干扰能力好但Sub-GHz信号在潮湿的树叶中衰减非常严重树叶含水量越高射频损耗越大。郊外河堤测试结果500米内丢包率0%1公里丢包率0%1.5公里时偶尔丢一帧2公里处丢包率约8%。这个结果符合E22-900M22S的官方参数22dBm发射功率接收灵敏度-136dBm理论视距传输距离在3到5公里之间。实际能达到2公里以上已经不错了因为地面曲率和环境反射的影响不可避免。需要特别说明的是这两组测试用的都是板载天线。如果你换成外置的吸盘天线或八木天线距离还能再提升至少30%到50%。板载天线的增益一般在0到1dBi左右方向性也差而外置玻璃钢天线增益能做到3到5dBi对通信距离的影响非常大。4.2 应用场景从传感器传感到Modbus远程控制都能做串口转LoRA这个组合能做的事情远不止传感数据上报。我做的第一版应用是给老家温室大棚里的一组土壤湿度传感器加无线回传。传感器输出的是RS485信号我用一个RS485转TTL的模块接到Pico的UART0Pico通过Modbus RTU协议去轮询传感器数据再把结果封装成简单文本帧通过E22发到离大棚200米外的屋子里的接收端。接收端再接一个E22到树莓派4B用Python脚本把数据存到SQLite里手机在上面的网页里就能看到实时湿度。整个系统最花时间的地方其实不在LoRA而在于Modbus RTU的轮询策略。Modbus的响应时间一般是10到50毫秒每个寄存器只能读16位数据一次完整查询可能要发多条报文。你要在Pico代码里做Modbus主站逻辑然后还要考虑LoRA空中的传输时延。LoRA默认空中速率下一个20字节的数据包在空中飞行时间大概在150到300毫秒之间如果你按Modbus的超时时限来等LoRA回复分分钟就超时报错。解决方案是自定义一个简化版的应用层协议把Pico采集到的一系列寄存器值打包成一个长报文一次性通过LoRA发出去接收端再统一解析。这其实是LoRA透传应用的常见模式不要把底层的轮询协议直接映射到无线链路上而是要针对无线链路的“高延迟、低带宽”特性做一次协议变换。另一个典型的应用场景是RS232转LoRA的数据采集比如连接一个老式的串口仪表。我可以把仪表输出的ASCII字符串直接交给Pico转发接收端再用串口调试助手看。由于RS232的电平是±12V必须在Pico和RS232设备之间加一个MAX3232芯片做电平转换其他逻辑和上面的透传代码完全一致。5. 常见问题与排查技巧实录我踩过的坑希望你跳过5.1 串口调试助手看不到数据怎么办这是最多人遇到的问题。现象是Pico和E22都通了代码也没报错但串口调试助手上一片空白。排查顺序我建议按照以下几个步骤来第一确认USB转串口驱动装好了。CH340和FTDI是市面上最常见的USB转串口芯片Windows 10以上系统一般能自动识别但某些山寨CH340芯片需要手动安装驱动而且还要注意你的串口调试软件选的是不是正确的COM口号。打开设备管理器看“端口(COM和LPT)”下面有没有出现带黄色感叹号的设备有就说明驱动有问题。第二确认波特率一致。Pico代码里设置的波特率、串口调试助手右上角的波特率、E22模组的串口波特率这三者必须完全一致。我曾经调试时Pico设成9600调试助手却用了115200数据当然是一堆乱码。排查时在Pico代码里加一句print(UART Ready)如果调试助手能看到这行字符说明链路没问题问题出在数据转发环节。第三检查TX和RX是否接反。这是串口调试永远的经典坑。Pico的GP4是UART1_TX要接E22的RXGP5是UART1_RX要接E22的TX。很多人习惯性地把同名的TX和TX接在一起结果自然是收不到数据。用万用表量一下引脚电平也行空闲时TX引脚应该维持在3.3V高电平如果测出来是0V那引脚可能被配置成了输入模式或者接错线了。5.2 能发送但收不到或者丢包严重优先查什么如果你用PC下发数据到PicoPico能通过E22发出去但另一端的E22收不到问题可能出在三个方面。一个是E22的频率和信道不匹配。E22-900M22S工作在850到930MHz频段具体频率由信道号和频偏参数决定。两端设备的信道号必须一致否则就是鸡同鸭讲。检查方法很简单在配置模式下分别读一下两端设备的信道寄存器值确保相同。第二个可能的问题是空中速率不匹配。E22在空中速率配置不一致时两端设备无法同步解调数据表现就是发送方以为发送成功了因为串口数据已经进FIFO接收方却什么都收不到。注意E22的空中速率和串口波特率是两码事前者指LoRA无线链路的调制速率后者指E22和MCU之间有线串口的速率。很多人调完串口波特率就忘了还有空中速率这回事。第三个隐蔽的问题天线没接好。用IPEX天线座的时候天线扣子没有完全按到底或者天线线缆内芯接触不良会导致射频功率反射回模块内部不仅通信距离大幅缩短还可能烧坏射频前端。我建议每次测试前都拧一拧IPEX接头确认扣合到位如果你是直焊天线到板卡上至少把焊点用万用表量一下导通性。5.3 数据能通但内容乱码别急着怀疑LoRA如果两端设备都在各自串口助手上能看到数据但收到的内容是乱码问题几乎肯定出在链路两侧的串口参数上。最典型的就是波特率不匹配或者数据位/停止位/校验位配置不一致。E22默认是8N18数据位、无校验、1停止位如果你的业务设备用的是8E1或者7E1那么数据在某些字节上就会偶发错误。这时候不要盲改LoRA参数先直接在Pico上绕过E22做回环测试把UART0的TX引脚直接短接到UART0的RX引脚通过串口助手发送数据看能不能原样收到。如果回环测试正常再把Pico的UART0 TX接到E22的TX注意这里是TX接TX做监听用串口助手发送数据看E22输出端能不能解析出正确帧。这样一级一级定位很快就能找到问题出在哪一段。另一个乱码原因是电气干扰。E22和Pico之间的杜邦线如果太长超过20厘米而且旁边走的是电机驱动线或者电源线高速串口信号很容易被干扰。特别是使用9600以上波特率时杜邦线的分布电容会导致信号边沿变缓进而产生误码。最稳妥的办法是把E22模块直接焊接在Pico的排针上或者用一块小的PCB转接板尽量缩短连线距离。实在要用杜邦线就选短线并且和电源线保持距离。5.4 E22模块发热严重或者工作电流异常大正常工作时E22-900M22S的静态电流大概在几毫安左右发射时峰值电流约120mA。如果你摸上去明显发烫或者电源指示灯暗淡大概率是天线没有正常接载射频功率全部反射回模块内部变成热量耗散掉了。立即断电检查天线连接不要长时间让模块在无天线状态下发射这会导致射频PA性能退化甚至永久损坏。另一种可能是模块进入了异常模式比如M0和M1引脚悬空导致电平不确定模块在省电模式和正常模式之间反复横跳。Pico的GPIO默认有下拉电阻但如果你用外部电路控制模式引脚务必确保上电时序正确先让Pico把GP6和GP7设置成低电平再给E22上电避免E22上电瞬间读到高电平进入错误模式。6. 扩展方向与进阶思路一个透传单元还能玩出什么花6.1 双向通信协议从单向上报到请求响应上面实现的透传是双向的但实际上很多应用只需要单向上报比如温湿度传感器每分钟上报一次数据。单向上报的代码逻辑更简单几乎不需要考虑接收逻辑。但如果你要做远程控制比如用手机通过网络控制大棚里的风扇那你就需要一个双向请求响应协议。我的建议是在透传层之上再封装一个轻量级协议。比如每条业务数据帧用一字节标识帧类型一字节表示目标节点ID两字节表示帧序号然后是数据域最后加两字节CRC16校验。帧格式可以自定义但一定要包含节点ID和帧序号。节点ID用来区分网络中多个LoRA节点帧序号用来检测丢帧和重复帧。CRC16建议自己写一个查表法的实现LoRA虽然空中链路自带CRC但MCU串口到E22模块这一段有线链路也可能出错应用层做一次CRC完全有必要。实现了这种基础协议后你就能做到主机下发查询指令从机收到后回传数据。比如主机发送0x01 0xAA 0x05 0x00 0x01 0x30 0x31 0x32 0x33 0x34 0x55其中0x01是帧类型请求0xAA是目标节点ID0x05是数据长度后面是数据最后是CRC。从机解析成功后回传相同格式的响应帧。这套协议用在上面的Pico代码里只需在lora_to_business函数中多一步解析逻辑根据帧类型决定是存数据还是回传响应。6.2 低功耗设计电池供电时怎么活得更久E22-900M22S和Pico的组合如果直接电池供电一个是Pico板载的LDO静态功耗就很高另一个是E22经常处于监听状态也比较费电。要做低功耗版本你需要从两个方向同时入手。一个是在Pico代码里使用machine.lightsleep()配合RTC定时唤醒。Pico在lightsleep模式下电流可以降到几十微安每10秒唤醒一次采集数据并通过E22发送。E22那边则要把M0和M1设置成01模式即唤醒模式WOR。WOR模式下E22会周期性醒来监听空中唤醒信号一般来说功耗低很多但代价是信道占用时间变长因为E22需要用较长的前导码确保能被对方监听识别到。E22的WOR周期通过配置寄存器设置周期越长越省电但响应延迟也越大。实际使用时要根据你的数据上报频率调整比如每10秒上报一次的话WOR周期设为1秒就够了。另一个方向是硬件上换更合适的电源方案。Pico原板不适合超低功耗设计你可以直接用RP2040芯片自己做最小系统板省略板载的Buck-Boost和USB转串口芯片将待机功耗降到微安级。E22的供电则可以用一个低静态电流的LDO比如TPS782系列或HT7333它们自身的静态电流只有几个微安不会成为耗电大户。6.3 多节点组网从点对点到简单星形网络单对单的LoRA透传只是入门真正的物联网场景往往是多个节点回传到一个中心节点。E22-900M22S支持通过地址和信道来区分不同的目标。最简单的星形组网方式是中心节点协调器使用一个固定地址子节点轮流发送数据每次发送前通过AT指令切换到配置模式把目标地址改成中心节点的地址再切回透传模式发送。这个方案虽然能用但每次切换模式都有延时而且无法处理同时发送时的碰撞。更好的方案是使用E22的固定地址发送模式你将每个子节点的E22地址设为它们的源地址中心节点地址设为广播地址或者统一的目标地址。E22在收到带地址的数据后如果地址匹配就输出不匹配则丢弃。代码上不同子节点只需要修改本机地址即可。至于信道区分主要是为了避免不同区域的LoRA网络互相干扰把相邻区域的节点配置到不同的信道上传输效率会更高。多节点组网最大的挑战是碰撞避免。LoRA协议的A类设备本身没有CDMA机制多个节点同时发射时会发生碰撞导致数据丢失。简单的时分方案是给每个节点分配不同的发送时隙比如节点1在每秒的第0到200毫秒窗口发送节点2在200到400毫秒窗口发送以此类推。实现时只需要在Pico代码里对时间戳取模判断窗口是否归属自己。时隙重叠的问题可以通过读取E22的空闲信道检测CAD功能来减少撞包概率不过这会增加代码复杂度和功耗小规模场景没必要。写在最后几个让我印象深刻的调试心得做这个项目前后花了大半个月最大的体会是串口转LoRA这种“看起来简单”的东西真要稳定可靠运行比想象的复杂得多。最开始我以为只要把串口数据原样搬到E22就能通结果卡在了接收拆包和天线上好几天才找到原因。后来用超时组帧解决了拆包又重新画了PCB解决天线净空问题整个系统的通信距离和稳定性才有了质的提升。如果你准备跟着这篇文章做一遍我有几个建议可以说一下。第一调试环境一定要配好用串口调试助手之前先检查CH340或者FTDI驱动这是所有工作的基础第二不要急着做完整功能先让两端串口回环测试通过再用E22点对点透传最后才加业务逻辑三级递进能省下很多调试时间第三E22模组的手册一定要常备在手边寄存器地址和帧格式查起来很方便不要凭着记忆写配置代码。后续我计划在这个串口转LoRA单元基础上加上太阳能板和锂电充电管理做成一个真正的室外无线采集节点。E22-900M22S的功耗表现配合休眠策略再加上一块2000mAh的锂电池理论续航做到半年以上应该问题不大。等这套方案测试完我会再整理一篇低功耗版本的实现记录到时可以直接参考。