Darkside（https対応しました）

　送信機の電源を先に入れておき、車体の主電源を入れる。それで暴発するということは、送信機が電源投入直後にトリガー信号を想定外に送り出している訳じゃないってことだ。仮に送信機の初期処理に問題あるのであれば、送信機の電源を入れて数秒後には問題ないはずで、後から車体電源を入れても暴発などしないはず。
　よって、車体側の初期処理に問題がある・・・と言いたいがそれなら車体側の電源を入れて数秒すれば大丈夫なはず。

　ところが実際には、車体側の電源ずっと入れたままで送信機の電源を入れ直すと、暴発する。
　そうなると、問題は車体側でも「送信途絶から送信開始への変化」時の処理である可能性が高まる。

　ここで更に情報を増やすべく、車体側の受信メイン dsPIC のプログラムを書き換えてみる。受信したキー入力をＳＰＩ送信するが、その送信直前でトリガーＯＦＦに上書きしてしまうのだ。これにより、送信データーにはトリガーが押されていないという情報しか乗らなくなる。果たして、これで暴発は起きるのか？
　書き込もうとして、誤算に気付いた。電動エアガンのメカボックスを取り付けた後では、書き込みピンが近過ぎてライターを挿すことができない！

　PicKit 4 には純正で延長ケーブルがあるが、それを使うと書き込み不良が多発すると判明している。とてもじゃないが、使ってられない。信頼性の差が、とんでもない。

　そこで、延長ケーブルを自作。
　見ての通り極めて単純なシロモノで、これが通信不良を頻発させるなんて市販品としておかしいだろ。

　問題なく使用できてエラーなく書き込みできるようになった。
　プログラムを書き換えつつ暴発のルーツを探ると、受信データーがダーティーだと判明。受信データー自体が、送信機の電源投入直後にトリガー押されたということになっている。

　しかし繰り返すが、送信機の電源を入れて暫く放置し、それから車体の主電源を入れてもその瞬間に暴発する。送信機の初期処理でゴミデーターが乗るのであれば、そのような症状は起こらない。
　送信機と受信処理で責任を押し付け合っているかのような、原因不明の暴発である。だが、受信側のソフトウェアに問題がある可能性の方が高い。受信側では傾斜データーを切れ目なく送り出すため、割り込みで強制的に一定周期でキー入力データーを送り出している。そこに、問題が紛れているのかもしれない。
　受信データーが存在した場合だけその直後にキー入力データーをＳＰＩ送信していた時は、こんな訳の分からない暴発は起きていなかった。