【L-RTK】F9P_Xbee経由でのRTCM3データ初めて見た＜バイナリーで化け文字＞

RTK通信のデータフォーマットはRTCMフォーマットというものを使うらしいので、u-centerの設定どおりにデータが送られているかを確認してみました。
※２０２４年初夏　ubloxはRTK事業で失敗したようです、ZED-F9Pは製造中止になるかもしれません。
=>心配なので、Ardusimple社に問い合わせたら、ZED-F9Pはあと５年以上供給するとの回答を得たので一安心しました。
Ardusimple社の製品を使っていて良かったです。

【RTK】Ublox異変＝＞F9P終わって、NEO-F9Pに移行L1-L5のみ＜事業存続の危機か＞

◎RTCM3は、基準局からNTRIPサーバ経由で送信される補正データですが、F9P初心者の一般のＲＴＫユーザーは、ブラックボックスで使えます。
①Ucenterをお使いなら、善意の基準局の設定すれば自動で受信できて、F9Pと同期されます。設定の記事はこちら
②マイコン経由でF9Pと同期させるなら、こちらの記事で、ライブラリとサンプルプログラムの使い方があります。ESP３２、M５系へコピペすればＯＫです。（Arduinoプログラムでライブラリを使ったセンサの接続経験がある方向けです）

———–これ以下は、一般ユーザーは知らなくてよい内容ですので、お忙しい方は、上記①②を実行すればＲＴＫ動作します。—————-
RTCM3をマイコンで受信して、F9Pに送信するタイミングが非常に難しいので、サンプルプログラムをそのまま使うことをお勧めします。
=>サンプルプログラムのprintをprintfに変更したらRTKが動かなくなるほどですのでいじったらいけません。

RTCM3データの500kbps以上の高速無線中継などは、GNSSのプロとか組み込み技術のプロでも厳しいです。ですので、これ以降の記事では、無線とかCPU間で通信してトライしたけど失敗した内容のものが多いので、以下の記事をご覧になっても時間の無駄です。私は、２－３年無駄しました。結局５年たってもサンプルプログラムのまま使ってます。
●何故ハマるのか＝＞RTK技術自体が、４M変動マージンが少ない技術ですので、初心者は必ずハマります。私はまともに管理できるようになるのに３年かかりました。ハマってどうしようもなくなったら、基板メーカーに聞いてみてください。信州MAKERSでは、Ardusimpleの基板を使っているので、SimpleRTK2Bでハマっている場合なら、回答できます。
RTKは、衛星電波受信環境に左右されやすいので（搬送波位相を測定しているので、マルチパス、電離層、気象条件で、受信状態がコロコロ変わります。ですので、街中など視界が悪い場所だと車載とか歩行はRTK計測できません）
実験時に最高の受信状態を作っておかないと、衛星電波の受信ばらつきでシステムのデバッグが不安定になって、何が何だかわからなくなります。以下がRTK受信の目安です。
RTK受信電波基準：40dB以上の衛星が１０個、50dB超えが数個あること

Ardusimple社のRTKアンテナ受信のガイドご覧ください

更に、F9P自体が、RTK計算能力が苦しいので、電波状態が厳しくなると、計算の遅延が発生して、マイコンからのRTCM３をうまく受信できない状態が発生したりします。NO RTKの発生課題は、こちらの記事に詳細があります。

