(19) BLEとIEEE802.15.4の共存に奮闘！ - 開発ログ＠2025/06/16(月)
最新の開発日記をアップしたよ！BLEとIEEE802.15.4の共存にめっちゃ苦戦したけど、モーター動いた瞬間はマジ感動！まだカクつき問題あるけど、進捗はガッツリ！みんな、読んでみてね！
BLE送信とMAUIアプリの連携チャレンジ
BLEでデータを送る仕組みを整えつつ、MAUIアプリ側でそのデータを受け取れるように奮闘したパート。最初は単純なバイト配列送信から始まり、MAUIアプリの通知設定やスキャンの問題にぶち当たって、試行錯誤の連続だったよ。
バイト配列送信の第一歩
まず、ESP32からBLEでデータを送るために、5バイトのバイト配列を構築して `ble_bidi_fast_tx_send` で送信するところからスタート。
モーター番号や位置、加速度をペイロードに詰め込んで、シンプルに送信！って思ったけど、MAUIアプリ側で準備が足りてなくてエラー発生（笑）。アプリ側で通知設定をオンにする必要があることに気づき、`SynchroDeviceManager` の `OnBleDeviceConnectionStateChanged` 内で `_bleCharacteristicTX.StartNotificationsAsync()` を追加。これでうまくいくはず！と意気込んだら、今度はデバイスがスキャンに引っかからない問題に直面。
昨日まで動いてたのに、なんで？って頭抱えた瞬間だったね。
通知設定とスキャンの壁
通知設定を入れたら、次はデバイスがスキャンで見つからないトラブルに突入。
原因を考えると、アンテナを短いケーブルに変えたことや、IEEE802.15.4の受信をオンにしたことが怪しい。まずアンテナを近づけてみたけど変化なし。じゃあIEEE802.15.4をオフにしたら…おお、デバイス見えた！でも、これってBLEとIEEE802.15.4が同時に動くとダメってこと？ちょっと焦ったけど、ログ見たら受信はできてるっぽい。
どうやらCoexistence設定が問題っぽいなって気づいて、設定をいじり始めたよ。ここからが試行錯誤の嵐だった！
Coexistence設定との格闘
BLEとIEEE802.15.4の共存を実現するために、Coexistence設定を何度も調整。HIGHやMIDDLE、LOWを試しながら、BLEのスキャン可否とIEEE802.15.4の受信を両立させる設定を探った。設定一つで結果がガラッと変わるから、めっちゃ神経使ったよ！
Coexistenceの初期設定と試行錯誤
CoexistenceのAPIがBLEとIEEE802.15.4の共存を助けるはずなのに、初期設定（`idle=HIGH, txrx=HIGH, txrx_at=LOW`）だとスキャンに引っかからない。
バランス設定に変えてみたり、API呼び出し自体をやめてみたり。試しに `esp_ieee802154_set_coex_config` を外したらスキャンできた！でも、これだとIEEE802.15.4の優先度が下がっちゃうから、モーター制御がちゃんと動くか心配。GitHubでAPIの使われ方を調べると、`txrx=MIDDLE` や `txrx_at=MIDDLE` が良さそうだとわかってきた。
設定を `idle=IDLE, txrx=MIDDLE, txrx_at=MIDDLE` にしたら、スキャンも受信もOK！やったぜ！って感じだったね。
モーター制御とカクつき問題
Coexistence設定が安定したところで、モーター制御のテスト。
Windowsでは単一モーターはスムーズだったけど、Androidで2つのモーターを同時に動かすとカクつく。iOSでも同じ。ログにキューオーバーフローはないし、MAUIアプリの通知設定やモーター数増加が影響してる？通知をオフにしたり、モーター数を減らしてみたりしたけど改善せず。結局、BLEの高頻度送信がネックっぽい。複数コマンドをまとめて送るように変更したけど、カクつきは解消せず。
スライダーがマルチタッチ前提じゃないって気づいたときは「え、マジで？」って笑っちゃったけど、これで一旦問題は保留。次に進もう！
FIZユニットからのデータ受信とモーター制御
FIZユニットからIEEE802.15.4でデータを受信して、BLE経由でMAUIアプリに送り、モーターを動かすパート。データ解析からスライダーへの反映まで、ようやく形になってきたけど、同時制御のカクつきは課題のまま。
データ受信と解析
FIZユニットからのデータをBLEでMAUIアプリに送るため、通知を再有効化。
`txrx_at=MIDDLE` に設定したら、IEEE802.15.4の受信もバッチリ！アプリ側で `_bleCharacteristicTX.ValueChanged` イベントを追加して、5バイトのデータを受信。ログ見たら、チャンネル、モーター番号、位置がESP32側と一致！でも、イベントハンドラがメインスレッドじゃないことに気づいてビックリ。`MainThread.BeginInvokeOnMainThread` を使ってスライダーに反映するようにしたよ。データ解析は順調で、モーター位置を正確に取得できた。
いよいよモーター動かすぞ！ってテンション上がった瞬間。
モーター制御と滑らかさの追求
アクティブなモーターを探して、受信した位置データを反映。
`foreach` でチャンネルとモーター番号をチェックして、ポジションを設定したら…動いた！GIFと動画で確認したら、めっちゃ感動！でも、ログ出力をやめても、複数モーターの同時制御だとスマホ側がカクつく。ESP32側はエラーなしだから、MAUIアプリの処理が重いのかも。`CommunityToolkit.Mvvm` のプロパティ設定が負担になってる？キューイングも試したけど効果薄。
コードが複雑化してきたから、機能分割が必要だなって思い始めたよ。
まとめ
この日はBLEとIEEE802.15.4の共存に全力で挑んだ一日だった。
バイト配列の送信から始まり、MAUIアプリの通知設定、Coexistenceの調整、FIZユニットからのデータ受信、そしてモーター制御まで、めっちゃ濃密！特にCoexistence設定は、HIGHやMIDDLEを試しまくって、ようやく `idle=IDLE, txrx=MIDDLE, txrx_at=MIDDLE` でスキャンと受信を両立できたときはガッツポーズもの。モーター制御もGIFで見る限り感動的だったけど、複数モーターの同時制御のカクつきは大きな課題として残った。ログ見てもエラーなし、キューもボトルネックじゃないから、MAUIアプリ側の処理負荷が怪しい。コードの複雑化も気になってきて、機能分割の必要性を感じたよ。
いやー、疲れたけど、進捗はしっかり出たから満足！
これから
明日からは、まずMAUIアプリのコードをスッキリさせるために、機能分割に着手したい。
`SynchroDeviceManager` がゴチャゴチャすぎるから、接続管理、データ解析、コマンド送信を別クラスに分けて整理する予定。カクつき問題は、CommunityToolkit.Mvvmのプロパティ通知やUI更新が重い可能性があるから、軽量化する方法を模索するよ。BLEの高頻度送信の限界も気になるから、データ送信の頻度を減らす工夫や、BLE5.0の可能性も調べてみる。あと、IEEE802.15.4とBLEの共存は安定したけど、モーター制御の安定性をもう少しテストして、複数モーターでも滑らかに動くようにしたい。
課題は山積みだけど、今日の進捗で勢い乗ってるから、ガンガン進めていくぞ！