基于nRF54LM20与Zephyr的蜂群健康监测：BLE Mesh与TinyML端侧推理实践

1. 蜂群健康监测的痛点与SwarmSense的设计初衷

养蜂这件事，看起来是农业，实际上是个精细活。一个中等规模的蜂场，几十箱蜂，每箱里面两三万只蜜蜂，蜂王的状态、巢温的波动、湿度的高低、群势的强弱，任何一个指标出问题，轻则减产，重则整箱飞逃。传统做法靠什么？靠老师傅开箱检查。但开箱本身对蜂群就是一次干扰，每次开箱巢温要掉好几度，蜜蜂需要重新调节，频繁开箱反而增加应激风险。

我最早接触蜂群监测是在三年前，当时帮一个做智慧农业的朋友搭原型。最初的想法很简单：放几个温湿度传感器进去，数据传到网关，手机上看曲线。但实际跑下来问题一大堆。首先是节点功耗，蜂箱放在野外，没有市电，靠电池撑，普通WiFi方案几天就没电了。其次是通信距离，蜂场往往在山区或者果园深处，单个网关覆盖不了所有蜂箱。最要命的是，光有数据没用，养蜂人要的是判断——这箱蜂到底有没有问题，需不需要干预。

SwarmSense这个项目的核心思路，就是把这几个问题一次性解决。它用nRF54LM20做主控，这是一颗基于Cortex-M33内核的低功耗无线SoC，支持BLE Mesh组网，跑Zephyr实时操作系统，并且在端侧做TinyML推理。翻译成人话就是：每个蜂箱里放一个小节点，节点之间自己组网、自己转发数据，不需要每个节点都直连网关；节点上跑一个轻量级的机器学习模型，直接在本地说“这箱蜂正常”或者“这箱蜂有异常”，只把结论和关键数据传出去，而不是把原始数据全部回传。

这样做的好处非常直接。第一，功耗下来了，因为不需要持续高带宽传输。第二，响应快了，异常在本地就能判断，不用等云端返回结果。第三，覆盖范围大了，Mesh网络天然支持多跳，蜂场再大也能通过节点中继把数据传回网关。适合谁来参考？如果你在做低功耗无线传感网络、边缘AI推理、或者智慧农业相关的项目，这套架构和选型思路都可以直接借鉴。哪怕你不养蜂，换成温室监测、仓储环境监控、设备状态监测，逻辑是通的。

2. 核心硬件选型与Zephyr系统搭建

2.1 为什么选nRF54LM20而不是ESP32

热搜词里出现了“esp32 ble mesh arduino”，说明很多人第一反应是用ESP32做Mesh。ESP32确实生态好、资料多、Arduino上手快，但放到蜂箱监测这个场景里，它有几个硬伤。第一是功耗，ESP32在BLE Mesh下的平均功耗比nRF54LM20高一个数量级，蜂箱节点靠纽扣电池或者小太阳能板供电，这个差距直接决定能不能长期免维护运行。第二是射频性能，nRF54LM20的接收灵敏度和发射功率在同类产品里属于第一梯队，Mesh多跳场景下链路余量更足。第三是Zephyr的原生支持，nRF54LM20是Nordic自家芯片，Zephyr里的一整套驱动、协议栈、电源管理都是官方维护的，踩坑概率低很多。

当然，ESP32不是不能用。如果你只是做概念验证，手头只有ESP32开发板，先用它把逻辑跑通完全没问题。但真要落地到蜂场长期部署，我建议还是换到nRF54LM20。我自己的做法是：原型阶段用ESP32快速验证传感器和Mesh逻辑，定型阶段切到nRF54LM20做功耗优化和稳定性打磨。

2.2 Zephyr环境搭建：west update到底在干什么

热搜里有人问“下载zephyr为什么要执行west update”，这个问题很典型。Zephyr不像Arduino那样一个IDE全包，它是模块化的，主仓库只包含内核和核心子系统，大量的驱动、协议栈、示例、外部库分散在几十个独立仓库里。west update的作用就是根据west.yml清单文件，把这些子仓库全部拉取到本地对应目录。不执行这一步，你会发现很多驱动找不到、示例编译不过。

具体操作流程我列一下，这是我在Ubuntu 22.04上实测可用的步骤：

