Matterゲートウェイ開発ボードの選び方：購入と動作確認のチェックリスト

ゲートウェイの開発を始めると、買う物が次々に増えます。Linuxボード、Bluetooth開発キット、デバッガー、USBシリアル変換器、パケットスニファー、電源、ケーブル。どれも役に立ちそうです。

ところが接続を始めると、必要なピンが出ていない、ファームウェアの対象チップが違う、今は使わない道具だった、といった問題が出てきます。物はそろっていても、確かめたい通信経路が組めません。

私たちのプロジェクトはBluetooth Mesh機器をMatterへ橋渡しするゲートウェイです。LinuxホストがMatterと機器の対応付けを担当し、Silicon LabsのモジュールがBluetooth Meshスタックを実行します。その先にTelinkベースの照明やスイッチを接続します。

PC上のMatter試作はApple Homeに接続でき、Linuxシステムイメージもビルド済みです。一方、実機への書き込み、Silicon LabsとTelinkのMesh相互接続、全体の安定性はこれから検証します。

そのため、購入の基準は一つです。これを買うと、まだ分からない何を確認できるのか。

買う前に通信経路を描く

Apple Homeでの操作は、次の経路を通って機器へ届く想定です。

Apple Home
    ↓ LAN上のMatter
Linuxホスト：機器表、コマンド変換、状態同期
    ↓ UART / BGAPI
Silicon Labsモジュール：Bluetooth Mesh NCP
    ↓ Bluetooth Mesh
Telink機器：照明やスイッチ

機器の物理ボタンを押した場合は、新しい状態が逆方向へ戻り、Apple Homeに反映される必要があります。

この構成のMatter接続にはEthernetまたはWi-Fiを使います。 機器側はBluetooth Meshです。Bluetooth MeshとThreadは、どちらもメッシュネットワークですが、別のプロトコルです。

Matterを使うという理由だけで、Thread開発ボードやThreadボーダールーターを追加する必要はありません。Matter over Thread機器を開発・接続するときに、その目的に合う機材を選びます。Apple Homeのコントローラー、ホームハブ、OSバージョンは、Appleの現在の対応条件に合わせて準備します。

LinuxボードにBluetoothが載っていても、そのまま今回のNCPを置き換えられるとは限りません。通常はドライバーやホスト側ソフトウェアの構成が異なります。今回は独立したモジュールでMeshスタックを動かし、BGAPIで操作する設計なので、変更時にはスタックとインターフェースも評価する必要があります。

最初はBluetoothを検証できる一式から

PCとスマホで動かした試作では、ハードウェアを待たずにMatter側を先行できました。次に確認したいのは、Silicon LabsのモジュールでTelink機器を必要な方法で制御できるかです。

ホストには手元のPCを使い続けられます。開発キットの対応シリアル経路、または適切なUSB-UART変換器で接続し、プロビジョニング、制御、状態通知を動かしてからLinuxボードへ移します。問題が起きたときに疑う場所を絞れます。

用意する物	購入前に見る点	確認できること
Silicon Labs開発キット	正確なチップ・ボード番号、Mesh NCPサンプル、書き込み・シリアル接続	SDKとファームウェアが対象ハードに対応するか
Telinkボードまたは制御可能な照明サンプル	書き換え可能なファームウェア、使用モデル、初期化手順	プロビジョニング、制御、状態通知、相互接続
書き込み・デバッグ用機材	キットに含まれるか、対象ボードへ接続できるか	書き込み、復旧、デバッグ
USBデータケーブル、電源、配線	データ通信、給電条件、コネクター、信号電圧	配線・給電の問題の切り分け
必要に応じてUSB-UART	フロー制御端子と論理電圧	ホストとNCPの通信

最初は標準的なオン・オフモデルを動かせるボードが一枚あれば始められます。商用電源の照明をいきなり接続するより、ボード上のLEDを確認する方が扱いやすいでしょう。

最小構成が動いたら、二台目、調光、複数チャンネルの機器を加え、グループ制御、複数エレメント、別モデルを試します。一台で成功しても、収容台数や長期安定性までは分かりません。

Silicon Labsはボード番号とファームウェアを対応させる

「xG24開発ボード」で検索すると、チップ、端子、付属品の違う製品が見つかります。設計書に「BG24モジュール」と書いてあるだけでは注文仕様として足りません。

