※２０２４年初夏　ubloxはRTK事業で失敗したようです、ZED-F9Pは製造中止になるかもしれません。
=>心配なので、Ardusimple社に問い合わせたら、ZED-F9Pはあと５年以上供給するとの回答を得たので一安心しました。

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

読者の皆さんに問いかけたいのは、あなたの行動は、コト作りを前提としたモノ作りになってますか？　です。

ALESの契約用にRTCMを受信するシステムを作るのですが、RTCMを受信してから、2つのF9P MovinBaseへ同時配信しなければいけないので、RTCMの受信パケットをRTCMのフレームに分解してESP-NOWで送信する方式を検討してます。そのため、RTCMのフレームの抽出の仕方 ESP-NOWだと250byteMAXなのでパケット全部一挙に送信できない不便さがありますが、ESP-NOWで行くという方針なので手間をかけてます。
を調査しました。

●ＲＴＣＭ触りたくないのですが
　ＲＴＣＭ規格は、有料仕様書を所有している人しか判りませんし、情報を公開してはいけないことになっているので、仕様の詳細を公開している資料はＷＥＢにはほとんどありません。ＲＴＣＭという団体が閉鎖的でダサい規格を維持してます、あと10年ももたないのではと思ってますが。とりあえず、ＲＴＫ機器はすべてＲＴＣＭで動いているので、使わざるを得ません。

●あちこちから教えていただいたＲＴＣＭの情報
国土地理院に、ＧＮＳＳ測量機器の解説資料をご紹介にあずかりました。
https://www.gsi.go.jp/common/000068240.pdf
このＰＤＦをダウンロードして、78ページにフレーム構造の図がありました。

プリアンブル8ビットは、０ｘＤ３です。、実際受信してあるＲＴＣＭデータをみると

2列目が予約６bitと3列目が10bitで合わせて2バイトですが、2列目がゼロなら3列目の数字がメッセージのバイト数になります。全フレームバイト数は、プリアンブル＋予約＋メッセージ長＋ＣＲＣ＝6バイト＋メッセージバイト数（3列目数値）上表の場合は、3列目が0x91＝hex2decして、１４５がメッセージ長で、＋6バイトで全長151バイトです
確かに151例目の０ｘ３３で終わっていて、次のフレームの０ｘＤ３がきてました。
ここで注意するのは、フレームの中に0xD3が何個も登場することがあるからです。ですので、騙されないように
総フレームバイト数を計算して、フレームの最後のバイトを確認して次に0xD3がきているれば、その頭の0xD3が本物のプリアンブルだと決定できるので、面倒な手続きをふまないとＲＴＣＭデータフレームを抽出できません。

※注意
0xd3だけで検出しても、万一フレーム内のメッセージデータに0x3dという数値がでてくるとミスリードするので、ヘッダーの3バイトから全フレーム数を把握して、ひと塊として管理していくことが重要みたいです。

メッセージデータ数は10bitなので、最大１０２３個あります。

※2021年5月追記
RTCM無線配信苦戦してます。基本から学習確認してますが、ＲＴＣＭの仕様書がないので
メッセージタイプＩＤを切り出すまでしかできません。2021年夏までには無線接続確実にしたいと思います。現在受信しているＲＴＣＭ３は、ＭＳＭ４の4個のメッセージであることがわかりました。

【RTK21】RTCM3をESP-NOWで送信検討＜RTCM無線配信＞

■試しに上記アルゴリズムでプNTRIP受信プログラムに、フレーム分解機能を追加してみました。

■NITRIPからのRTCMをフレームに分解して表示するサンプルプログラム
通常のNTRIP受信プログラムに追加したものですので、NTRIP受信プログラムを
動作させたことがある方ならお使いいただけますが、初めての場合は、何もないシンプルなNTRIP受信プログラムから学習しはじめてください。こちらです。

 GISTにアップしてあるので、M5AtomでM5StickC動作させてありますが、M5StickCでもM5Atomでも動作すると思います。
https://gist.github.com/dj1711572002/117354e2cbe66b181037c64de19d93db