※F9Pからの出力で、TeraTermなど汎用シリアルモニタで文字として見えるのはAscii形式の出力データだけです。NMEAは、ASCIIなので、見られますが、RTCMデータとUBXデータ(Ublox独自フォーマット）は、バイナリなので、TeraTermで見ると化け文字となります。
※2023年１２月追記：TeraTermでバイナリ受信データをHEX数で表示させる方法がありました。設定方法は、こちらの記事です。

基礎的な話しですが以外と面倒な点があって、これのせいでF9Pがとっつきにくい一因になってます。何故化け文字になるかというと、バイナリのデータは、バイトの始まり位置やデータの区切り、行の終わりに目印が無いので、それぞれのフォーマットに従った専用解析ソフト(ucenterとかRTKlib)で見るか、自分で解析プログラムを作る以外に文字データとしてみることはできません。私は、初めは、VBAでプログラム作ってバイナリーデータに慣れてから、ESP32,M5Stackのプログラム、次にVB.NETのプログラムを組みました。初めてから10か月くらいかかりましたので、気長に、F9Pと付き合っていく覚悟が必要です。しかし、私の記事を読みながら進めれば、２－３か月でできるのではないかと期待してます。プログラムができる方なら、私のソースコードを読んで、自分用にカスタマイズされれば、２ー３日で完成させることができると思います。
※NTRIP レシーバー(ntrip client)をお持ちの場合は、Ardusimple社で販売してますが、自作もできます。
u-centerにRTCM3出力を読み込ませれば、自動的に翻訳してくれます。
NTRIPレシーバーは、Arduinoでライブラリーをつかったプログラムを作ったご経験のある方なら作れます。
作り方はこちらの記事にあります。　ESP32,ESP8266とか、M5シリーズで動作できます。
u-centerでの見方は、レシーバーのＵＳＢシリアル出力をPCへ差し込んで、u-centerでポート番号とボーレート指定して接続すれば、
View-PacketConsoleで受信したRTCM3の内容がみれます。下図、私は内容は判りませんが、各衛星電波の補正データが入っているらしいです。

※Ｆ９Ｐ購入２年後の感想「RTCM3は、RTKの重要インフラです。」
しかし、中身は知らなくても十分RTKは遊べます。私は、全く内容を理解しないで4年間F9P使ってます。
インフラなので常時安定供給されないとRTKは成り立ちません。水道の蛇口がNTRIPレシーバーにあたります。自作で蛇口を作っても使っているうちに不具合が出てRTKできなくなりますので、高くても既製品でRTCM3の安定供給を獲得したほうがRTKライフは幸せになれます。RTCM3は、Ardusimple社のWiFi-NTRIP-Masterを購入するだけであとは何もしないのが一番時間と手間とストレスの無駄が無い方法です
※ＲＴＫ２ＧＯの基準局がダウンしている場合予備の基準局へ自動接続するプログラム作りました。
【STA24】RTK2GO基準局自動切換えPgm作った＜予備の基準局に自動切換え＞

※２０２２年１２月２日注記
善意の基準局でよく使われているNTRIP接続　rtk2go.comで接続方法に大変更がありました。
従来は、IDとパスはブランクよかったのですが、これからはIDに自分のメルアド、パスに none ４文字をいれる必要があります。詳細は下記記事をご覧ください。

【RTK22】RTK2GO.COMのNTRIP接続方法が変わった＜NC_NAGANO様に感謝＞

●RTCM3とは

米国に本部がある海洋RTCM(RadioTechnical Comission For Maritime Service)
という無線ナビゲーション技術の公益団体らしいです。ここで、世界の関係メーカーと学会など専門家委員が規格をきめているらしいです。
その規格の中で、RTCM3フォーマットが決められているそうです。
RTCMは、有償（$340)でしか仕様書を公開しないので、趣味人の購入は
割りにあいません。
⓪2022年３月追記　RTCM仕様書のコピーサイトがありました。そのうちLINK無くなると思いますがいまのうちに
ダウンロードすればお宝になります。
https://ge0mlib.com/papers/Protocols/RTCM_SC-104_v3.2.pdf
RTCMは、bit単位でデータを収納してあるので、デコードプログラム作りが面倒です。

①WEB公開されている一番詳しい資料は国土地理院のGNSS機器の規格に関する文書です。
https://www.gsi.go.jp/common/000068240.pdf
これの78ページあたりの基本的なRTCMフォーマット解説あります。

②もっと分かりやすい解説されているのがこちら様のブログ記事で感謝です。
https://blog.misatowater.com/entry/tech/ntrip/rtcm-basic

こちらの記事の画像を抜粋させていただきます。ヘッダーは0xD3,0x00,xXXで始まるそうですが、ストリーム配信で、NMEAとは違うフォーマットです。NMEAがASCIIで混在したバイナリなので文字化けに見えました。

※2022年６月追記　F9Pのデータ出力タイミングを測定しました。電波状況によって、演算量が大きく変化して
それに応じて出力タイミングがばらつきます。このようなチップなので、RTCM3を安定的に受信させるには、F9Pがどんな状態でもRTCM3を受信できるように、素早く送りつけることが重要です。MovingBaaseの場合、RTK計算で50-70msec食ってその後RTKデータ送信して、そのあとにRoverにRTCM送信していたら、全周期125msecのうち90msecくらい食ってしまいますので、そのあとからRTCM3を受信するので、タイミングとしては、非常狭いのでコケ易いです。

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

※2021年1月20日追記
RTCM3の解析してますが、F9PへマイコンでRTCM3を送信する場合は、注意しないとコケマス。

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

【RTK2021】RTCM3フレームの抽出法学習＜つかみどころがない規格＞

※MovingBaseでもＲＴＣＭ３は、使いますので、内容を調べてみました。ＮＴＲＩＰのＲＴＣＭ３に比べて通信速度が速くてタイミング余裕が数msecを競うシビアな使い方でのＲＴＣＭ３通信で、結局無線化は断念しました。

【RTK21】RTKの無線化その１＜BaseとRoverの通信内容＞

