●ここ３カ月の経緯
パワーメーター２０１９テーマでは、ここ３年適当に開発してきたパワーメーターの実験評価精度と信頼性を高めることを留意してここ３カ月進めてきております。SeatTubeのひずみ波形とクランクのトルク波形との相関性を精度と信頼性を管理した状態で、比較して、SeatTube型パワーメーターの客観的評価を決定するのが、９月末までの目標です。
●クランクのＸｂｅｅからの通信データの異常
現象１：クランク角度をIMUで重力加速度から計算しているのですが、左右で位相がずれてしまう現象がある
現象２：クランクデータにタイムスタンプをつけてＸｂｅｅで送信しているのですが、タイムスタンプの時刻データの周期がばらついて、累積して位相ずれが大きくなる現象
●長時間測定で発見した現象
電池寿命を測定するため７時間連続で、ＣＰＵ基板からＸｂｅｅでタイムスタンプとデータ連番を送信してTeraTermで受信ログする実験をしました。
①電池寿命試験のデータ
７時間持ったデータの周期とデータ欠落のグラフ
※4msecで７時間ログするとデータ行が630万行にもなってしまって、個々のデータを見てられないので、
１秒毎に間引いて、グラフにしました。4msecで割り込み送信しているＰｇｍから、周期ばらつきとデータ欠落数をプロットしたものです
結果１：が、周期は時間とともに階段状に遅くなっていく傾向があります。
結果２：データ欠落数も累積して12000秒経過で１０万個にも達していてとても、10万データ/630万データ=1.6%欠落がある点で
数％の精度を判断する積分処理の精度にも悪影響があります。
②マイコンのDC3.3V供給
結果３：安定した電源から供給すると欠落データ数が12000秒後でも３万個程度で電池駆動の場合より30%に激減した。
結果４：周期の遅延傾向は同じく発生している。
③Xbee通信をやめてＵＳＢシリアルで測定
結果５：データの欠落はゼロでした。
結果６：周期の遅延傾向は、上記２条件とも同じ傾向
●周期の遅延の解析
１秒毎のデータで、生の4msecのプロットではないので、生データを見てみると、4msec周期と5msec周期が混在していてデータ時間経過とともに5msec周期が増えてきて全体として遅延していくことが判りました。
結果７：ＵＳＢシリアルでは、遅延は1500秒以降は累積してないので、一定値で落ち着いている。
＝＞周期の遅延は、Ｘｂｅｅの送信とは別にＣＰＵの割り込み精度の可能性もあるため別途解析する
●Xbeeで１１５２００ｂｐｓ通信データは信頼できるのか？
検索すると ねむいさんのブログ記事がありました。
http://nemuisan.blog.bai.ne.jp/?eid=160036
なんと、Ｘｂｅｅでは１１５２００ｂｐｓでは欠落が多くて使えないからフロー制御が必要だと書いてありました。
フロー制御無しで使えるのは19200bpsまでが確実だそうです。
●HardwareFlow制御を試してみた
作業１：Xbeeの設定をＸＣＴＵでＦＬＯＷ制御有に設定
作業２： XbeeのＣＴＳをマイコンのＲＴＳ、ＸｂｅｅのＲＴＳをマイコンのＣＴＳに接続
作業３：マイコン側プログラムにＦＬＯＷ制御文をいれる
pc.set_flow_control(Serial :: RTSCTS,PA_12,PA_11);//rts、cts
●最悪条件でどうなるか電池駆動Ｘｂｅｅ送信で１時間だけ測定してみました。
結果８：データ欠落数は、フロー制御無しでは、１２０００秒間で１０万個だったのが、フロー制御有では、４０００秒間で９千個まで減ったので比例していると考えると1/3程度(0.5%)に減って、マイコンＤＣ電源並みにデータ欠落が激減しましたが、ＵＳＢシリアルのようにゼロにはなりませんでした。HardwareFlow1制御しても絶対的な対策にならないことが判りました。
●以後
電源のバラツキとフロー制御で高速データ通信の精度と信頼性を確保しようとしてますが、未だ不足があることが判りました。
Xbee無線通信で１１５２００ｂｐｓ高速転送する場合のデータ欠落は必然的に発生するという認識を得ました。
①アナログ無線の感覚で、アンテナと距離位置関係などを気にして、通信の信頼性を設計していかないとこれ以上は無理かと思いました。
※２０２０年８月記
Xbeeの高速データ通信信頼性が悪い点で、他の方式を
模索した結果２０２０年度からはWiFi系のESP-NOW規格を採用することで、ここ３年苦労してきた無線の課題を全部クリアーすることができました。