# 安装依赖 sudo apt install --no-install-recommends git cmake ninja-build gperf \ ccache dfu-util device-tree-compiler wget \ python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \ make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1 # 安装west pip3 install west # 初始化工作区 west init ~/zephyrproject cd ~/zephyrproject # 拉取主仓库 west update # 导出环境变量 west zephyr-export # 安装Python依赖 pip3 install -r ~/zephyrproject/zephyr/scripts/requirements.txt # 安装Zephyr SDK cd ~ wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.5/zephyr-sdk-0.16.5_linux-x86_64.tar.xz tar xvf zephyr-sdk-0.16.5_linux-x86_64.tar.xz cd zephyr-sdk-0.16.5 ./setup.sh

注意：west update第一次执行会拉取大量仓库，网络不好的话建议配置好代理或者用国内镜像。另外SDK版本要和Zephyr版本匹配，版本不匹配会出现编译工具链找不到的问题。

编译一个nRF54LM20的示例验证环境：

cd ~/zephyrproject/zephyr west build -b nrf54lm20dk/nrf54lm20/cpuapp samples/hello_world west flash

如果串口能看到Hello World输出，环境就算通了。这里有个细节，nRF54LM20DK的板级配置在Zephyr里可能有多个变体，nrf54lm20dk/nrf54lm20/cpuapp是应用核的配置，具体以你本地Zephyr版本里的boards目录为准。

2.3 BLE Mesh在Zephyr里的配置要点

Zephyr的BLE Mesh协议栈配置主要通过Kconfig完成。核心配置项包括：

CONFIG_BT=y CONFIG_BT_MESH=y CONFIG_BT_MESH_RELAY=y CONFIG_BT_MESH_RELAY_RETRANSMIT_COUNT=3 CONFIG_BT_MESH_RELAY_RETRANSMIT_INTERVAL=20 CONFIG_BT_MESH_FRIEND=y CONFIG_BT_MESH_LOW_POWER=y CONFIG_BT_MESH_GATT_PROXY=y CONFIG_BT_MESH_PB_GATT=y

这里解释几个关键选择。CONFIG_BT_MESH_RELAY开启中继功能，让节点可以转发其他节点的消息，这是Mesh覆盖范围的关键。CONFIG_BT_MESH_LOW_POWER和CONFIG_BT_MESH_FRIEND配合使用，低功耗节点不用一直监听，而是通过Friend节点缓存消息，定期唤醒拉取，这对电池供电的蜂箱节点至关重要。CONFIG_BT_MESH_GATT_PROXY让手机可以通过GATT连接直接入网配置，现场调试很方便。

实操心得：Relay的重传次数和间隔要权衡。次数太多、间隔太短，网络拥塞严重，功耗飙升；次数太少、间隔太长，消息到达率下降。蜂场这种节点密度不高的场景，我实测RETRANSMIT_COUNT=3、INTERVAL=20ms比较平衡。

3. TinyML模型在蜂群健康预测中的落地

3.1 蜂群健康到底预测什么

蜂群健康的核心指标其实不多，但每个都有明确的物理意义。巢温是最关键的，健康蜂群会把巢温稳定在34.5到35.5摄氏度之间，波动超过1度就说明调节能力出了问题。湿度反映通风和酿蜜状态，长期高于70%容易滋生霉菌。重量变化反映采蜜和消耗的平衡，突然掉重可能是分蜂或者飞逃。声音频谱能反映蜂群情绪，失王群和正常群的频谱特征差异明显。

SwarmSense的TinyML模型输入就是这几路传感器数据的时间序列，输出是一个健康评分和异常类型分类。模型不需要很大，因为特征维度低、模式相对固定。我用的是一个三层全连接网络，输入是过去30分钟的温湿度滑动窗口，加上重量变化率和音频特征，输出四分类：正常、温度异常、湿度异常、疑似失王。

3.2 模型训练与量化部署

训练在PC上完成，用TensorFlow或者PyTorch都行。数据来源有两个：一是公开的蜂群监测数据集，二是自己蜂场采集的标注数据。这里要强调，公开数据集只能用来预训练，真正部署前一定要用自己场地的数据做微调，因为不同地区、不同蜂种的基线特征有差异。

模型量化和转换用TensorFlow Lite Micro的流程：

import tensorflow as tf # 加载训练好的模型 model = tf.keras.models.load_model('hive_health_model.h5') # 转换为TFLite converter = tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations = [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] converter.inference_input_type = tf.int8 converter.inference_output_type = tf.int8 # 代表性数据集用于量化校准 def representative_dataset(): for i in range(100): yield [calibration_data[i:i+1].astype('float32')] converter.representative_dataset = representative_dataset tflite_model = converter.convert() with open('hive_health_model.tflite', 'wb') as f: f.write(tflite_model)

