如果你现在在搜索引擎里敲LORA，前几页大概率会被各种AI模型微调教程刷屏，太多人把LoRA这个缩写用在了大模型参数高效微调上。但我今天要聊的这块JY-KMT-LORA，和那个AI圈的LoRA没有任何关系。它是老老实实做物理层无线数传的模块，LoRa是Long Range的缩写，主打低功耗、远距离、抗干扰。我在一个山区环境监测项目里用了它三个月，今天把完整的选型、配置、实测和踩坑记录都放出来，希望能帮到正在挑选微型LoRa数传模块的朋友。
这块模块尺寸大概16×14mm，和一枚1元硬币差不多大，UART串口直接收发数据，内部走的是SX1262方案，供电范围2.3~3.6V，发射功率最高可以到+22dBm，接收灵敏度标称-139dBm。如果你正在做传感器数据回传、远距离遥控开关、农田或山林监测这类项目，又纠结于体积和功耗，那这篇文章值得花几分钟看完。我会从硬件检查聊到AT指令，再从ESP32实际驱动聊到低功耗优化，最后把踩过的坑完整复盘一遍。
1. 一块老实的LoRa模块，为什么值得单独写一篇
1.1 项目背景：传感器节点和网关之间隔了两公里山路
我维护的是一个小型环境监测系统，需要在山上放五个传感器节点，把温湿度、气压、电池电压这些数据传回山脚值班室。节点分布在山坡和山谷里，最近的离接收点大概800米，最远的直线距离2.3公里，中间有树丛、岩石，还有一定的高低起伏。我一开始试过2.4G的nRF24L01，空旷环境能跑一两百米，但在这种地形下基本不可用。后来换过普通的433MHz收发模块，外接LNA后勉强到1公里，但休眠电流大，而且抗干扰能力一般，稍微复杂一点的电磁环境下就开始丢包。
纠结了很久之后才转向LoRa方案。LoRa的核心价值就是两个：灵敏度高，能解调非常微弱的信号；抗干扰能力强，对多径和同频干扰比FSK要稳健很多。最后在选型时看到了JY-KMT-LORA，因为体积小、SX1262方案、串口直通，符合我“低功耗、低速率、长距离”的需求，就直接买了几块回来测试。
1.2 JY-KMT-LORA的定位和购买前要确认的版本差异
JY-KMT-LORA是一款国产微型UART LoRa数传模块，对外接口不多，核心引脚就VCC、GND、TXD、RXD，部分版本还带了AUX状态脚和M0/M1配置脚。默认开机就是透传模式：串口进去什么，另一端串口就出来什么，使用方式非常像一根无线串口线。正是这种“简单粗暴”的用法，让它在原型验证阶段能省掉大量开发时间。
但买之前有几个版本差异一定要问清楚。按频段分有410~493MHz和862~930MHz两种，国内使用建议选410~493MHz版本，可以覆盖433MHz和470MHz频段，合规又够用。按天线接口分有弹簧天线、IPEX座和焊盘三种；弹簧天线体积小但增益一般，IPEX可以外接延长线和吸盘天线，适合需要把天线放到高处的场景。按发射功率分有+22dBm和+17dBm版本，前者距离更远，后者功耗更低。我建议批量买之前先找商家要型号尾缀和AT指令手册，避免买到固件版本不一致的库存货。
另外，发帖交流的时候经常有人把这个型号误会成AI驯化的LoRA，实际上它只是拼写上一样，底层技术完全不同。LoRa通信靠的是线性调频扩频技术，不是神经网络微调，搜索资料时别搞混了。
1.3 适合这类模块的项目画像
折腾完这个项目，我的判断很明确：JY-KMT-LORA适合做低速、远距离、电池供电的数据传输，比如周期性上报传感器数据、GPS轨迹、远程开关量状态。节点数量控制在几十个以内，上报频率不高，单包数据几十到一百字节左右，这种场景是它的舒适区。反过来，如果项目需要传图片、音频、视频，或者要求低延迟频繁双向交互，那就别用LoRa，它的空中速率是硬瓶颈，再折腾也是白费。
宣布完边界之后，下面进入正题，从拿到模块的第一天开始讲。
2. 拿到手先做三个测试，再决定要不要用进项目
2.1 供电和串口电平：先量电压再接TTL
很多人的第一个坑不是代码，而是接线。JY-KMT-LORA的供电范围是2.3~3.6V，典型3.3V，超过3.6V可能会损坏射频前端。用USB转TTL调试时，先把模块的VCC接到USB转TTL的3.3V输出上，不要接到5V。如果USB转TTL是靠跳线选电平的，一定要确认TXD输出是3.3V电平，而不是5V。5V电平的串口直接怼到模块RX引脚，轻则误码，重则击穿引脚。
接线表如下：
| JY-KMT-LORA引脚 | USB转TTL / ESP32 |
|---|---|
| VCC | 3.3V |
| GND | GND |
| TXD | RXD |
| RXD | TXD |
还有一点容易忽略：地线必须共地。串口通信的参考电平是以GND为基准的，如果两边不共地，波形可能漂移，导致数据接收不稳定。如果用的是5V单片机比如Arduino Uno的TX/RX，不能直连，必须做电平转换或者用分压电阻，否则模块寿命会受影响。
我实测过模块的电流：接收待机状态大概10mA，发射瞬间能到110mA左右，休眠状态下可以压到2uA左右。这个数据在做电源设计时非常关键——稳压芯片至少要能满足120mA的峰值电流，否则模块在发射瞬间可能触发低压复位，表现就是“发都发不出来”。
2.2 读取固件版本：验证模块是不是翻新或乱刷固件
接线完成后，打开串口助手，波特率先设9600、8N1，然后发送AT指令。JY-KMT-LORA默认波特率一般是9600，但不同固件可能有差异。建议先发AT+VER?或者AT+VERSION?，正常会返回类似“JY-KMT-LORA V2.1”的字符串。
这里有个很典型的坑：如果你买的模块是从二手平台或者不明渠道来的，内部配置可能被上一个用户改过，波特率可能不是9600。我遇到过一块模块在9600下全是乱码，换到4800才正常。所以如果发送AT指令没反应，不要急着判断硬件坏了，先检查三件事：
- TX和RX是不是交叉接的，USB转TTL的TX应该接模块的RX，USB转TTL的RX接模块的TX。
- 波特率对不对，多试几个常见值：4800、9600、19200、115200。
- 模块是不是处于透传模式而不是指令模式，有些固件需要先像发送特定的退出指令才能进AT模式。
如果能正常读到版本号，至少说明模块是活的，接下来就可以做最简单的点对点透传测试。
2.3 一对模块的透传测试：先别折腾高级功能
我调试新模块的习惯是先跑通最基础的数据透传，再做高级配置。拿两块JY-KMT-LORA，分别接两个USB转TTL，保持默认参数一致，然后在A模块串口发送“hello”，B模块的串口如果能收到“hello”，说明链路通、固件正常、天线基本可用。
如果没收到，优先检查模块是不是处于指令模式。很多模块上电默认透传模式，但如果你之前用过AT指令且没有退出，它可能还停在配置模式，这时串口收到的不是数据而是指令响应。通常用AT+MODE=TRANSPARENT或AT+OPMODE=0切回透传，具体以手册为准。
透传没问题之后，再看信号质量。部分固件支持AT+RSSI?查询模块收到的信号强度，可以用于判断距离余量。测试时把两块模块放在同一水平线、天线垂直、离地至少1米以上，不要贴着桌面或者地面测，否则信号会被地面积累效应吸收，得到的RSSI会非常难看。
3. 配置指令集与应用层设计：从默认参数到可靠传输
3.1 AT指令速查表与常用配置
JY-KMT-LORA这类模块几乎都是靠AT指令配置参数的。我整理了一份常用指令表，方便现场配模块时快速查阅：
| 指令 | 含义 | 示例 |
|---|---|---|
| AT+ADDR? | 查询本机地址 | AT+ADDR? |
| AT+ADDR=1234 | 设置本机地址 | AT+ADDR=1234 |
| AT+NETID? | 查询网络ID | AT+NETID? |
| AT+NETID=1 | 设置网络ID | AT+NETID=1 |
| AT+FREQ? | 查询工作频率 | AT+FREQ? |
| AT+FREQ=433.0 | 设置频率，单位MHz | AT+FREQ=433.0 |
| AT+RATE? | 查询空中速率 | AT+RATE? |
| AT+RATE=1.2 | 设置空中速率，单位kbps | AT+RATE=1.2 |
| AT+PWR? | 查询发射功率 | AT+PWR? |
| AT+PWR=22 | 设置发射功率，单位dBm | AT+PWR=22 |
| AT+BAUD? | 查询串口波特率 | AT+BAUD? |
| AT+BAUD=9600 | 设置串口波特率 | AT+BAUD=9600 |
| AT+SLEEP | 进入休眠模式 | AT+SLEEP |
| AT+WAKEUP | 唤醒模块 | AT+WAKEUP |
注意，不同批次固件对AT指令的兼容性可能不一样。我在测试过程中发现部分指令要求先进入AT指令模式才能执行，直接在透传模式发AT可能被当成普通数据发出去。所以正式入项目前，一定要把商家提供的AT指令手册完整读一遍，不要想当然。
建议开工前至少配置三个参数：NETID、ADDR、RATE。NETID用于隔离不同网络，防止附近有别的LoRa设备时串收数据；ADDR用于同一网络内区分不同节点；RATE则是距离和功耗的权衡点，下面展开说。
3.2 空中速率、灵敏度与功耗的取舍
LoRa通信有一个很直观的特性：空中速率越低，接收灵敏度越好，距离越远，但单包数据在空中停留的时间越长，功耗越高。通俗点说，你说话慢一些，每个字更清楚，别人更容易听清；但把同样一句话说完，需要的时间也更长，嗓子的耗电自然也更多。
我根据实际测试经验整理了一张粗略对照表：
| 空中速率 | 实测接收灵敏度 | 100字节有效数据空中时间（估算） | 适合场景 |
|---|---|---|---|
| 0.573 kbps | 约-139 dBm | 约1.4秒 | 极限距离 |
| 1.2 kbps | 约-137 dBm | 约0.7~0.9秒 | 推荐默认 |
| 4.8 kbps | 约-128 dBm | 约0.17秒 | 距离较近 |
| 62.5 kbps | 约-119 dBm | 约13ms | 数据量大但距离近 |
对于我的山区项目，节点距离在1~3公里之间，还要穿树林和少量岩层遮挡，所以把空中速率定在1.2kbps。这个速率下链路余量足够，单包也不会占用太长时间。如果节点离接收端不到500米，可以把速率提到4.8kbps或更高，省电又降低信道占用时间。
计算链路预算时有个简单公式：链路余量 = 发射功率 + 发射天线增益 - 路径损耗 + 接收天线增益 + 接收灵敏度。实际项目里不需要精确算路径损耗，直接用RSSI实测判断更靠谱。我在后面第4章的实测距离表里会给一组可以参考的数据。
3.3 串口粘包、半包问题：写代码之前必须想清楚
LoRa模块对应用层来说就是一根无线串口线。但串口数据是流式的，没有天然边界，所以很容易出现粘包或半包。如果接收端只在Serial.read()收到一个字节就立刻处理，那遇到长数据就会拆得七零八落。
解决办法是自己定义帧协议。我用的帧格式很简单：
帧头0xAA 0x55 | 数据长度LEN(1字节) | 数据区(LEN字节) | CRC8(1字节)帧头用来同步，LEN告诉接收端这一帧后面还有多少字节，CRC8用来校验数据完整性。接收端按照状态机处理：先等0xAA，再等0x55，然后读LEN，再读LEN个数据字节，最后读CRC并校验。只有完整且校验通过的一帧才被拿去解析。
这种做法非常简单，但能解决大多数串口透传导致的“数据错位”问题。如果你要更可靠，还可以在数据区里加节点ID和序号，方便接收端去重和区分来源。
4. 用ESP32驱动JY-KMT-LORA：一对多广播实战记录
4.1 接线与硬件注意事项
ESP32的串口电平是3.3V，可以直接连JY-KMT-LORA，不需要电平转换。我用的是ESP32的UART2， RX引脚分配为GPIO16，TX引脚分配为GPIO17。接线如下：
| JY-KMT-LORA | ESP32 |
|---|---|
| VCC | 3V3 |
| GND | GND |
| TXD | GPIO16 |
| RXD | GPIO17 |
代码里初始化串口可以用：
Serial2.begin(9600, SERIAL_8N1, 16, 17);注意ESP32的GPIO16和GPIO17不是所有开发板都引出来，焊盘可能需要飞线，做原型时换成任何可用GPIO都行。还有一点，模块和ESP32之间的连线尽量短，不要用超过20cm的杜邦线，否则发射瞬间的电磁干扰可能串扰到RX线上，造成误码。
4.2 发送端代码：把传感器数据打包成帧
我的节点板是一块ESP32接多个传感器，周期性把数据通过LoRa模块发送到接收端。发送端的核心逻辑是：读取传感器数据，填入protobuf或者自定义二进制结构体，加上帧头、长度和CRC后，通过Serial2发送。
下面是一个精简版示例，假设节点ID为1，发送温度、湿度和电池电压：
#include <DHT.h> #include <Wire.h> #define DHTPIN 4 #define DHTTYPE DHT22 DHT dht(DHTPIN, DHTTYPE); uint32_t lastTxTime = 0; const uint32_t TX_INTERVAL = 60000UL; // 每60秒发一次 byte calcCRC8(byte data[], byte len) { byte crc = 0x00; for (byte i = 0; i < len; i++) { crc ^= data[i]; for (byte j = 0; j < 8; j++) { if (crc & 0x80) { crc = (crc << 1) ^ 0x31; } else { crc <<= 1; } } } return crc; } void sendFrame(byte nodeId, int16_t temp, uint16_t hum, uint16_t batt) { byte buf[9]; buf[0] = 0xAA; buf[1] = 0x55; buf[2] = 6; // 数据长度：nodeId(1) + temp(2) + hum(2) + batt(2) buf[3] = nodeId; buf[4] = highByte(temp); buf[5] = lowByte(temp); buf[6] = highByte(hum); buf[7] = lowByte(hum); buf[8] = calcCRC8(buf, 8); Serial2.write(buf, 9); } void setup() { Serial.begin(115200); Serial2.begin(9600, SERIAL_8N1, 16, 17); dht.begin(); } void loop() { if (millis() - lastTxTime >= TX_INTERVAL) { lastTxTime = millis(); float t = dht.readTemperature(); float h = dht.readHumidity(); if (isnan(t)) t = 0; if (isnan(h)) h = 0; int16_t tempInt = (int16_t)(t * 10); uint16_t humInt = (uint16_t)(h * 10); uint16_t batt = analogRead(36) * 2; // 粗略读取电池电压 sendFrame(1, tempInt, humInt, batt); } }这个代码在发送时先把浮点数量化成整数，比如温度25.3度存成253，接收端再除以10还原。这样做的好处是压缩数据体积，减少空中时间，降低功耗。对于低速率LoRa链路来说，多一发字节都可能增加不少空中时间，所以能短就短。
4.3 接收端代码：解析多节点数据
接收端我用了另一块ESP32连接LoRa模块，负责接收五个节点的数据，然后通过WiFi或者串口送到上位机。关键在于解析逻辑必须能应对串口断帧。
我用一个简单的字节缓存状态机：
#define BUFFER_SIZE 64 byte rxBuf[BUFFER_SIZE]; byte rxIndex = 0; byte expectLen = 0; bool headerGot = false; void processFrame(byte buf[], byte len) { byte crc = buf[len - 1]; byte calc = calcCRC8(buf, len - 1); if (crc != calc) return; byte nodeId = buf[3]; int16_t temp = ((int16_t)buf[4] << 8) | buf[5]; uint16_t hum = ((uint16_t)buf[6] << 8) | buf[7]; // 按nodeId区分不同传感器节点 } void handleSerialByte(byte c) { if (!headerGot) { if (rxIndex == 0 && c == 0xAA) { rxBuf[rxIndex++] = c; } else if (rxIndex == 1 && c == 0x55) { rxBuf[rxIndex++] = c; headerGot = true; } else { rxIndex = 0; } return; } rxBuf[rxIndex++] = c; if (rxIndex == 2) { expectLen = c + 3; // 帧头2 + 长度1 + 数据长度 + CRC1 } if (rxIndex >= expectLen) { processFrame(rxBuf, rxIndex); rxIndex = 0; headerGot = false; } } void loop() { while (Serial2.available()) { handleSerialByte(Serial2.read()); } }这样即使串口分多次把数据吐出来，也能正确拼出一帧。多个节点通过nodeId来区分，互不干扰。
4.4 实测距离与RSSI记录
所有理论都要落地。我拿了三对JY-KMT-LORA模块，在同一个频段下用1.2kbps空中速率、+22dBm发射功率，弹簧天线垂直放置，模块离地1.2米左右，在不同地形下做了一个粗测：
| 场景 | 距离 | RSSI实测 | 丢包率 | 备注 |
|---|---|---|---|---|
| 平坦草地 | 1.2km | -105 dBm | 0.2% | 稳定 |
| 城市街区 | 0.6km | -95 dBm | 1% | 有建筑遮挡 |
| 山谷起伏 | 2.3km | -115 dBm | 2% | 节点架设在树上 |
| 平原视距 | 4.0km | -120 dBm | 5% | 换SMA外接天线 |
| 开阔湖面 | 6.8km | -128 dBm | 10% | 接近灵敏度极限 |
这个数据给我最直接的感觉是：弹簧天线在1~2公里内够用，但想上更长距离就必须外接天线且架高。城市环境里树的遮挡影响也很大，传输方向上有厚树林时，丢包率会明显上升，所以节点位置一定要选高处，哪怕只比周围高两米，效果都能提升不少。
5. 低功耗优化：让电池供电节点跑一年而不是一周
5.1 进入休眠模式的方法与唤醒策略
LoRa模块如果不休眠，一直处于接收状态，电流10mA左右，虽然不算高，但对电池供电节点来说是个天文数字。假设一块3000mAh的电池，10mA待机电流也只能撑300小时，12天多一点，完全不可接受。所以必须让模块大部分时间处于休眠状态。
JY-KMT-LORA支持AT+SLEEP进入休眠模式。休眠前要确保已经退出透传模式并进入AT指令模式，因为直接在透传模式下发AT+SLEEP可能被当普通数据发出去。休眠后电流可以降到2uA级别。唤醒方式各个版本不同，有的通过拉低M0引脚唤醒，有的通过发送一串0xFF脉冲唤醒。我使用的是串口唤醒：MCU定时醒来后，先往LoRa模块的RX脚发若干个0xFF字节，等模块响应后，再延时约20ms，然后发送业务帧。实测下来，10ms是不够稳定的，前几个字节可能被吃掉，延时20ms基本稳妥。
5.2 占空比、数据包长度和电池容量估算
休眠策略的本质是降低占空比。不需要一直收发，只在需要做事的时候醒来，做完立刻睡回去。下面用我的实际节点参数算一笔账：
- 节点每10分钟上报一次，一天上报144次。
- 每次发送10字节有效数据，加上帧头和CRC共约12字节。
- 空中速率1.2kbps，加上前导码等开销，实际一次发射约0.3秒。
- 发射峰值电流110mA。
那么一天发送耗电为：
0.3秒 * 144次 * 110mA / 3600秒 ≈ 1.32mAh 休眠电流2uA一天耗电： 2uA * 24小时 = 0.048mAh两项加起来大约1.4mAh/天。如果用一节18650电池（标称3300mAh），理论续航可以达到2357天，约6年多。当然这是理想值，实际要把DC-DC转换效率、电池自放电、温度影响、节点MCU功耗都算进去。我的节点总静态功耗大约15uA，加上ESP32深度睡眠每60秒醒一次，整体折合下来大概2~3mAh/天，一节18650能跑一年以上，项目已经完全够用。
有个反向经验：很多人在低功耗设计时一味调低空中速率，其实不一定划算。速率越低，同一包数据在空中停留时间越长，发射能量集中时间也越长。如果距离允许，把速率从1.2kbps提到4.8kbps，空中时间可以缩短到原来的四分之一，反而更省电。所以距离和功耗之间要做动态平衡，并非越低越好。
5.3 休眠唤醒时序里的坑
休眠和唤醒过程中有几个坑，我全部踩过。
第一个坑是休眠前没有等发送完成。直接发AT+SLEEP，而上一包数据还在空中，模块直接被掐断，接收端会收到一个残缺的半包。正确的做法是先等待模块的AUX引脚变为高电平，表示空闲状态，再进入AT指令模式发送休眠命令。
第二个坑是唤醒后立刻发数据。模块从休眠到正常工作需要一定时间，如果MCU醒来后马上发业务帧，前几个字节大概率丢失。我的经验是唤醒后先发一串0xFF作为唤醒脉冲，然后延时20ms，再发业务帧。另外可以把业务帧本身设计成带重发机制，比如第一遍发完，隔100ms再发一遍，用冗余换取可靠性。
第三个坑是电源电容不足。模块发射瞬间电流超过100mA，如果电池供电线很长，压降会非常明显，可能导致模块瞬时复位。我给每块模块的VCC和GND之间都加了一个100uF电解电容和一个0.1uF陶瓷电容，这个组合可以明显改善发射时的电压跌落。
6. 踩坑记录与完整排查链路：照着做能省一天时间
6.1 串口乱码：模块波特率被改过，不是硬件坏了
有一天换了一块新到的JY-KMT-LORA，插上USB转TTL后，在串口助手9600波特率下收到的全是乱码。我第一反应是接线接错了，检查一遍没问题；第二反应是USB转TTL坏了，换一个依然乱码；开始有点怀疑模块质量问题。
后来耐着性子把波特率扫了一遍，试到4800时，串口助手出现正常的AT响应。原来这块模块出厂前被测试过，内部波特率被改成了4800，并不是出厂默认的9600。最后用AT+BAUD=9600把它改回来。这个经历提醒我：批量购买模块时不要假设每个模块都是默认配置，最好先统一读取一遍参数，再统一写入自己的配置。
6.2 通信距离突然缩水：天线焊点虚焊和贴地测试
项目跑到第二个月，突然收到一个节点上报质量下降的告警，原来稳定1.5公里的链路，现在100米内都丢包。第一反应是附近有电磁干扰，但同样位置的另一个节点又正常，于是排除干扰。第二反应是接收端坏了，替换接收模块后问题依旧。
最后把发射节点拆下来，用AT+RSSI?查询接收端收到的信号强度，发现比正常值低了30dB以上。盯着天线看了半天，发现弹簧天线的根部焊盘有虚焊，补焊之后信号立刻恢复正常。这类问题在高震动或温差大的环境里特别容易发生，模块和天线之间最好用热熔胶或树脂点一下固定。
另外一个排查过程中犯过的错误是：测试时手持模块贴着地面。地面会吸收和反射无线电信号，导致RSSI值非常难看。后来我重新规范了测试方法：模块离地至少1米，天线垂直，人退后几米，避免身体遮挡天线主方向。实测数据才真正可参考。
6.3 多节点同时上报导致全频道丢包：时分上报必须做
当我把节点数从2扩展到5之后，出现了一个严重问题：接收端经常整个周期一个包都收不到。起初我以为是LoRa模块坏了，后来才发现，五个节点的上报时间都被设置成了整点，也就是同一时刻大家全部醒来发送数据。两个以上的LoRa节点在同一频点同时发射，接收端解调器会直接失败，表现为“全频道丢包”。
LoRa本身在大多数数传模块里没有内置载波监听和冲突避免机制，至少JY-KMT-LORA没有暴露这个能力。所以应用层必须自己做时分复用。我的做法是每个节点开机后生成一个随机偏移量，比如在原始上报周期上增加0~30秒的随机延时。这样节点虽然还是10分钟内各发一次，但不会挤在同一秒。
伪代码如下：
uint32_t randomOffset = random(0, 30000); if (millis() - lastBaseTime >= TX_INTERVAL + randomOffset) { // 发送数据 }更严格一点还可以做ACK确认和重传：接收端每收到一帧就回一个ACK帧，节点没收到ACK就在随机延时后重传。但ACK会增加空中负担和复杂度，低速率场景下如果丢包率不高，不一定值得。像我这样5个节点、每小时几包的数据量，用随机偏移基本就够了。
7. 最后的实话：谁适合用JY-KMT-LORA，谁建议换方案
如果让我给结论，JY-KMT-LORA适合的场景很清晰：节点数量不大、数据量小、上行周期性传输、距离可以到两三公里，而且对尺寸和功耗敏感。它不适合的场景也很清晰：不适合传图片和语音，不适合高并发，不适合作低延迟控制链路，更不建议做持续双向透传。
如果距离只有一两百米，用BLE或者Zigbee体验会好很多；如果对数据速率要求高，比如要传图片，那宁愿上4G Cat.1模块；如果完全不介意功耗，可以用普通的FSK射频模块，成本更低。LoRa的不可替代性在于它同时做到了低功耗、远距离和一定程度的抗干扰，但这不是白来的，代价就是低速率。
按我个人的使用体会，这块模块在1.2kbps、+22dBm、外接天线、节点架高的组合下非常稳定，三个月下来没有丢过关键数据。唯一让我不满意的就是AT指令的标准化程度不够，不同批次的手册总有小差异，所以批量货一定要先拿到手亲手验证一遍配置再铺开。
最后分享一个能省事的经验：如果你的节点数量超过两位数，不要拿着串口助手一块一块手动配置。用USB转TTL把模块接到电脑，写一个简单的Python脚本按顺序把AT配置发给模块，每个指令间隔200ms，配置完自动断电切换下一块。用这个办法，我十块板子十分钟就全部配完了，比手点快了不止一倍。
