3月に突入してしまいましたが、STA22全システムの構想図作ってみました。欲張りすぎて夏までかかりそうですが、野沢温泉スキー場のサマースキー場があるので、夏場でも測定できますので、のんびりやっていきます。
※進捗状況は、本記事の一番下に追記していきます。
0405 ：データ伝送方法をMTPにした
0407:信州SKYPARK実験１回目
●遅れている原因
①薄型ＢＯＸでＦ９Ｈを使いこなすのに、時間がかかった。仕様に迷いがあった。
②teensy4.1のUSB HOSTの基礎動作でトラブル多かった。
③当初の目的（高速化）から、直後に見られるクイックビューモニター開発に変更した。
④実験サイトの長野市引っ越しのための工事が２か月遅れて２月後半完成となった。（オミクロン、積雪）
＝＞新サイトでスキーベンドセンサーや重心位置フォースプレートの実験を行う予定が２か月遅れた。
●STA22特徴
特徴１：滑走直後に今の滑りを評価できるターン解析グラフィックが見られる（M5Core2,スマホ）
特徴２：測位の信頼性をブザー音で常時モニターして、測定精度の失敗を同時に知らせる。
特徴３：スキー板のMovingBase１対プラス重心位置に単独RTKキットを付加する。重心位置に関しては、力、変位センサなどで測定することに方針変更しました。
＝＞スキーターンにおける基本姿勢として重心位置をモニターする。
特徴４：板のたわみセンサー前後で、板のたわみ具合とターンと姿勢を同期モニターする。
特徴５：ブーツの角付け角度を測定して、ターンデータと同期させる。
●システムの名称と機能表
黄色塗りつぶし部分は、確認済みで実装へ進めますが、緑色は基本動作を確認しただけ、青色は、未着手。
こうみると１５％くらいしか出来てません、年末から初めて、３月で１５%なので４月、５月では無理なので
夏秋のサマースキーまでずっと延長する覚悟でやっていきます。
●日程
３月２１日までに長野市の新実験サイトへ引っ越します。そこから、活動を再開します。
来年以降は、３０分でスキー場にいけるので、大量の実験ができるようになります。
ーーーーー以下 その後のシステム開発のメモを備忘録として列記していきます。ーーーーー
※２０２２年４月５日追記
STA22では、データ欠落ゼロ品質をめざしてます。何故なら１０Hzと遅いサンプリングで、１個データが
欠けるとターンの重要なポイントを失ってターン解析ができなくなる可能性があるので、データ欠落ゼロに
する必要があります。
■STA開発で経験したデータ欠落発生原因
①アンテナノイズによる電波伝送障害
②RTKでのNTRIP受信障害
③F9P内での計算処理障害
④F9PからIF通信障害
⑤IFから無線通信での障害
⑥SDカードログでの障害
⑦ロガーCPUの障害
一番多いのが、⑤＞①＞②＞⑦です。
■⑤の無線データ伝送方式 無線と有線の使い分け対策案
⑤＝＞無線の信頼性にかかわるので、無線を使わなければいい、もしくは、無線は、モニター用にしか使わない
SDログを解析処理するときだけ、長いUSBケーブル経由で、データ転送を行うが、静止状態での転送なので
揺動ノイズなどはなく、一括転送なので、失敗しても再度転送できるので、被害が少なくて済む。
⑤＝＞足元のマイコンから長いUSBケーブルを足から胸まで通して、タブレットまで接続しておいて、測定終了時にSＤカードからＭＴＰモードを使って、一括データ閲覧解析を行う方式を採用することの決定した
【Teensy4.1】MTPモードでSDカード抜かずにWin10へマウント＜TyToolでPgm切替便利＞
⑤＝＞無線モニターは、受信状態監視パラメータと座標データだけをESP-NOWで無線通信してM5Coreで表示
■①GPS衛星電波受信対策案、常時監視して失敗を警報することで、測定失敗を避ける
①＝＞受信状態監視するために、FIX率をリアルタイムに表示、haccが３ｃｍ以上になったら警報ブザーを鳴らすなどGPS電波障害に対しては、警報を鳴らして計測の成否をその場で知らせることで失敗測定を防止する。
①＝＞ＲＡＷデータもＳＤログして、後日ＲＴＫの全状態を再現解析できるようにする
①＝＞アンテナ線を短くする、揺動を減らす、太くするなどして、足元にF9Pを設置することで、スキー板のアンテナ間距離を５０ｃｍ以内にしてある。アンテナ線も太いものにする対策する
■②NTRIPレシーバー障害、常時監視して失敗を警報することで、測定失敗を避ける
②＝＞NTRIPレシーバーの不調は、WiFiルーターの寸断が多いです、携帯電波状況の悪い場所をあらかじめチェックしてそこを使わないようにしたほうがいいです。特にスキー場上部が電波が弱いので、電波状態のチェックは重要です。
③＝＞flags値が６７未満になったら警報を鳴らす
■⑦ロガーCPUプログラムのタイミング不良
⑦＝＞ESP32系をやめてARM系Teensy4.1に変更する、SDカード書き込み速度がM5系より圧倒的に早いので
プログラムに余裕ができるので、ログ不良が少ない。
⑦＝＞Ｍ５ＳｔｉｃｋＣを加速度センサとモニター用無線モジュールとして使う
以上の構成をＳＴＡver0.１として、４月いっぱいで完成させて５月から実測実験開始する
———※２０２２年４月７日 信州SKYPARKで、第一回目実験 バグ発見—————————-
信州松本もようやく暖かくなってきたので、屋外実験を開始しました。
結果１：F9Hが動作しなくなった。延長アンテナ線が不良だったが、設定を初期化してしまって
再設定で、UART1のIn=none,Out=noneとしてなかったので、仕事が多すぎてRTK計算できなかった。
設定：UART2 In=RTCM3 460800bps out=none ,USB In=UBX Out=UBX としてUART1は全部none
結果２：基準局長野市のNC_NAGANO様で５１ｋｍ離れていても、４０秒で１ｃｍＦＩＸ
自宅では、１０分くらいかかっていたので、見晴らしの良い場所でないと実験できない。
結果３：STA22アナライザバグがあった。
■バグ１＝＞Teensy経由NAV-PVTとNAV-RELPOSNEDをUcenterでログしたファイルを
バイナリ読み込みしたら、１７０行目からB5,62,01,7のヘッダがなくなってしまった。
原因は、B5,62,01,0A UBX-MONセンテンスが混入していた。時々F9Pから勝手に混入があった。
Ucenter表示では、MONを無視して表示しているようで、今までMONが入っているのに気づかなかった。
STA22のプログラムのバイナリ読み込みを大幅に変更して、今まで１７２バイト毎に読み込んいたのを
B5,62,01,07のヘッダを検出してそこから１７２バイトを読み込んで、DGVに収納表示するアルゴリズムに変更
■バグ２＝＞測位精度確認のため、ＥＸＣＥＬでRELPOSHNの値をみたら２１０となっていた。
ＲＥＬＰＯＳＨＮは、ＲＥＬＰＯＳ値がｃｍ単位の整数に対して、小数点精度を表現する役割で、
-99～99*0.1mm単位で計算されるはずなので、２１０という値はでないはず。
RELP_trans()をみると、バイト値そのものだったので、int8に変更int(Byte-128)と修正
結果４：Teensyプログラムバグ
■バグ１＝＞Teensy SDログファイルをみると、200msec周期でログされていて、抜けてしまっていた。
新規エポックが発生したときだけＳＤログするようにif文をいれたつもりだったら、そうは動作してない。
今週中にバグ修正する。
結果５：Ｆ９Ｈｎｏフィールド測定初めてなので、アンテナを１ｍ丁度の板材に固定して振り回してみた。
真北に設置するとPOSN=1m POSE=0mとなる真東だとＰＯＳＮ＝０ｍ POSE＝１ｍとなる。
結果６：精度検証は、上記バグがあるため第二回で測定検証する。
——-2022年４月２０日———————————–
デバッグほぼ完了、次回からは、シリーズ記事として、STA22のPhaseⅠとして記事にしていきます。
①Ｆ９Ｈときどきつまづく
測定中に次第にデータ抜けが増えてくる現象miscount値をモニターしながら解析した
RoverのF9Hが時々狂って周期が200msecに落ちてしまうことが発生して、データ落ちが発生する
BaseのF9Pは、常に平常ですが、F9Hが時々狂う現象があるので、ucenterに接続して、再度設定しなおすと治りますが、通電オフして、翌日電源オンしたときに狂う現象が見られます。毎回起動前にチェックして、いったん起動したら電源を落とさないようにすれば、狂うことはないので、恒久対策ができるまでは、電源常時オンで逃げます。
②無線モニターで表示する監視データをそろえた。
③フィールドでの、激しく動いた場合のＵＳＢＨＯＳＴの接触不良などの試験を始めます。
