※本記事２０２０年１月初心者のころのシステムなので最新システム(2022)をご覧ください。
F９P接続システムは、現在では、Arm Cortex-M7ＣＰＵ(Teensy.1)を使用してシステムを組んでます。
F9Pは、特殊なチップなので、出力タイミングのばらつきが多く、データログプログラムを完璧にするのに
２年半かかってます。本記事のシステムだと１％くらいデータ落ちがありますが、最新システムだと３シグマ以下に管理されてます。そのために、Teensy4.1を使ってます。
シリアル通信で460800bpsが必要なのは、MovingBaseモード仕様の場合で、Base-Rover間通信だけです。
他は、115200bpsでデータ通信すれば大丈夫です。無線はデータ落ちがあるので、マイコンにＳＤカードを内蔵してデータをログしないと危険です、無線は、測定時のモニター用で使ってますが、Ｘｂｅｅは、モニター用としてもデータ落ちが多く使えませんでした。現在は、モニター用にWiFiのESP-NOWとBlueToothだけ使ってます。
Teensyを使った最新システムの作り方のカテゴリーはこちらです。
http://shinshu-makers.net/shinshu_makers/?cat=53
※２０２１年３月末追記
本記事は、１年前の記事ですが、当時は、F9Pの出力レートを460800bpsにしないといけないと勘違いしていたので、ずいぶん無駄な苦労をしてしまいました。
現在では、115200bps出力で受信できるので、普通のマイコンでも処理できてます。ですので、NucleoF446Reのような高性能マイコンを必要ありませんが、
ArduinoUNOでは無理です。ARM coreTEX M３以上、ESP32以上の処理能力は必要です。
２０２１年版の最新システムはこちらの記事です。２セットのRTKキットからのデータをログしてます。
4日前にＸｂｅｅでの送信はボーレート460800bpsが無理なので断念しました。
しかし、ＲＴＫの場合は、通常のマイコン計測に比較して200msecに一回しかない超遅いシステムです。何とかなりそうなので実験してみました。
この理由は、Ｆ９ＰのＣＰＵが大きな行列式を計算している時間がほとんどで、通信するためにＣＰＵの時間を割けないという理由から、MovingBaseモードでは200msecサンプリングではボーレート460800bpsで出力しないと計算が間に合わなくなるということと理解してます。(MobingBase アプリ仕様書）
そういう理由なら、Ｆ９Ｐが計算している時間を使ってゆっくりと無線送信してやればいいのではとアイデアが浮かびました。
※４月１日記
最近、この現象を再確認したのですが、ＲｏｖｅｒのSimpleRTK2BのＵＡＲＴ１を１１５２００ｂｐｓに変更してもＦＩＸ精度は460800bpsと変化は発生しませんでした。
たぶん、本記事を書いた時の実験で、ＵＡＲＴ２を１１５２００ｂｐｓに変更してしまったので、一挙に精度が低下したのではないかと推測します。
つまり、MovingBaseモードでは、460800bpsにしないといけないのは、Base-Rover間の
ＲＴＣＭ３通信速度が必須であって、Ｒｏｖｅｒの出力速度は１５２００ｂｐｓでもよいということです。４６０８００ｂｐｓで出力をマイコンで受信しているのですが、
マイコン内で、マイクロＳＤカード書き込みしたり、ＮＡＶ－ＰＶＴとＲＥＬＰＯＳＮＥＤの値を実データ値に変換してスマホにＢＴ送信したり計算処理してますので、１１５２００ｂｐｓで受信していると200msec周期でのデータ落ちリスクがあるので、やはりログするマイコンは４６０８００ｂｐｓのほうがよいので、現在のシステムはこのまま使っていきます。ＳＤカードにフルログを保存しておけば、後日ucenterで完全に再現できるので
詳細な解析ができるので、性能のよいロギングシステムを組んでおいたほうがお得だと思ってます。
●アイデア
「F9Pからの460800bps送信データをマイコンでバッファしてからＸｂｅｅで230400bpsでゆっくり送信する」
●課題１：UBXのバイナリーで1回のサンプリングデータをバッファする方法
ＭＢモードの出力は、UBXのみで、２つのセンテンスだけです。
UBX-NAV-PVTとUBX-NAV-RELPOSNEDです。
ucenterのView-Packet-Consoleで観察してみると
ＰＶＴが100バイト、RELPOSNEDが72バイトしかありません。
オシロでみると10msec以下で送信してました。
200msecなので、あとの190msecは、F9Pの計算時間みたいです。
その間にゆっくりとＸｂｅｅ送信すればいいということです。
シリアルのreadableのフラグをみてみたのですが,Ｆ９Ｐが200msec間ずっと上げていて、利用できません。そこで、上記172バイトをカウントしながら受信することにしました。
●460800bpsは、マイコンのＵＡＲＴ性能では厳しい
手持ちのマイコン３個で受信実験したのですが、
小型のNucleo L432KCは、全然受信できませんでした。
中型のLPC 1768は、受信がほぼできるのですが、読み間違いが発生する。
17byteが余計なセンテンスがはいってしまってます。
この場合、ucenterは、時間がずれてしまってＮＧです。
大型のNucleo F446REで何とか無事受信してＸｂｅｅ送信できました。
■マイコンのＵＡＲＴ性能
トータルした速度が高くないとダメみたいです。
小型では、高速ＩＦの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 | 〇 |
※ESP３２のほうがクロックが高いので、いいかと調べてみましたが、ＵＡＲＴの本数が少ないのと高速送受信した記事がなかったので、実績がなさそうなのと仕様書の記述が上記ＣＰＵのようにきちんと
記述されていない点で、ＥＳＰ３２は、使いませんでした。
ＬＰＣ１７６８では、下記のように17バイトの行が紛れ込んでます。
エラーが発生してます。
NucleoF446REでようやくもともにＸｂｅｅ送信できました。
●プログラム
Ｆ９Ｐ Roverから172バイトを受信して、Ｘｂｅｅへ127バイト送信するだけなので、単純でしたがこれができるようになるのに2日試行錯誤しました。バイト配列 bData[]に172バイト格納した直後から、Ｘｂｅｅへ送信開始します。時間的には、100msec以上空き時間があるはずなのですが、
実際は余裕があまりなくて、ちょっと、printf文をいれる、受信データがおかしくなってしまいます。ＣＰＵのクロックとＵＡＲＴの高速性に頼ったプログラムですので、いかに高性能のＣＰＵを使うかで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まで大きくなると思ってませんでしたが、Ｆ９Ｐは、周辺のマイコンも高性能で規模の大きいものを要求してきます。今までのArduinoなどmbedでは、歯が立たなくなりそうなので、ＰＣベースで処理したほうがいいと感じてます。RASPIは、ucenterが動作しないので、使いにくいと思います。Ｔｅｅｎｓｙ３．２を仕入れてあるので、Ｔｅｅｎｓｙでできればサイズ的には実用的なので、後日実験してみます。
