Darkside（https対応しました）

　ソフトウェアで時間待ちループを回したところ、ループ消費時間は２〜３ミリ秒で安定。これを使うことにした。

　Jetson Nano 側から同期信号を出力させ、dsPIC 側でタイミングを合わせる。それでも液晶ディスプレイの表示は崩壊するが、逆にここまでの検証があったからこそＬＣＤアクセスが原因だとはっきりする。
　ＬＣＤ表示を止めたところ、少なくとも Jetson Nano 側でＩ２Ｃバスのエラーは発生しなくなった。dsPIC 側では、確認手段がない。

　送信機には折り返しデーターが来ているので、dsPIC が基本的に動作しているのは間違いない。ならば、実際に車体の自動水平が働くかどうかを確認すれば済むのだが、これも容易ではない。
　受信機 dsPIC からの傾斜センサー値をＳＰＩで受け取るように走行制御 dsPIC のプログラムを修正せねばならないし、その上でサスアーム用サーボの配線を行わねばならない。

　問題は車体側基板の三端子レギュレーター過熱トラブルが解決していないことで、配線を行えば基板の取り外しも面倒になる。そもそも、過熱がいつ発生するか分からない状態で種々の動作確認したくない。
　やはり、過熱問題を何とかするのが先決だ。

　再現性は無いものの、これまでの経験では車体を傾けると発生し易い。
　傾斜センサーの値が変わることを確認しようと車体を揺らすと、過熱することが多い。

　試すものの、過熱しない。

　いったん仕方なく現象を直接再現させるのを諦め、基板を外して目視する。相変わらず、怪しいパターンは発見できない。主要部分をエポキシコーティングしていることもあり、導電性ゴミが入り込んでいる可能性も低い。犯人は基板ではなくコネクターの可能性も高いが、そちらも怪しい部分は見当たらない。わざわざ作り直したんだし。

　過熱が夢じゃないのは明白なのだが、何が条件で発生するのが分からない。ハードウェアの不安定は、始末が悪い。
　ソフトウェアの不安定は、不安定に見えるだけで実際は症状の再現条件ははっきりしている。単に、それを知れていないだけだ。
　それに対しハードウェアの不安定は、本当に不安定だったりする。再現条件も何も、短絡するかしないか物理的にギリギリの場所が隠れていて、僅かな外力の差で短絡したりしなかったり・・・となると発見は至難だ。

　やむを得ず基板と車体側それぞれ徹底清掃し、もろもろの作業を続行する。
　まずは、傾斜センサーのＳＰＩ受信から。そう思ったのだが、送信側の dsPIC からして十分に機能していない。前照灯部分の配線を接続したのに、送信機の操作で前照灯が反応しない。一瞬点灯することはあるが、すぐに消える。
　どうやら、ほぼ常時「受信タイムアウト」扱いになっている。