ALES契約は、1受信端末に1契約なので、スキー両足システムが2端末なので2契約になってしまうので、RTCMの分配機能をつくることにしました。
タイミング的に、F9Pの出力が125msecで、NTRIPからのRTCMが約1秒なので
どのCPUで受信させて、無線で同期配信すればいいか基礎データを測定しました。
RTCMは、非公開仕様なのでヘッダーが不明で、どこからデータが始まって終わるのかも意味不明です。そこで、受信データと時刻をログして、並べて観察して周期性のあるデータをとらえて観察しました。
※ＲＴＣＭ３をいじるのは時間の無駄です。
その後ＲＴＣＭ３の内容と受信送信タイミングを確認しましたが、F9Pの状態が一定ではないようで、Ｆ９Ｐに無線で送るプログラムを作っても数十分するとダメになったりして、安定してＲＴＣＭ３をＦ９Ｐへ送信できるのは、有線シリアル１１５２００ｂｐｓだけでした。ＲＴＣＭ３に時間と手間をかけすぎたので、肝心のＧＮＳＳ ＲＴＫの基礎学習がおろそかになってしまって、目的の達成が大きく遅延してしまったので、ＲＴＣＭ３をいじるのは、やめました。
●測定プログラム
NTRIP接続端末は、M5Atomでできているので、
そのシリアル出力をM5Stackにつないで、M5Stackで測定しました。
時間測定なので、途中でSerial.printをいれると数msec遅延してしまうので、一定時間で配列にデータと時刻をバッファして、一定時間経過後まとめて、Serial.printさせて測定プログラムを終了するようにしました。
https://gist.github.com/dj1711572002/af04e9344a425910ec296448410d3a29
●結果
①時間ーデータ数
約1秒毎に約500Byteのデータが受信されてます。
受信時間は、100msecかかってます。ボーレートは11520bpsです。
②データの詳細
1）ヘッダの文字探し
1秒間隔で最初にくるByteをFILTERすると
０ｘｄ３がプリアンブルだそうです。d3,予備,データ長
0xｄ３+予備(6bit)+データ長(10bit)+本データ＋CRC(24bit）なので
データ長＋6バイトが全バイト数となります。0xd3は、ヘッダ以外にデータ中にも存在しているので、ヘッダの確定には、0xd3をみつけたら次の2バイトからデータ数＋６＝全データ数を計算して、その数だけ読み込んで、最後のバイトの次に0xd3が来れば、そこまでで1本のRTCM3データが確定したとします。下記図で151バイト中にデータの最後から2番目に0xd３がでてるが、これはヘッダではないことが、全バイト数が判っていれば騙されない。
２）受信時間間隔
1秒周期のはずですが、960-1480msecとばらつきます。
データのサイズは、４８９Byteが基準ですが、
時々３０２Byteとかすくなくなったり、途切れて2分割で４８９Byteが送られてくる場合があります。結構いい加減です。
●以後
１つのCPUで
１：RTCM受信してF9Pに送る機能 １Hz
２：F9P MovingBase出力 ８Hz
を同時にできるか実験していきます。
※追記 詳細なRTCMシリアル通信の解析をしました。大変はまりやすい通信方法で、F9Pの欠点といえます。