※２０２１年５月連休追記１年半後「ＲＴＣＭは触らないほうがいい」
本記事１年半前で始めたばかりの記事なのでXbeeを使ってますが、これは大失敗でした。
Ｘｂｅｅは、高速大容量通信では信頼性が著しく悪化して使えません。Ｘｂｅｅ参考記事BlueToothも多少ましですが、ＲＴＣＭ通信では、高速(115200bps)では信頼性が悪いです。
BlueTooth参考記事
最終的に有線シリアルが最も安定して信頼性がありますが、無線接続ならＷｉｆｉ系の通信しか残らないので難しくなるのですが、幸いＷｉｆｉ系でも簡単なプログラムで信頼性高速な規格ESP-NOWを使ってＲＴＣＭ無線通信を実現してます。事例記事
１年半の間ＲＴＣＭと悪戦苦闘しました。通常のマイコンだとＡＳＣＩＩデータをＣＳＶフォーマットで扱うことがほとんどなので、バイナリーでデリミタもＣＲＬＦもないＲＴＣＭ規格は、つかみどころがないデータフォーマットです。初心者の場合はいじらないほうがいいです。ucenterを使うか、既製品でＲＴＣＭを出力してくれる機器を使うのが無難ですが、滅多にありませんが最近仕入れた下記モジュールは便利で簡単です。

【RTK21】WiFi NTRIP MASTER凄く便利です＜超簡単なＮＴＲＩＰ接続＞　

ArduSimple社のSimpleRTK2B用のWiFi NTRIP MASTERが一番簡単です。
ＲＴＣＭの扱い方で、私のやり方をご紹介します。
①ＲＴＣＭファイルは、uint8_t型かchar型の配列変数に格納するのがいいです。
uint8_t data[600] もしくは　char cdata[600]とかです。RTCMは、500～600byteあります。
②目視したい場合は、Serial.print(data[i],HEX) ;の次にカンマをつけたほうが安全です。
　RTCMのヘッダが0xd3,0x00,データ数(例A1)と最初の３バイトをみつけるのに、
　カンマ無で出力するとD30A1と並んでくると0x00なのか0x0Aなのか見間違います。
　ＲＴＣＭ抽出の記事
③ログする場合は、バイナリーのまま保存します。ｃｓｖにする場合は自分のルールを
　決めておいて、使うときはバイナリに戻す必要があります。
④Ｆ９ＰへＲＴＣＭを送信するのは、連続して一括して送信しないとＲＴＫエラーになります。
　データ間で数十msec遅延があるだけでエラーになるので、Xbee,BlueToothで送信するとこけるので使わないほうがいいです。どうしてもXbeeとBlueToothを使いたい場合は、38400bps以下で
使わないとデータ落ちが防げません。ＲＴＣＭタイミングの記事

※2021年4月25日追記　＜RTK初めてから1年4か月経過して随分様子が判るようになって高度な測定ができるようになりました。＞
実際にフィールドでの測定で、RTKが正常かどうかを確認するのに便利なパラメータの監視方法があります。
①NTRIP接続が正常に稼働しているか、受信状態でＬＥＤを点滅させることが必要です。ＲＴＣＭデータ入ってこないで
ＲＴＫが異常になったのか、アンテナとＦ９Ｐ基板が異常でＲＴＫが異常になっているのか切り分けします。

②ＲＴＫが正常かみるには、UBX-NAV-PVTセンテンスのflagsパラメータが有効です。
floatになるとflags=67 Fixedでflags=131となります。67未満の数値はＲＴＫが異常であることをしめします。
この2か所を常に監視モニターしていれば、ＲＴＫが正常に測位できているか確認できます。
事例としてスキーターンアナライザーでの使い方を紹介してあります。
スキーのように激しい動きのある測定はハードソフト面で難易度が高いので、スキー測位ができるシステムは信頼性が高いです。

【STA】NTRIP&RTK監視機能追加とBOX固定位置変更＜アンテナ線揺動させてはダメ＞

※2021年1月8日追記
　本記事から1年後に、またRTCM3を分配配信しないといけなくなったので、学習再開しました。RTCMは、0xd3がプリアンブルですが、データ内にもたくさん0xd3が現れるので
先頭を探すのが大変です。私は、1Hz周期で受信されるので、1秒近く待った後に最初にくる0xd3が先頭という解釈でプログラムを作ってます。
自分が受信しているRTCMのサイズと時間を調べてみました。

【RTK2021】NTRIPからのRTCM3の受信データの観察＜結構ばらつく＞

●Xbeeから見た基準局からのRTCM3が化け文字になっている件
CR+LFデリミターでASCIIコードを見れば、通常は受信データ見えるのですがRTCM3だけは化け文字しかでなくて上記ブログの解説で納得しました。
実験：u-center[View-Messagesview-UBX-CFG-PRT]でXbeeがつながっているUART2の
出力データを[0+1+5-UBX+NMEA+RTCM3]と設定してSENDします。

これで、NMEAとRTCM３が混在したデータが基準局のXbeeから移動局のXbeeへ送信されるはずなので、移動局のXbeeをはずして、Xbee単体でXCTUに接続して受信データを見てみました。ＲＴＣＭ３は、バイナリーみたいです。NMEAの＄GPｘｘｘｘｘは、文字が見えるのですが、途中で化け文字群が現れます、これがRTCM3ではないかと
思って、上記ブログ記事を読むと、[D3,00,xx]がRTCM3のヘッダーだそうです。確かに、ありました。