The previous post settled two things: devices and the gateway talk SIG Mesh, and on the gateway the Mesh stack lives on a separate Bluetooth module that the Linux program drives over a serial port.
That leaves a very concrete question: which Bluetooth chip?
We compared three vendors: Telink, Silicon Labs and Nordic. We changed our minds once along the way and ended up with Silicon Labs in the gateway and Telink in the devices. This post lays out the comparison and the reasoning.
First, what does this chip do in the gateway?
The gateway's Bluetooth module isn't an ordinary Mesh node. It plays several roles:
- Provisioner: provisions new devices, assigns addresses, distributes and binds keys.
- Controller: sends on/off, dimming and color commands and receives status reports.
- Always-on node: relays messages for devices further away.
- Co-processor: takes commands from the Linux host over UART and reports incoming messages back.
So the comparison isn't really about the silicon. What matters more is whether the vendor ships ready-made gateway firmware, and how usable the serial protocol between host and module is. That layer decides how much code the gateway program needs and whether anyone can debug it later.
Telink: cheapest, firmware included, but a proprietary protocol
Telink dominates China's lighting and switch market, and our devices already used its chips. Its SIG Mesh SDK is open on GitHub and includes a prebuilt gateway firmware, mesh_gw.
Roughly, mesh_gw looks like this:
| Layer | Content | Modifiable? |
|---|---|---|
| Bluetooth stack and Mesh stack | Encryption, network and transport layers | Closed source, libraries only |
| Gateway application layer | Serial command handling, provisioning flow, status reports | Open source |
| Host interface | UART (the newer TL321X supports UART only) | Telink's own protocol |
The strengths are obvious:
- Cheap chips, a few yuan each in volume.
- Gateway firmware out of the box, plus a Windows debugging tool.
- Same vendor as the devices, so any Telink vendor models on the devices are understood directly.
The problem is the serial protocol. Telink defined it themselves, documentation is thin, and many details only become clear from reading the SDK source. Commands are named HCI_CMD_GATEWAY_..., which suggests standard Bluetooth HCI, but they aren't, and the framing differs too: frames from host to module have no length header and are split by UART idle time, while frames back from the module do carry one.
There's also a capacity limit: mesh_gw stores at most 200 nodes by default, or 110 with remote provisioning, because node data lives in a single flash sector. Fine for a home; commercial use means changing the SDK's storage layout.
Our first prototype was written against this protocol, along with a simulated module for testing. It worked, but every new feature meant digging through source code again, which never felt solid.
Nordic: the best tools and docs, but you write the gateway firmware
Nordic's nRF52840 and nRF5340 are well regarded among Bluetooth developers. Documentation, sniffing tools and phone apps are among the best in the industry, and the nRF52840 Dongle costs around ten dollars and plugs straight into a USB port.
Nordic has one key gap, though: the current nRF Connect SDK has no official serial gateway firmware. The old nRF5 SDK for Mesh had one, but it's no longer maintained. That leaves three options on the gateway side:
| Approach | On the module | On the host | Verdict |
|---|---|---|---|
| Write your own gateway firmware | Zephyr's Mesh provisioner and client models plus a custom serial protocol | Translation only | Cleanest architecture, but one to two thousand lines of C to write |
| Module as a plain Bluetooth controller | Zephyr's standard HCI firmware | BlueZ's Mesh daemon on Linux, or your own stack | Firmware is ready, but no development on Windows |
| Zephyr Mesh Shell | Built-in command line | Text commands | Debugging only |
On capacity, Zephyr's stack can be configured up to 4,096 nodes, with one to two thousand realistic given memory. But the default is only 8 nodes, with a replay-protection list of 10 entries. Leave it and the 11th device's messages start failing, a classic trap when building a gateway on Zephyr.
Nordic fits two cases: you want full control of the gateway's Mesh layer, or one gateway must manage several hundred devices or more. Neither applied to us, and the modules cost noticeably more, so we passed.
Silicon Labs: a documented serial protocol, and that decided it
Silicon Labs takes the same approach as Telink, "the module runs the stack, the host sends commands", officially called NCP (network co-processor) mode. The difference is that its serial protocol, BGAPI, is properly documented:
- Every command, response and event is documented, with official host libraries in C and Python.
- It covers almost the full Mesh API: provisioning, configuration, standard models, key refresh and firmware updates.
- The SDK includes a host-side provisioner example (application note AN1371), so our Rust implementation can follow its flow.
- NCP Commander, a graphical tool, can provision devices and switch lights without writing any code.
BGAPI framing is simple: a 4-byte header plus up to 255 bytes of payload.
[hdr0][len_lo][class][cmd][payload 0–255 bytes]
hdr0: bit7 command/event, bits 6–3 device type, bits 2–0 length high bits
One caveat: BGAPI has no checksum on the serial link. Frames are split by length alone, so RTS/CTS hardware flow control must be enabled to avoid dropped bytes. When choosing the main processor, confirm its UART supports flow control.
On price, the EFR32BG24 used for gateways lists at about US$2.70–3.70 per chip in 1,000-unit quantities on Silicon Labs' site, more than Telink. Per gateway, that's roughly an extra US$2.
The three side by side
| Telink | Nordic | Silicon Labs | |
|---|---|---|---|
| Gateway firmware | Ready (mesh_gw) |
Write your own, or standard HCI | Ready (NCP examples) |
| Serial protocol | Proprietary, thin docs | Your own, or standard HCI | BGAPI, documented, with host libraries |
| Debugging tools | Yes | Best | Good |
| Default node capacity | 200 (110 with remote provisioning) | 8, must be raised, up to 4,096 | Set by NCP firmware configuration |
| Chip cost | Lowest | Higher | Medium |
| Chinese supply chain | Most mature | Fair | Good |
Our choice: Silicon Labs in the gateway, Telink in the devices
The final combination:
- Gateway: a Silicon Labs BG24-series module running NCP firmware.
- Devices: still Telink, running Telink's SIG Mesh SDK.
A gateway uses one module, so paying a couple of dollars more buys a documented serial protocol, a full Mesh API and official examples, and makes maintenance far easier. Devices are different: switches and lights ship in volume, so a small per-chip difference adds up, and Telink's cost and local ecosystem fit better.
The two vendors coexist in one network thanks to the SIG standard models from the last post. As long as devices stick to standard models like Generic OnOff, Light Lightness and CTL, the gateway's vendor doesn't matter. If a device uses Telink vendor models, either switch to standard ones or implement the matching vendor model on the gateway.
After dropping the Telink protocol, only the serial protocol layer of the gateway program needs rewriting; Matter, the device table and the mapping layer stay untouched. That's the layered design from the first post paying off.
Still to verify
These conclusions are still on paper. Once the boards arrive, three things come first:
- Do a Silicon Labs gateway and Telink devices actually interoperate? Before writing code, use NCP Commander to provision a board flashed with Telink's light firmware and switch it on.
- Can the main processor's UART run hardware flow control? Run long stress tests and watch for dropped frames.
- How many devices can one gateway handle reliably? Tune the NCP firmware's node count and replay list to real needs.
The results will get their own post.
Final thoughts
When choosing a gateway's Bluetooth chip, it's tempting to focus on price and specs. What really shapes development and maintenance is often the invisible serial protocol: is it documented, can you debug it, and can you find out why something broke?
If you're choosing a chip for a Bluetooth Mesh gateway, or working with Silicon Labs BGAPI or Telink's mesh_gw, I'd be glad to talk: linktr.ee/weiyii
Cover image: Phooto, CC BY-SA 3.0.
This article was prepared for DEV with AI assistance.
Top comments (0)