企业官网建设流程全解析

最近在做一个点对点无线数传的小项目，手头正好有一对亿佰特E28系列的LoRa模块，就把透传、定点传输、RSSI信号测试，以及MicroPython端的驱动都完整跑了一遍。这套组合做下来，整体体验比我想象中顺利，但中间也踩了几个比较隐蔽的坑。这篇文章就把整个项目从头到尾拆开讲一遍，包括E28模块的选型思路、透传和定点传输两种模式的区别、MicroPython环境下的驱动配置、RSSI测试的具体方法，以及我实测中遇到的问题和解决办法。

开头先说明一点，搜索LoRa模块资料的时候很容易看到一堆“LoRA微调”“LoRA训练”的内容，那是AI大模型领域的参数高效微调技术，跟无线通信里的LoRa（Long Range，远距离无线电）完全不是一个东西，只是名字撞了。本文聊的LoRa是Semtech公司推出的扩频调制技术，用在物联网、传感器数据回传、遥控遥测这些场景里，特点就是传输距离远、抗干扰强、功耗低，代价是速率比较慢。搞清楚这一点，再往下读就不会被热搜词带偏了。

这个方案适合谁参考？如果你手头有E28、E22、E32这类串口LoRa模块，想用ESP32或者其他支持MicroPython的板子做原型验证，或者正准备做果园、仓库、农田这类场景的低速率数据采集链路，那这篇文章应该能帮你省下不少排查时间。

1. 项目拆解：E28 LoRa模块到底能干什么

1.1 透传和定点传输，两个最容易绕晕的概念

E28模块虽然是LoRa射频模块，但你在使用它的时候，绝大多数情况下接触不到LoRa的物理层细节。模块内部已经把协议栈封装好了，你只需要通过串口或者SPI往里面塞数据就行。这也是为什么这类模块在工业场景里这么受欢迎——它不是让你去搞射频设计的，而是让你把精力放在自己的业务逻辑上。

不过，E28本身支持两种数据传输方式，这两种方式的差异非常关键，选错了会导致整套通信逻辑跑不通。

第一种是透传模式。这个名字起得很形象，就是“透明传输”的意思。你往模块串口里写什么字节，对端模块的串口就原样吐出来什么字节，中间所有LoRa协议的封装、解封装、校验、重发机制全部由模块自己处理。在这种模式下，两台设备之间只要保证模块地址和信道设置一致，通电就能通信，完全不关心数据内容。它的优点是简单可靠、零开发成本，缺点是所有节点共用同一个“频道”，缺少寻址能力，不适合多节点组网。

第二种是定点传输模式。这种模式下，发送方在数据前面指定目标节点的地址，模块只把数据投递给对应地址的接收端。你可以把它理解成快递寄件：透传模式相当于你把东西放到一个公共柜台上，谁拿都行；定点传输模式则是在包裹上写了收件人，只有收件人能签收。这样就能做到点对点通信、点对多点通信，甚至广播，为以后挂多节点留出了扩展空间。

用一个更生活化的类比：透传就像你和朋友约在老地方见面，只要双方都知道地点，去了就能见到；定点传输则像寄快递，你要在面单上写清楚收件人地址，快递员才会送对门。

1.2 为什么选E28而不是其他LoRa方案

市面上LoRa模块很多，E22、E32、E19、E01系列，还有各种直接用SX1268/SX1276射频芯片搭的板子，为什么最后选了E28？我当时的判断标准主要有三点。

第一，E28基于Semtech SX126x系列芯片（比如E28-433M20S用的是SX1268，915M版本用SX1262），这颗芯片是目前Sub-GHz LoRa里综合性能比较均衡的一颗。它的接收灵敏度能做到-137dBm级别（SF12、125kHz带宽条件下），相比老款的SX1276系列低了大概几个dB，别小看这几个dB，在射频链路里每个dB都是白花花的通信距离。而且SX126x支持LoRa和FSK两种调制方式，虽然多数E28出厂默认只在LoRa模式开放配置，但万一以后想切到FSK做高速率近距传输，硬件上是留了余地的。

第二，E28模块把SX126x周边整理得很干净。板上集成了阻抗匹配、巴伦、射频开关，你只需要接天线、供电和串口/SPI，不需要自己画匹配电路，这对做产品和做原型的人来说省了一大笔射频调试的时间。我见过不少直接拿SX126x芯片裸调的项目，光天线匹配那块就能折腾一周，而用模块基本上拿来就能通。

