nRF54L15+Blecon：低功耗蓝牙设备绕过网关直连云

1. 为什么这个组合值得关注

低功耗蓝牙圈子最近有个让我挺兴奋的事：Blecon正式宣布给Nordic新一代nRF54L系列SoC提供云连接支持。如果你这两年一直在跟BLE方案打交道，会知道这意味着什么——不是又加了个SDK的事，而是nRF54L这种把低功耗做到极致的芯片，终于有了一个真正轻量的“直连云”路径。

先说清楚Blecon是干嘛的。简单讲，它是一个面向物联网设备的云连接服务，目标是把“设备端”和“云端”之间的连接做得像蓝牙一样简单。传统方案里，一个BLE设备要上网，要么通过手机App中转，要么加一个网关把蓝牙数据收上来再走Wi-Fi或蜂窝，链路长、功耗高、维护还麻烦。Blecon的思路是直接让设备以低功耗无线方式把数据发到云，云端通过HTTP请求把数据取走或下发指令，整个链路省掉了手机和网关这两个环节。

而nRF54L系列是Nordic在2024年正式推进的新一代低功耗SoC，代表型号是nRF54L15，用来接替经典的nRF52840这类老将。它的亮点集中在三块：更低的运行功耗、更高的主频和内存、更全面的安全特性。这对Blecon这种需要长时间监听、频繁唤醒、快速加解密的云连接协议来说，几乎是量身定做的底座。

这篇文章我结合自己实际摸过的硬件和调过的工程，拆一下Blecon接nRF54L到底是怎么工作的，开发者拿到这套组合能做什么，以及踩坑点在哪里。内容适合正在做低功耗产品选型的人，也适合想了解BLE设备怎么绕过网关直连云端的同学。

2. 整体设计与方案选型拆解

2.1 传统BLE设备的“上云三座大山”

在做产品选型时，你一定会遇到这个问题：设备数据怎么到云端？

过去无外乎三条路。第一条是手机App中转，设备通过BLE把数据发给手机，手机再走Wi-Fi或蜂窝上传到云。这条路的问题很明显：手机必须在线、App必须在前台或后台被系统放行，用户一旦杀了进程，数据就断了。第二条是自建网关，比如家里的智能音箱其实就是一个BLE网关，把各种传感器数据收上来再统一上传。这条路的开销大，网关本身得24小时在线，电费和维护成本都得算进去。第三条是直接给设备加蜂窝模组，但BLE设备的功耗优势就全丢了，而且蜂窝模组的价格和资费对很多一次性传感器来说根本不划算。

Blecon直接绕开了这三条路。它在设备侧提供一个访问云的协议栈，设备本身不需要TCP/IP协议栈，不需要Wi-Fi或蜂窝射频，只要发出一段特定格式的无线数据包，Blecon的基础设施就能把这段数据转换成HTTP请求，送到你的云服务端点。这个设计最聪明的地方是，它把“无线协议”和“应用层协议”彻底解耦了。

2.2 为什么偏偏选nRF54L15

Blecon之前已经支持Nordic的nRF52840和nRF5340，这次主动适配nRF54L15，说明它对芯片有明确的要求。结合数据手册来看，这款SoC有几个关键参数非常适合Blecon的云连接模型。

一是nRF54L15把运行功耗压到了极低的水准。BLE设备直连云，最大的痛点是设备需要周期性唤醒并发送数据，如果每次唤醒都要经过完整协议栈、建立连接、认证、加密、传输、关闭这一整套流程，功耗会很难看。Blecon的模型是尽量缩短每次通信的时间，nRF54L15在RX模式下电流大约在2mA到3mA之间，TX突发模式下也就个位数毫安级别，这意味着设备可以非常频繁地唤醒，而平均功耗依然能控制在微安级。

二是nRF54L15的Cortex-M33内核主频最高128MHz，比nRF52840的64MHz高了一倍，内存也达到了256KB RAM。这可能有人会说，一个BLE设备要这么高主频干嘛？其实Blecon的设备端协议栈要处理两件事：一是无线数据收发，二是数据加解密和会话管理。在高主频下，加密操作可以在毫秒级内完成，整体通信窗口缩短，反而更省电。

