【RTK2021】F9PへRTCM入力するシリアル波形をオシロで観察してみた<RTCMシリアル通信はまりやすい>

M5Atomで新システムは全部組んだので、ALES NTRIP接続で得たRTCMデータを複数の端末に無線分配する方法をESP-NOWでやろうとして、ここ何日かトライしたのですが、F9PのRTCM受信タイミングを解析したので備忘録しておきます。
※F9P MovingBaseで最高速で使う場合、RTCMシリアル通信入力でのトラブルがたくさんありましたが、オシロで観察して判ったのはESp32系M5を使って、F9PへのRTCMシリアル入力は、非常にナイーブで、タイミング、シリアル波形レベルなど微妙な違いで、NO RTKになってしまいます。安定した条件が出たらそれを維持すべきで、ちょっとでも条件を変えるとすぐ NORTKになってしまうということです。
想定原因1:F9PをMovingBase125msec駆動すると、チップの限界能力になるためRTCM受信に割ける時間と処理に余裕がないため、シリアル信号の4M変動で、ころころとNORTKになってしまう。
=>無線でRTCMをF9Pへ入力する場合Xbeeの調子によって、NORTKになってしまうことがある。
=>ESP-NOWなどパケット通信だとRTCMタイミングがNTRIP受信時と違ってしまうため、NORTKしかでないので、パケットそのままF9Pに突っ込んでもダメでした。
=>RTCM通信のナイーブさを鑑みると無線は、リスクがあるので有線でマイコンシリアルからNTRIP受信したデータを有線でいれるのが最も安定、再現性が有ります。
想定原因2:M5系のシリアル通信が、複数のシリアルを使った場合、ノイズが多く、シリアル波形レベルが変化します。その外乱が、F9Pが限界状態にあるときに、NORTKの原因となってしまう。M5のプログラムで、一度安定したら、一行でもプログラムや配線を変更してはいけません。
(普通の使い方でM5系のシリアルは大丈夫ですが、高性能のチップを動作させるときに異常が発生しやすいです、今回F9Pではまりましたが、ひずみゲージアンプのAD7193,AD7194のSPI駆動でもはまったことがあります。)

●ESP-NOWとRTCMの相性の悪さ
ESP-NOWのパケットの最大サイズが255byteですが、RTCMの1回の受信パケットサイズは500BYTEを超えることがあります。ですので、分割してF9Pへ送信したのですが、
F9Pは、その分割されたRTCMを認識してくれないのでNO RTKのままになってダメでした。
あまりにもおかしいのでオシロで観察してみました。
オシロでトリガーエッジをとるためにdigitalWriteでHIGH,LOWいれて、TX波形を観察しました。
その部分のプログラムは下記です。
M5AtomでNTRIP受信してF9Pへ流す方法で、Serial2のTX波形をオシロで観察します。
setupにpinMode(25,OUTPUT);と定義しておいて、25ピンにHIGHLOWがでるようにしておきます。

void loop() {
// put your main code here, to run repeatedly:
while(ntrip_c.available()) {
digitalWrite(25,HIGH);//NTRIP IN
char ch = ntrip_c.read();
Serial2.print(ch); //Binary Send to grove
Serial.print(ch);
//Serial.print(“,”);//
// M5.Lcd.print(ch,HEX);
digitalWrite(25,LOW);//NTRIP OUT
}

2021年10月追記 千円台のロジアナで見たほうがベターです。
オシロでは、ノイズなどを見れるですが、通信データの確認は、ロジアナがよいです。
オシロは5万円以上しますが、千円台のロジアナでも結構使えるので、電子工作必携です。

【RTK21】RTKの無線化その2<Base出力をロジアナで見た>


●オシロ波形観察

①正常な受信波形
従来の使い方で、NTRIPに接続して受信したデータをそのまま有線でSerial2 TXで送信
青が、ピンのHIGHLOWでLOOPに入るとHIGH LOOPからでるとLOWです。
黄色がSerial2のTXですが、青と黄色がほぼ同じタイミングででてます。

 


上記の200msecを拡大20usecでみるとLOOPは、13usec付近で回っているみたいです。

②ESP-NOWでパケットで送信した場合
フレーム毎に分割してそのままばらばらと送信すると上記のNTRIP直接のように
きれいな束になってRTCMが送信されてませんでした。

上記を500msecを10msecに拡大すると
総通信時間は80msecで、正常時とあまり変わりがないのですが、波形が2分割されてます。これはESP-NOWのパケットのタイミング次第でばらつきますが、ほとんどが2分割になってでてきます。

③LOOP内での遅延、外乱でもNO RTKになる現象
たまたま、ログ表示で、Serial.print(data,HEX)をSerial.print(data)ノーフォーマットで
流したら、TeraTerm画面は化け文字だらけになるのですが、それとともに、F9PもNO RTKになってしまうという珍現象を発見しました。これもオシロで観察しました。
青のタイミングがGNDと3.3Vレベルに届いてない鈍った波形になってます。
それとともに、黄色のTXも多少ばらついてます。
ESP32かM5のどちらかがぼろいのは明白ですが、F9Pmo外乱に弱いと思います。

この程度の変化でF9Pは、NoRTKになってしまいます。
●考察
①F9Pは、RTCMの受信タイミングに非常に敏感であること判った。
通常のシリアル通信では、問題にならないような微妙な変化でもNo RTKになる。
現象1:RTCMデータが30msec遅れて2分割ではいるとNO RTKとなる
現象2:NTRIP受信して送信するLOOPでのちょとした外乱でNORTKになります。
例えば、M5系のみ使えるprintfを使うと NORTKになります。
Serial2.print(data);//F9Pへ送信
Serial.printf(“%x,”,data);//これをやるとNo RTKでダメだった

しかし、F9P送信後でも、Arduino の正規のprint命令

  Serial.print(data);
            Serial.print(“,”);//これなら、RTK OKになります。
これも、M5特有のシリアル命令を使ったりするとシリアル波形が乱れてNGになる
ということみたいです。F9Pでなければこの差を発見することはなかったです。

●結局、Xbeeに戻してみたが無線は有線より安定しません。
昨年、最初にF9PのRTCM送信をXbeeでやったきりで1年ぶりに戻して確認してみると
RTKになるにはなるのですが、マイコンから直接シリアル線でF9Pに接続する場合に比較して、FIX時間が遅くなるし、時々NORTKになったりして、やはり不安定になります。無線系は、アナログ電波の調子によって、通信速度がころころ変わるので、RTCMのタイミングばらつきが大きくなるため、どうしても有線シリアルよりたいRTCMタイミングがきれいにそろって入信できないので、無線では、ベストのRTCMを与えられないというのが結論です。これは、私のようなF9Pの限界ギリギリの速度で使った場合に見られる現象だと思いますので、1Hzとかゆっくりと測位する場合は条件が違ってくると思いますので、鵜呑みにしないでいただければ幸いです。

 

●CPU
どうも、ESP32かM5のシリアル通信の作りがヤバい感じがします。
mbedとかきちんとしたCPUでF9Pを動かしてみたほうがF9Pには良い感じがしました。
mbedも落ち目ですが、いずれもmbed Studioが使いやすくなったら戻ろうと思います。

 

 

コメントを残す

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