ベンチ上では問題なくペアリングできた。ところが現場では2〜3時間おきに切れる。しかも都合の悪いときにだけ、再現性もなく。私たちは3週間かかりました。以下が、見つかった順の4つの原因です。そして最後の1つは、そもそもBluetoothモジュールのせいではありませんでした。
スリープクロックがドリフトしていた
Bluetoothモジュールはコネクションイベントの合間にスリープし、32kHzのクロックで起床します。その水晶が数百ppmずれていると、無線は遅れて起きてウィンドウを逃し、相手は待って、諦めて、リンクが落ちます。ランダムに見えますが、実際には温度に追従します。私たちが見つけた個体は40℃を超えたときだけ失敗していました。だからこそラボでは一度も再現しなかったのです。「ランダムな切断」を信じる前に、その個体を恒温槽に入れてください。
送信時に電源レールが垂れていた
送信は電流スパイクです。数マイクロ秒の間に数十ミリアンペア。LDO、配線、デカップリングのどれかがレールを支えきれないと、VDDが落ちてBluetoothモジュールはブラウンアウトするか、そのままリセットします。見分け方は、トラフィックが最も重いときに切断が集中することです。たいていの人はこれを干渉と読み違えます。アイドル時ではなく、TXバースト中のレールをオシロスコープで見てください。私たちはコンデンサを4ミリ動かしただけで直ったことがあります。
誰も合意していない接続パラメータ
ホストがモジュールには守れないコネクションインターバルを要求したり、騒がしい部屋には短すぎるスーパービジョンタイムアウトを設定したりする。静かなラボなら何も起きません。Wi-Fiのアクセスポイントと電子レンジが加わると、連続してイベントを取りこぼし、タイムアウトに達します。まずペリフェラル側に要求させ、データシートがかつて「効率的」と呼んだからといって7.5msをハードコードするのはやめましょう。混雑した部屋で生き残るリンクは、生き残れない高速リンクより価値があります。
アンテナが金属に埋まっている
禁布領域を無視した、モジュールをべたのグランドプレーンの上に置いた、金属蒸着の窓のある筐体に入れた。こうなると通信距離は1メートルまで縮み、リンクはその境界で激しくバタつきます。VNAでは一目瞭然で、ノートPCから60センチのベンチでは完全に見えません。だからプロジェクトの終盤まで生き残ってしまうのです。
モジュールのせいではなかった一件
私たちは1週間「Bluetoothモジュールの問題」を追いかけましたが、実際にはホストMCUがI2Cバスのロック中にモジュールをリセット保持していたのが原因でした。Bluetoothモジュールはその間ずっと健全でした。今では、ホストの「何が起きたか」という話を信じる前に、モジュール自身のリセット理由を読みます。
今の私たちのデバッグ手順
無線はスニファ、レールはオシロ、そして「ランダム」と表現されたものには恒温槽。そのうえで、誰かの意見より先にモジュール自身の診断情報を見ます。「接続が切れ続ける」というチケットの多くは、RFではなく電源かクロックに行き着きます。幸いなことに、それらは安く直せる方です。
最初に伝えたいこと
アンテナやスタックに手を付ける前に、レールとスリープクロックを確認してください。10回中9回はそちらが安い解決策で、アンテナは誰もが最初に手を伸ばす高い方の部品です。