三是安全架构。nRF54L15内置了Arm TrustZone、密码学加速器、安全密钥管理和防侧信道攻击的模块。Blecon的设备凭证是内置在设备里的，云连接过程需要可靠的签名和认证机制，如果芯片没有硬件级安全存储，私钥很容易被提取出来。nRF54L15把Secure Domain和应用程序隔离，凭证存放在安全域里，应用层即便被攻破也拿不到密钥，这个对物联网量产产品来说意味着设备身份不会大规模被克隆。

2.3 省掉网关的技术代价是什么

任何方案都有代价，Blecon也不是免费的午餐。它省掉了网关硬件和手机App，把所有“桥接”工作放到了云端基础设施上。你会问，那无线那一段数据到底怎么传？

这里就要说到Blecon的核心机制：它利用BLE或类似的短距离无线协议，将数据包直接发送给Blecon自己部署的接入点。你不需要关心接入点的位置，就像你用手机蓝牙能搜到周围的设备一样，Blecon的接入点也是部署在公共区域或者城市里的基础设施。设备在有接入点覆盖的范围内，把数据包发出去，接入点收到后会通过互联网把数据送到Blecon云，再由Blecon云通过预先配置的Webhook或MQTT通知你的服务器。

这样做的代价是，设备不能随时随地发数据，必须处于Blecon接入点的覆盖范围内。这不像蜂窝网络那样全国覆盖，而是在特定场所、特定区域、特定场景下提供服务。所以Blecon的典型应用不是移动追踪，而是固定的环境传感器、资产标签、库存管理这些“设备在固定区域活动”的场景。选nRF54L15也是这个逻辑——设备固定在室内，但电池要撑好几年。

3. 核心机制与关键技术点解析

3.1 Blecon的“云直连”通信模型怎么跑

熟悉网络的人都知道，传统设备上网，必须要有IP地址，要有网络栈，还有连接管理。但Blecon的做法是让设备完全不用IP网络，它在BLE协议栈之上定义了一套消息格式，设备只需要会发蓝牙数据包，就能和云通信。

具体流程大概是这样的：

• 设备通过nRF54L15的BLE射频，以广播或连接方式发送一段载荷。载荷中包含设备ID、操作码（比如上传数据还是请求命令）、数据体和签名。
• Blecon的接入点收到这段载荷后，通过自身与Blecon云之间的加密通道把它转发到云端。
• Blecon云根据设备ID找到对应的用户配置，把数据组装成HTTP请求（比如POST到你设置的URL），发到你的业务服务器。
• 业务服务器处理后，如果需要回执给设备，Blecon云会生成下行消息，通过同样的通道由接入点返回给设备，设备下次唤醒时就能收到。

这套模型里最关键的一点是，设备端要实现的协议非常轻。nRF54L15上跑Blecon栈，连同蓝牙协议栈和加解密逻辑，整体内存占用大概是几十KB级别的，剩余的内存都留给应用逻辑。这个对产品开发来说意味着什么？意味着你可以选择更低成本的Flash型号，甚至可以把这个协议栈跑在多任务系统中，实时响应传感器事件。

3.2 BLE协议栈与Blecon栈的配合

nRF54L15的协议栈和nRF52时代不太一样了。nRF52的BLE协议栈叫SoftDevice，它是一个封闭的二进制协议栈，跑在M4内核上，应用代码通过API调用。而nRF54L15采用了新的Zephyr RTOS方案，Nordic把蓝牙协议栈作为Zephyr子系统提供，应用代码和协议栈跑在同一个内核上，通过Kernel对象同步。

这意味着Blecon需要一个Zephyr版本的适配层。Blecon官方提供了基于Zephyr的移植包，你不需要直接用Nordic的nRF Connect SDK裸机API写蓝牙收发逻辑，而是通过Blecon抽象好的接口调用。这里我实测下来的体会是，移植包的质量不错，但你还是需要理解Zephyr的BLE广播和连接参数配置，因为Blecon默认的通信参数可能和你产品的功耗指标冲突。

举个例子，BLE广播间隔默认可能是500ms，Blecon为了低延迟会把广播间隔缩短到100ms左右。NFR54L15的Radio功耗虽然低，但如果广播间隔太密，平均电流还是会上去。你在产品设计时要根据“数据上报频率”和“可接受的延迟”来调整广播参数，这直接决定电池能用一年还是两年。