私たちの目標はBGM240シリーズです。目標モジュール、評価ボード上のチップ、SDKバージョン、サンプルプロジェクトを対応させて確認します。型番に「24」があるだけで同じバイナリーを書き込めるわけではありません。

確認したい項目は次の五つです。

選んだBluetooth Mesh SDKで、この正確なボード向けのNCPプロジェクトを作れるか。
プロビジョナーと必要なクライアントモデルに、サンプルや明確な設定手順があるか。
Flash、RAM、コンポーネント構成の要求を満たせるか。
デバッガーやメインボードは含まれるか。無線ボードだけ買う場合、何を追加するか。
UART、フロー制御、リセット、デバッグ端子を外部ホストへ接続できるか。

Bluetoothサンプルが動くことと、必要なBluetooth Mesh NCPを動かせることは、別々に確認します。販売元には対象ボードとプロジェクトの組み合わせを示してもらいたいところです。

NCPアプリケーションとブートローダーも別物です。デバッガーで書き込めても、LinuxホストからUART経由で更新できるとは限りません。将来その更新方法を使うなら、ブートローダー、端子、更新モードへの入り方、ファームウェアの組み合わせまで確認します。

少し高いキットでも、デバッグ、シリアル接続、資料がそろっていれば、裸のボードを買って道具を後から集めるより楽な場合があります。

USB-UARTはチップ名だけで選ばない

FT232やCP2102を使った小型変換基板でも、TX、RX、GND、電源しか出していない製品があります。ICが信号を持っていても、完成品の基板から引き出せなければ使えません。

今回ならTX、RX、RTS、CTS、GNDが利用できる物を優先し、必要な通信速度でのドライバー対応を確認します。見るべきなのは、完成品の端子と回路図です。

RTS/CTSは両端でデータの流れを調整します。各信号の方向とボードの資料に従って接続し、NCPファームウェア、ホスト設定、実配線を一致させます。片側が未接続のフロー制御信号を待っていれば、通信自体が始まらないこともあります。

ハードウェアフロー制御は受信処理が追いつかないことによる欠落を減らしますが、誤り検出や再送は担当しません。 電気的なノイズ、配線不良、プロトコル解析の問題は別途調べます。有効・無効は両端の設定によりますが、今回の検証用ハードでは端子を確保します。

電圧にも注意が必要です。UARTは1.8Vの場合も3.3Vの場合もあります。変換基板の「3.3V / 5V」ジャンパーが電源出力だけを切り替え、TX/RXの論理電圧は変えない場合もあります。

信号電圧、フロー制御端子、対応速度を購入前に確認します。TTL UARTとRS-232は直接混用できません。ボードが別電源で動いている場合、変換器の電源端子をつなぐかは、その給電設計に従います。

LinuxボードはSDKと使える端子で選ぶ

CPUの比較はRK3506、RK3562、RK3576、RDK X5の記事で行いました。購入時は開発条件へ視点を移します。

選択肢	検証する目的	事前確認
RK3562	計画中の標準ゲートウェイ	BSP、UARTピン多重化、フロー制御、Wi-Fi、供給
RK3506	機能確認後に小さい構成を評価	32ビットツールチェーン、実測メモリー、保存領域、安全機能
RDK X5	既存のSDK・イメージ作成を実機へつなぐ	ボード版、対応イメージ、書き込み、端子設定
手持ちのLinux機	ホストプログラムとシリアルの開発	実行互換性、適切なUARTまたはUSB接続

全部買う必要はありません。標準版はRK3562を計画し、システムイメージの作業はX5 SDKで始めています。手持ちの機材で確認できる範囲は先に進められます。

販売元には四つの条件を確認します。

再ビルドできるSDK。 入手方法、バージョン、ビルド環境、ツールチェーン、対象ボード設定まで必要です。書き込み済みイメージだけでは、システムの削減やドライバー変更で困ります。

実際に使える業務用UART。 SoCのUART数が多くても、TX/RX/RTS/CTS一式が端子に出ているとは限りません。ピンの兼用とデバイスツリーを確認し、起動ログがNCP通信へ混ざらないよう、デバッグコンソールを分けます。

起動しない場合の復旧方法。 書き込み端子、リカバリーモード、コンソール、パーティション資料は、自作イメージの開発で重要です。

適切なネットワークと保存領域。 IPv6、LAN内の発見、Wi-Fiドライバー、設定と機器情報の永続化を確認します。ルーター、VLAN、クライアント分離、ファイアウォールも発見に影響します。これは公開IPv6サービスを契約する話とは別です。

