Choosing Matter Gateway Development Boards: A Hardware and Validation Checklist

Gateway shopping lists grow quickly: a Linux board, a Bluetooth kit, a debugger, a serial adapter, a packet sniffer, power supplies, cables and breakout boards. Each item seems useful.

Then you start connecting them. One board is missing a pin. A firmware image targets a different chip. Another tool turns out to be unnecessary for the experiment in front of you. You have bought the hardware, but still cannot assemble the connection you wanted to test.

Our project bridges Bluetooth Mesh devices into Matter. A Linux host handles Matter and device mapping; a Silicon Labs module runs the Bluetooth Mesh stack; Telink-based lights and switches sit downstream. The PC prototype already connects to Apple Home, and we have built a Linux system image. Flashing the target board, testing real Silicon Labs–Telink Mesh interoperability and verifying the complete system are still ahead.

That makes my purchasing rule straightforward: each purchase should help answer a specific unresolved question.

Draw the connection before buying hardware

An operation in Apple Home should follow this path:

Apple Home ↓ Matter over the local network Linux host: device mapping, commands, state synchronization ↓ UART / BGAPI Silicon Labs module: Bluetooth Mesh NCP firmware ↓ Bluetooth Mesh Telink device: light or switch 

When someone presses the device's physical button, its new state must travel back and update Apple Home.

This diagram prevents a few common purchasing mistakes. The Matter connection in this design uses Ethernet or Wi-Fi. The downstream radio network is Bluetooth Mesh. Bluetooth Mesh and Thread are different protocols, despite both being mesh networks.

Using Matter here does not automatically require a Thread development kit or a Thread border router. Those become relevant if we later develop or connect Matter-over-Thread devices. Apple Home controllers, home hubs and software versions should follow Apple's current compatibility requirements.

Built-in Bluetooth on a Linux board also does not automatically replace our NCP. It normally comes with a different driver and host software arrangement. Our architecture places the Mesh stack on a separate module and accesses it through BGAPI; replacing that layer means evaluating the software interface and stack as well.

Start with the Bluetooth experiment

The PC-and-phone prototype let us work on Matter before the hardware arrived. The next useful purchase should establish whether the Silicon Labs module can control the Telink devices as required.

An existing PC can remain the host. Connect the Silicon Labs kit through its supported serial interface or a suitable USB-to-UART adapter. Get provisioning, control and status reporting working before moving the host to a Linux board. That gives each failure fewer possible causes.

One device board running a standard on/off model is enough to start. Observing its LED is easier than immediately connecting a mains-powered light.

After the smallest setup works, add a second node, dimming and multi-channel devices to exercise group control, multiple elements and different models. One working node proves the basic procedure; it says little about network capacity or long-term reliability.

Match the Silicon Labs board to the firmware

A search for an “xG24 development board” produces kits with different chips, connectors and accessories. “BG24 module” in a design document is not a precise enough order specification.

Our planned module is in the BGM240 family. Before ordering, match the production module, the evaluation board's chip, the SDK version and the example project. Sharing “24” in their names does not mean two boards can run the same firmware binary.

I would confirm five things:

1. Can the chosen Bluetooth Mesh SDK create the required NCP project for this exact board?
2. Are the provisioner and required client models covered by examples or documented configuration?
3. Does the target meet the project's Flash, RAM and component requirements?
4. Does the kit include a debugger or development mainboard? What else is needed if buying a radio board separately?
5. Where are UART, flow-control, reset and debug signals, and can an external host reach them?

A working Bluetooth example establishes support for that example. We need Bluetooth Mesh NCP specifically, so I would ask the supplier to identify the corresponding board and project.

The NCP application and its bootloader are also separate components. Flashing through a debugger proves that programming path. If the Linux host will later update the module over UART, we must also check the bootloader, pins, update-entry procedure and compatible firmware combination.

A complete kit may cost more than a bare board, but included debugging, serial access and documentation can save a lot of piecemeal setup.

A USB-to-UART chip name is not enough

Small FT232- or CP2102-based adapters are easy to buy without much thought. Some expose only TX, RX, ground and power. Even if the chip supports other signals, inaccessible pins on the finished adapter are no help.

For this design, I would choose an adapter exposing TX, RX, RTS, CTS and GND, then confirm driver support at the required baud rate. Check the finished board's pinout and schematic.

RTS/CTS coordinates the two ends of the connection. Wire signals according to their direction and both board manuals. The NCP configuration, host settings and physical wiring must agree: an endpoint waiting for flow control that is not connected may never communicate normally.

Hardware flow control reduces loss caused by an overwhelmed receiver. It does not provide error checking or retransmission. Electrical interference, wiring faults and parser errors still need their own diagnosis. Whether flow control is enabled depends on both ends; our hardware plan reserves the necessary connections.