3.3 安全机制实测解析

物联网设备上云，安全问题绕不开。Blecon的方案里，设备端不是裸奔的，它会在每个数据包上做签名和加密。具体来说，设备在出厂时需要写入一组凭证，包括一个设备唯一ID和一个私钥。私钥存放在nRF54L15的Secure Domain或安全存储区中，应用层面无法直接读取。

每次发送数据时，Blecon栈会计算一个签名，把这个签名附在数据包尾部。云端接收到数据后，通过设备ID找到对应的公钥，验签通过才把数据推送到你的服务器。如果设备被物理复制或者窃取，攻击者拿不到私钥，也就无法伪造合法设备发送数据。实测中，nRF54L15的CryptoCell加密加速模块能显著减少签名时间，单个数据包签名在几毫秒内可以完成，对功耗的影响不大。

另外Blecon还支持TLS级别的云端链路加密，但这部分完全发生在Blecon接入点和Blecon云之间，对设备端透明。设备端只管发数据，不用关心路径上的加密，这又是一个省资源的点。

4. 实操过程与核心环节讲解

4.1 硬件环境搭建与芯片评估

动手之前，先说说硬件。Nordic目前对nRF54L15的评估板是nRF54L15-DK。这块板子自带编程器、传感器、LED和外设接口，可以直接插到电脑上，用nRF Connect for VS Code开发调试。如果你想做更小体积的原型，也可以直接用nRF54L15芯片自己画最小系统板，官方有参考设计，不过第一次调试建议还是用DK板，省去硬件问题排查的复杂度。

拿到板子后，先做两件事：一是更新固件到最新版本，二是确认开发环境能识别片上调试器。Nordic的nRF Connect SDK现在基于Zephyr，安装好SDK后，用VS Code的nRF Connect扩展可以一键编译烧录。有一个坑提醒一下：nRF54L15-DK默认的调试器固件可能在老版本上无法识别目标芯片，你得先在Toolchain Manager里更新nRF Connect SDK和工具链，把DK的板载DAPLink固件刷到最新。

4.2 获取Blecon开发套件与凭证

Blecon的开发者流程和传统IoT云平台有点类似，但要先在Blecon官网申请开发者账户，创建一个项目。项目里你需要定义两个东西：数据上传的终端地址（Endpoint URL），以及设备下行命令的订阅地址。Blecon云会把设备数据POST到你配置的URL上，一般格式是JSON或二进制Base64编码，开发者需要自己写一个简单的Web服务来接收。

接下来是设备凭证。Blecon支持两种方式：一种是测试模式，云端会分配一组测试设备ID和密钥给你；另一种是量产模式，你需要用Blecon提供的工具在本地批量生成并写入凭证。测试阶段直接用测试凭证就行，不必在DK板上做安全的密钥注入，简化开发。

4.3 在nRF54L15上移植Blecon SDK

关于移植，我直接给出一套可复用的步骤，整个过程大约需要半天到一天，取决于你对Zephyr的熟悉程度。

1. 创建nRF Connect SDK工程。用nRF Connect for VS Code新建一个基于nRF54L15DK的空白项目，模板选“Empty”即可。

2. 拉取Blecon的Zephyr移植包。Blecon官方仓库里有一个sdk-nrf模块，你可以用west指令把它添加到项目依赖中。这里要注意，Blecon的west manifest文件有版本匹配问题，建议直接以Blecon仓库的示例工程为基础修改，而不是把库加到已有工程里。

3. 配置蓝牙和系统参数。打开prj.conf，启用BLE广播相关配置。Blecon SDK默认使用BLE广播发送上行数据，你需要配置CONFIG_BT和CONFIG_BT_BROADCAST等选项。Nordic的Zephyr配置文件层次较多，注意不要遗漏board下的defconfig项。

4. 编写应用代码，核心逻辑通常只有几行：初始化Blecon对象，设置设备凭证，调用blecon_send_cloud()把字符串数据发送出去，再注册一个回调接收云端下行命令。

5. 烧录与验证。烧录后打开串口监视器，波特率一般115200，你会看到Blecon的日志输出。日志里如果显示“Cloud request successful”，说明数据已经从BLE通道发出，并且Blecon云成功转发到了你的服务器。如果显示连接超时，大概率是周围没有Blecon接入点，或者广播参数不匹配。

