SF32 BLE Talkbackインターコム¶

Talkbackとは¶

OpenSiFli Talkbackは、SF32LB52-DevKit-ULP（Huangshan Piとも呼ばれます）向けの複数デバイス対応BLEプッシュ・トゥ・トーク（PTT）サンプルです。Masterモードではルームを作成し、Slaveモードではルームを検索して参加します。参加後、ユーザーが通話キーを押している間は送信し、離すと停止します。公式の基準実装では最大8台のデバイスに対応し、最大3台が同時に発話できます。

このプロジェクトは音声コーデックにOpusを使用し、RGB LED、キー、ディスプレイを組み合わせた簡易ローカルUIを備えています。また、ワンキーでのSlave再接続、バッテリー電圧／残量表示、60秒間入力がない場合のスリープ、長押しによる電源オフ／オン動作も実装しています。そのため、単純な1対1音声サンプルより、携帯型インターコムの参照例として有用です。

SF32を採用する理由¶

この開発手順では、SF32LB52のBLE、オーディオ、ディスプレイ、キー、バッテリー監視、低消費電力動作を、動作する1つの基準構成で評価できます。カスタムRF、オーディオ、電源設計に投資する前に、対応開発ボード上でネットワークと音響を評価できます。

「最大8台、同時発話3台」は上流実装の上限であり、通信距離、干渉、パケット損失、あらゆる同時発話パターンを含め、製品条件で検証済みであることを示すものではありません。上流資料には、ルーム認証、リンク暗号化方針、音声プライバシーの保証、バイナリーのtalk_backコンポーネントに関する完全なライセンス範囲も記載されていません。いずれも製品レビューで個別に確認する必要があります。

開発ボード資料について： SiFli WikiのULP開発ボード中国語ページは「未公開」とされ、低消費電力センサー／ウェアラブル用途、3軸または6軸センサー、低消費電力測定用テストポイントのみを記載しています。完全なボード仕様ではありません。周辺機器は実際の基板リビジョンと回路図で確認してください。以下のTalkback動作は、固定した上流アプリケーションソースに基づいています。

目標、対象範囲、開始条件¶

目標： リビジョンを管理した2台以上のボードで、ルーム作成、参加、PTT音声、退出／再接続、スリープ／ウェイク、バッテリー状態の動作を再現し、カスタムハードウェアへの移行が妥当か判断できる証跡を残します。

対象外： このページは、長距離通信、リンク劣化時の音声品質、エンドツーエンド暗号化、認証、量産時の電力、アンテナの一貫性、法規制への適合、任意のBLEデバイスとの互換性を証明するものではありません。

開始条件： SiFli-SDKのビルド環境を導入し、UART経由でファームウェアを書き込み、ログを確認し、安全にスピーカーとバッテリーを接続できること。音声動作の基準試験には、同一リビジョンのボードが最低2台必要です。

ハードウェアとソフトウェアの仕様¶

ハードウェア仕様¶

ソフトウェア仕様¶

サポート対象の基準構成を選ぶ¶

まず、同一リビジョンのSF32LB52-DevKit-ULPを2台用意します。デモリポジトリーを6fa55acに固定し、^2.4を満たす具体的なSiFli-SDKコミットを選んで記録し、talk_back/1.2@sifliのConan解決結果も保管してください。最初の再現試験では、オーディオパラメーター、役割ロジック、低消費電力のタイミングを変更しないでください。

リポジトリーのルートから、実在するパスへ移動してビルドします。

cd talkback/project
scons --board=sf32lb52-lchspi-ulp -j8

Windowsでは、生成される書き込みスクリプトはbuild_sf32lb52-lchspi-ulp_hcpu\uart_download.batです。実行し、プロンプトが表示されたら該当するCOMポートを入力します。全デバイスに同じ基準イメージを使用し、各ボードの識別情報とイメージハッシュを記録してください。

デフォルトの操作と状態表示¶

プロジェクトの開発段階と判断ポイント¶

システム構成と依存関係¶

flowchart LR
    subgraph A["Master — SF32LB52-DevKit-ULP"]
        AM["マイク"] --> AC["Opus／オーディオ処理"]
        AK["KEY1／KEY2"] --> AN["ルーム／PTT状態機械"]
        AN --> AL["RGB LED／ディスプレイ"]
        AC <--> AN
    end
    subgraph B["Slave — SF32LB52-DevKit-ULP"]
        BN["BLE Talkbackネットワークコンポーネント"] <--> BC["Opus／オーディオ処理"]
        BC --> BS["スピーカー"]
        BK["KEY1／KEY2"] --> BN
        BN --> BL["RGB LED／ディスプレイ"]
    end
    AN <--> |"BLEルーム制御／音声"| BN
    AP["バッテリー／USB電源"] --> A
    BP["バッテリー／USB電源"] --> B

主な故障領域は、BLEスキャン／ルーム作成、ルーム状態の同期、同時発話のスケジューリング、Opus／音響経路、キーイベント、低バッテリーとスリープ、電源キーによる復旧、未公開コンポーネントとライセンス情報です。まず役割と状態を診断し、その後に無線、オーディオ、ローカル電源の問題を切り分けます。

段階1 — 未変更のソース基準構成を確立する¶

目標： 固定したソース、SDK、解決済み依存関係から再現可能なイメージが生成されることを確認します。

1. アプリケーションと具体的なSDKコミットを固定し、依存関係の解決結果を保管します。
2. クリーンなディレクトリーでsf32lb52-lchspi-ulpをビルドし、2台のボードに書き込みます。
3. 各デバイスがSlaveとして起動し、赤色LEDが点灯することを確認した後、キー、ディスプレイ、バッテリー、スピーカーの経路を試験します。