量化到int8之后，模型大小从几百KB降到几十KB，推理速度在Cortex-M33上单次大约几毫秒，完全满足实时性要求。Zephyr里集成TFLite Micro需要把运行时库作为模块加入，然后在应用代码里加载模型数组、分配tensor arena、调用推理接口。

注意：tensor arena的大小要算够。我一开始按经验给了8KB，结果推理时直接hard fault。后来用interpreter->arena_used_bytes()打印实际需求，发现要12KB多。建议先给足余量，跑通后再优化。

3.3 端侧推理与云端协同的分工

TinyML在端侧做的是快速筛查，不是最终诊断。我的设计是：端侧模型输出置信度高于0.85的异常，直接触发告警上报；置信度在0.6到0.85之间的，上报原始特征数据，由网关或云端做二次判断；低于0.6的按正常处理，只记录不告警。这样既保证了响应速度，又避免了误报过多导致养蜂人麻木。

这个阈值不是拍脑袋定的。我拿历史数据做过ROC曲线分析，0.85对应的误报率大约5%，漏报率8%，对蜂群监测来说是可以接受的平衡点。如果你对漏报更敏感，可以把阈值降到0.75，代价是误报率上升到12%左右。

4. 系统联调与现场部署的实操记录

4.1 节点硬件组装与传感器校准

单个蜂箱节点的硬件构成：nRF54LM20模组、SHT40温湿度传感器、HX711加称重传感器、MEMS麦克风、电源管理电路、18650锂电池。传感器放在巢框上方和箱体底部各一个，取平均值更能反映整体状态。

传感器校准这一步不能省。SHT40出厂精度不错，但蜂箱内高湿环境下长期运行会有漂移，我每三个月用标准温湿度计做一次单点校准。称重传感器更麻烦，温度变化会影响零点，需要在固件里做温度补偿。我的做法是记录空载时不同温度下的ADC读数，拟合一条补偿曲线，运行时根据当前温度修正。

// 简化的温度补偿示例 float compensate_weight(float raw_adc, float temperature) { float zero_offset = 0.02f * (temperature - 25.0f); float compensated = (raw_adc - zero_offset) / CALIBRATION_FACTOR; return compensated; }

4.2 Mesh网络现场调试

蜂场部署Mesh网络，最大的坑是节点位置。蜜蜂是群居昆虫，蜂箱排列有讲究，但Mesh节点不能随便放。金属箱体对2.4GHz信号屏蔽严重，节点天线最好伸出箱体外或者贴在箱壁内侧非金属区域。我试过把节点完全塞在箱内，通信距离直接砍半。

网络配置流程：先给网关节点上电，用手机App通过GATT连上去，配置好网络密钥和AppKey。然后逐个给蜂箱节点上电，节点会自动进入配网模式，网关发现后分配地址。配网完成后，用Mesh的配置客户端设置每个节点的Relay和Friend角色。靠近网关的节点设为Relay，边缘节点设为Low Power。

实操心得：配网时一次只开一个节点，配好一个关一个再开下一个。同时开多个节点配网，地址分配容易乱，而且信号冲突会导致配网失败。这个坑我踩过，折腾了一下午才发现是同时上电的问题。

4.3 功耗实测与电池寿命估算

实测数据：Low Power节点在Friend模式下，平均电流约15微安；Relay节点因为要持续监听和转发，平均电流约800微安。用3000mAh的18650电池，Low Power节点理论续航超过20年（当然电池自放电和老化会先到），Relay节点大约150天。

实际部署时，Relay节点我建议接小太阳能板，5V/100mA的板子配合TP4056充电模块，基本可以做到免维护。Low Power节点用一次性锂亚电池就行，体积小、自放电低。

4.4 告警策略与养蜂人反馈闭环

技术做得再好，养蜂人不用就是白搭。我最初设计的告警是App推送，结果发现很多老师傅根本不看手机推送。后来改成两个通道：一是蜂箱上的LED指示灯，异常时闪红灯，巡场时一眼就能看到；二是每天早晚各一条短信汇总，只报异常箱号，不报正常箱。

养蜂人的反馈也很重要。App里有个“标记误报”按钮，养蜂人点一下，这条数据就进入负样本库，定期用来重新训练模型。这个闭环跑起来之后，模型在本地数据上的准确率从最初的82%提升到了94%。

5. 常见问题排查与避坑指南

5.1 编译与系统类问题

问题一：west update卡住或者报错

最常见的原因是网络问题。Zephyr的子仓库分布在多个托管平台，国内访问不稳定。解决办法是配置git的代理，或者使用国内的镜像源。另外west update支持--narrow参数只拉取当前项目需要的仓库，能省不少时间和带宽。