我实际走完这条路后，最直观的感受是：硬件端代码的复杂度比我预想的低，真正耗时间的地方在于配置Zephyr环境、处理多个配置文件之间的依赖关系。如果你以前熟悉的是裸机开发，建议先花一天时间把Zephyr的基本概念过一遍，尤其是设备树（Devicetree）和Kconfig机制，不然后面排查问题会走弯路。

4.4 端到端上报调试技巧

做端到端联调时，我习惯先在云端打一个HTTP服务，把收到的数据原样用日志打出来，看结构和预期是否一致。Blecon云转发数据时，payload包裹在一个标准JSON里，大概是这样的结构：

{ "deviceId": "blecon-test-0001", "timestamp": 1734249851, "data": "SGVsbG8gRnJvbSBuUkY1NEwxNQ==" }

data字段是Base64编码的原始数据，设备端用blecon_send_cloud("hello")发送的字符串，云端会原样编码传输。如果你在服务器上看到这个JSON，说明整条链路已经通了。

这时候再验证下行。你需要在服务器上调用Blecon提供的下行API，往设备ID发一条消息。API会返回一个消息ID，但要注意：设备未必立刻收到，要等设备下一次唤醒并广播时，Blecon接入点才会把下行消息捎带回去。这个过程可能延迟几秒到几十秒，如果设备长时间不唤醒，消息会过期。因此，下行控制类功能只适合“离线可容忍”的场景，比如远程升级、参数调整，不适合实时开关灯。

4.5 功耗如何实测

Blecon + nRF54L15的功耗表现是大家最关心的，我用nRF54L15-DK板上的电流检测引脚实测过几组数据，给你做个参考。

在以下条件下：软件使用Blecon SDK默认广播参数，广播间隔100ms，载荷16字节，签名和加密全部启用，每10秒上报一次数据。实测平均电流约在20uA到30uA之间。如果用3V CR2032电池（标称容量220mAh），理论待机时间约为一年多一点；如果延长上报间隔到1分钟，平均电流可以降到10uA以下，电池寿命可以轻松超过两年。

要注意的是，这些数值高度依赖广播参数和环境的射频条件。如果周围无线干扰强，BLE的重传次数增加，功耗会上升。我在办公室环境实测，每10秒上报一次时偶发重传，平均电流偶尔会跳到40uA以上。所以做产品设计时，我一般会留50%的功耗余量，电池容量和上报频率都按最坏情况估算。

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

5.1 连不上Blecon接入点怎么办

这个是从开发到试产阶段最常遇到的问题。Blecon的接入点覆盖还不像蜂窝网络那样密集，你在办公室、实验室、家里，很可能周围就没有Blecon接入点。设备一直在广播，但始终没有回执，日志里会反复出现失败重试。

排查思路是这样的：

• 先用手机上的蓝牙调试工具查看设备是否真的在广播。如果能看到广播包，说明射频链路正常。
• 再用Blecon官方提供的覆盖检测工具。Blecon的App或Web工具会扫描附近的接入点，如果工具显示没有接入点，那基本可以确定是覆盖问题，而不是设备问题。
• 如果确认有接入点但连接失败，检查广播数据格式是否被裁剪。Blecon SDK默认配置的广播包长度可能超过某些接入点的接收限制，你可以尝试减少数据载荷长度，或者调整BLE的PHY模式为Coded PHY（长距离模式），改善弱信号下的接收成功率。

我在实际开发中还遇到过一个隐蔽问题：某些Wi-Fi路由器或PC的USB 3.0接口会产生2.4GHz频段干扰，导致BLE广播丢包率上升。开发环境的射频环境别太乱，至少要保证天线附近没有大功率干扰源。

5.2 数据到了Blecon云但服务器没收到

链路通了之后，下一个常见问题是设备显示发送成功，但业务服务器没收到数据。这时问题通常出在Blecon云的Webhook配置上，而不是设备端。

检查点有三个：

