【PMM2018】街乗り10kmでNaNデバッグ<BT送信周期遅くした>

自宅から松本城まで街乗りで、往復で10㎞あるので、PMM2018のデバッグがてら散歩しました。

●歩道段差超え振動でCPUコネクタ接触不良
スタートから1㎞もしないうちに異常動作になったので
一旦引き返して、家でみてみると1回転の1回点滅のLEDが細かく点滅しているので、これはハードだということで、基板をサドルから引き出してみるとCPUが抜けかけてました。
街乗りで、歩道の段差を何回も通過したときの振動でCPUのソケットから抜けてきたみたいです。これはいけないということで
信越シリコン一液型オキシムゴムで固めました。
いざとなれば、きれいに剥げるので、大丈夫です。

更に、頻繁に基板を修理点検するので、PMM2018が落ち着くまでは、サドルバッグにいれておくことにしました。

●走行中のNaN発生の対策
Processingのプログラム眺めても、速度関係の数値は、割り算はマイコン側でしてあるので、単にBlueToothライブラリから受信して表示しているだけでしたので、NaNが発生するのは
BluTooth受信部で間違った文字で数値でなくなった場合が最も怪しいのではないかと思いました。
MSLABO様のProcessing解説でNaNの説明がありました。

以下の条件下で、float()命令は期待通り動作します。

  • アラビア数字と “.”  は半角文字のみOKです
  • “+” または “-“の記号文字は文字列の先頭についている場合のみOKです
  • “+” または “-“の記号文字は半角文字だけが許可されています
  • “.” 記号文字は無くてもOKです
  • “.” 記号文字は文字列のどこにあってもOKですが、MAX1つのみです

上記の条件を満たさない場合、変換結果はNaNになります。NaNとは「Not a Number」の略で、Javaで「非数値」を示す記号です。具体例は下記サンプルプログラムを参照してください。

なお、PROCESSINGが扱える float値は±10の38乗ですが有効桁は7桁しかありません。変換結果がfloatで扱える有効桁数を超える場合は極端に精度が落ちるか、Eの階乗付きの値が戻されます。  例:”19999999” ⇒ 2.0E7 が戻されます

もともと、BlueTermに比べて、私のプログラムは倍遅い

【PMM2018】BLUETOOTH受信部完成した<BLUETERMの倍遅い>

ので、高速で送信するとバッファ処理でミスが発生するのではないかと思って、While LOOPの周期を1msecから50msecまで落としました。それで、松本城往復デバッグしました。

●松本城往復デバッグ
CPUを充填剤で固めて、サドルバッグにいれてから再出発して
調子よく走行してましたが、4kmちょうどでNaNが発生しました。再起動して、松本城まで行って、引き返してきて残り6kmではNaNは発生しませんでした。もっと、長距離で長時間でこの現象を追っていかないといけないと思います。

●送信部をTicker割り込みで定期通信することにした。
(mbed Pgm rev07)
while Loopを遅くすると他の処理に影響があるので
BlueTooth送信部のみ指定のticker周期で送信できます。
100msec程度でも十分なのでこれで明日以降長距離長時間
走行します。

●以後
パワーメーターにデータをPMM2018に取り込む作業をはじめます。PowerTap本日動作しなかったので電池切れになったみたいですので、ついでに自作パワーメーターを再開しようと思います。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です