第三，生态好。E28虽然是串口模块，但它同样把SPI引脚引出来了，这就意味着你可以用现成的MicroPython SX126x驱动直接操作底层寄存器，做RSSI读取、SF/BW参数动态调整这些透传模式下做不了的操作。这一点在后面RSSI测试环节特别重要，因为透传模式下你能拿到的信号强度信息非常有限，而通过SPI直读寄存器，能拿到当前信道噪声底、最近一包数据的RSSI和信噪比SNR，这些才是判断链路质量的关键数据。

当然，选E28也有代价。LoRa本身速率很低，在SF7、125kHz带宽下，实际有效吞吐也就每秒几千字节，传个温度、湿度、GPS坐标这种小数据包绰绰有余，但你想传图片、传音频文件就完全不现实了。另外Sub-GHz的频段在不同地区是有使用限制的，选型的时候一定要确认你所在地区允许使用的频段范围，型号后面的433M、868M、915M就是频段标识，别买错了。

2. MicroPython环境准备与硬件接线

2.1 硬件清单

我这次用的是一对E28-915M30S模块，工作频段在862~928MHz，标称发射功率最大可以做到1W（30dBm）量级。不过实际跑测试的时候我通常把它配到22dBm左右，已经足够覆盖大部分测试距离了。如果你在国内做433M频段的应用，E28-433M20S也是常见选择，功率20dBm级别，通感能力差不多，就是频段不同。

主控板我用的是一块ESP32-S3开发板，选它的原因很简单：支持MicroPython、SPI接口多、双核跑起来不容易被中断处理拖垮，而且价格便宜、资料多。其实只要你手里的板子支持MicroPython，比如标准的ESP32、RP2040（树莓派Pico）、STM32系列，都可以按同样的思路来做，硬件差异只是SPI引脚号不一样而已。

还需要准备的东西：两套天线（E28通常是SMA座，注意选和频段匹配的天线）、杜邦线若干、一块USB转TTL小板用于给模块做AT配置、一对对讲机或者手机用于测试时沟通，以及一个笔记本电脑跑串口调试助手。

2.2 接线说明

E28模块引脚不算多，但接错一根就能让整个系统静默罢工。我这次通过SPI方式让ESP32直连模块，引脚分配如下：

有几个细节要特别强调。

DIO1这根线很多人会忽略，但SX126x在工作时，接收完成、发送完成、CAD检测这些事件都是通过DIO1引脚产生中断通知主控的。如果DIO1不接，你就只能靠轮询寄存器去判断是否有数据到达，不仅代码变复杂，还容易在MicroPython这种有垃圾回收机制的环境里漏掉数据。所以宁可少接一个不用的GPIO，DIO1必须接上。

供电方面，E28在发射瞬间电流会冲得比较高，30dBm功率版本瞬时电流可能到几百毫安量级。有些开发板的3V3输出能力一般，直接带模块会出现电压跌落，表现就是近距离通信正常、稍微拉远一点就丢包。我的建议是用外部3.3V稳压芯片单独给模块供电，或者至少用一块电流输出能力充足的开发板，并且电源引脚附近并一个100uF左右的电解电容。

电平匹配也值得留意。E28的逻辑电平一般是3.3V，如果你的主控是5V逻辑（比如普通Arduino UNO），需要做电平转换，否则长时间直接怼上去有烧引脚的风险。ESP32、RP2040这些3.3V单片机以及MicroPython常见的主控板都没这个问题。

2.3 MicroPython固件与驱动选择

ESP32-S3刷MicroPython固件这一步，官方文档写得很清楚。下载对应板型的固件后，用esptool先擦除再烧写即可，命令大概是：

esptool.py --chip esp32s3 --port /dev/ttyUSB0 erase_flash esptool.py --chip esp32s3 --port /dev/ttyUSB0 --baud 460800 write_flash -z 0x0 ESP32S3_GENERIC-20240602-v1.23.0.bin

烧完之后，用Thonny或者mpremote连接REPL，能正常执行print("hello")就说明环境OK。

