【RTK22】F9P出力タイミングのリアルタイムからの遅延測定＜TimePulse出力重要＞

２０２２年度は、RTK　MovingBaseシステムとIMUなどのセンサとの同期を図ってます。
F9Pの出力とセンサのデータタイミングのリアルタイム同期できるのか測定してみました。
RTK　MovingBaseでは、計算が重いので、衛星電波受信してから結果がでるまで55msecほどかかってました。
ですのでマイコンで受信した時刻はリアルタイムから55msec遅れているので、システムのクロックとしては、採用できないので、F9PのTimePulseピンから正確なリアルタイム信号をマイコンで受信してシステム全体の時間管理しないといけないことが、判明いたしました。IMUとの同期もすべてTimePulseで統一します。
※その後、IMUデータと同時ログプログラム作成中ですが、F9P出力データが7１～77msec遅れる場合もありました。周期８Hzで125msecのはずが120msecになったりバラバラです。F９P側の都合とマイコン側のUSB HOSTのシリアル通信バッファの都合で受信タイミングはコロコロ変わるということを前提にシステム組まないといけないことがわかりました。Time Pulse起点でIMU時刻を管理しておけば、RTKの位置情報とIMUの位置情報を照合できるので、TimePulse信号をマイコンに引き込むことは必須です。

※IMUとF9P同期でタイムパルスの割り込み処理とインターバルタイマーではまりました。【STA23】BNO055測定 Interval Timerではまった＜Priorityと現合調整＞
内部のタイマーでIMU測定タイミングを発生させると、プログラムがややこしくなるので、
外部のRTCでクロックを作ってマイコンピン割り込みでIMUタイミング作るのがおすすめです。

●４CHオシロが便利
＝＞オシロがよい理由
・ロジアナより、タイミング全体から細部まで自在に即観察できる。
・プログラムのタイミングもdigitalwriteだけで見れるので測定遅延が気にならない。
RIGOL DS1054Zです。電子工作趣味の方にユーザーが多いです。４CHで画面が綺麗です。

F9PからTimePulseとUART1のTXからＲＴＣＭ３をオシロにいれます。

マイコンは、Teensy4.1を使っているのでピンに余裕がたくさんあるのでdigitalwroiteピンを出してオシロにいれます。

①タイミング遅延測定
1Ch:TimePulse
2Ch:マイコン受信ブロックIf文入口(Teensyのピン４１をdigital.write(41,HIGH)にしてif文最後でLOW）
3Ch:マイコン受信データログブロックif文入口(Teensyのピン39をdigital.write(41,HIGH)にしてif文最後でLOW）
4Ch:F9P UART1のTXピン(RTCM3を460800bpsでRoverへ送信する）

１）TimePulseからの遅延
TimePulseは、GPSの基準時刻で衛星の原子時計からの時刻なので並みいるNTPやRTCよりもはるかに精度の良いクロックです。１秒周期で100msecの矩形波が出力されます。この基準を受信してからF9PがRTK計算を実施するので計算時間とデータを出力する時間分、マイコンなど周辺機器が受信するタイミングは、リアルタイムから遅延します。MovingBaseモードの計算処理で55msec±5msecほど遅延がありました。さらに、Roverへ送信するＲＴＣＭ３は、マイコンへの送信が完了してから送信開始するので59msec遅れます。

２）MovingbaseからＲoverへ送信されるＲＴＣＭ３信号
RTCM3は１KByte以上あるので460800bpsで送信しても26msecもかかります。これがMovingBase通信のネックとなってます。

②マイコンプログラム処理のタイミング測定

３）USB HOST SERIAL受信部
TimePulseから55msec遅れて、バッファ満杯になったところで一挙に読み込んでいる。読み込み動作はμsecで完了していてDelayの3msec分の時間だけが見える。

４）受信データ　SD書込み処理
エポック受信が完了した時点をでデータをログ、変換してモニター送信をおこなう。
SDログは、BaseとRoverの２個のUBXファイルにしてあるので、OPEN-CLOSEを２回おこなう。
SD書込みが23msecもかかっているが、これは、使い勝手上の理由で遅らせてあります。
万一電源が落ちたりした場合、Closeをしておかないと、SDデータが消失してしまうため、
１データセットを書き込んだら直後にCLOSEするプログラム仕様にしてある。
弊害として、OPENしてからすぐCLOSEするとエラーがでるので、8msecdelay(8)をいれてあるため
トータルして22msecくらいが、ＯＰＥＮＣＬＯＳＥ処理とdelayで食っている。

＝＞せっかく、超高速CPUのTeensy４．１を使ってSdが遅いのももったいないので、改善しました。
あまりにも時間を浪費しすぎるので、１分に１回Closeする仕様に変更したら、
SD書込み２ファイルで３－４msecプラスモニター用TXTファイルも2msecで3FILEログできました。これなら、加速度センサーの測定を追加しても50Hz以上でサンプリングしてログできるので、便利になります、１分間に一回だけ周期が遅れるデメリットがありますが、RTKデータが欠落するわけでなく、加速センサーの１タイミングデータをロスするだけなので大勢に影響なしと判断します。