前回のBuildroot作業では、デフォルトでIPv6が無効でした。起動してインターネットにつながるだけでは、Matterゲートウェイとしての確認は終わりません。

スニファーとロジックアナライザーは必要になってから

企画メモにはnRF52840 Dongleもありますが、初回購入の必須品にはしません。

nRF Sniffer for Bluetooth LEのような道具は無線通信の観察に役立ちます。ただし、対応ハード、ファームウェア、キャプチャー方法は使用バージョンの資料で確認します。Mesh解析にはベアラー、暗号、鍵、解析ソフトの条件もあります。

Bluetooth Dongleを買って挿せば、Meshの通信内容がすべて読めるわけではありません。 無線層に調べたい問題があり、対象の通信を観察できると確認してから買います。ThreadスニファーやゲートウェイNCPとしても、自動的に使えるわけではありません。

ロジックアナライザーはUARTの有無、フロー制御の変化、異常前後のバイト列を見るのに向いています。入力電圧、チャンネル数、サンプリング性能を実際の信号に合わせます。

最初はシリアルログ、応答、Mesh状態イベント、タイムスタンプを残します。それでも分からない電気信号や空中線上の疑問が出たら、必要な道具を追加します。

到着したら層ごとに確認する

段階	作業	確認できたと判断する条件
開発キット	対応ファームウェアを書き込み、シリアル・リセット・デバッグ接続	安定通信と期待する起動イベント・版情報
最小Mesh	対応するホスト例やツールで配網・モデル設定	機器が動き、状態を返す
双方向状態	機器の物理ボタンを操作	ホストが変化を受け取る
自作ホスト	コマンド・応答・イベントを実装	同じ機器を追加・制御・照会・削除できる
Matter橋渡し	機器を端点へ対応付け	Apple Homeで操作でき、機器側変化も戻る
Linux統合	対象ボードへ移し、起動・ネットワーク・UARTを設定	再起動後も機器識別と必要な情報が正しく復元される
復旧	ホスト・モジュール・機器を個別に再起動し、ネットワークと電源を切る	障害中の表示を説明でき、復旧後に制御と同期が戻る

コマンド送信と、実際の操作完了は区別します。シリアル書き込み成功はバイト列を渡せた段階です。NCPの応答も、何を受理・完了した応答なのかを読み取る必要があります。状態は対応するMesh Status、実機の動作、Matter表示を合わせて確認します。

Apple Homeだけ点灯表示になり、実物が消えたままなら合格ではありません。楽観的更新を使う場合は、機器の電源断や応答タイムアウトで、誤表示が残り続けないかも試します。

ホスト再起動からの復帰が成功しても、モジュール交換からの復旧は別の課題です。機器一覧が残っているだけでは、鍵、シーケンス番号、ネットワーク状態を適切に扱えているとはいえません。専用の信頼性検証が必要です。

私なら注文をどう分けるか

最初に必要なNCPを動かせるSilicon Labsキットと、制御可能なTelinkボードを一枚購入します。足りない電源、配線、書き込み機材をそろえ、PCで配網、モデル制御、状態通知を確認します。

次に対象Linuxボードを追加して、動作済みのホストプログラムを移します。SDK、UART一式、復旧手順を確認し、将来の量産モジュールまで継続して支援できる供給元を選びたいところです。

その後、機器の種類と台数を増やし、多チャンネル、調光、切断、復旧を試します。専門的な測定機材は問題に応じて追加します。販売元への問い合わせは、例えば次のようにまとめられます。

LinuxホストとBluetooth Mesh NCPを使うゲートウェイを開発します。正確なボード型番・ハードウェア版、対応SDKとサンプル、書き込み・デバッグ用付属品、UART・RTS/CTS・リセット・デバッグ端子の配置と電圧を教えてください。Linuxボードについては、UARTのデバイスツリー設定、システム再ビルド、復旧書き込みの方法も必要です。

明確な回答をもらえて初めて、購入候補として判断できます。ファームウェア、相互接続、状態通知、再起動後の動作を一つずつ確かめれば、コスト削減や専用基板設計にも根拠を持って進めます。

Silicon Labs NCP、Telinkとの相互接続、Linux UARTに取り組んでいる方は、こちらからぜひ交流しましょう。

参考：Silicon Labs Bluetooth Mesh API、RDK公式資料、Luckfox Lyra RK3506、nRF Sniffer for Bluetooth LE。