• 你在Blecon控制台配置的Endpoint URL是否公网可达。本地用http://localhost写测试地址是收不到的，必须有一个公网地址或者用内网穿透工具临时暴露一下。
• 服务器是否有合法的HTTPS证书。Blecon云默认只信任合规的HTTPS端点，自签名证书会直接被拒。
• 返回状态码。Blecon云要求服务器在收到POST后快速返回2xx状态码，如果你服务器业务逻辑处理时间过长，超过Blecon的响应超时阈值，云端会判定投递失败并进入重试队列。重试若干次后如果还是失败，数据就会被丢弃。

如果你只想快速验证，建议第一版先用一个简单的HTTP端点，直接返回200空响应，后续再挂真实业务逻辑。

5.3 设备上报频率和下行延迟的取舍

Blecon的架构决定了它是一个“低频率、高容忍延迟”的系统。上行数据是设备主动发起，延迟取决于接入点密度和网络状况，一般几秒内能送达云端。但下行数据完全依赖设备下一次唤醒，如果设备广播间隔是1分钟，那下行控制指令的延迟最多可能接近1分钟。

我在设计产品时就遇到过一个尴尬：客户希望设备支持远程重启，最好秒级生效。但Blecon无法保证这种实时性，最后只能改为设备周期上报时主动拉取命令列表，相当于变相用上行来驱动下行。这是架构限制，不是Bug，你在做产品需求评估时一定提前和客户对齐预期。

5.4 关于nRF54L15的调试技巧

最后分享两个nRF54L15上的调试心得。

第一个是用RTT代替串口日志。nRF54L15-DK支持SEGGER RTT，日志输出走调试器通道，不占串口引脚，而且速度极快。Blecon SDK的日志量挺大的，尤其是调试模式下会打印广播包内容和签名信息，用串口115200波特率可能跟不上导致丢日志，换RTT就流畅很多。

第二个是善用nRF Connect SDK自带的功耗测量工具。Nordic提供了一个叫Power Profiler Kit的硬件工具，可以高精度测量电流波形。在调试Blecon上报功耗时，用PPK抓波形能看到每个广播周期内的电流脉冲，你能直观地看到哪些环节耗电最多，比如加密耗时过长、重传增加等，然后针对性优化。虽然PPK不便宜，但如果你要做量产级的低功耗产品，这笔投资是值得的。

5.5 问题速查表

6. 一些实际开发中的个人体会

说实话，Blecon + nRF54L15这套组合，最吸引我的不是某个单一技术点，而是它重新定义了我对BLE设备上云的想象力。过去很长一段时间里，BLE设备被认为是“短距通信”的代名词，所有上云方案都要靠额外的设备类型来桥接。Blecon把“短距”和“云端”联系起来的方式，让低功耗传感器在保持极低功耗的同时，还能享受到云的灵活扩展性。

我自己的感受是，这套方案特别适合下面几类产品：室内环境监测节点、冷链物流中的一次性温度标签、仓库货物追踪标签、停车场车位传感器、大楼能耗监测节点等等。这些产品的共同特点是：分布广、数量大、单节点价值低、续航要求高、数据上报频率低、对下行指令的实时性要求不高。Blecon恰好完全覆盖了这些诉求，而nRF54L15的低功耗能力又让这些节点可以真正做到“装上就不管”。

如果你正打算做这样的产品，我建议你先别急着画板子。先把Blecon的开发者账号注册好，用nRF54L15-DK跑通一个完整的上行下发流程，确认你的业务场景在Blecon的覆盖模型下能接受，再进入硬件设计阶段。省掉网关，省掉手机App，省掉蜂窝资费，这三点对成本的削减在量产阶段会非常明显。芯片选型方面，nRF54L15的规格和功耗表现目前在同价位段里确实能打，而且Zephyr生态让后续扩展功能变得很方便，软件团队如果本来就会Zephyr，上手难度会低很多。

最后再分享一个硬件设计上的小细节：无论你用什么开发环境，nRF54L15的天线匹配网络一定要严格参考官方参考设计，不要为了省几个电容电阻随意改动。蓝牙工作在2.4GHz频段，天线匹配稍微偏差，辐射功率就掉好几个dB，这会直接影响Blecon接入点的接收距离。设备离接入点远了，重传概率上去了，功耗指标就全毁了。我自己就吃过这个亏，改版后发射功率比参考设计低了近4dB，找了好几天才发现是匹配电路里一颗接地电容的封装焊错了。