问题二：编译报错“board not found”

说明板级配置文件不在Zephyr的boards目录里。nRF54LM20是比较新的芯片，老版本Zephyr可能没有支持。解决办法是升级Zephyr到最新版本，或者从Nordic的官方仓库拉取板级配置放到本地boards目录。

问题三：TFLite Micro推理结果全是0或者乱码

先检查输入数据的预处理是否和训练时一致。量化模型对输入scale和zero_point非常敏感，训练时用的归一化参数必须原样搬到端侧。我遇到过输入忘了做int8转换，直接传float进去，结果全错。

5.2 通信与组网类问题

问题四：Mesh消息丢包严重

排查顺序：先看节点距离，超过30米或者有混凝土墙阻隔，丢包是正常的，加Relay节点。再看Relay配置，重传次数不够或者间隔太长都会导致丢包。最后看信道干扰，2.4GHz在蜂场可能被WiFi或者其他设备干扰，用nRF Connect扫描一下信道占用情况，必要时换信道。

问题五：Low Power节点收不到消息

检查Friend节点是否正常工作。Low Power节点依赖Friend缓存消息，如果Friend节点掉线或者缓存满了，消息就丢了。建议每个Low Power节点至少有两个Friend候选，一个主用一个备用。

5.3 传感器与数据类问题

问题六：温湿度读数跳变

蜂箱内环境其实很稳定，读数跳变通常是传感器接触不良或者电源纹波太大。检查I2C走线是否过长、上拉电阻是否合适。另外SHT40的加热器功能在结露时很有用，可以定期开启清除凝露。

问题七：称重数据漂移

前面提过温度补偿，但还有一种情况是蜂箱被外力移动或者地面沉降。这种漂移是阶跃式的，不是渐变。我的处理是在固件里做变化率检测，如果短时间内重量突变超过阈值，标记为“疑似移动”而不是“重量异常”，避免误报。

5.4 独家避坑技巧

第一个技巧：固件里留一个“维护模式”。长按节点上的按键5秒进入维护模式，此时节点全速运行、关闭低功耗，方便现场调试和固件升级。调试完再切回正常模式。这个功能看起来简单，但现场排查问题时能省大量时间。

第二个技巧：模型版本号写进广播数据。Mesh节点广播里带一个字节的模型版本号，网关收到后如果发现版本不一致，就知道该节点需要升级。避免出现新旧模型混跑导致判断标准不一致的问题。

第三个技巧：蜂箱编号和Mesh地址做映射表存在网关里。不要依赖节点自己报编号，因为节点更换或者重配网后编号可能变。网关维护一张地址到箱号的映射表，换节点时只改网关配置，不用动节点。

第四个技巧：定期做“空箱测试”。找一个空蜂箱，放上节点跑一周，看看基线数据。空箱和实箱的温湿度、重量特征完全不同，空箱数据可以用来验证传感器是否正常，也可以作为异常检测的对照。

6. 从原型到产品的扩展思路

这套系统跑通之后，扩展方向其实很多。硬件上可以加二氧化碳传感器判断通风状态，加蜂王标记识别做更精细的群势评估。软件上可以把多个蜂场的数据聚合起来做区域病虫害预警，这个价值比单场监测大得多。

通信方面，BLE Mesh适合蜂场内组网，但蜂场和蜂场之间、蜂场和云端之间还需要回传通道。我的做法是网关通过4G Cat-1模组上传，功耗和成本都比NB-IoT更平衡。如果蜂场有WiFi覆盖，网关也可以走WiFi，但野外场景别指望这个。

模型方面，目前是四分类，后续可以做成多标签输出，同时判断多个异常类型。另外可以引入在线学习，让模型根据养蜂人的反馈持续微调。不过在线学习在MCU上实现有难度，折中方案是在网关做增量训练，定期把更新后的模型下发给节点。

成本控制是产品化的关键。原型阶段用的都是开发板，单节点成本两三百。量产的话，nRF54LM20模组、传感器、电源管理加起来可以压到八十以内，加上外壳和电池，整箱成本一百出头。对规模化蜂场来说，这个投入产出比是算得过来的。

我个人在实际部署中最大的体会是：别追求一步到位。先跑通温湿度监测和Mesh组网，再叠加TinyML，最后做告警闭环。每一步都验证稳定了再往下走。我见过太多项目一上来就想做全功能，结果每个模块都不扎实，现场一跑全是问题。蜂群监测是个长期活，系统稳定比功能花哨重要得多。