去年有一次我带着一帮朋友去山里徒步走到半路有人脚崴了手机一格信号都没有那一刻我真切体会到什么叫“叫天天不应”。也是从那次之后我开始认真琢磨一套不依赖运营商网络的离网求救系统。折腾了大概两个月最终还是选定了M5Stack加树莓派的组合一头做随身求救终端一头做营地或救援队这边的接收网关中间走LoRa无线链路消息用AES-GCM做端到端加密。整套系统可以做到“不插SIM卡、不连公网、连不起WiFi也能稳稳发出一条加密的求救报文”。这篇博文就把这套系统的架构思路、核心代码和踩坑过程完整梳理一遍给同样想做应急通信、DIY救援设备的朋友一个可以照着抄的参考。1. 整体设计与选型逻辑1.1 离网场景下救援通信到底缺什么先界定一下“离网”这个词。这里说的是通信层面上的“离网”不是完全不要电。真正的野外救援场景里运营商基站大概率是没有信号的就算有信号拥挤状态下信令信道也容易被占满普通电话根本打不出去。WiFi和蓝牙就更不用说了覆盖范围太小也只能在短距离内凑合用。这时候只剩下两类通道可用一类是卫星通信比如北斗短报文、铱星、海事电话覆盖好但设备成本和通信费用高另一类就是自建的无线电链路常见的有LoRa、APRS、数传电台等设备便宜、部署灵活覆盖范围几公里到几十公里不等代价是需要自己架设接收端。我选择的方案是LoRa作为主链路。原因很直接LoRa属于低功耗广域网技术接收灵敏度可以达到-130dBm级别在野外开阔环境下很小的发射功率配合较好的天线就能轻松实现几公里甚至更远的通信。更重要的是M5Stack生态里本来就有成熟的LoRa模块树莓派这边也有对应SPI接口的LoRa板卡两边都能用Python或Arduino快速驱动开发门槛比我自己搞一个SDR方案低太多。1.2 M5Stack和树莓派的分工M5Stack和树莓派在项目里不是竞争关系而是各管一头。M5Stack Core2自带2.0英寸屏幕、触摸面板、几个物理按键、麦克风、扬声器还支持内部电池和外接GPS模块特别适合做随身求救终端。它的主控是ESP32双核240MHz做LoRa报文封装、加密运算、GPS解析绰绰有余睡眠电流也能压得很低关键时刻按一下求救键就会开机发送。更关键的是M5Stack本身是一个模块化生态GPS、LoRa、电池底座都是即插即用的不需要自己重新画板子、焊天线这在野外项目的稳定性上非常重要——少一个虚焊点就少一个故障源。树莓派这边则做接收端网关。我用的是树莓派4B如果你手头有树莓派2B、3B也够用因为LoRa的接收解调是SX1278芯片干的活树莓派只是从SPI口把数据读出来再解密、解析、落库。说实话这个活儿对CPU要求很低耗的是开发和维护的便利性Python环境好配日志、数据库、Web展示都能快速搞定将来想加个MQTT转发或者短信猫报警也就是多写几十行Python的事。网关放在营地或者救援队指挥点一片覆盖区内所有终端发来的求救信标都会被它汇总记录。1.3 数据链路设计整套系统的数据流是单向的、面向求救优先设计的。M5Stack终端先把GPS位置、时间戳、求救者ID、紧急消息组装成明文报文再用AES-GCM加密然后把密文和认证标签塞进LoRa的payload字段RF无线发出。树莓派网关持续监听LoRa信道收到数据后先做GCM鉴权和解密如果认证通过就把位置和消息显示在监控界面并记录到SQLite数据库里。这里强调“单向”是有意为之双向链路会引入应答、重传、握手等协议复杂度求救场景里终端侧越简单越不容易出错一次按下就是“发出去并持续重发”网关侧只要保证收到一条就算成功。即便这样的机制非常“笨”但它可靠性极高别人家那套复杂的TCP风格信令在这条信道上反而会浪费宝贵的空中时间。反正LoRa信道本身就是半双工的真正求救时也没有人会在通道里跟你握手协商。2. 加密与报文设计既要保密更要防伪造2.1 为什么不用普通ECC/RSA选了AES-GCM很多朋友一开始会想到用非对称加密来保护求救消息比如RSA或ECC但这里有个实际问题LoRa单包payload最大一般就是256字节左右实际推荐还要留余量。RSA-2048签名和密文加起来轻轻松松超过这个预算更别提握手里不止一条消息。所以我在终端侧选了对称加密的AES-GCM模式密钥长度128bit兼顾安全性和链路开销。AES-GCM对求救消息尤其合适因为它同时提供加密和完整性校验。传统AES-CBC即使加密了攻击者依然可以篡改密文内容而GCM在解密的同时会做GHASH校验一旦密文被改动、重放或拼接解密接口会直接丢弃。这套机制在人为故意干扰的LoRa信道上特别重要不要说恶意篡改就算是电磁环境差导致的比特翻转GCM也能在接收端直接识别避免把一堆乱码当成求救信息存入后台。2.2 求救报文的帧结构我设计的报文结构是这样的具体字段可以按自己需求增减字段长度说明Magic2字节固定同步头例如0x5353用来快速识别本系统Version1字节协议版本号方便以后升级MsgType1字节消息类型0x01代表求救0x02代表心跳/测试SenderID2字节终端ID用CRC或自定义编号用于识别哪个终端发出求救Timestamp4字节Unix时间精确到秒便于网关评估消息新鲜度Latitude4字节GPS纬度用int32表示精确到1e-6度Longitude4字节GPS经度同上int32表示Altitude2字节海拔单位米也可以省略MessageLen1字节自定义消息长度最多255字节Message变长自定义求救信息如“ankle injured, need rescue”以上是“明文侧”的格式。实际在空中传输时我会把Latitude、Longitude、Timestamp、Altitude、Message等字段全部拼成一个字节流用AES-GCM加密再加上12字节IV。LoRa payload里放的就是“帧头(明文)IV密文字节流16字节GCM tag”这样的结构。帧头必须保持明文因为网关要在不知道解密内容的情况下先识别这是不是本系统的包中间的关键内容全走加密和tag校验。解释一下GCM nonce的生成。GCM的安全性依赖nonce不会重复求救终端每次发送都会重新生成8字节随机数作为nonce主体再补上4字节固定盐值拼成12字节IV。网关端用相同的密钥加上收到的IV来解。这样即使同一个终端短时间内发多条相同位置消息每次密文也完全不同无法被直接重放分析。2.3 密钥管理断电不丢部署固定对于这种离网场景的终端我用的密钥管理策略是“出厂预置 现场固定”。终端侧把128bit的AES密钥以字节数组烧进M5Stack的Flash存储NVS区网关侧读取同一个密钥到树莓派的配置文件里。救援队伍在出发前用一个简单的密钥生成脚本生成一对相同密钥分别部署到终端和网关。需要注意密钥不能明文写在共享的配置文件里后就随手发到网上。现实中常见做法是统一用一段工程号加日期做种子配合PBKDF2派生出128bit密钥。这样即使有人拿到配置文件外泄没有种子也推导不出实际密钥。这套系统的密钥管理逻辑不需要在线密钥中心完全离网也能工作配置复杂度也低。当然如果有一天你希望多支队伍使用同一片覆盖区域就需要升级为每台终端单独密钥、网关端保存密钥表这是后话。3. M5Stack 求救终端实现3.1 硬件准备与接线我用到的硬件清单如下M5Stack Core2如果手头是Core或FIRE接口略有差异但整体兼容M5Stack GPS模块基于NEO-M8N串口输出NMEA协议M5Stack LoRa模块用SX1276/SX1278433MHz或868MHz属于ISM频段具体可用频点取决于你所在地区允许的免执照频段两节18650电池或者M5Stack官方电池底座保证野外至少要能撑一天12到18cm长的拉杆天线或四分之一波长钢丝天线接线方面M5Stack的模块基本是即插即用的GPS模块插到后面板I2C口或专用UART口LoRa模块插到GROVE口或者通过HAT堆叠。如果你的模块是裸的SX1278接线可能需要飞线注意把MISO、MOSI、SCK、NSS、RST区分清楚这几个信号错一根整个SPI通信直接哑火。第一次通电前建议用一个最基础的SPI scan程序确认LoRa芯片能被访问到再继续写上层逻辑。3.2 主程序流程我用Arduino环境开发开发板选“M5Stack Core2”引入M5Stack库、TinyGPSPlus库、M5Stack LoRa库。程序核心流程不复杂无非四件事初始化、GPS定位、加密打包、LoRa发送。但细节决定成败。先看主程序框架#include M5Stack.h #include TinyGPSPlus.h #include loRa.h TinyGPSPlus gps; HardwareSerial GPS_SERIAL(2); // M5Stack GPS模块通常用串口2 // 预置的128bit密钥实际部署时通过PBKDF2派生后写入 uint8_t aesKey[16] {0x00, 0x00, 0x11, 0x11, 0x22, 0x22, 0x33, 0x33, 0x44, 0x44, 0x55, 0x55, 0x66, 0x66, 0x77, 0x77}; // 终端ID uint16_t senderId 0x0001; void setup() { M5.begin(); M5.Power.begin(); GPS_SERIAL.begin(9600, SERIAL_8N1, 16, 17); LoRa.setPins(SS_PIN, RST_PIN, DIO0_PIN); if (!LoRa.begin(433E6)) { M5.Lcd.println(LoRa init failed); while(true); } M5.Lcd.println(SOS Terminal ready); } void loop() { M5.update(); if (M5.BtnA.wasPressed()) { sendSOSMessage(ankle injured, need rescue); } while (GPS_SERIAL.available() 0) { gps.encode(GPS_SERIAL.read()); } }这个例子把GPS解析放进了主循环但实际使用中最好加一点调度策略比如按键触发后先强制读取GPS最多20秒如果定位成功则打包发送如果还在冷启动阶段则进入“未定位重发模式”把最后一个已知位置带上并在消息里标一个“position_stale”字段。3.3 加密打包实现加密部分我没有直接用Arduino里那种一次性超长代码写而是先封装了一个小工具函数输入是明文字节流和长度输出是密文帧。核心参数都拉到最前面方便后续换密钥或改算法。关键实现参考如下#include mbedtls/gcm.h void aesGcmEncrypt(uint8_t *plaintext, size_t plaintextLen, uint8_t *iv, size_t ivLen, uint8_t *ciphertext, uint8_t *tag, uint8_t *aad, size_t aadLen) { mbedtls_gcm_context ctx; mbedtls_gcm_init(ctx); mbedtls_gcm_setkey(ctx, MBEDTLS_CIPHER_ID_AES, aesKey, 128); mbedtls_gcm_crypt_and_tag(ctx, MBEDTLS_GCM_ENCRYPT, plaintextLen, iv, ivLen, aad, aadLen, plaintext, ciphertext, 16, tag); mbedtls_gcm_free(ctx); }一次求救发送的调用逻辑是先填充明文结构体打包成字节流然后生成12字节随机IV接着调用AES-GCM加密最后组合成“帧头 IV 密文 tag”交给LoRa发送。注意M5Stack的ESP32 SDK内置了mbedtls加密库不需要额外下载第三方加密库这大大降低了编译难度。如果你用的是UIFlow图形化开发环境也可以在模块库里找到Crypto组件但操作起来没有Arduino环境可控我建议还是回到Arduino上写。3.4 LoRa发送与重发策略求救信号最怕“发一次没人听见”所以发送策略很重要。我的做法是按下求救键后立刻连发5次每次间隔约5秒然后进入周期模式每2分钟重发一次直到手动关机或按键取消。重发周期可以改但要和网关侧“连续监听”配合如果网关有多个接收通道周期可以适当缩短。LoRa发送的同时我在M5Stack的屏幕上显示当前发送状态、GPS卫星数、已发送次数万一遇到GPS没定位还是会持续发确保救援队能看到最后已知位置。屏幕上用红色大号字体显示SOS和坐标也能让求助者自己把位置抄下来告诉营地方。这里有个小技巧串口打印和屏幕刷新都加一点节流否则ESP32在高频LoRa发射时容易出现看门狗复位具体表现就是屏幕卡住、发送中断。4. 树莓派接收网关搭建4.1 网关程序架构树莓派网关这头我用的是Python 3加spidev库驱动SPI配合SX127x模块监听特定频率的LoRa数据。整个网关从功能上分成四层SPI物理层驱动从SX1278芯片FIFO读回原始字节流帧解析层识别Magic、长度、类型等字段把完整LoRa payload组装出来解密层用相同密钥执行AES-GCM解密同时对密文做完整性校验应用层把解析后的GPS位置、时间、消息写入SQLite并在Web界面或LCD上呈现树莓派上监听LoRa关键是驱动代码不能和普通串口混在一起。我用的是某款基于SX1278的树莓派HAT它把RF模块挂在SPI0的CE0上DIO0接到GPIO25做中断通知。简单说就是树莓派在做别的任务时LoRa芯片收到数据会通过DIO0引脚拉高告诉CPU“来活了”CPU再去读SPI FIFO。中断方式比纯轮询高效得多也容易漏包。4.2 使用SX127x接收原始数据如果你的LoRa模块是SX1278且挂在同一SPI总线上可以先用现成的Raspberry Pi LoRa库做一个收发测试确认物理链路已经通了再上自己的解密逻辑。这里给一个接收端的骨架代码import spidev import RPi.GPIO as GPIO from SX127x.LoRa import * from SX127x.board_config import BOARD BOARD.setup() lora LoRa() lora.set_mode(MODE.SLEEP) lora.set_freq(433.0) lora.set_pa_config(pa_select0, max_power14, output_power14) lora.set_bw(BW.BW125) lora.set_coding_rate(CODING_RATE.CR4_5) lora.set_spreading_factor(SF.SF7) lora.set_rx_crc(True) lora.set_mode(MODE.RXCONT) def on_rx_done(): lora.clear_irq_flags(RxDone1) payload lora.read_payload() lora.reset_ptr_rx() # 到这里就能拿到完整的LoRa payload字节流 lora.on_rx_done on_rx_done while True: time.sleep(0.1)这个库的好处是已经把SX127x的寄存器操作封装好了你只需要关注read_payload返回的原始字节。坏处是它的API风格有点老调试时要多对几遍寄存器文档尤其注意SF和BW的配置必须与终端完全一致否则一个包都收不上来。4.3 解密与数据库写入拿到LoRa payload后先把帧头解析出来确认Magic、Version、Length都合法再截出IV、密文、tag交给Python的cryptography库做AESGCM解密from cryptography.hazmat.primitives.ciphers.aead import AESGCM def decrypt_sos(payload, key): # 帧格式[2字节 Magic][1字节 Version][1字节 MsgType][2字节 SenderID] # [12字节 IV][密文长度N][密文][16字节 tag] iv payload[6:18] ciphertext payload[18:18N] tag payload[18N:18N16] aesgcm AESGCM(key) try: plaintext aesgcm.decrypt(iv, ciphertext tag, None) return plaintext except Exception: log_to_db(AUTH_FAIL, payload) return None数据库我用SQLite表结构非常简单CREATE TABLE IF NOT EXISTS sos_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, sender_id INTEGER, msg_type INTEGER, timestamp INTEGER, lat REAL, lon REAL, altitude REAL, message TEXT, rssi INTEGER, snr REAL, receive_time TEXT );RSSI和SNR会从LoRa寄存器读出来这两个参数对于事后判断信号覆盖很有用别偷懒不存。实际部署中我会顺手把原始payload的hex也存到另一个字段里方便出问题以后回放排查。4.4 可视化与告警提示网关不只是“收到数据记一行日志”真实场景里救援队需要立刻看到。我做了两种提示一是终端界面用树莓派接了一个小LCD收到求救时整屏红底白字显示“SOS ALERT”和具体坐标、时间同时LED灯闪烁、蜂鸣器响二是Web页面树莓派上跑一个轻量Flask服务把SQLite数据通过地图组件标出来。因为不依赖外网我让页面引用本地缓存的静态地图资源树莓派同时开一个手机AP热点营地人员用手机连上来打开浏览器就能看到实时求救点。这里有个很关键的点离网状态下地图瓦片不能加载所以你要么预加载一批本地瓦片要么干脆不做地图用一个简单的经纬度文本列表代替。第一次测试时我就死在了“页面是空的、地图区域一片灰”上折腾了很久才发现是CDN请求超时。5. 常见问题、调试技巧与野外实测心得5.1 LoRa通信距离和天线选择先说结论同样配置下我实测过在海拔差不多的丘陵地带433MHz加18cm拉杆天线、1瓦左右的发射功率点到点能拉出约3到5公里如果是开阔水面或山顶对山顶5到10公里也不是不可能。但信号质量受地形影响极大不要抱太大期望。经验教训有这么几条天线尽可能垂直人手持终端时尽量让天线朝上避免手掌挡住振子网关天线尽量架高最好高于附近障碍物这一点甚至比加功率还重要如果救援队伍有多个营地就把LoRa网关挂在5米长的PVC杆上LoRa的SF扩频因子调大比如SF10或SF11能提灵敏度但也更慢占用空中时间更长要在距离和消息速率之间找平衡。5.2 GPS收星慢与冷启动问题M5Stack外接的NEO-M8N冷启动可能需要30秒到2分钟在山区树冠遮挡严重的环境会更久。我实际踩过的坑是第一次测试时按完求救键GPS还没定位程序就把个默认的(0,0)坐标发出去了网关那边在地图上看到一个非洲海岸的求救点相当尴尬。解决办法发送前判断GPS是否有效无效则发送“未定位求救包”里面带设备编号和时间戳并附一条最后已知位置字段。同时在终端屏幕上打印当前定位状态提醒使用者“GPS定位中请移步开阔处”。还有一个容易被忽视的是天线朝向。M5Stack的GPS模块天线通常在PCB背面终端平放在桌面时会背朝天空收星效果差拿在手里歪着放反而不好。我后来给终端加了一小块泡沫垫保证放地上时模块背面也朝上收星速度明显提升。5.3 加密认证失败调试如果你发现网关一直收不到或者日志里全是AUTH_FAIL大概率不是频率没对上而是密钥不对或协议字段偏移解析错。一个排查步骤是先用不加密的“裸发模式”在M5Stack上发一串“ABCDEF”网关直接打印hex确认物理链路和SPI没问题再在M5Stack上对这段明文加密后发送网关先打印接收到的hex和终端发送的hex对比确认空中数据完整最后才交给解密函数确认IV、密文、tag的截取位置一致。协议字段偏移的bug非常恼人好在只要在两边各自打印hex就能快速定位。还有一个容易错的地方是字节序ESP32和树莓派都是小端序但如果你从某个参考代码里复制了大端解析很容易在整数维度上得出一些奇怪的结果。另外树莓派这边使用的Python cryptography库要求密文和tag拼接传递而M5Stack端有些封装是分开返回的拼接顺序如果搞反同样会一直认证失败。5.4 供电与续航M5Stack Core2内置电池容量大约1100mAh单纯待机能撑一两天但如果一直亮屏加LoRa周期发射可能几个小时就没电。我改造了供电方案用两节18650并联的电池盒通过5V升压模块接到M5Stack的USB口LoRa模块如果直接由主板供电发射电流比较大的时候SPI偶发异常稳妥做法是给LoRa模块单独用锂电池供电或者选带独立供电的HAT。树莓派网关不必太省电但野外营地供电也紧张我用一个5V 3A的太阳能控制器加12V锂电池组给树莓派供电实测一块120Wh容量的电池能撑一天以上。建议给树莓派配一个支持看门狗的电源模块万一程序崩溃还能自动重启。电源和天线是我觉得这套系统里最不能省钱的两个地方。5.5 简单故障速查表现象可能原因排查方向终端屏幕显示“LoRa init failed”SPI接线错误或LoRa板未上电检查NSS/RST引脚定义用示波器看SPI时钟收不到任何包频率不一致或SF/BW参数不一致终端和网关统一频率、SF、编码率逐项确认收到包但AUTH_FAIL密钥不一致或协议偏移错误关加密裸发对比hex逐个字段对GPS数值为(0,0)未定位就发送判断gps.location.isValid()后再发终端发送时死机重启LoRa模块瞬时大电流拉垮电源给LoRa独立供电更换输出稳定的DC-DC模块网关Web页面打不开Flask服务未启动或局域网IP变了用同一AP下测试固定树莓派IP地址上面这张表是我在实际测试中整理出的常见问题速查给营地技术员用非常顺手。这里多说一句排查这类系统唯一的原则就是“分层验证”先物理通道再协议格式最后才涉及加密逻辑。只要每层能独立打印出符合条件的输入输出整个链路就不会有大问题。反过来如果你一上来就怀疑加密多半会把时间浪费在看不懂的hex里。最后再分享一个实用心得这套系统里真正花时间的不是加密算法也不是LoRa配置而是野外环境下各种“软故障”。树莓派网关放在营地里电源波动、USB转串口松动、SPI线被老鼠咬断这些才是实际问题。建议你做完第一版后带到附近的公园、山头多跑几次把天线摆放、GPS冷启动、供电续航这些真实场景里的问题都暴露出来再回到室内慢慢迭代。毕竟一套只能在桌面上跑通的求救系统真到了它该起作用的地方是没有第二次调试机会的。 
长河君 · 2026/9/20 5:11:16 · 阅读 1.2k 基于LoRa与AES-GCM的离网求救系统：M5Stack与树莓派实战
去年有一次我带着一帮朋友去山里徒步走到半路有人脚崴了手机一格信号都没有那一刻我真切体会到什么叫“叫天天不应”。也是从那次之后我开始认真琢磨一套不依赖运营商网络的离网求救系统。折腾了大概两个月最终还是选定了M5Stack加树莓派的组合一头做随身求救终端一头做营地或救援队这边的接收网关中间走LoRa无线链路消息用AES-GCM做端到端加密。整套系统可以做到“不插SIM卡、不连公网、连不起WiFi也能稳稳发出一条加密的求救报文”。这篇博文就把这套系统的架构思路、核心代码和踩坑过程完整梳理一遍给同样想做应急通信、DIY救援设备的朋友一个可以照着抄的参考。1. 整体设计与选型逻辑1.1 离网场景下救援通信到底缺什么先界定一下“离网”这个词。这里说的是通信层面上的“离网”不是完全不要电。真正的野外救援场景里运营商基站大概率是没有信号的就算有信号拥挤状态下信令信道也容易被占满普通电话根本打不出去。WiFi和蓝牙就更不用说了覆盖范围太小也只能在短距离内凑合用。这时候只剩下两类通道可用一类是卫星通信比如北斗短报文、铱星、海事电话覆盖好但设备成本和通信费用高另一类就是自建的无线电链路常见的有LoRa、APRS、数传电台等设备便宜、部署灵活覆盖范围几公里到几十公里不等代价是需要自己架设接收端。我选择的方案是LoRa作为主链路。原因很直接LoRa属于低功耗广域网技术接收灵敏度可以达到-130dBm级别在野外开阔环境下很小的发射功率配合较好的天线就能轻松实现几公里甚至更远的通信。更重要的是M5Stack生态里本来就有成熟的LoRa模块树莓派这边也有对应SPI接口的LoRa板卡两边都能用Python或Arduino快速驱动开发门槛比我自己搞一个SDR方案低太多。1.2 M5Stack和树莓派的分工M5Stack和树莓派在项目里不是竞争关系而是各管一头。M5Stack Core2自带2.0英寸屏幕、触摸面板、几个物理按键、麦克风、扬声器还支持内部电池和外接GPS模块特别适合做随身求救终端。它的主控是ESP32双核240MHz做LoRa报文封装、加密运算、GPS解析绰绰有余睡眠电流也能压得很低关键时刻按一下求救键就会开机发送。更关键的是M5Stack本身是一个模块化生态GPS、LoRa、电池底座都是即插即用的不需要自己重新画板子、焊天线这在野外项目的稳定性上非常重要——少一个虚焊点就少一个故障源。树莓派这边则做接收端网关。我用的是树莓派4B如果你手头有树莓派2B、3B也够用因为LoRa的接收解调是SX1278芯片干的活树莓派只是从SPI口把数据读出来再解密、解析、落库。说实话这个活儿对CPU要求很低耗的是开发和维护的便利性Python环境好配日志、数据库、Web展示都能快速搞定将来想加个MQTT转发或者短信猫报警也就是多写几十行Python的事。网关放在营地或者救援队指挥点一片覆盖区内所有终端发来的求救信标都会被它汇总记录。1.3 数据链路设计整套系统的数据流是单向的、面向求救优先设计的。M5Stack终端先把GPS位置、时间戳、求救者ID、紧急消息组装成明文报文再用AES-GCM加密然后把密文和认证标签塞进LoRa的payload字段RF无线发出。树莓派网关持续监听LoRa信道收到数据后先做GCM鉴权和解密如果认证通过就把位置和消息显示在监控界面并记录到SQLite数据库里。这里强调“单向”是有意为之双向链路会引入应答、重传、握手等协议复杂度求救场景里终端侧越简单越不容易出错一次按下就是“发出去并持续重发”网关侧只要保证收到一条就算成功。即便这样的机制非常“笨”但它可靠性极高别人家那套复杂的TCP风格信令在这条信道上反而会浪费宝贵的空中时间。反正LoRa信道本身就是半双工的真正求救时也没有人会在通道里跟你握手协商。2. 加密与报文设计既要保密更要防伪造2.1 为什么不用普通ECC/RSA选了AES-GCM很多朋友一开始会想到用非对称加密来保护求救消息比如RSA或ECC但这里有个实际问题LoRa单包payload最大一般就是256字节左右实际推荐还要留余量。RSA-2048签名和密文加起来轻轻松松超过这个预算更别提握手里不止一条消息。所以我在终端侧选了对称加密的AES-GCM模式密钥长度128bit兼顾安全性和链路开销。AES-GCM对求救消息尤其合适因为它同时提供加密和完整性校验。传统AES-CBC即使加密了攻击者依然可以篡改密文内容而GCM在解密的同时会做GHASH校验一旦密文被改动、重放或拼接解密接口会直接丢弃。这套机制在人为故意干扰的LoRa信道上特别重要不要说恶意篡改就算是电磁环境差导致的比特翻转GCM也能在接收端直接识别避免把一堆乱码当成求救信息存入后台。2.2 求救报文的帧结构我设计的报文结构是这样的具体字段可以按自己需求增减字段长度说明Magic2字节固定同步头例如0x5353用来快速识别本系统Version1字节协议版本号方便以后升级MsgType1字节消息类型0x01代表求救0x02代表心跳/测试SenderID2字节终端ID用CRC或自定义编号用于识别哪个终端发出求救Timestamp4字节Unix时间精确到秒便于网关评估消息新鲜度Latitude4字节GPS纬度用int32表示精确到1e-6度Longitude4字节GPS经度同上int32表示Altitude2字节海拔单位米也可以省略MessageLen1字节自定义消息长度最多255字节Message变长自定义求救信息如“ankle injured, need rescue”以上是“明文侧”的格式。实际在空中传输时我会把Latitude、Longitude、Timestamp、Altitude、Message等字段全部拼成一个字节流用AES-GCM加密再加上12字节IV。LoRa payload里放的就是“帧头(明文)IV密文字节流16字节GCM tag”这样的结构。帧头必须保持明文因为网关要在不知道解密内容的情况下先识别这是不是本系统的包中间的关键内容全走加密和tag校验。解释一下GCM nonce的生成。GCM的安全性依赖nonce不会重复求救终端每次发送都会重新生成8字节随机数作为nonce主体再补上4字节固定盐值拼成12字节IV。网关端用相同的密钥加上收到的IV来解。这样即使同一个终端短时间内发多条相同位置消息每次密文也完全不同无法被直接重放分析。2.3 密钥管理断电不丢部署固定对于这种离网场景的终端我用的密钥管理策略是“出厂预置 现场固定”。终端侧把128bit的AES密钥以字节数组烧进M5Stack的Flash存储NVS区网关侧读取同一个密钥到树莓派的配置文件里。救援队伍在出发前用一个简单的密钥生成脚本生成一对相同密钥分别部署到终端和网关。需要注意密钥不能明文写在共享的配置文件里后就随手发到网上。现实中常见做法是统一用一段工程号加日期做种子配合PBKDF2派生出128bit密钥。这样即使有人拿到配置文件外泄没有种子也推导不出实际密钥。这套系统的密钥管理逻辑不需要在线密钥中心完全离网也能工作配置复杂度也低。当然如果有一天你希望多支队伍使用同一片覆盖区域就需要升级为每台终端单独密钥、网关端保存密钥表这是后话。3. M5Stack 求救终端实现3.1 硬件准备与接线我用到的硬件清单如下M5Stack Core2如果手头是Core或FIRE接口略有差异但整体兼容M5Stack GPS模块基于NEO-M8N串口输出NMEA协议M5Stack LoRa模块用SX1276/SX1278433MHz或868MHz属于ISM频段具体可用频点取决于你所在地区允许的免执照频段两节18650电池或者M5Stack官方电池底座保证野外至少要能撑一天12到18cm长的拉杆天线或四分之一波长钢丝天线接线方面M5Stack的模块基本是即插即用的GPS模块插到后面板I2C口或专用UART口LoRa模块插到GROVE口或者通过HAT堆叠。如果你的模块是裸的SX1278接线可能需要飞线注意把MISO、MOSI、SCK、NSS、RST区分清楚这几个信号错一根整个SPI通信直接哑火。第一次通电前建议用一个最基础的SPI scan程序确认LoRa芯片能被访问到再继续写上层逻辑。3.2 主程序流程我用Arduino环境开发开发板选“M5Stack Core2”引入M5Stack库、TinyGPSPlus库、M5Stack LoRa库。程序核心流程不复杂无非四件事初始化、GPS定位、加密打包、LoRa发送。但细节决定成败。先看主程序框架#include M5Stack.h #include TinyGPSPlus.h #include loRa.h TinyGPSPlus gps; HardwareSerial GPS_SERIAL(2); // M5Stack GPS模块通常用串口2 // 预置的128bit密钥实际部署时通过PBKDF2派生后写入 uint8_t aesKey[16] {0x00, 0x00, 0x11, 0x11, 0x22, 0x22, 0x33, 0x33, 0x44, 0x44, 0x55, 0x55, 0x66, 0x66, 0x77, 0x77}; // 终端ID uint16_t senderId 0x0001; void setup() { M5.begin(); M5.Power.begin(); GPS_SERIAL.begin(9600, SERIAL_8N1, 16, 17); LoRa.setPins(SS_PIN, RST_PIN, DIO0_PIN); if (!LoRa.begin(433E6)) { M5.Lcd.println(LoRa init failed); while(true); } M5.Lcd.println(SOS Terminal ready); } void loop() { M5.update(); if (M5.BtnA.wasPressed()) { sendSOSMessage(ankle injured, need rescue); } while (GPS_SERIAL.available() 0) { gps.encode(GPS_SERIAL.read()); } }这个例子把GPS解析放进了主循环但实际使用中最好加一点调度策略比如按键触发后先强制读取GPS最多20秒如果定位成功则打包发送如果还在冷启动阶段则进入“未定位重发模式”把最后一个已知位置带上并在消息里标一个“position_stale”字段。3.3 加密打包实现加密部分我没有直接用Arduino里那种一次性超长代码写而是先封装了一个小工具函数输入是明文字节流和长度输出是密文帧。核心参数都拉到最前面方便后续换密钥或改算法。关键实现参考如下#include mbedtls/gcm.h void aesGcmEncrypt(uint8_t *plaintext, size_t plaintextLen, uint8_t *iv, size_t ivLen, uint8_t *ciphertext, uint8_t *tag, uint8_t *aad, size_t aadLen) { mbedtls_gcm_context ctx; mbedtls_gcm_init(ctx); mbedtls_gcm_setkey(ctx, MBEDTLS_CIPHER_ID_AES, aesKey, 128); mbedtls_gcm_crypt_and_tag(ctx, MBEDTLS_GCM_ENCRYPT, plaintextLen, iv, ivLen, aad, aadLen, plaintext, ciphertext, 16, tag); mbedtls_gcm_free(ctx); }一次求救发送的调用逻辑是先填充明文结构体打包成字节流然后生成12字节随机IV接着调用AES-GCM加密最后组合成“帧头 IV 密文 tag”交给LoRa发送。注意M5Stack的ESP32 SDK内置了mbedtls加密库不需要额外下载第三方加密库这大大降低了编译难度。如果你用的是UIFlow图形化开发环境也可以在模块库里找到Crypto组件但操作起来没有Arduino环境可控我建议还是回到Arduino上写。3.4 LoRa发送与重发策略求救信号最怕“发一次没人听见”所以发送策略很重要。我的做法是按下求救键后立刻连发5次每次间隔约5秒然后进入周期模式每2分钟重发一次直到手动关机或按键取消。重发周期可以改但要和网关侧“连续监听”配合如果网关有多个接收通道周期可以适当缩短。LoRa发送的同时我在M5Stack的屏幕上显示当前发送状态、GPS卫星数、已发送次数万一遇到GPS没定位还是会持续发确保救援队能看到最后已知位置。屏幕上用红色大号字体显示SOS和坐标也能让求助者自己把位置抄下来告诉营地方。这里有个小技巧串口打印和屏幕刷新都加一点节流否则ESP32在高频LoRa发射时容易出现看门狗复位具体表现就是屏幕卡住、发送中断。4. 树莓派接收网关搭建4.1 网关程序架构树莓派网关这头我用的是Python 3加spidev库驱动SPI配合SX127x模块监听特定频率的LoRa数据。整个网关从功能上分成四层SPI物理层驱动从SX1278芯片FIFO读回原始字节流帧解析层识别Magic、长度、类型等字段把完整LoRa payload组装出来解密层用相同密钥执行AES-GCM解密同时对密文做完整性校验应用层把解析后的GPS位置、时间、消息写入SQLite并在Web界面或LCD上呈现树莓派上监听LoRa关键是驱动代码不能和普通串口混在一起。我用的是某款基于SX1278的树莓派HAT它把RF模块挂在SPI0的CE0上DIO0接到GPIO25做中断通知。简单说就是树莓派在做别的任务时LoRa芯片收到数据会通过DIO0引脚拉高告诉CPU“来活了”CPU再去读SPI FIFO。中断方式比纯轮询高效得多也容易漏包。4.2 使用SX127x接收原始数据如果你的LoRa模块是SX1278且挂在同一SPI总线上可以先用现成的Raspberry Pi LoRa库做一个收发测试确认物理链路已经通了再上自己的解密逻辑。这里给一个接收端的骨架代码import spidev import RPi.GPIO as GPIO from SX127x.LoRa import * from SX127x.board_config import BOARD BOARD.setup() lora LoRa() lora.set_mode(MODE.SLEEP) lora.set_freq(433.0) lora.set_pa_config(pa_select0, max_power14, output_power14) lora.set_bw(BW.BW125) lora.set_coding_rate(CODING_RATE.CR4_5) lora.set_spreading_factor(SF.SF7) lora.set_rx_crc(True) lora.set_mode(MODE.RXCONT) def on_rx_done(): lora.clear_irq_flags(RxDone1) payload lora.read_payload() lora.reset_ptr_rx() # 到这里就能拿到完整的LoRa payload字节流 lora.on_rx_done on_rx_done while True: time.sleep(0.1)这个库的好处是已经把SX127x的寄存器操作封装好了你只需要关注read_payload返回的原始字节。坏处是它的API风格有点老调试时要多对几遍寄存器文档尤其注意SF和BW的配置必须与终端完全一致否则一个包都收不上来。4.3 解密与数据库写入拿到LoRa payload后先把帧头解析出来确认Magic、Version、Length都合法再截出IV、密文、tag交给Python的cryptography库做AESGCM解密from cryptography.hazmat.primitives.ciphers.aead import AESGCM def decrypt_sos(payload, key): # 帧格式[2字节 Magic][1字节 Version][1字节 MsgType][2字节 SenderID] # [12字节 IV][密文长度N][密文][16字节 tag] iv payload[6:18] ciphertext payload[18:18N] tag payload[18N:18N16] aesgcm AESGCM(key) try: plaintext aesgcm.decrypt(iv, ciphertext tag, None) return plaintext except Exception: log_to_db(AUTH_FAIL, payload) return None数据库我用SQLite表结构非常简单CREATE TABLE IF NOT EXISTS sos_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, sender_id INTEGER, msg_type INTEGER, timestamp INTEGER, lat REAL, lon REAL, altitude REAL, message TEXT, rssi INTEGER, snr REAL, receive_time TEXT );RSSI和SNR会从LoRa寄存器读出来这两个参数对于事后判断信号覆盖很有用别偷懒不存。实际部署中我会顺手把原始payload的hex也存到另一个字段里方便出问题以后回放排查。4.4 可视化与告警提示网关不只是“收到数据记一行日志”真实场景里救援队需要立刻看到。我做了两种提示一是终端界面用树莓派接了一个小LCD收到求救时整屏红底白字显示“SOS ALERT”和具体坐标、时间同时LED灯闪烁、蜂鸣器响二是Web页面树莓派上跑一个轻量Flask服务把SQLite数据通过地图组件标出来。因为不依赖外网我让页面引用本地缓存的静态地图资源树莓派同时开一个手机AP热点营地人员用手机连上来打开浏览器就能看到实时求救点。这里有个很关键的点离网状态下地图瓦片不能加载所以你要么预加载一批本地瓦片要么干脆不做地图用一个简单的经纬度文本列表代替。第一次测试时我就死在了“页面是空的、地图区域一片灰”上折腾了很久才发现是CDN请求超时。5. 常见问题、调试技巧与野外实测心得5.1 LoRa通信距离和天线选择先说结论同样配置下我实测过在海拔差不多的丘陵地带433MHz加18cm拉杆天线、1瓦左右的发射功率点到点能拉出约3到5公里如果是开阔水面或山顶对山顶5到10公里也不是不可能。但信号质量受地形影响极大不要抱太大期望。经验教训有这么几条天线尽可能垂直人手持终端时尽量让天线朝上避免手掌挡住振子网关天线尽量架高最好高于附近障碍物这一点甚至比加功率还重要如果救援队伍有多个营地就把LoRa网关挂在5米长的PVC杆上LoRa的SF扩频因子调大比如SF10或SF11能提灵敏度但也更慢占用空中时间更长要在距离和消息速率之间找平衡。5.2 GPS收星慢与冷启动问题M5Stack外接的NEO-M8N冷启动可能需要30秒到2分钟在山区树冠遮挡严重的环境会更久。我实际踩过的坑是第一次测试时按完求救键GPS还没定位程序就把个默认的(0,0)坐标发出去了网关那边在地图上看到一个非洲海岸的求救点相当尴尬。解决办法发送前判断GPS是否有效无效则发送“未定位求救包”里面带设备编号和时间戳并附一条最后已知位置字段。同时在终端屏幕上打印当前定位状态提醒使用者“GPS定位中请移步开阔处”。还有一个容易被忽视的是天线朝向。M5Stack的GPS模块天线通常在PCB背面终端平放在桌面时会背朝天空收星效果差拿在手里歪着放反而不好。我后来给终端加了一小块泡沫垫保证放地上时模块背面也朝上收星速度明显提升。5.3 加密认证失败调试如果你发现网关一直收不到或者日志里全是AUTH_FAIL大概率不是频率没对上而是密钥不对或协议字段偏移解析错。一个排查步骤是先用不加密的“裸发模式”在M5Stack上发一串“ABCDEF”网关直接打印hex确认物理链路和SPI没问题再在M5Stack上对这段明文加密后发送网关先打印接收到的hex和终端发送的hex对比确认空中数据完整最后才交给解密函数确认IV、密文、tag的截取位置一致。协议字段偏移的bug非常恼人好在只要在两边各自打印hex就能快速定位。还有一个容易错的地方是字节序ESP32和树莓派都是小端序但如果你从某个参考代码里复制了大端解析很容易在整数维度上得出一些奇怪的结果。另外树莓派这边使用的Python cryptography库要求密文和tag拼接传递而M5Stack端有些封装是分开返回的拼接顺序如果搞反同样会一直认证失败。5.4 供电与续航M5Stack Core2内置电池容量大约1100mAh单纯待机能撑一两天但如果一直亮屏加LoRa周期发射可能几个小时就没电。我改造了供电方案用两节18650并联的电池盒通过5V升压模块接到M5Stack的USB口LoRa模块如果直接由主板供电发射电流比较大的时候SPI偶发异常稳妥做法是给LoRa模块单独用锂电池供电或者选带独立供电的HAT。树莓派网关不必太省电但野外营地供电也紧张我用一个5V 3A的太阳能控制器加12V锂电池组给树莓派供电实测一块120Wh容量的电池能撑一天以上。建议给树莓派配一个支持看门狗的电源模块万一程序崩溃还能自动重启。电源和天线是我觉得这套系统里最不能省钱的两个地方。5.5 简单故障速查表现象可能原因排查方向终端屏幕显示“LoRa init failed”SPI接线错误或LoRa板未上电检查NSS/RST引脚定义用示波器看SPI时钟收不到任何包频率不一致或SF/BW参数不一致终端和网关统一频率、SF、编码率逐项确认收到包但AUTH_FAIL密钥不一致或协议偏移错误关加密裸发对比hex逐个字段对GPS数值为(0,0)未定位就发送判断gps.location.isValid()后再发终端发送时死机重启LoRa模块瞬时大电流拉垮电源给LoRa独立供电更换输出稳定的DC-DC模块网关Web页面打不开Flask服务未启动或局域网IP变了用同一AP下测试固定树莓派IP地址上面这张表是我在实际测试中整理出的常见问题速查给营地技术员用非常顺手。这里多说一句排查这类系统唯一的原则就是“分层验证”先物理通道再协议格式最后才涉及加密逻辑。只要每层能独立打印出符合条件的输入输出整个链路就不会有大问题。反过来如果你一上来就怀疑加密多半会把时间浪费在看不懂的hex里。最后再分享一个实用心得这套系统里真正花时间的不是加密算法也不是LoRa配置而是野外环境下各种“软故障”。树莓派网关放在营地里电源波动、USB转串口松动、SPI线被老鼠咬断这些才是实际问题。建议你做完第一版后带到附近的公园、山头多跑几次把天线摆放、GPS冷启动、供电续航这些真实场景里的问题都暴露出来再回到室内慢慢迭代。毕竟一套只能在桌面上跑通的求救系统真到了它该起作用的地方是没有第二次调试机会的。