1. 项目缘起为什么我们需要一个双模离线通信器在物联网和智能硬件项目里通信是绕不开的核心。无论是智能家居的传感器数据上报还是野外环境监测节点的数据汇聚都需要一个稳定、可靠的通信链路。但现实往往很骨感Wi-Fi覆盖不到的地方怎么办4G/5G模块功耗太高、成本太贵怎么办网络基础设施因故中断设备间如何保持联络这就是“离线通信”或“自组网通信”的价值所在。它不依赖任何中心化的网络基础设施如路由器、基站让设备之间能够直接对话形成一个独立、自治的网络。我最近折腾的一个项目就是基于这个需求打造了一个名为“Dual-Mode Off-Grid Communicator”的玩意儿。顾名思义它集成了两种主流的短距离无线通信技术ESP-NOW和LoRa并且支持构建网状网络。你可能要问为什么是两种一种不够用吗这正是这个项目的精妙之处。ESP-NOW是乐鑫为ESP32/ESP8266系列芯片开发的协议速度快、延迟极低但通信距离短通常在百米级别视环境而定。LoRa则以其惊人的通信距离城市数公里开阔地十公里以上和极低的功耗著称但数据传输速率很慢。把它们俩结合起来就像组建了一支特种部队ESP-NOW是突击手负责局域网内设备间的高速、实时数据交换LoRa是侦察兵负责将关键信息传送到遥远的后方节点。两者互补能覆盖从室内密集部署到野外广域覆盖的复杂场景。这个双模通信器的核心价值在于提供了一种灵活、鲁棒的通信冗余方案。当一种通信方式失效时另一种可以作为备份。更重要的是通过构建Mesh网络数据可以在节点间多跳中继极大地扩展了网络的物理覆盖范围和可靠性。无论是用于灾害应急通信、农业大棚监测、还是大型仓库的资产追踪这个架构都提供了坚实的基础。2. 技术选型深度剖析ESP-NOW与LoRa的互补哲学在动手之前我们必须彻底理解手中的两把“武器”。选择它们并非一时兴起而是基于一系列严苛的工程权衡。2.1 ESP-NOW局域网内的“闪电侠”ESP-NOW是乐鑫基于Wi-Fi底层开发的一种无连接通信协议。你可以把它理解为Wi-Fi的“精简版”或“直连版”。它不需要复杂的握手、关联和IP配置设备间配对后即可直接发送数据包。核心优势极低延迟省去了TCP/IP协议栈的 overhead端到端延迟可以做到毫秒级非常适合需要快速响应的场景比如遥控指令、传感器状态同步。高吞吐量理论速率和Wi-Fi一致在实际应用中传输几百字节到几KB的数据几乎是“瞬间”完成。配置简单无需网络SSID和密码通过MAC地址直接通信组网逻辑相对清晰。功耗相对较低相比保持完整的Wi-Fi连接ESP-NOW的功耗要低不少尤其适合电池供电的传感节点。固有局限通信距离短这是Wi-Fi物理层的天然限制。在理想的视距环境下可能达到100-200米但一旦有墙体、树木遮挡距离会急剧下降。它本质上是为室内或小范围覆盖设计的。网络规模受限虽然官方称支持最多20个设备组网但在实际Mesh中管理大量节点的路由和转发会变得复杂且广播风暴风险增加。依赖特定硬件目前主要支持乐鑫的ESP32/ESP8266系列芯片生态相对封闭。注意ESP-NOW的数据包最大长度是250字节。这意味着你不能用它来传输图片或大文件。它的设计初衷就是传输小批量的控制指令或传感器读数。2.2 LoRa远距离的“信鸽”LoRa是一种基于扩频技术的无线调制方式工作在Sub-GHz频段如433MHz 868MHz 915MHz。它的核心思想是“用时间换空间”通过极低的传输速率换取超远的通信距离和极强的抗干扰能力。核心优势超远距离这是LoRa的杀手锏。在城市环境中轻松达到2-5公里在开阔地带甚至能超过10公里。超低功耗LoRa模块在发射和接收时的电流峰值可能比ESP32小一个数量级在深度睡眠模式下更是微安级别非常适合太阳能电池板供电、数年才更换一次电池的野外设备。强穿透性Sub-GHz频段的无线电波绕射和穿透能力远强于2.4GHz的Wi-Fi能更好地应对复杂地形和建筑物遮挡。固有局限极低速率这是为距离付出的代价。常见的LoRa模块空中速率在0.3kbps到几十kbps之间。传输一条“温度25.6°C”的信息很快但想传个几十KB的日志文件就得等上好一会儿了。需要专用模块ESP32本身不支持LoRa必须外接像SX1276/SX1278这样的LoRa射频芯片模块如常见的Heltec、TTGO的LoRa32开发板。协议自定LoRa本身只是物理层和链路层技术。要实现组网、寻址、确认、重传等网络功能需要自己实现或采用现成的上层协议如LoRaWAN。本项目中的Mesh网络就需要我们自己设计一套简单的协议。为什么是“双模”而非“单选”想象一个森林火灾监测网络。部署在树上的温湿度传感器节点Node A需要频繁地向附近的网关节点Gateway汇报数据。如果只用LoRa所有节点都直接与远方的网关通信虽然能传到但大量节点同时长距离发射会急剧增加整体功耗和无线信道冲突。如果只用ESP-NOW网络覆盖范围又太小。双模架构下Node A可以用ESP-NOW将数据快速发给几十米外的另一个中继节点Node B。Node B收集了附近多个节点的数据后再通过LoRa“攒够一包”统一发送给远方的网关。这样大多数节点只需进行短距、快速的ESP-NOW通信功耗低、延迟小只有少数中继节点承担远距离LoRa通信的任务。这种分层架构在能耗、效率和可靠性上取得了最佳平衡。3. 硬件架构设计与核心组件选型要实现这个双模通信器硬件是地基。我的设计目标是尽量集成化、低功耗、便于原型开发同时为未来产品化留出空间。3.1 主控芯片ESP32的双重角色我选择了ESP32-S3作为主控。原因如下原生支持ESP-NOW这是乐鑫的亲儿子对ESP-NOW的支持最完善性能也最好。充足的外设与内存ESP32-S3拥有双核处理器、充足的RAM和Flash能够同时处理ESP-NOW协议栈、LoRa驱动、Mesh路由逻辑以及用户应用程序游刃有余。低功耗模式支持多种深度睡眠模式对于由电池供电的终端节点至关重要。ESP32在这里扮演着“大脑”和“ESP-NOW通信模块”的双重角色。3.2 LoRa模块远距离的翅膀LoRa部分我选择了市面上非常成熟的Semtech SX1278芯片模块。选择它而不是更新的SX1262主要是出于生态和稳定性的考虑生态成熟SX1278的驱动如RadioLib、LoRa.h经过多年打磨非常稳定社区资源丰富。引脚兼容很多开发板如TTGO LoRa32直接集成了SX1278方便快速上手。满足需求对于本项目主要传输的小数据包SX1278的性能完全足够。模块通过SPI接口与ESP32-S3连接。关键的引脚包括SCK, MISO, MOSI, NSS (片选), RST (复位), DIO0 (中断)。DIO0引脚用于触发数据接收完成中断这对于实现高效的事件驱动编程模式很重要。3.3 电源管理续航的生命线对于离线设备电源管理是灵魂。我的设计包含两部分电源路径管理支持Micro-USB供电和3.7V锂电池供电自动切换。使用一颗TP4056充电管理芯片为锂电池充电同时通过一个理想二极管电路如MOSFET搭建实现电源无缝切换防止电池向USB口倒灌。动态功耗调节在软件层面需要根据设备角色中继节点、终端节点动态调整工作模式。例如终端节点大部分时间处于深度睡眠仅定时唤醒通过ESP-NOW快速上报数据后继续睡眠。中继节点则需要更频繁地监听信道因此采用轻度睡眠定时唤醒LoRa接收的模式。提示在PCB布局时务必为数字部分ESP32和射频部分LoRa模块使用独立的LDO稳压器并用磁珠或0欧电阻进行隔离防止数字噪声干扰敏感的射频电路导致LoRa通信距离大打折扣。3.4 外围电路与接口为了提升实用性和可调试性我还增加了以下部分OLED显示屏一块128x64的I2C OLED屏用于显示设备状态、网络ID、信号强度、电池电量等信息在部署和调试时非常直观。用户按键1-2个物理按键用于切换工作模式、手动触发发送、进入配置状态等。状态LED用RGB LED或不同颜色的LED来指示电源、ESP-NOW活动、LoRa活动、错误状态。扩展接口引出ESP32剩余的GPIO、I2C、UART接口方便连接各种传感器温湿度、光照、PIR等。最终的硬件原型可以是一块自制的PCB也可以是基于TTGO LoRa32 V2.1.6这类开发板进行改装。后者能极大加快验证速度。4. 软件架构与双模协议栈设计硬件搭好了软件才是让整个系统活起来的关键。软件架构的核心挑战在于如何让ESP-NOW和LoRa这两个差异巨大的通信方式协同工作并组织成一个有序的Mesh网络。4.1 整体软件架构事件驱动与状态机我采用了一个事件驱动的架构核心是一个主循环不断检查各种事件标志位。这比传统的延时轮询方式更高效更能利用ESP32的双核特性。// 伪代码示意架构 void loop() { // 检查ESP-NOW接收事件 if (espnow_data_received_flag) { processESPNowPacket(); espnow_data_received_flag false; } // 检查LoRa接收事件由DIO0中断触发设置标志位 if (lora_data_received_flag) { processLoRaPacket(); lora_data_received_flag false; } // 检查定时器事件例如定时发送传感器数据 if (sensor_report_timer_expired) { readSensorData(); sendDataViaESPNow(); // 优先通过ESP-NOW发送 sensor_report_timer_reset(); } // 检查用户按键事件 if (button_pressed_flag) { enterConfigurationMode(); button_pressed_flag false; } // 处理Mesh路由表维护等后台任务 manageMeshRoutingTable(); // 进入低功耗模式根据当前状态决定深度睡眠或轻度空闲 enterLowPowerState(); }每个通信模块ESP-NOW LoRa都在中断服务程序或回调函数中快速设置事件标志位主循环再进行处理避免在中断中执行耗时操作。4.2 统一数据包格式设计为了让数据能在ESP-NOW和LoRa网络间无缝流转必须定义一个统一的应用层数据包格式。这个格式需要兼顾效率与必要性。我设计的包结构如下采用C语言结构体描述#pragma pack(push, 1) // 按1字节对齐节省空间 typedef struct { uint8_t packetType; // 包类型数据(0x01)、路由更新(0x02)、确认(0x03)等 uint32_t sourceNodeId; // 源节点唯一ID uint32_t destNodeId; // 目标节点ID (0xFFFFFFFF表示广播) uint8_t ttl; // 生存时间每经过一跳减1防止环路 uint8_t hopCount; // 已跳转次数 uint32_t sequenceNum; // 序列号用于去重和确认 uint8_t payloadLen; // 有效载荷长度 uint8_t payload[250]; // 有效载荷实际长度由payloadLen决定 uint16_t checksum; // CRC16校验和 } MeshPacket_t; #pragma pack(pop)这个结构体总共约 44411412502 271 字节。对于ESP-NOW250字节限制来说有点大但我们可以通过压缩字段如用2字节短ID或分包传输来解决。对于LoRa一次传输271字节可能需要拆成多个LoRa数据包这就需要在上层实现简单的分片与重组逻辑。关键字段解析packetType这是路由决策的关键。数据包需要被中继转发路由更新包需要被洪泛到全网确认包则可能不需要转发只回复给上一跳。ttl和hopCount这是实现Mesh网络防环和路径选择的基础。ttl通常设为网络直径如10每经过一个中继节点减1减到0则丢弃。hopCount记录路径长度可用于选择最优路径。sequenceNum每个源节点维护一个递增的序列号。接收方可以据此判断是否为重复收到的包比如通过广播洪泛时一个包可能从多条路径传来避免重复处理。4.3 ESP-NOW通信层实现ESP-NOW的实现相对直接但有些细节决定成败。1. 初始化与配对#include esp_now.h #include WiFi.h void setupESPNow() { WiFi.mode(WIFI_STA); // 必须设置为STA模式 WiFi.disconnect(); // 断开可能存在的Wi-Fi连接降低干扰 if (esp_now_init() ! ESP_OK) { Serial.println(ESP-NOW初始化失败!); return; } // 注册发送和接收的回调函数 esp_now_register_send_cb(onESPNowDataSent); esp_now_register_recv_cb(onESPNowDataRecv); // 添加对等设备Peer信息 esp_now_peer_info_t peerInfo {}; memcpy(peerInfo.peer_addr, broadcastAddress, 6); // 广播地址 peerInfo.channel 1; // 所有设备需在同一信道 peerInfo.encrypt false; // 本项目先不加密实际应用务必启用加密 esp_now_add_peer(peerInfo); }2. 关键技巧信道选择与抗干扰ESP-NOW工作在Wi-Fi信道。在2.4GHz这个拥挤的频段干扰无处不在。我的经验是使用WiFi.扫描周围环境选择一个相对空闲的信道如1 6 11并让网内所有设备固定在此信道。在esp_now_send后一定要在发送回调onESPNowDataSent中检查发送状态。发送失败很常见必须实现重试机制。我的策略是最多重试3次每次间隔随机时间如100-500ms以避免多个节点同时重试造成碰撞。3. 处理广播与单播向广播地址发送数据理论上同一信道所有ESP-NOW设备都能收到适合用于路由发现、网络信令。但广播不可靠且会增加网络负载。对于重要的传感器数据应采用单播方式指定下一跳节点的MAC地址。这就需要维护一个邻居表记录附近设备的MAC地址与逻辑Node ID的映射关系。4.4 LoRa通信层实现LoRa层的实现更底层一些需要仔细配置射频参数。1. 初始化与参数配置#include RadioLib.h SX1278 radio new Module(SS, DIO0, RST, DIO1); // 根据实际引脚连接 void setupLoRa() { // 初始化物理层 int state radio.begin(915.0); // 频率根据地区法规设置 if (state ! RADIOLIB_ERR_NONE) { Serial.print(LoRa初始化失败错误码: ); Serial.println(state); while (true); // 卡住 } // 设置关键参数需要在通信范围内所有节点一致 state radio.setBandwidth(125.0); // 带宽 125 kHz state | radio.setSpreadingFactor(9); // 扩频因子 SF9 (SF7-SF12越大越慢越远) state | radio.setCodingRate(5); // 编码率 4/5 state | radio.setOutputPower(17); // 发射功率 17 dBm (最大20 注意法规限制) state | radio.setPreambleLength(8); // 前导码长度 state | radio.setCRC(true); // 启用CRC校验 if (state ! RADIOLIB_ERR_NONE) { Serial.println(LoRa参数配置失败!); } // 设置接收模式 radio.startReceive(); }2. 参数权衡的艺术LoRa的带宽、扩频因子、编码率共同决定了通信的“速度-距离-鲁棒性”三角关系。扩频因子 (SF)这是最重要的参数。SF从7到12递增。SF每增加1接收灵敏度提升约3dB通信距离几乎翻倍但传输时间也翻倍。对于本项目如果节点间距在1公里内SF9是一个很好的平衡点。如果追求极限距离可以用SF12但要忍受极慢的速率。带宽 (BW)带宽越宽速率越快但接收灵敏度越低距离变短。125kHz是常用值。编码率 (CR)纠错强度4/5到4/8。CR越高纠错能力越强但有效数据负载越小。在干扰较强的环境如城市可以选用4/7或4/8。我的建议是先在目标部署环境进行实地测试。固定其他参数调整SF找到能稳定通信的最低SF值这样可以获得最佳的传输效率和功耗。3. 发送与接收中断LoRa发送是阻塞式的radio.transmit()会一直等到发送完成。而接收应采用中断模式。当DIO0引脚触发中断时表示一个数据包接收完成我们在中断服务程序(ISR)中只设置一个标志位然后在主循环中调用radio.readData()读取数据。这避免了在ISR中进行复杂操作。4.5 Mesh网络路由逻辑实现这是整个项目最复杂的部分。我实现的是一个简单的基于距离向量的按需路由协议灵感来源于AODV但做了大量简化以适应单片机资源。1. 邻居发现与维护每个节点定期如每30秒通过ESP-NOW广播一个“心跳包”packetType HEARTBEAT。心跳包包含自己的Node ID和位置信息如果有GPS。收到心跳包的节点会更新自己的“邻居表”。邻居表记录着邻居ID、信号强度RSSI、最后收到心跳的时间。如果一个邻居超过一定时间如90秒没有更新则认为其离线。2. 路由表建立路由表记录如何到达网络中的其他节点。每条记录包含目标节点ID、下一跳节点ID、跳数、最后更新时间。初始状态节点只知道它的直接邻居跳数1。学习路由当节点收到一个数据包时它会检查包头的sourceNodeId和hopCount。它知道这个包是从上一跳节点即发送这个包的邻居传来的。于是它可以建立一条到sourceNodeId的路由下一跳就是这个邻居跳数是hopCount1。路由请求 (RREQ)当节点A需要发送数据给未知的节点D时它会广播一个RREQ包。收到RREQ的节点会记录下到节点A的反向路径然后继续广播。当RREQ到达D时D会沿着反向路径单播一个路由回复 (RREP) 给A。A收到RREP后就建立了到D的路由。3. 数据转发当节点需要发送一个应用数据包时检查目标是否是自己。如果是则上传给应用层处理。如果不是则查找路由表。如果找到路由则将数据包通过指定的下一跳可能是ESP-NOW或LoRa根据下一跳的通信能力决定发送出去并更新包头的hopCount和ttl。如果没找到路由则缓存数据包并触发上述的RREQ过程。4. 双模路由策略这是本项目的特色。我的策略是短距优先如果下一跳节点在ESP-NOW邻居表中则优先使用ESP-NOW发送因为速度快、功耗相对低。长距兜底如果下一跳节点不在ESP-NOW范围内但路由表显示可通过多跳ESP-NOW到达则按路由转发。LoRa骨干对于需要跨区域通信或者ESP-NOW路径跳数过多比如超过3跳的情况则启用LoRa。可以将数据包发送给一个指定的、具有LoRa能力的“网关节点”或“中继节点”由它通过LoRa长距离传输到目标区域再由该区域的节点通过ESP-NOW分发下去。这个策略需要在数据包包头或路由表中增加一个“能力字段”标记节点是否支持LoRa。5. 实战部署与性能调优经验纸上得来终觉浅绝知此事要躬行。将这套系统部署到真实环境中会遇到无数在实验室里想不到的问题。5.1 环境部署与网络规划在部署前必须进行细致的网络规划节点角色划分不是每个节点都需要双模。我将节点分为三类终端节点 (End Device)只有ESP-NOW负责采集数据电池供电深度睡眠为主。它们只与最近的中继节点通信。中继节点 (Relay Node)具备ESP-NOW和LoRa。负责汇聚终端节点的数据并通过LoRa与其他中继节点或网关通信。通常需要更强的供电如太阳能板。网关节点 (Gateway)具备LoRa和回传链路如以太网、4G。负责将整个Mesh网络的数据汇总并上传到云端服务器。通常部署在供电稳定的位置。网络拓扑设计采用“星型簇骨干网”结构。终端节点围绕中继节点形成星型簇使用ESP-NOW。中继节点之间通过LoRa形成骨干网。网关连接骨干网。这种结构清晰易于管理和维护。地址分配为每个节点分配一个唯一的Node ID。可以采用有意义的编码例如用高字节表示区域低字节表示节点序号。5.2 实地测试与信道优化在实验室一切正常一到现场就崩这是无线项目常态。1. ESP-NOW距离测试不要相信数据手册的“视距100米”。拿着两个设备在实际部署环境中有墙壁、树木、其他Wi-Fi干扰走一遍。记录不同距离下的RSSI接收信号强度指示和丢包率。你会发现可能穿过一堵承重墙后距离不到20米信号就衰减得无法使用了。根据测试结果调整中继节点的密度。我的经验是在典型的室内办公环境为了保证可靠性ESP-NOW中继节点的间距最好在15-25米以内。2. LoRa参数现场调优带上笔记本电脑和设备到现场进行LoRa链路测试。使用一个固定的发送节点在多个接收点测试。首要任务是找到能稳定通信的最大距离固定发射功率逐步增加SF直到在目标最远点能稳定接收丢包率1%。测试不同天线的影响弹簧天线、棒状天线、外接SMA天线效果差异巨大。在可能的情况下为LoRa模块配备一个外接的、频率匹配的天线能极大改善性能。注意“捕获效应”LoRa有很强的捕获效应。当两个信号同时到达功率强的信号会“捕获”接收机弱信号会被忽略。这在Mesh网络中可能导致某些路径不稳定。可以通过错开不同节点的发送时间加随机延迟来缓解。3. 功耗实测与电池估算这是电池供电项目的生死线。用万用表串联到电池供电回路测量设备在不同工作模式下的平均电流。深度睡眠电流ESP32-S3 LoRa模块好的设计可以做到20μA以下。ESP-NOW发送瞬间电流可能高达200mA但持续时间短几十毫秒。LoRa发送电流约120mA持续时间长与SF和包长成正比发送一个字节在SF9下可能需要几十毫秒。LoRa接收电流约10mA。假设一个终端节点每5分钟唤醒一次用ESP-NOW发送100字节数据耗时约10ms然后深度睡眠。其平均电流大致为(200mA * 0.01s 20μA * 299.99s) / 300s ≈ 0.067mA。一个2000mAh的电池理论续航可达2000mAh / 0.067mA ≈ 30000小时 ≈ 3.4年。这只是一个理想估算实际要考虑电池自放电、电路静态功耗、温度影响等但足以说明优化功耗的巨大意义。5.3 常见问题与排坑指南在开发过程中我踩过不少坑这里分享几个最有代表性的1. ESP-NOW与Wi-Fi的冲突问题设备同时运行ESP-NOW和普通的Wi-Fi客户端/AP模式极不稳定。 根因ESP-NOW和Wi-Fi共享底层硬件和缓冲区同时运行容易导致资源冲突和崩溃。 解决不要在同一个设备上混用ESP-NOW和Wi-Fi连接。如果设备需要连接互联网设计成双机架构一个ESP32专做ESP-NOW Mesh节点另一个ESP32或其它模块如ESP8266作为Wi-Fi客户端连接路由器两者通过UART串口通信。2. LoRa通信随机失败问题LoRa通信时好时坏有时完全收不到。 排查过程首先检查硬件连接特别是天线是否接好。用频谱仪或另一个LoRa设备监听确认发送端确实在发射。检查发送和接收方的参数频率、带宽、SF、编码率是否完全一致一个字节都不能错。检查电源。LoRa发射时峰值电流较大劣质LDO或电量不足的电池会导致电压跌落模块复位。务必在电源引脚并联一个大电容如100μF钽电容0.1μF陶瓷电容。最后发现是软件问题发送函数radio.transmit()返回成功但之后没有及时调用radio.startReceive()重新切回接收模式导致错过了后续的包。必须在每次发送完成后立即重新启动接收。3. Mesh网络中的“广播风暴”问题网络规模稍大如超过10个节点偶尔会出现所有节点疯狂重发网络瘫痪。 根因路由请求(RREQ)包被全网广播每个节点都处理并转发如果TTL设置过大或路由收敛慢会产生指数级增长的广播包。 解决合理设置TTL根据网络规模设置不要盲目设大。使用随机延迟在转发广播包前加入一个随机延迟如10-100ms避免所有节点同时转发。实现重复包检测利用sourceNodeId和sequenceNum每个节点缓存最近收到的广播包ID对于重复包直接丢弃不转发。考虑使用“泛洪抑制”算法如MPR (Multi-Point Relay)。4. 设备死机与看门狗在复杂的Mesh逻辑和无线通信中断下程序跑飞或死锁的风险增加。 解决务必启用硬件看门狗。#include esp_task_wdt.h void setup() { esp_task_wdt_init(10, true); // 10秒超时触发panic复位 esp_task_wdt_add(NULL); // 将当前任务加入看门狗监控 } void loop() { esp_task_wdt_reset(); // 在主循环中定期喂狗 // ... 其他代码 }同时在可能长时间阻塞的操作如等待LoRa发送完成中也要加入超时判断和看门狗复位。打造这个双模离线通信器的过程是一次对无线通信技术、嵌入式系统和网络协议的深度实践。它没有使用任何现成的复杂协议栈而是从底层开始根据实际场景需求进行裁剪和设计这让我对“通信”的本质有了更深刻的理解。从最初的点对点通信到简单的星型网络再到如今能多跳中继、双模协作的Mesh网络每一步都解决了实际问题也带来了新的挑战。这种架构的灵活性是它最大的优点。你可以根据项目需求轻松调整节点的角色和通信策略。例如在需要极低功耗的传感器网络中可以让LoRa只用于下行指令上行数据全部由ESP-NOW多跳汇聚。在需要广域覆盖的车辆追踪中可以让每个移动节点都具备LoRa能力直接与远方的网关通信。当然它目前还是一个原型在安全性如通信加密、网络管理如远程固件升级、大规模组网稳定性等方面还有很长的路要走。但对于许多物联网应用场景来说它已经提供了一个非常坚实且高性价比的起点。