驱动方面，因为我用的是SX126x芯片的模块，我选择了micropySX126x这个开源库，它对SX1262/SX1268的支持比较完整，包含了begin初始化、send发送、receive接收、get_rssi读信号强度这些接口。如果你用的是E28-2G4M20S这种2.4GHz频段的型号，它的射频芯片是SX1280，驱动完全是另一套，千万别搞混。

库的安装也很简单，把整个仓库拖进板子的文件系统里，然后在REPL里import试一下：

from machine import Pin, SPI import SX126x

这里不同版本的库导入路径略有差异，一般以你下载的那个仓库的示例代码为准。装好之后，先写一个最简初始化脚本验证硬件连接是否有问题：

from machine import Pin, SPI from micropySX126x.sx126x import SX126x spi = SPI(1, baudrate=1000000, polarity=0, phase=0, sck=Pin(13), mosi=Pin(11), miso=Pin(10)) cs = Pin(12, Pin.OUT) rst = Pin(14, Pin.OUT) dio1 = Pin(9, Pin.IN) lora = SX126x(spi, cs, dio1, rst, gpio_chip="esp32s3") lora.begin(freq=915, bw=125000, sf=7, cr=5, syncWord=0x12, power=22, currentLimit=140, preambleLength=8, implicit=False, crcOn=True, txIq=False, rxIq=False) print("SX126x init done")

这段代码核心是begin方法里那堆参数：freq是中心频率，单位MHz；bw是信道带宽，125000就是125kHz；sf是扩频因子，我用的是7，属于兼顾速率和距离的默认值；cr是编码率，5表示4/5；power是发射功率，单位dBm；syncWord是同步字，通信双方必须一致才能互通。如果这一串配置能顺利执行完不报错，硬件连接基本就没问题了。

3. 透传模式与定点传输模式的实现

3.1 先把模块配置到透传模式

E28这类串口模块，最常见的用法不是走SPI直读寄存器，而是通过串口透传。虽然两种模式都能通信，但透传模式更适合快速把链路跑起来验证距离和信号。

透传模式下，模块工作参数的配置有两种途径：一种是直接发AT指令，另一种是用亿佰特官方的配置软件，通过USB转TTL连接模块，在图形界面里设置地址、信道、空中速率、发射功率这些参数。我个人的建议是，第一次用的时候先用官方配置软件把所有参数理清楚，后续再用AT指令做动态修改，因为AT指令集在不同批次、不同型号之间偶尔会有细微差异，软件配置反而最不会出错。

假设你通过配置软件把两个模块都设置好了：模块地址设成相同，比如都是0x0001，信道也都一致，空中速率选了一个适中的档位，那透传的代码就极其简单了。ESP32上开一个UART，往里面写数据就行：

from machine import UART, Pin uart = UART(1, baudrate=9600, tx=Pin(43), rx=Pin(44)) uart.write(b"hello from esp32")

对端模块的串口只要接在另一块ESP32上，同样以9600波特率读取，就能收到完整的5个字节。整个过程中，LoRa的调制解调、扩频、纠错全部由E28模块自己完成，MicroPython端不感知任何射频细节。

透传模式最适合的验证场景是链路距离测试。你可以把一台设备放在固定点，另一台拿着往远处走，串口发递增序号，对端记录收到的序号连续性。这样就能快速判断在某个距离和环境下链路是否可靠。很多朋友第一版测试喜欢直接传自己的业务数据，我建议先跑序号，因为序号能立刻暴露丢包和乱序，比看业务数据直观得多。

3.2 切换到定点传输模式

当你开始挂多个节点的时候，透传模式就不够用了。所有模块如果都在同一个信道上广播，A发给B的数据，C也会收到，即使C在业务上不需要，也要在软件层做过滤。定点传输模式就是为了解决这个问题。

定点传输模式的配置重点是“目标地址”。有些E28型号需要在AT配置里指定一个静态目标地址，之后所有串口数据都会发给这个地址；有些型号则支持在数据帧头部动态携带目标地址，这样同一个模块发数据时每帧可以指定不同的接收方。

以后者为例，数据帧格式大致是：

发送方在业务数据前面拼上接收方地址的两个字节，模块会把整个帧发出去，对端模块检查帧头地址，匹配自己的模块地址就上抛数据，不匹配就丢弃。这样A发给B的数据，C即使在同一信道也不会收到，因为地址对不上。