Check voltage levels too. A board's UART might use 1.8V or 3.3V. A “3.3V/5V” jumper may select only the adapter's power output, without changing TX/RX logic levels.

Before ordering, establish the signal voltage, exposed flow-control pins and supported baud rates. TTL UART and RS-232 are not directly interchangeable. If the target already has its own supply, decide whether to connect the adapter's power pin according to the board's power design.

Choose the Linux board for its SDK and usable interfaces

We already compared processors in the RK3506, RK3562, RK3576 and RDK X5 article. Purchasing is now about development conditions.

We do not need all four. RK3562 is the planned standard product platform, while system-image work began with the X5 SDK. An existing platform can answer useful questions before the final hardware is selected.

I want four things from a Linux board supplier.

A rebuildable SDK: download access, version, build environment, toolchain and board configuration. A preinstalled image alone leaves us dependent on the supplier when trimming the system or changing drivers.

A usable application UART: a processor having many UARTs does not guarantee that a full TX/RX/RTS/CTS set reaches an accessible header. Check pin sharing and device-tree configuration. Keep the debug console separate so boot logs do not enter the NCP protocol stream.

A recovery path: flashing interface, recovery mode, debug console and partition documentation. When a custom image fails to boot, these become more valuable than extra compute performance.

Networking and persistent storage suited to the system: check IPv6, local discovery, Wi-Fi drivers and where configuration and device data survive reboots. Routers, VLANs, client isolation and firewalls can interfere with discovery. This is separate from purchasing public IPv6 service from an ISP.

Our earlier Buildroot work found IPv6 disabled in the default configuration. Booting successfully and reaching the internet are only the beginning of checking a Matter gateway.

Buy sniffers and logic analyzers when needed

The original topic notes included an nRF52840 Dongle. I would not make it mandatory in the first order.

Tools such as nRF Sniffer for Bluetooth LE can help observe radio traffic. Supported hardware, firmware and capture methods must match the tool version. Mesh analysis also depends on the bearer, encryption, keys and decoding software.

Buying a Bluetooth dongle does not automatically make all Mesh application traffic readable. Buy it once a problem really requires radio-level observation and the tool supports the traffic of interest. It also does not automatically serve as a Thread sniffer or the gateway's NCP.

A logic analyzer is useful for UART activity: bytes on the line, flow-control transitions and the stream around a fault. Choose input levels, channel count and sampling capability appropriate for the actual signals.

For the first experiments, capture serial logs, command responses, Mesh status events and timestamps. Add electrical or radio observation when those logs leave a specific question unanswered.

Test each layer after the boards arrive

Sending a command and completing a physical operation are different milestones. A successful serial write means bytes reached the serial subsystem. An NCP response must be interpreted according to the operation it acknowledges. Device state needs the relevant Mesh Status, observation of the device and agreement with the Matter display.

If Apple Home immediately shows a light as on while the real light remains off, the test has not passed. With optimistic state updates, also unplug the device and test response timeouts: the interface should not retain an incorrect state indefinitely.

Split recovery tests as well. Recovering from a host reboot does not prove module replacement works. A retained device list does not prove keys, sequence numbers and network state are handled correctly. Module replacement and network restoration need dedicated reliability work.

How I would place the orders

First, buy a Silicon Labs kit that supports the intended NCP firmware and one controllable Telink device board. Fill gaps in power, cables and programming access. Use the PC to establish provisioning, model control and status reporting.

Second, add the target Linux board and migrate the working host program. Confirm the SDK, complete UART interface and recovery procedure, preferably within a vendor ecosystem that can also support the future production module.

Then increase device variety and count. Test multi-channel switches, dimming, disconnections and recovery. Buy specialist capture and measurement tools as problems justify them.

Here is a supplier request you can reuse:

We are building a Linux-hosted gateway with a Bluetooth Mesh NCP. Please provide the exact board model and hardware revision, matching SDK and example project, required programming/debugging accessories, and the pinouts and logic levels for UART, RTS/CTS, reset and debug. For the Linux board, please also confirm UART device-tree configuration, system rebuild instructions and recovery flashing.

Clear answers make a board worth considering. A useful development setup helps resolve firmware compatibility, interoperability, return status and recovery one question at a time. Once those are understood, cost reduction and a custom carrier board become much better-informed decisions.

Working on Silicon Labs NCP, Telink interoperability or Linux UART integration? Get in touch.

References: Silicon Labs Bluetooth Mesh API, RDK documentation, Luckfox Lyra RK3506, nRF Sniffer for Bluetooth LE.

Cover: Windell Oskay, CC BY 2.0.

Originally published at ay3s.com.