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

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

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

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

 

F9PからTimePulseとUART1のTXからRTCM3をオシロにいれます。

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

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

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

2)MovingbaseからRoverへ送信されるRTCM3信号
RTCM3は1KByte以上あるので460800bpsで送信しても26msecもかかります。これがMovingBase通信のネックとなってます。

 

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

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

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

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

 

 

 

コメントを残す

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