代码实现思路就是给发送函数包一层：

def send_to(addr: int, payload: bytes, uart: UART): frame = addr.to_bytes(2, "big") + payload uart.write(frame)

接收端的处理更简单，因为模块硬件已经把不匹配的帧过滤掉了，串口收到的就是纯负载数据，不需要再解析地址。如果你要支持广播，一般把目标地址设成0xFFFF即可。

我实测下来，定点传输模式在多节点场景下最大的好处不是“省流量”，而是让接收端的业务逻辑变得干净。收到数据就处理，不用关心是不是发给自己的，因为模块已经筛过一遍了。但在做固件开发之前，一定要仔细阅读你手上那个E28型号的数据手册，确认它是静态目标地址还是动态帧头地址，这两种模式的代码写起来差别很大。

3.3 参数怎么选：SF、BW、功率的取舍

不管你用透传还是定点传输，LoRa链路的质量最终都取决于三个关键参数的搭配：扩频因子SF、信号带宽BW和发射功率。这三个参数之间是典型的跷跷板关系。

扩频因子SF决定了每个数据符号用多少比特来表示。SF越大，信号抗干扰能力越强、接收灵敏度越高、通信距离越远，但空中传输时间成倍增加，实际吞吐率断崖式下降。举个例子，同样大小的数据包，SF7发送可能只需要几十毫秒，SF12发送可能要几百毫秒甚至更久，因为LoRa是低速率扩频通信，扩频因子直接跟速率挂钩。

信号带宽BW则相反，带宽越宽速率越高，但接收灵敏度会变差。125kHz和500kHz带宽相比，后者的速率大概是前者的4倍，但灵敏度会差好几个dB。

发射功率这个参数最直观，但也最容易让人产生误解。很多人觉得功率调得越大越好，实际不是。功率大了，模块发热增加、电池消耗加快，而且近距离通信时过强的信号可能造成接收端饱和，反而影响通信质量。我一般测链路的做法是：先用中等功率（比如20dBm）配合SF7、125kHz带宽去测，如果近距离能通、远距离丢包，再逐步调到SF9或者SF12，最后才考虑加大功率。这个顺序能帮你判断链路瓶颈到底在速率策略上还是射频功率上。

这套参数没有绝对最优，完全取决于你的现场环境。我能给的建议只有一个：先建立链路，再优化参数，不要一开始就追求极限配置。

4. RSSI测试：从原理到实测记录

4.1 RSSI读的是哪一路信号

RSSI（Received Signal Strength Indicator，接收信号强度指示）是衡量无线链路质量最直观的指标之一。但很多新手第一次看到RSSI数值就懵了，因为SX126x芯片实际上提供好几种RSSI，含义完全不同。

第一种是信道当前RSSI，你可以理解成当前频点上环境噪声加上所有信号的综合电平。这个值在空闲状态下读出来，反映的是信道背景噪声水平。如果这个值本来就很高，比如-85dBm，那说明这个频点很“脏”，真正有用的信号容易被淹没。

第二种是数据包RSSI，也就是收到一帧有效数据时，芯片测到的该帧信号强度。这才是我们判断通信距离和链路质量最关心的数字。SX126x在接收完成后，会把最近一包数据的RSSI和SNR（信噪比）存到状态寄存器里，MicroPython驱动里一般封装成get_rssi()类似的方法。

第三种是SNR，信噪比。它表示信号和噪声的比值，单位为dB。在LoRa这种扩频系统里，SNR可以出现负值，因为扩频增益可以让信号在噪声之下被解调出来。这也是LoRa相比传统FSK的一大优势——它能在信噪比为负的情况下仍然成功接收。

我这次测试重点关注的是数据包RSSI和SNR。数据包RSSI用来评估“信号够不够强”，SNR用来评估“信号在噪声里清不清晰”。两个指标结合起来看，比单看一个数字可靠得多。

4.2 实测步骤与记录方法

RSSI测试要做得有参考价值，就必须有统一的测试方法和仔细的记录。我的测试流程是这样的。

先固定好发送端。发送端用一块ESP32加E28模块，放在一个位置固定的桌子上，天线用支架立起来，保持竖直。代码里用定时器每隔一秒发一包16字节的数据，数据内容包含一个自增序号和时间戳。接收端也是同样的硬件组合，放在移动端，用移动电源供电，靠串口把接收结果打出来，同时记录RSSI和SNR。

