【L-RTK】MBモード460Kbps出力をXbee無線230Kbpsでucenter動いた<NucleoF446Re必要>

4日前にXbeeでの送信はボーレート460800bpsが無理なので断念しました。
しかし、RTKの場合は、通常のマイコン計測に比較して200msecに一回しかない超遅いシステムです。何とかなりそうなので実験してみました。
この理由は、F9PのCPUが大きな行列式を計算している時間がほとんどで、通信するためにCPUの時間を割けないという理由から、MovingBaseモードでは200msecサンプリングではボーレート460800bpsで出力しないと計算が間に合わなくなるということと理解してます。(MobingBase アプリ仕様書

そういう理由なら、F9Pが計算している時間を使ってゆっくりと無線送信してやればいいのではとアイデアが浮かびました。
※4月1日記
最近、この現象を再確認したのですが、RoverのSimpleRTK2BのUART1を115200bpsに変更してもFIX精度は460800bpsと変化は発生しませんでした。
たぶん、本記事を書いた時の実験で、UART2を115200bpsに変更してしまったので、一挙に精度が低下したのではないかと推測します。
つまり、MovingBaseモードでは、460800bpsにしないといけないのは、Base-Rover間の
RTCM3通信速度が必須であって、Roverの出力速度は15200bpsでもよいということです。460800bpsで出力をマイコンで受信しているのですが、
マイコン内で、マイクロSDカード書き込みしたり、NAV-PVTとRELPOSNEDの値を実データ値に変換してスマホにBT送信したり計算処理してますので、115200bpsで受信していると200msec周期でのデータ落ちリスクがあるので、やはりログするマイコンは460800bpsのほうがよいので、現在のシステムはこのまま使っていきます。SDカードにフルログを保存しておけば、後日ucenterで完全に再現できるので
詳細な解析ができるので、性能のよいロギングシステムを組んでおいたほうがお得だと思ってます。

●アイデア
「F9Pからの460800bps送信データをマイコンでバッファしてからXbeeで230400bpsでゆっくり送信する」

課題1:UBXのバイナリーで1回のサンプリングデータをバッファする方法

 MBモードの出力は、UBXのみで、2つのセンテンスだけです。
UBX-NAV-PVTとUBX-NAV-RELPOSNEDです。
ucenterのView-Packet-Consoleで観察してみると
PVTが100バイト、RELPOSNEDが72バイトしかありません。
オシロでみると10msec以下で送信してました。
200msecなので、あとの190msecは、F9Pの計算時間みたいです。
その間にゆっくりとXbee送信すればいいということです。

シリアルのreadableのフラグをみてみたのですが,F9Pが200msec間ずっと上げていて、利用できません。そこで、上記172バイトをカウントしながら受信することにしました。



●460800bpsは、マイコンのUART性能では厳しい
手持ちのマイコン3個で受信実験したのですが、
小型のNucleo L432KCは、全然受信できませんでした。
中型のLPC 1768は、受信がほぼできるのですが、読み間違いが発生する。
17byteが余計なセンテンスがはいってしまってます。
この場合、ucenterは、時間がずれてしまってNGです。
大型のNucleo F446REで何とか無事受信してXbee送信できました。
■マイコンのUART性能
トータルした速度が高くないとダメみたいです。
小型では、高速IFのTeensyが使えるかもしれないので、後日試してみます。

試したマイコン CPU Clock UART速度 460800bps受信
Nucleo L432KC Cortex M4 80MHz Max  204Kbps ×
LPC 1768 Cortex M3 100MHz Max 6.25Mbps
Nucleo F446RE Cortex M4 180MHz Max 5.12Mbps

※ESP32のほうがクロックが高いので、いいかと調べてみましたが、UARTの本数が少ないのと高速送受信した記事がなかったので、実績がなさそうなのと仕様書の記述が上記CPUのようにきちんと
記述されていない点で、ESP32は、使いませんでした。

LPC1768では、下記のように17バイトの行が紛れ込んでます。
エラーが発生してます。

NucleoF446REでようやくもともにXbee送信できました。

 

●プログラム
F9P Roverから172バイトを受信して、Xbeeへ127バイト送信するだけなので、単純でしたがこれができるようになるのに2日試行錯誤しました。バイト配列 bData[]に172バイト格納した直後から、Xbeeへ送信開始します。時間的には、100msec以上空き時間があるはずなのですが、
実際は余裕があまりなくて、ちょっと、printf文をいれる、受信データがおかしくなってしまいます。CPUのクロックとUARTの高速性に頼ったプログラムですので、いかに高性能のCPUを使うかでMovingBaseの精度がきまります。

#include “mbed.h”
#include “SDFileSystem.h”
Serial pc(USBTX,USBRX);
Serial F9P(PC_6,PC_7);;//F9P uart1 TX,RX-F446RE Serial6 TX,RX 5.62MHz
Serial Xbee(PA_9,PA_10);//Xbee TX,RX F446RE Serail TX,RX 5.62MHzDigitalOut myled(LED1);int i=0;
unsigned char c;
unsigned char bData[10000];int main() {
pc.baud(460800);
F9P.baud(460800);
Xbee.baud(230400);
while(1){
if(F9P.getc()==0xb5){
bData[0]=0xb5;
for(i=1;i<172;i++){
bData[i]=F9P.getc();
}
for(i=0;i<172;i++){
Xbee.putc(bData[i]);
}
}
}
}

 

●以後
NucleoF446Reまで大きくなると思ってませんでしたが、F9Pは、周辺のマイコンも高性能で規模の大きいものを要求してきます。今までのArduinoなどmbedでは、歯が立たなくなりそうなので、PCベースで処理したほうがいいと感じてます。RASPIは、ucenterが動作しないので、使いにくいと思います。Teensy3.2を仕入れてあるので、Teensyでできればサイズ的には実用的なので、後日実験してみます。

 

コメントを残す

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