蓝牙 Mesh 网关的芯片怎么选：泰凌、芯科还是 Nordic？
对比泰凌 mesh_gw、Nordic Zephyr 和芯科 NCP/BGAPI 三种蓝牙 Mesh 网关方案：网关固件、串口协议、节点容量和成本，以及我们为什么选择网关用芯科、设备用泰凌。
上一篇定下了两件事：设备和网关之间走 SIG Mesh；网关这边，Mesh 协议栈放在一颗单独的蓝牙模组里，Linux 主程序通过串口指挥它。
接下来的问题就很具体了：这颗蓝牙芯片选谁？
我们前后比较了三家：泰凌（Telink）、芯科（Silicon Labs）和 Nordic。中间还推翻过一次，最后网关用芯科，设备继续用泰凌。这篇把比较的过程和理由摊开讲。
先说清楚：网关上的这颗芯片要干什么
网关里的蓝牙模组不是普通的 Mesh 节点，它要扮演几个角色：
- 配网者：给新设备配网、分配地址、下发和绑定密钥；
- 控制端：发送开关、调光、调色命令，接收设备上报的状态；
- 常电节点：顺带做中继，帮远处的设备转发消息；
- 协处理器：通过串口听 Linux 主机的指令，把收到的消息原样上报。
所以选芯片，比的不只是芯片本身，更重要的是厂商有没有现成的「网关固件」，以及主机和模组之间的串口协议好不好用。这一层决定了网关程序要写多少代码，以后出问题有没有人能查。
泰凌：成本最低，固件现成，但协议是私有的
泰凌在国内灯控和开关市场用得最多，我们的设备原本就是泰凌的芯片。它的 SIG Mesh SDK 开源在 GitHub 上，里面直接带着一份编好的网关固件 mesh_gw。
mesh_gw 的结构大概是这样：
| 层 | 内容 | 能不能改 |
|---|---|---|
| 蓝牙底层、Mesh 协议栈 | 加密、网络层、传输层 | 闭源，只给库文件 |
| 网关应用层 | 串口命令处理、配网流程、状态上报 | 开源，可以改 |
| 和主机的接口 | UART（新芯片 TL321X 只支持串口） | 泰凌私有协议 |
优点很明显：
- 芯片便宜，量产单价几块钱人民币；
- 网关固件现成，烧进去就能用，还有 Windows 调试工具；
- 和设备同一家，设备上用了泰凌自己的扩展模型，网关也能直接认。
问题出在串口协议上。它是泰凌自己定义的，文档很少，很多细节只能读 SDK 源码才能弄明白。比如命令名叫 HCI_CMD_GATEWAY_...，看起来像蓝牙标准的 HCI，其实完全不是，帧格式也不一样：主机发过去的帧没有长度头，靠串口空闲来切分；模组发回来的帧又带长度头。
还有一个容量问题：mesh_gw 默认最多只能存 200 个节点，开启远程配网时只有 110 个。原因是节点信息只放在 Flash 的一个扇区里。家用够了，但商业场景要改 SDK 的存储布局。
我们最开始的原型就是按泰凌这套协议写的，还写了一个软件模拟的模组来测试。能跑，但每加一个功能都要回去翻源码，心里不踏实。
Nordic：工具和文档最好，但网关固件要自己写
Nordic 的 nRF52840、nRF5340 在蓝牙开发圈口碑很好，文档、抓包工具、手机调试 App 都是行业里最好的一档。nRF52840 Dongle 只要十美元左右，插电脑 USB 就能开发。
但 Nordic 有一个关键的短板：新一代 nRF Connect SDK 里没有官方的「串口网关固件」。早年的 nRF5 SDK for Mesh 有一个，已经停止维护了。所以网关这边有三种做法：
| 做法 | 模组上跑什么 | 主机做什么 | 评价 |
|---|---|---|---|
| 自己写网关固件 | Zephyr 的 Mesh 配网者和客户端模型，加一层自定义串口协议 | 只做翻译 | 架构最干净，但要自己写一两千行 C |
| 模组只当蓝牙控制器 | Zephyr 自带的标准 HCI 固件 | Linux 上跑 BlueZ 的 Mesh 守护进程，或者自己实现协议栈 | 固件现成，但 Windows 上开发不了 |
| Zephyr Mesh Shell | 自带的命令行 | 发文本命令 | 只适合调试 |
容量上，Zephyr 的协议栈允许配置到 4096 个节点，按内存估算实际能做到一两千个。但默认配置只有 8 个节点，防重放列表只有 10 条，不改的话第 11 个设备的消息就会出问题。这是用 Zephyr 做网关很容易踩的坑。
Nordic 适合两种情况：网关的 Mesh 部分想完全自己掌控，或者单个网关要管几百个以上的设备。我们这两条都不太符合，而且模组价格明显更贵，就没有选它。
芯科：串口协议有正式文档，这是决定性的
芯科（Silicon Labs）的思路和泰凌一样，也是「模组跑协议栈、主机发指令」，官方叫 NCP（网络协处理器）模式。区别在于这套串口协议，也就是 BGAPI，是一套有正式文档的接口：
- 每条命令、响应、事件都有文档，C 和 Python 都有官方主机端库；
- 覆盖的功能几乎就是完整的 Mesh API：配网、配置、各种标准模型、密钥更新、固件升级；
- SDK 里有现成的主机端配网示例（官方应用笔记 AN1371），我们的 Rust 实现照着它的流程写就行；
- 调试工具 NCP Commander 有图形界面，不写代码就能配网、开灯，相当于泰凌的调试工具。
BGAPI 的帧格式很简单：4 字节头，加最多 255 字节的数据。
[hdr0][len_lo][class][cmd][payload 0–255 字节]
hdr0：bit7 区分命令/事件，bit6–3 是设备类型，bit2–0 是长度高 3 位要注意一点：BGAPI 在串口上没有校验和，完全靠长度切帧，所以必须打开 RTS/CTS 硬件流控，防止丢字节。选主控芯片时，要确认它的串口支持流控。
价格方面，芯科网关这一档用的 EFR32BG24，官网 1000 片标价大约 2.7～3.7 美元，比泰凌贵。按每台网关算，多十几块钱人民币。
三家放在一起
| 泰凌 | Nordic | 芯科 | |
|---|---|---|---|
| 网关固件 | 现成（mesh_gw） |
要自己写，或用标准 HCI | 现成（NCP 示例） |
| 串口协议 | 私有，文档少 | 自己定义，或标准 HCI | BGAPI，有正式文档和主机端库 |
| 调试工具 | 有 | 最好 | 好 |
| 默认节点容量 | 200（远程配网 110） | 8，需调大，最多 4096 | 由 NCP 固件配置决定 |
| 芯片成本 | 最低 | 较高 | 中等 |
| 国内供应链 | 最成熟 | 一般 | 较好 |
我们的选择：网关用芯科，设备用泰凌
最后的组合是：
- 网关：芯科 BG24 系列模组，跑 NCP 固件；
- 设备：继续用泰凌，跑泰凌的 SIG Mesh SDK。
网关一台只用一颗模组，贵十几块钱，换来的是有文档的串口协议、完整的 Mesh API 和官方示例，以后维护起来省心得多。设备不一样，开关和灯的出货量大，每颗贵一点乘上去就是一大笔钱，泰凌的成本和国内方案商资源更合适。
两家芯片能放在一个网络里，靠的就是上一篇讲的 SIG 标准模型。只要设备只用 Generic OnOff、Light Lightness、CTL 这类标准模型，网关是谁家的都没关系。如果设备用了泰凌自己的扩展模型，就要换成标准模型，或者在网关上把对应的厂商模型也实现一遍。
换掉泰凌协议之后，网关程序里只有串口协议那一层要重写，Matter、设备表和翻译层都不用动。这也印证了第一篇里分层设计的好处。
还没验证的事
这些结论目前还是纸面上的，开发板到了之后要先确认三件事：
- 芯科网关和泰凌设备实际能不能互通。先不写代码，用芯科的 NCP Commander 给一块烧了泰凌灯固件的开发板配网、开灯。
- 主控的串口能不能开硬件流控，跑长时间压力测试，看会不会丢帧。
- 单个网关能稳定带多少设备，NCP 固件里的节点数、防重放列表这些参数要按实际需求调好。
验证结果会单独写一篇。
最后
选网关的蓝牙芯片，很容易只盯着芯片价格和参数。真正影响开发和维护的，往往是那份看不见的串口协议：有没有文档、能不能调试、出了问题能不能查到原因。
如果你也在给蓝牙 Mesh 网关选芯片，或者正在对接芯科 BGAPI、泰凌 mesh_gw，欢迎来聊：linktr.ee/weiyii