然后是移动测量。每到一个测试点，先让接收端稳定30秒，让自动增益控制收敛，然后连续接收50包数据，统计每包的RSSI和SNR，算出平均值，再统计丢包数。关键要记录的信息包括：距离、环境描述（空旷/有树遮挡/过墙角）、平均RSSI、平均SNR、丢包率。

我当时的记录表大致是这样：

这张表的数据是我从真实测试里归纳出来的典型走势，具体数值会因为你用的天线、发射功率、频段和环境不同而有明显差异，但趋势是一致的：距离越远，RSSI越差，SNR跟着变差，最后丢包率上升。

有几个测试细节容易被忽略。第一，天线极化方向要保持一致，发送端天线竖直，接收端天线也尽量竖直，一旦一端天线横过来，信号可能掉十几个dB。第二，高度差对结果影响很大，接收端贴着地面和举到1.5米高度，RSSI能差出20dB以上，因为地面反射和多径效应在近距离影响非常剧烈。第三，人体本身会吸收和反射射频信号，测试时人尽量站在接收端天线侧后方，不要挡在天线和发送端之间。

4.3 实测数据怎么看：几个关键判断标准

拿到一组RSSI数据之后，怎么判断链路是否健康？我一般看三个维度。

第一个维度是接收灵敏度余量。模块在给定参数下的灵敏度是固定的，比如SF7/125kHz下SX126x的典型灵敏度约-123dBm。你测到的RSSI只要比这个底噪高出10~15dB以上，链路就是比较健康的。如果测到-110dBm，虽然距离灵敏度极限还有十几dB的余量，但已经进入危险区，稍微有点环境波动就会掉包。

第二个维度是SNR趋势。正常空旷环境下，SNR随着距离增大缓慢下降，但如果某段距离上SNR断崖式下跌而RSSI变化不大，大概率是多径衰落或者出现了同频干扰。这种情况下靠加大发射功率改善有限，更应该考虑调整天线位置、方向或者换频点。

第三个维度是RSSI标准差。在一个固定测试点连续收几十包，如果RSSI波动超过5dB，说明信道不稳定，可能是附近有人走动、树木被风吹动、或者汽车经过造成的信号反射变化。稳定的链路RSSI值应该非常平稳，波动一般在2dB以内。

如果你懂一些射频基础，可以参考自由空间路径损耗公式大致估算理论值：

FSPL(dB) = 20 * log10(d) + 20 * log10(f) + 32.44

其中d是距离，单位km，f是频率，单位MHz。比如915MHz、100m距离的理论损耗大约是20log10(0.1) + 20log10(915) + 32.44，算出来约71.6dB。如果你的发射功率是20dBm，天线增益先忽略，那理论接收功率就是20 - 71.6 = -51.6dBm左右。实际测试因为有地面反射、树木吸收、天线效率损耗，测到的RSSI一般会比理论值差10~20dB。这个公式的价值在于帮你建立“合理预期”，当实测值异常差的时候，你能判断出是链路本身问题还是模块硬件问题。

5. 常见问题与排查技巧实录

5.1 收发不到数据的排查顺序

这是LoRa模块项目里出现频率最高的问题。我见过很多朋友一上来就问代码怎么写，结果排查到最后发现是地址没对上。这里我整理了一个排查顺序，按这个顺序走，绝大多数问题能在十分钟内定位。

先说现象，再给原因。

实际处理这类问题，我强烈建议用一个最简单的测试程序：一端每1秒发一个固定字符串，另一端收到后立刻打印。代码越简单，变量越少，排查越容易。不要一上来就写完整的业务协议，协议层的问题会掩盖射频层的问题，让你误判故障点。

5.2 RSSI数值异常的几种情况

有时候数据能正常收发，但RSSI数值看起来不对劲，这时候要分情况分析。

如果RSSI高出预期，比如几十米距离测出来才-30dBm，这通常会发生在发送端功率开得很大的情况下。近距离下高功率信号会让接收端进入饱和区，RSSI读数反而不准，而且可能伴随偶发误码。解决办法很简单，近距离测试时把发射功率降到10dBm左右，更符合实际近距离场景。

