STA25システムは、２０２４年夏からCPU構成を２CPUにするつもりで準備していたのですが、１２月になって、実装を始めるとと
これ以上基板が増えると防水ケースが大きくなりすぎて、ただでさえ大きくて重いのでテストライドでも支障がでると思って
２０２５年正月に思い切って１CPUで処理することにしました。慌ててプログラムを作成したのですが、どうもデバッグが不完全で
３個のF9Pからのデータ受信のうちテールのRoverの受信がデータ落ちが３０－５０％も発生する場合があることがわかったのが
３月にはいってからで、あまりにもやることが多すぎて、Teensｙ4.1でもデータ落とさざるを得ないので、仕事を減らしてやる対策を
とってきました。
●CPU負荷軽減対策
対策１：Baseからのデータ量１Kbyte/epochを172byte/epochに減らしました。NAV-SATを無くしたので、衛星受信状態のログができなく
なりましたが、衛星受信状態が悪かろうか好かろうがあまり測定には反映されないので、無くても良い仕様でした。
対策２：Teensy4.1のハードウェアシリアルは、データ量が多くて時間を食うシリアルデバイスに対しては、非常に有効な機能ですが、
バッファを大きくして更に複数個使うとSDライブラリーと干渉して、SD OPENエラーでSDログができなくなります。
そこで、３個もハードウェアシリアルを使わないで、２個にして、最後の３個めは、普通のSDライブラリにしました。
６４バイトで、SD書き込みしている間は、他のデバイス制御が止まるので、コンフリクトが発生することが３月にはいってわかりました。現時点では、F9P２個分の測定だけで、片肺稼働してます。
＝＞４月からは、２CPUにして、ひずみゲージアンプとIMU２個とBASEボードを１個ケース、Rover２個を１CPUで面倒を見る
構成に変更します。これなら、無理なく出来るはずなので、データ落ちなどなくなると思います。
システムに余裕を持たせておかないと来年以降に採用するX20Pチップの２５Hzログができなくなるので、２５Hzログ出来る余裕を
もたせたシステムにしておきます。
対策３：私のおっとりした滑りでは、速度も振動もないのでシステム実装をいじめてなかったのですが。
今回、横田様というプロテストライダー様に乗っていただいて、システム実装が脆弱であることが露見しました。
現象１：重い雪２０ｃｍをかき分けて滑る場合、アンテナは雪に埋もれると特にテールのアンテナが埋もれる。
＝＞雪で重れる滑走だとテールは完全に全滅となる。トップも調子がわるい、センターは高い位置にあるので生きている
現象２：激しい振動で、BNO085がドリフトしたり周期が乱れてしまう。FUSIONアルゴリズムは、急な運動が向かないのは
BNO055で証明されていたのですが、やはりBNO085でも高速度での高振動では、狂ってしまいました。
RVCモードをやめてFUSIONとノーマルモードにして、I2Cで受信する方法に変更してみます、
現象３：ねじ類が全て緩んだ、１回滑走で、アンテナのネジとメインボックスのネジが緩んでいた、メインボックスにIMU
がはいっていたので、余計な振動を拾ってFUSIONが狂ったのかもしれない、センターアンテナ部のケースに引っ越します。
対策４：ログ操作、スマホでオンオフやるのがBlueTermでテキスト入力がやりにくいので、何らかのジェスチャーでスタートして
スタートの確認がすぐわかる方法を考えます。IMUの動作でジェスチャーを検出するアイデアだします。
●以後
次回が４月末に横田様にテストライド２回目をやっていただくので、急いで上記対策をおこないます。