保管する証跡： バージョンマニフェスト全体、ビルド／書き込みログ、ファームウェアハッシュ、両ボードのリビジョン、起動記録。

ゲート1の終了条件： 同じ入力から同一の基準イメージを再現可能に生成して両デバイスに書き込め、起動時の状態が上流の動作と一致すること。

段階2 — ルーム設定と双方向PTTを検証する¶

目標： デバッガーを使わずに、ユーザーが最低限のルームを作成して利用できることを確認します。

1. 待機中に一方のデバイスでKEY2を短押しし、青色LED点灯のMasterにします。もう一方は赤色のSlaveのままにします。
2. 両方のデバイスでKEY2を長押しします。Masterはルームを作成し、Slaveはスキャンします。ペアリングは30秒でタイムアウトします。
3. 開始待ち状態でMasterのKEY2を長押しして開始します。通話状態ではKEY2を押している間発話し、離すと停止します。
4. 送信中の緑点灯、受信中のオレンジ点灯を確認し、双方向で音声を聞き取れることを確かめます。

保管する証跡： 役割、操作の時系列、LED状態、UARTログ、双方向の音声サンプル、再試行結果。

ゲート2の終了条件： 2台以上のデバイスで双方向PTTセッションを繰り返し完了でき、インジケーターが実際の音声方向と一致し、30秒タイムアウト後に説明可能な状態へ戻ること。

段階3 — 退出、再接続、収容台数の境界を検証する¶

目標： 上流の復旧経路と容量上限を確認し、ユーザーが操作不能にならないことを確かめます。

1. 通話状態で退出するには、KEY2を離してからKEY1を短押しします。送信中のデバイスは退出できません。
2. 過去に接続成功したSlaveは、待機中にKEY1を短押しすると再接続します。Masterには同等の再接続経路はありません。
3. 通信範囲外への移動、ペアリングタイムアウト、Masterの停止、電源再起動を試します。
4. 複数ユーザー動作が必要な場合は想定人数まで台数を増やし、最大8台、同時発話3台という記載上の上限を検証します。

保管する証跡： 各故障について、初期状態、トリガー、復旧操作、復旧時間、ログ、最終的なルーム参加者。

ゲート3の終了条件： 対象とする各故障に、明確で反復可能かつユーザーが理解できる復旧経路があり、必要な台数／同時発話数を上限値の記載だけで判断せず、対象RF環境で実測していること。

段階4 — 音声、RF、消費電力を評価する¶

目標： 開発ボードの動作が、想定する筐体、通信距離、動作時間を満たせるか判断します。

1. 静かな環境、近端の同時発話、背景雑音、複数のスピーカー音量設定で、明瞭度、クリッピング、エコー、PTT開始／終了時の音切れを記録します。
2. 想定距離、障害物越し、2.4 GHz干渉下で接続、切断、復旧を記録します。
3. 60秒間入力がない場合のスリープ、Slaveへの役割リセット、任意キーでのウェイク、長押しによる電源オフ／オン、バッテリー残量20%未満のLED表示を確認します。
4. 待機、送信、受信、スリープ、ウェイク時の電流を測定します。開発ボードの測定値を最終製品のバッテリー寿命と同一視しないでください。

保管する証跡： 試験環境、ボード／アンテナの向き、音声ファイル、距離と干渉、電流波形、バッテリー条件、復旧結果。

ゲート4の終了条件： 製品チームが対象環境に必要な音響、RF、電力、ウェイクのしきい値を定義して達成し、未達項目すべてに担当者と対応方針があること。

段階5 — 製品化準備のレビュー¶

カスタムハードウェアに進む前に、少なくとも次の質問に答えてください。

• ルームは信頼できるデバイスをどのように識別し、音声と制御データにはどの認証、暗号化、リプレイ保護を適用しますか。
• talk_back/1.2@sifli、Opus、WebRTCコンポーネント、リポジトリー内ソースファイルのライセンス、ソース提供、脆弱性対応は誰が管理しますか。
• 対象アンテナ、筐体、人体による遮蔽、同時発話条件で、通信範囲、レイテンシ、パケット損失、復旧を測定しましたか。
• マイク、アンプ、スピーカーキャビティ、音量制限は、音響と安全の要件をどのように満たしますか。
• 低バッテリー、異常な電源断、ファームウェア破損、現場更新の失敗から、デバイスはどのように復旧しますか。
• 適用されるBluetooth、EMC、無線、バッテリーの適合性評価は何ですか。

ゲート5の終了条件： リスク一覧に証跡、担当者、緩和策、明示的な続行／保留／中止の判断が記載されていること。セキュリティ、ライセンス、法規制の問題を、担当者不在の「後回し」の作業として残してはいけません。

製品設計への引き継ぎ¶

固定したソース／SDK／依存関係、役割と状態機械、容量と復旧のマトリクス、オーディオ／RF／電力の測定値、アンテナと音響の前提、バッテリー／充電の境界、セキュリティ／プライバシーモデル、ライセンス資料、量産試験の要件、復旧計画を引き継いでください。SF32LB52xの製品統合手順を使って、チップ、モジュール、ボード、ハードウェア設計ガイド、チェックリストを選定します。検証済みの動作をカスタム回路図とレイアウトへ反映し、開発ボードの結果がそのまま当てはまると仮定せずに再確認してください。

主な情報源¶

• OpenSiFli Talkbackディレクトリー
• アプリケーションレビュー時のコミット6fa55ac
• Talkback公式README
• Talkback Conanマニフェスト
• Talkbackプロジェクト設定
• OpenSiFli/SiFli-SDK
• SF32LB52-DevKit-ULP公式Wikiソース
• SF32LB52-DevKit-ULP中国語Wikiソース

最終更新: 2026-10-19