M5Atomで新システムは全部組んだので、ALES NTRIP接続で得たRTCMデータを複数の端末に無線分配する方法をESP-NOWでやろうとして、ここ何日かトライしたのですが、F9PのRTCM受信タイミングを解析したので備忘録しておきます。
※F9P MovingBaseで最高速で使う場合、ＲＴＣＭシリアル通信入力でのトラブルがたくさんありましたが、オシロで観察して判ったのはESp32系Ｍ５を使って、Ｆ９ＰへのＲＴＣＭシリアル入力は、非常にナイーブで、タイミング、シリアル波形レベルなど微妙な違いで、NO RTKになってしまいます。安定した条件が出たらそれを維持すべきで、ちょっとでも条件を変えるとすぐ ＮＯＲＴＫになってしまうということです。
想定原因１：Ｆ９ＰをMovingBase１２５msec駆動すると、チップの限界能力になるためＲＴＣＭ受信に割ける時間と処理に余裕がないため、シリアル信号の４Ｍ変動で、ころころとＮＯＲＴＫになってしまう。
＝＞無線でＲＴＣＭをＦ９Ｐへ入力する場合Ｘｂｅｅの調子によって、ＮＯＲＴＫになってしまうことがある。
＝＞ＥＳＰ－ＮＯＷなどパケット通信だとＲＴＣＭタイミングがＮＴＲＩＰ受信時と違ってしまうため、ＮＯＲＴＫしかでないので、パケットそのままＦ９Ｐに突っ込んでもダメでした。
＝＞ＲＴＣＭ通信のナイーブさを鑑みると無線は、リスクがあるので有線でマイコンシリアルからＮＴＲＩＰ受信したデータを有線でいれるのが最も安定、再現性が有ります。
想定原因２：Ｍ５系のシリアル通信が、複数のシリアルを使った場合、ノイズが多く、シリアル波形レベルが変化します。その外乱が、Ｆ９Ｐが限界状態にあるときに、ＮＯＲＴＫの原因となってしまう。Ｍ５のプログラムで、一度安定したら、一行でもプログラムや配線を変更してはいけません。
（普通の使い方でＭ５系のシリアルは大丈夫ですが、高性能のチップを動作させるときに異常が発生しやすいです、今回Ｆ９Ｐではまりましたが、ひずみゲージアンプのＡＤ７１９３，ＡＤ７１９４のＳＰＩ駆動でもはまったことがあります。）
●ESP-NOWとRTCMの相性の悪さ
ESP-NOWのパケットの最大サイズが255byteですが、RTCMの1回の受信パケットサイズは５００BYTEを超えることがあります。ですので、分割して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年１０月追記 千円台のロジアナで見たほうがベターです。
オシロでは、ノイズなどを見れるですが、通信データの確認は、ロジアナがよいです。
オシロは５万円以上しますが、千円台のロジアナでも結構使えるので、電子工作必携です。
●オシロ波形観察
①正常な受信波形
従来の使い方で、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と３．３Vレベルに届いてない鈍った波形になってます。
それとともに、黄色のTXも多少ばらついてます。
ESP32かM5のどちらかがぼろいのは明白ですが、F9Pmo外乱に弱いと思います。
この程度の変化でF9Pは、NoRTKになってしまいます。
●考察
①F9Pは、RTCMの受信タイミングに非常に敏感であること判った。
通常のシリアル通信では、問題にならないような微妙な変化でもNo RTKになる。
現象１：RTCMデータが30msec遅れて2分割ではいるとNO RTKとなる
現象２：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年ぶりに戻して確認してみると
ＲＴＫになるにはなるのですが、マイコンから直接シリアル線でＦ９Ｐに接続する場合に比較して、ＦＩＸ時間が遅くなるし、時々ＮＯＲＴＫになったりして、やはり不安定になります。無線系は、アナログ電波の調子によって、通信速度がころころ変わるので、ＲＴＣＭのタイミングばらつきが大きくなるため、どうしても有線シリアルよりたいＲＴＣＭタイミングがきれいにそろって入信できないので、無線では、ベストのＲＴＣＭを与えられないというのが結論です。これは、私のようなＦ９Ｐの限界ギリギリの速度で使った場合に見られる現象だと思いますので、１Ｈｚとかゆっくりと測位する場合は条件が違ってくると思いますので、鵜呑みにしないでいただければ幸いです。
●CPU
どうも、ESP32かM5のシリアル通信の作りがヤバい感じがします。
mbedとかきちんとしたCPUでF9Pを動かしてみたほうがF9Pには良い感じがしました。
mbedも落ち目ですが、いずれもmbed Studioが使いやすくなったら戻ろうと思います。