如果RSSI异常偏低，比如明明只隔了十米，RSSI却测到-90dBm，优先怀疑天线。很多模块的天线是SMA接口的，拧的时候没对准螺纹，看起来接上了，其实内针没顶到插座上，这种情况信号衰减能到30dB。还有一种常见情况是用了错误频段的天线，比如433M模块接了915M天线，虽然接口能拧上，但天线在错误频段上效率极低，通信距离惨不忍睹。

另外，RSSI读数在MicroPython下偶尔会有“跳变”现象，同一个位置连续测几十包，有时候会冒出个别异常值，这通常是模块的AGC还没收敛或者环境中出现了突发干扰。处理方式是在软件里做中值滤波或者取平均值，不要用单包数值做判断。

5.3 MicroPython环境下的独有坑

用MicroPython做LoRa应用，开发效率确实比C语言高很多，但有些坑是Python这个运行时环境特有的。

第一个坑是垃圾回收引起的时序抖动。MicroPython的垃圾回收器会在内存紧张时暂停执行，这个暂停时间最长可能几十毫秒。如果你的代码在发送循环里，GC一暂停，还没来得及读取DIO1中断标志，下一包数据就到了，就会出现“漏包”现象。解决办法一是尽量少创建临时对象，把发送数据的buffer提前分配好；二是在对实时性要求高的逻辑里，使用machine.disable_irq()暂时关闭中断，核心操作完成后再打开。不过关中断会阻塞系统，只适合极短的关键区，不要长时间使用。

第二个坑是SPI速率问题。SX126x芯片手册里写的SPI最大时钟很高，但实际在MicroPython环境里，驱动开销和杜邦线的物理性能都会限制速率。我实测下来，1MHz的SPI时钟最稳定，2MHz偶尔会在长线缆下出数据错误，4MHz以上基本不可靠。如果拔高SPI速率后通信开始出问题，先降回1MHz试试，大概率能解决。

第三个坑是DIO1中断回调函数的写法。MicroPython里GPIO中断回调函数里不能做太重的操作，比如不能发送数据、不能申请大内存。正确的做法是回调函数里只置一个标志位，主循环检测到标志位后再去做接收处理。

received_flag = False def dio1_callback(pin): global received_flag received_flag = True dio1.irq(trigger=Pin.IRQ_RISING, handler=dio1_callback) while True: if received_flag: received_flag = False msg, err = lora.receive() rssi = lora.get_rssi() print(msg, rssi)

5.4 关于FSK模式的扩展想法

SX126x芯片本身支持LoRa和FSK两种调制方式，E28模块有些型号允许你通过配置切换到FSK模式。LoRa的优势是灵敏度高、抗干扰强、适合低速远距离，FSK的优势是速率可以做得更高、频谱利用率更直接。

我个人的判断是，这个切换选项在常规项目里用到的概率不大。因为E28模块出厂通常默认LoRa模式，各种软件工具和文档也是围绕LoRa展开的，你非要去切FSK，就得自己啃芯片手册，性价比不高。除非你的需求是在近距离传相对大一点的数据块，同时对距离要求不高，那FSK值得研究一下。大多数传感器数据回传场景，老老实实用LoRa就够了。

如果你确实要做LoRa和FSK混合的协议，那就不能用现成的串口透传模式了，必须走SPI直连芯片，在代码里切换调制方式。这个复杂度等于自己做射频驱动，建议有足够时间和精力再上。

最后再分享两个我从测试里总结出来的小技巧。

第一个是所有测试数据包里一定要带上序号和发送时间戳。这样接收端不仅能看收到没有，还能分析丢包间隔、时延变化。我最初测试时只发固定字符串，丢包只能看到一个“丢了”，但不知道是哪一包丢的，后面加上了自增序号，问题定位效率翻倍。

第二个是测试前把所有可能松动的物理环节都拧紧。天线座、杜邦线、模块的排针，任何一个虚接都能让信号表现忽好忽坏，干扰你的判断。我踩过最冤的一次坑就是天线内芯没顶到位，白白浪费了半天时间排查软件，最后发现是物理接触不良。

这套E28加MicroPython的LoRa测试链路，从快速验证链路，到读RSSI评估信号质量，再到透传和定点传输切换，整个流程走通之后，再去做具体的物联网项目心里就有底了。如果你正在做类似的事情，希望这篇文章能帮你绕开我踩过的这些坑。