1. 为什么我要做这个“串口转LoRA”单元先说一下背景。前阵子帮朋友改造一个户外环境监测点现场已经有成熟的RS232/RS485传感器和采集终端但布线成本实在离谱一趟线拉下来接近千元。我第一反应是用Wi-Fi或蓝牙中继但现场有围墙、金属棚、大片空旷地实测2.4G信号穿两道墙就基本报废了。后来换成LoRA思路几百米到两三公里的无线链路功耗还低很适合这种“小数据量、远距离、低速率”的场景。项目标题里提到的“串口转LoRA模块单元”说白了就是把一路标准UART串口通过E22-900M22S模组变成LoRA无线链路再配合树莓派Pico做控制和数据缓冲。这里“串口”可以是对外的一个接口也可以是Pico本身的硬件串口。用户拿到的设备如果是串口输出接上这个单元就能变成无线节点下行再配一个接收端就是一套完整的点对点无线透传系统。E22-900M22S是一颗工作在850MHz~930MHz频段的LoRA射频模组内部核心是Semtech SX1262方案最大发射功率22dBm接收灵敏度能到-136dBm左右具体和空中速率有关。它把射频部分、功放、滤波、以及串口协议栈都封装好了对外直接是TTL电平的UART接口。树莓派Pico则负责按需配置模组、转发串口数据、管理收发状态。两个东西加在一起就是一套不需要懂射频前端细节、也能快速落地的串口转LoRA方案。这篇文章会把我的完整设计思路和踩坑记录分享出来适合正在做无线数据采集、远程设备控制、或者想把老旧串口设备“无线化”的开发者参考。2. 选型逻辑为什么是E22-900M22S Pico而不是其他组合2.1 LoRA相比Wi-Fi/蓝牙/NB-IoT优势到底在哪里先说结论LoRA不是万能的它只适合“小数据量、低速率、远距离、低功耗”这四件事同时成立的场景。我的场景是每5分钟上报一次温湿度、电池电压和开关状态每次数据不超过100字节传输距离要求至少500米还要穿过两堵砖墙。这个需求Wi-Fi办不到距离太短、蓝牙办不到距离更短、4G/NB-IoT可以但功耗和资费不划算。LoRA的扩频调制方式决定了它在相同的发射功率下能比FSK等窄带调制获得更远的通信距离代价是速率极低通常在0.3kbps~62.5kbps之间。如果你的项目是视频传输、语音对讲、或传感器秒级上报大量波形数据那LoRA并不合适别硬套。E22-900M22S的官方标称传输距离在“空旷可视、2.4kbps、22dBm”条件下可以到3~5公里我实测在市区非视距环境下大概是500~800米隔两堵24cm砖墙稳定通信距离约120米左右具体数据后面章节会给表格。2.2 E22-900M22S模组的关键参数与封装细节E22-900M22S是亿佰特Ebyte推出的一款UART串口转LoRA模组重点参数如下参数项数值/说明核心芯片Semtech SX1262工作频段850~930MHz软件可配需按当地法规选择合法频段发射功率可配置最大约22dBm约158mW接收灵敏度约-136dBm 2.4kbps通信接口TTL UART3.3V电平默认串口参数9600bps, 8N1, 透传模式模块尺寸约25mm x 15.5mm带屏蔽罩天线方式外置天线IPEX座或板载天线视具体型号而定它提供三种封装型号E22-900M22S外置天线、E22-900M22S(PCB)板载PCB天线、以及带SPI接口的版本。我选的是外置天线版本因为调试时换天线方便后期如果要做成产品可以换板载天线版本省成本。模组对外引脚里最重要的一组是VCC、GND、M0、M1、RXD、TXD、AUX。M0和M1是工作模式选择引脚AUX是状态指示输出RXD/TXD是串口数据线。它内部封装好了LoRA协议栈对外看起来就像一个“无线串口”你给它串口发什么对方就收什么不需要自己处理LoRA调制解调。2.3 树莓派Pico在这个单元里扮演什么角色树莓派Pico用的是RP2040双核Cortex-M0主频最高133MHz板载2MB Flash硬件UART有两路GPIO都支持中断3.3V逻辑电平和E22-900M22S的TTL电平完全兼容不需要额外电平转换芯片。价格不到二十块MicroPython生态成熟很多做智能硬件的朋友已经很熟悉了。在这个单元里Pico扮演的是“预处理器和控制器”而不是纯透传的“线缆替代品”。具体职责是上电后通过M0/M1引脚把模组切到配置模式设置工作频率、空中速率、发射功率、串口波特率然后存起来。切回透传模式后把外部串口设备送来的数据读入缓冲区再转发给E22-900M22S从E22-900M22S收到的数据也缓存后转发给外部串口。通过AUX引脚判断模组当前是否忙避免在模块还没准备好时就往它的UART写数据造成丢包。如果以后要组网还可以在Pico上做地址过滤、数据分包、CRC校验、重传逻辑。也就是说Pico不是“必须存在”的——如果你只是纯点对点透传甚至可以直接把外部设备的串口接到E22-900M22S上就能用。但一旦涉及多节点、动态配置、状态上报Pico的价值就出来了。3. 模块引脚、工作模式与推荐参数配置3.1 M0/M1/AUX引脚到底怎么用E22-900M22S的四种工作模式由M0和M1两个引脚的高低电平组合决定具体如下M1M0工作模式说明00一般模式透传串口数据直接无线发送能收到对端数据唤醒功能开启01唤醒模式透传发射前会加唤醒码适合接收方处于省电模式时使用10省电模式透传接收方低功耗监听发射方需用唤醒模式才能叫醒它11配置模式串口指令可读写内部寄存器数据不参与无线收发实际项目中我把M0和M1都接到了Pico的GPIO上而不是直接接死。原因很简单我需要先在配置模式下写参数再切回一般模式做透传。如果用跳线帽固定电平每次改参数都得断电拆外壳太麻烦。用GPIO控制后程序里拉高拉低就能切换。AUX引脚是开漏输出内部上拉到VCC含义是上电初始化完成后AUX从低变高表示模组就绪。收到无线数据后AUX拉低表示正在输出数据到串口。串口数据写入模组后AUX会保持低电平一段时间直到数据从无线口发出完毕再恢复高电平。这第三个状态最关键。很多朋友踩的坑就是往串口丢了一帧数据没等AUX变高就发下一帧结果是前一条还没发完后一条已经覆盖了模块的发送缓冲区数据就这么丢了。3.2 推荐参数配置频率、空中速率、发射功率、地址E22-900M22S通过AT指令配置指令示例在配置模式下通过串口发送ATPRF19.2K // 设置空中速率 ATPOWER22dBm // 设置发射功率 ATUART9600,8,N,1 // 设置串口波特率 ATCH62 // 设置信道频率偏置 ATADDH0 ATADDL0 ATCS0 // 同步字点对点可保持默认 ATWRITE // 保存配置到Flash我的推荐配置如下这是一组在“距离、速率、功耗”之间比较均衡的取值参数推荐值说明串口波特率9600通用性好外部设备默认值多是9600空中速率19.2kbps距离和速率的折中若追求最远距离降到2.4kbps发射功率22dBm功耗不是大问题且需要距离时开到最大信道/频率默认信道多组设备共存时务必错开信道数据格式8N1透传默认这里特别提醒串口波特率和空中速率是两个不同的事情。串口波特率是本地MCU到模组之间的有线速度空中速率是模组与模组之间的无线速度。如果串口波特率远高于空中速率数据就会在模组的缓冲区里排队一旦数据量大缓冲区溢出就是丢包。这部分我单独在下一章算一笔账。4. 吞吐量与波特率匹配一笔很多人没算清的账4.1 空中速率 vs 串口波特率的数学关系E22-900M22S的内部缓冲区并不是无限大官方资料显示每包最多约200字节。这里说的“包”是指一次无线帧它包含前导码、CRC、以及你的串口数据。假设你设空中速率19.2kbps这个数字并不等于“每秒能传19200位用户数据”因为LoRA物理层还有编码冗余、前导码开销。以SX1262为例空中速率19.2kbps时实际有效载荷速率大约是标称值的七到八成。再算上LoRA帧结构里的头、CRC等一字节有效数据对应空中大约11个bit1起始位8数据位1停止位少量帧开销。所以实际可承载的串口数据量大约是19.2kbps / 11 ≈ 1.75KB/s如果你的串口波特率是9600理论上串口数据率是960字节/秒远小于1.75KB/s所以一般不会积压。但如果把空中速率调到2.4kbps那有效承载能力大约只有218字节/秒这时候串口还按9600发数据肯定排队连续发几秒就丢包。这就是我在第3.2节推荐19.2kbps的原因。多节点组合时还要把协议开销算进去——如果一包数据只发20字节但前导码就有好几个字节的时间实际的“包效率”很低单向传输的最高包速率大概也就每秒几包到几十包。4.2 纯透传能跑多快实测参考我在实际测试中两个E22-900M22S模组空中速率设为19.2kbps串口均为9600单次发送128字节连续发送100包损耗情况如下序号发送间隔实际收到丢包率现象1200ms/包100/1000%稳定2100ms/包99/1001%偶尔丢1字节350ms/包93/1007%明显丢包缓冲区溢出从数据可以看出纯透传模式下只要发送间隔太短模组缓冲区就会溢出。要解决这个问题要么降低空中速率和波特率的比值要么在Pico侧增加重传机制要么把数据帧拆小并等待AUX信号后再发下一帧。4.3 什么场景需要“数据分包和重传”如果只是温度传感器每5分钟上报一次那完全不担心速率问题随便丢几百字节都没有压力。但如果是串口屏或者PLC等下位机可能连续吐几百上千字节这时候就必须在Pico层做分包处理从外部串口读入数据先放进一个环形缓冲区。每攒够128字节或遇到帧尾就把这一帧交给LoRA模组发送。发送前必须等AUX引脚为高电平。对端收到后返回一个ACK帧发送端没收到ACK就重传。这套逻辑在Pico的MicroPython里实现并不复杂关键是搞清楚“什么时候算一帧结束”。我习惯用帧尾超时判断串口收数据时如果200ms内没有新字节就认为一帧结束了送去LoRA发送。5. 最小系统搭建接线、供电和样板设计5.1 Pico与E22-900M22S的引脚连接Pico本身有两个硬件UARTUART0选用GP0TX和GP1RXUART1选用GP4TX和GP5RX。我把UART0接E22-900M22SUART1留作对外串口方便连接外部设备或者调试串口。接线表如下E22-900M22S引脚树莓派Pico引脚说明VCC3V3(OUT)3.3V注意电流GNDGND共地M0GP2模式控制M1GP3模式控制RXDGP0 (UART0 TX)模块RX接Pico TXTXDGP1 (UART0 RX)模块TX接Pico RXAUXGP6状态读取输入如果你用的是5V单片机一定要加电平转换但Pico是3.3V所以可以直接连。别接反RXD和TXD这是新手最容易犯的错。5.2 供电设计LoRA发射瞬间电流不可忽视E22-900M22S在22dBm发射时瞬时电流可能在120mA以上虽然只持续几十毫秒但如果用Pico板载的3.3V LDO供电电压跌落会导致模组复位、丢包或者射频输出异常。我的做法是如果只用USB供电在E22-900M22S的VCC和GND之间并联一个100uF钽电容加一个0.1uF陶瓷电容尽量贴近模组电源脚。如果做独立电池供电用一节3.7V锂电池先经LDO降到3.3VLDO旁边同样加大电容。不要把Pico的VSYS和3V3混着用最好让Pico的USB口供电、外部设备单独供电但地线必须共地。实测下来同样的固件、同样的频段供电好和供电差的两个板子丢包率可以从5%降到接近0%。所以先检查电源再排查软件这是排错顺序。5.3 天线位置模组天线离Pico的USB座至少5厘米E22-900M22S外置天线通过IPEX座连接天线要尽量远离Pico的USB接口、电源线和数字信号线。USB口在工作时会有高频噪声天线太近会抬底噪灵敏度下降。如果是板载PCB天线版本这个问题更严重因为天线就在板上必须严格按照模组说明书的净空区要求画板。我在样板阶段没太在意天线位置把天线弯到了USB线旁边结果同一堵墙测试距离从120米直接掉到60米左右。后来把天线横过来远离USB线距离才恢复正常。别小看这几厘米。6. 固件实现从透传到可靠的串口转发6.1 MicroPython快速原型代码Pico开发用MicroPython非常快下面是一套完整的点对点透传基础代码包含初始化、模式切换、数据转发。# main.py - Pico E22-900M22S 串口转LoRA单元 from machine import Pin, UART import time # 引脚定义 uart_lora UART(0, baudrate9600, txPin(0), rxPin(1)) # 接E22模块 uart_ext UART(1, baudrate9600, txPin(4), rxPin(5)) # 对外串口 M0 Pin(2, Pin.OUT) M1 Pin(3, Pin.OUT) AUX Pin(6, Pin.IN) def set_mode(mode): # mode: 0透传, 3配置 if mode 0: M0.value(0) M1.value(0) elif mode 3: M0.value(1) M1.value(1) time.sleep_ms(50) def wait_aux_high(timeout_ms1000): start time.ticks_ms() while time.ticks_diff(time.ticks_ms(), start) timeout_ms: if AUX.value() 1: return True return False # 上电初始化 set_mode(3) # 进入配置模式发送AT指令可在此处 # 如果要用AT指令配置可以在这里写 # uart_lora.write(bATPRF19.2K\r\n) # time.sleep_ms(100) # uart_lora.write(bATWRITE\r\n) set_mode(0) # 切回透传 wait_aux_high() # 主循环双向转发 while True: if uart_ext.any(): data uart_ext.read() if data and wait_aux_high(): uart_lora.write(data) # 等模块把数据发完防止下一包覆盖 time.sleep_ms(10) if uart_lora.any(): data uart_lora.read() if data: uart_ext.write(data)这段代码里最难的是那个wait_aux_high()之后的time.sleep_ms(10)。如果不加这个小延时外部串口连续来数据时主循环会立刻往LoRA模组再写数据而模组还在发上一帧就可能丢。10ms是我按19.2kbps空中速率估算出来的经验值如果你把空中速率降到2.4kbps这个间隔要加长到50ms以上。6.2 C SDK实现中断接收更好MicroPython适合原型验证但如果要做可靠通信我建议还是切到Pico官方C SDK。C语言的好处是可以直接注册UART中断用环形缓冲区处理数据不用在主循环里轮询。核心逻辑如下uart_lora和uart_ext都注册RX中断收到字节存入各自的环形缓冲区。主循环里检查ext_rx_buf有没有数据有就整段取出等AUX高后发给uart_lora。检查lora_rx_buf有数据就转发到uart_ext。定时器每200ms检查一次ext_rx_buf是否还有数据如果超时没新数据就把当前积累的数据当成一帧发给LoRA。用中断的好处是外部设备不管什么时候来数据MCU都不会漏收。MicroPython的uart.any()和uart.read()在数据流快速到达时偶尔会有内核调度延迟导致串口数据被覆盖C下基本没有这个问题。6.3 数据帧设计别裸发加头部和校验即便LoRA模组本身自带CRC校验也只是保证“无线帧”没错而不是“你的应用帧”完整。我的建议是在Pico层加一个简单的帧头、长度、payload、CRC16例如帧头 2字节 0xAA55 长度 1字节 数据 1~ 200字节 CRC16 2字节发送端把外部串口来的数据打包成这样的帧接收端解析后只把payload部分转给外部串口。这样既能校验完整性又方便以后做多节点组网和重传。为什么不能用模组的透传功能直接发因为透传模式下你没法知道一帧数据的边界在哪里尤其是对端连续发多个短帧时接收端无法区分“这是两帧数据”还是“一帧完整数据”。7. PCB布局与板载天线注意事项不是随便画就能用7.1 关于“LoRA模组板载天线怎么画”的热搜问题很多人在论坛问E22-900M22S板载天线版本怎么画PCB。说句实在话如果是自己DIY调试我更推荐用外置天线版本的模组可以省去天线设计的麻烦。但如果要做产品板载天线不可避免那就得注意几个关键点天线下方要“净空”正反面都不能铺铜不能走任何信号线。净空区边界用一圈过孔做围栏用来隔离地平面。天线区域离地平面边缘要有约3~5mm距离天线正下方那一层板尽量不要有地平面。模组天线馈点到天线的走线要控制阻抗50欧姆。FR4板材1.6mm厚度时表层50欧姆微带线的线宽大约在3mm左右这对板载天线来说太宽了所以一般会改成共面波导形式线宽可以缩到1~1.2mm。天线馈点附近预留π型匹配网络一个串联电容加两个并联电容或者0欧/磁珠位置因为实际板子装好后要用网络分析仪调匹配。更稳妥的方法是直接去下载亿佰特官方提供的原理图和PCB封装库它们是经过测试的参考设计照着画别自己瞎发挥。7.2 阻抗匹配和底噪控制的心得我在画样板时接手过一块别人画的板子模组天线下面没有开净空区整个地层全铺满了。结果是发射功率只有标称的一半不到接收灵敏度也掉了将近10dB。用频谱仪看发射频谱明显带毛刺杂散发射超标。后来重新按照官方参考设计布局问题立刻消失。当然没有网络分析仪也能做基本判断用两个相同的板子面对面测RSSI如果同样的距离、同样的功率设置RSSI明显低于官方标称值大概率就是天线匹配或净空区有问题。你也可以用模组的AT指令读取RSSI比如ATRSSI?在E22-900M22S上可以读到对端信号的强度这个数值是判断链路质量最直接的参考。7.3 多层板的层叠建议如果板子层数紧张建议至少四层板顶层走信号和模组第二层完整地平面第三层走电源和少数信号底层继续铺地。天线净空区在所有层都要禁布铜。如果只有两层板那更要严格保证天线区域下方没有地天线周围的铺地也要留好距离。另外E22-900M22S模组底部有散热焊盘要打过孔连接到主地层这有助于模组在长时间满功率发射时散热。虽然LoRA模组功耗不高但连续发送时外壳温度还是能感受到明显上升散热焊盘连地更稳妥。8. 实测数据与调试工具怎么判断单元是否合格8.1 距离与RSSI实测参考我用这套单元做了大量测试测试条件发射功率20dBm空中速率19.2kbps波特率9600园区环境接收端接标准外置胶棒天线。结果如下场景距离实测RSSI丢包率100包备注室内同房间5m-55~-65dBm0%正常隔一堵砖墙30m-85~-95dBm0%正常隔两堵砖墙120m-100~-110dBm0~1%临界偶发室外视距300m-90~-100dBm0%稳定室外视距800m-110~-120dBm1~3%可勉强使用室外视距1.2km-120dBm以下10%不推荐同一套硬件如果把空中速率从19.2kbps降到2.4kbps室外视距1.2km也可以跑到接近0%丢包但数据传输速率会低很多。所以你要先明确项目最看重距离还是速率再定参数。RSSI数值我用两个办法验证过一是模组AT指令读到的值二是频谱仪实际测量的信号强度两者误差在3dB以内还算可信。8.2 串口调试过程中必用的几类工具串口调试助手Windows下我用SSCOM或者XCOM发送AT指令、查看收发数据都方便。macOS下用minicom或者Serial Studio。CH340/CH341/USB-TTL工具E22-900M22S是3.3V TTL电平调试的时候不要用5V的USB转TTL直接怼需要确认工具支持3.3V跳线。Pico自带USB口虽然也能做串口调试但它是模拟出来的CDC串口在配置LoRA模组时不如外接USB转TTL稳。逻辑分析仪如果你怀疑串口数据错乱或丢字节直接把逻辑分析仪夹在Pico的GP0/GP1上看波形能一眼定位波特率是否匹配、是否多发了字节。我习惯用Saleae或国产的几百块逻辑分析仪配合 PulseView 即可。频谱仪/接收机如果想做更正式的射频验证可以用RTL-SDR加SDR#看E22-900M22S发射的频谱检查频偏和杂散。普通项目不做也行。8.3 回环测试的接线陷阱调试时最典型的操作是“一发一收”两个模块对测。很多朋友会把两个模块直接面对面接线A模块的TXD接B模块的RXDA模块的RXD接B模块的TXD。这样做没错但如果你用USB转TTL同时连两个模块要特别注意共地。另外你如果用同一个Pico的UART0既接E22模块又接USB调试串口那就会冲突因为一个UART只能被一个设备占用。我的建议是LoRA模组接UART0调试串口独立走USB口Pico自带CDC外部设备接UART1。这样你既能看到Pico的打印日志又能控制LoRA链路互不干扰。9. 踩坑清单这几个问题浪费了我整整两天9.1 RXD/TXD接反而导致无数据这听起来很基础但我自己就犯过一次帮朋友排查时也遇到过一次。E22-900M22S的RXD是模块的接收引脚必须接Pico的TX引脚TXD是模块的发送引脚接Pico的RX。如果你用杜邦线连接颜色一样很容易插反结果就是两边都收不到数据。这种问题用逻辑分析仪一测就能看出来是哪一端没信号。9.2 没有等待AUX信号就发数据这个问题我在前面反复强调了因为值得。E22-900M22S不是一上电就能立刻接收串口数据的它有初始化时间。如果你在程序里刚 reset 模块就立刻往UART写AT指令大部分情况下第一条指令会被吞掉。我现在的代码里每次切换模式后都会调用wait_aux_high()确保模块真正就绪后再读写。9.3 两地地址/信道不一致导致“一方能发另一方收不到”E22-900M22S的接收端必须和发送端设置相同的ADDH、ADDL地址和信道才能正常通信。我调试时遇到过一边是默认全0另一边是不小心改过信道结果就是只有一方能收到数据。排查方法很简单进入配置模式用ATADDH?、ATADDL?、ATCH?分别读回两端参数逐一对比。9.4 发射时天线悬空模块频偏和杂散超标LoRA模组功率不算大但不接天线长时间发射射频输出端口处于失配状态会导致输出频谱变差、杂散超标极端情况下可能损坏PA。建议在外壳里固定天线调试时也要先接天线再发射。如果你设备需要运输最好在模组输出端加一个0欧电阻做预留出厂测试完再断开。9.5 电源瞬间跌落导致E22模组自动复位前文提到过LoRA发射瞬间电流大劣质USB线或LDO余量不足都会导致模组复位。我遇到过一种很隐蔽的现象单独给模组供电没问题一接上Pico并让Pico同时驱动继电器等负载模组就开始反复重启。最后排查发现是3.3V电源轨上的纹波超过了模组允许范围加了一个470uF电解电容才好。电源问题的排错顺序一定是先查电源再看天线最后才怀疑程序。9.6 MicroPython主循环延时不均匀导致丢字节MicroPython的垃圾回收和调度偶尔会产生毫秒级停顿这在低速率通信场景下问题不大但如果你在100ms间隔之内连续收发大量数据就可能丢帧。建议对实时性要求高的场景直接上C SDK或者减少主循环里其它耗时操作。我现在的项目里不太关键的部分用MicroPython没问题但只要涉及多节点组网和可靠重传我都改回C。9.7 忽略相邻节点干扰LoRA虽然扩频增益高但同频段内如果有多组设备同时工作相邻信道的干扰一样存在。实测两个紧挨着的一发一收设备如果信道间隔不够接收端灵敏度明显下降。解决办法是不同节点组错开信道或者使用不同的扩频因子/带宽组合不过E22-900M22S的透传模式下可调参数有限最直接的做法是信道错开至少1MHz以上。10. 扩展思路一主多从、低功耗休眠和网关化10.1 一主多从轮询方案E22-900M22S本质上更适合点对点但如果只用点对点价值有限。考虑到Pico是双核MCU我目前正在做的一版是“一主多从”轮询方案主节点给每个从节点分配一个ID从节点平时处于省电模式M11, M00主节点通过唤醒模式M10, M01广播唤醒码然后再发送目标地址和数据帧。从节点收到后回传数据。这种方案的难点是时序主节点广播唤醒码后要等从节点从省电模式切换到接收模式才能发正式数据等待时间不好控制。我目前的做法是从节点唤醒后主动发一个“准备就绪”短帧主节点收到后再发数据。实际测试下来4个从节点轮询一次每轮耗时约200ms数据量不大完全够用。10.2 低功耗休眠设计如果要电池供电Pico的功耗其实是不能忽视的。E22-900M22S在休眠模式M11, M01配置模式下不是休眠需要另接SLEEP引脚或使用特定型号下电流可以降到几个微安但Pico在MicroPython下进入休眠比较麻烦。最简单的做法是用一颗低功耗MCU比如STM32L0或Pico W的无线模组备用芯片专门管Pico的供电定时上电完成数据上报后立刻断电。这个方案我还在实验中等稳定了再单独写一篇。10.3 做一个串口LoRA网关很多用户的项目最终都会走上“传感器节点 LoRA 云端”这条路。E22-900M22S这套单元可以作为终端节点网关侧则用另一块PicoE22模组把收到的数据通过USB或以太网转发到树莓派、PC甚至可以直接在Pico上做一个简易MQTT客户端把数据通过Wi-FiPico W上传。这样串口LoRA单元就不只是“延长线”而是一个完整的物联网采集链路网关了。
