【STA23】SDLOGデータをBlueToothでアップロードする機能追加＜遅い＞

実際にフィールドで、実験するといろいろな課題が出てくるので、毎回改善していきます。
両足での実滑走実験一回目は、散々でした。WIN10タブレットが2CHのBlueToothを受信ログしているとハングしてしまうので、しょうがないので、2個のAndroidスマホでBlueTermで左右別々にログしたのですが、旧機種で遅いので、データ落ちがひどくて、全体の分tあ何等かの異常が発生してしまいました。
●２CHBlueToothログがコケる原因
原因：受信端末のCPU能力が低い
＝＞corei5の大型タブレットやノートＰＣでは、２ＣＨ同時ログも全然問題なかったのですが、
手持ちのＷＩＮ１０タブレット　Fujitsu ArrowsTab Q335/kでは、インテル® Atom™ Z3735Fで
処理能力が不足でした。

対策：目的は、滑走開始と滑走直後にシステムの正常確認とログ操作ですので、全データをリアルタイムモニターする必然性は、ありません。そこで、120msec毎に全データを受信ログする方法をやめて、1200msecに一回データを受信する方法に変更します。このくらい遅くすれば、大丈夫ではないかと思います。

弊害：リアルタイムモニターで全データをログできていると、タブレットのログファイルだけで
ターン解析ができてしまうので、システムのＳＤカードを抜いて読み込む手間が無いので、
その場で、確認できるはずでしたが、間引いてモニターするので、不可となりました。

弊害対策１：
滑走直後にファイルをＣＬＯＳＥするときにＳＤカードにログしたてのファイルを
BlueToothでアップロードさせるやり方
＝＞データが重すぎて、１０分のデータをアップロードするのに、8分近くかかってしまいました。
だいたい、824Byte/120msecなので、１秒間に6.97kByteです。SPPで11.52Kbbyte/secで転送しているので、
実時間の6.97/11.52=６０％も転送時間がかかってしまうという非実用的なことになります。
弊害対策２：
F9Pのバイナリーメッセージ全部をまるごと転送しようとするので、１エポック824byteと巨大になってしまうので
マイコンで、必要なデータ加工をしてしまって、解析に使うのに必要なデータのみを転送する方式に変更しました。そうすると、208Byteまで圧縮できました。上記１のデータの４分の１の時間で転送できることになります。
だいたい、実ログ時間の15%程度時間がかかります。スキー滑走１本１０分で、滑走後にデータをアップロードする時間が、１－２分ならなんとかいいかという感じです。リフトに乗っているときにアップロードすればいいかもしれません。下記実験では、実測定時間18secのファイルをアップロードで2.772secで１５％となってます。

●プログラム備忘録
単純なので、３時間程度でできました。
現在のFileをＯＰＥＮして、読みながら変換するだけです。
仕様：
SDカードのDIRを見ながらファイルを選ぶCHOOSER機能は、面倒なので、ログ終了と同時にアップロードをして、アップロード終了したら、プログラムをRESETとして初期状態に戻して、ログファイルのDIRを送信するという仕様にしました。
方法：
読み込みながら、バイナリデータを実数データに変換してバッファ配列に記録していきます。バッファ配列は、シリアル受信と同じものを使っているので、あとは、モニター送信関数に
渡せば、フォーマットを整えて、BlueTooth送信してくれます。

操作：
アップロード機能は、SDログ中に uキーを押すとアップロードを開始します。teratermでも認識できるように
ASCIIデータとして加工して見えますので、その場で、データが全部アップロードされたから確認できます。
https://gist.github.com/dj1711572002/a0985e0fab4d0fc0a186445a823e9d3c