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

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

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

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

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

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

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

 

 

コメントを残す

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