最近立て続けに、農業用トラクターの後付け自動操舵システム CHCNAV NX510 で同じご質問をいただいております。

内容はこのNX510 の示す精度表示がFIXしているにも関わらず徐々に劣化していき、しきい値を超えて停止するというものです。

問題はこのシステムがローバーで、弊社の受信機（またはu-blox製のGNSSモジュール）を基準局にした場合に起こります。

以下の内容は2022/10月に作成しました。これまで必要な方のみご案内していたものですが、お問い合わせが増えてきましたので公開いたします。内容はかなり細かな原因について調査しています。ユーザー様は対処方法のみご覧いただければと思います。

記事

ようやくこの問題に終止符が打てそうです。（FIXしてはいるが精度値が0.01づつ徐々に大きくなっていく問題）

弊社（松本市）にて現象の再現ができました。これはチャンスだと設定など変更を行わずにさまざまなログやデータの解析をおこないました。そして、NX510の精度が戻る瞬間に変わるデータを見つけることができました。

いろいろ矛盾していた、現象がすべて解明できました。

真の原因

問題は、RWSのRTCMに含まれる観測時刻にありました。 u-bloxのRTCMは内部クロックの誤差を修正した真の観測時刻をそのままRTCMに記載します。

そのため、1秒ごとの出力ですがピッタリの秒ではなく、0.999 1.999 2.999といったピッタリよりわずかにずれた時刻のRTCMを生成することがあります。このずれはクロックバイアスのリセットがあると.000になったりまた.999になったりします。

NX510のsystem.firmware.logに以下のような記録がありました。

[2022-09-18 03:11:35:085117][ INFO  ] dsm  check_rtcm_data 791 : [dsm] rtcm id is 1074, old time is 11560, rtcm32 time is 11560
[2022-09-18 03:11:35:085187][ INFO  ] dsm  check_rtcm_data 791 : [dsm] rtcm id is 1084, old time is 11560, rtcm32 time is 11560
[2022-09-18 03:11:35:085252][ INFO  ] dsm  check_rtcm_data 791 : [dsm] rtcm id is 1094, old time is 11560, rtcm32 time is 11560
[2022-09-18 03:11:35:086406][ INFO  ] dsm  check_rtcm_data 791 : [dsm] rtcm id is 1124, old time is 11560, rtcm32 time is 11560

これは前のRTCM時刻が11560(11560は週の始まりからの秒数です)で新しいRTCMが同じ11560であると言っています。これをさかいに精度値の変化が始まります。これは例えば 42.000 のあとに42.999のRTCMが来たときに起こります。小数点を切り捨てると同じ秒数を示してしまうからです。

トプコンなど受信機によっては、観測時刻がピッタリ .000秒でないとFIXしないものがあります。

しかし、NX510はそうではない様で、.001が.000になってもFIXも精度もそのまま持続しています。

しかしながら.000から.999になる場合はFIXは持続しますが、精度表示のみ徐々に劣化していきRWSの観測時刻が.000に戻ったときにNX510の精度が0.01に戻ります。

現象の動画

動画にはクロックバイアスの様子も入っています。事前に画面の説明をします。

精度表示

基準局クロックバイアス画面

RTCM時刻画面*1

では動画です。少しわかりずらいですが、クロックバイアスが -1000µ secになると同時にRTCM 時刻が毎秒 .000になり、NX510の精度が0.01に戻ります。

観測時刻が.000や.999になる理由

RWSのRTCMが000から.999になるのは受信機内部のクロックバイアスが-500µ秒(-0.0005秒)に達した際に観測時刻を変更するためです。さらにクロックバイアスが -1000µ秒になると観測時刻は.999 から .000に戻ります。

この周期は、40分ほどだと思っていましたが、実際は個体によって異なってくると思われます。原子時計の精度に近いほど周期が長くなります。

問題の無い例と問題のある例

RWSのRTCM時刻の変化のパターンによってNX510での問題の有無が変わってきます。12秒のRTCMと13秒のRTCMで例にとってみます。

12.000 --> 13.001 問題なし
12..000 --> 12.999 精度表示が徐々に劣化を示す
12..001 --> 13.000 問題なし
11..999 --> 13.000 問題なし

要するに、受信したRTCMの時刻の秒以下の端数を切り捨てて、直前に受信したRTCMの秒より進んでいればよいわけです。

参考までに、正バイアスのデバイスは、バイアスが500µSec以上になると下図のように RTCMは.001になります。

その後、1000µSecになると、バイアスはリセットされるとともにRTCMは.000になります。この変化の場合、NX510は特に問題ありません。

前述のとおり、NX510のRTKエンジンは、.000以外にも対応できていると思われます。問題は、.999のRTCMが出現したときにそのRTCMをNGであると判断してしまうことと、それに基づいた精度計算のみではないかと思われます。判断はNGですがRTKエンジンは（20分ほどでもFIXのままなので）計算に使用していると思われます。

RTCMのチェックをする際に、秒以下を切り捨てではなく四捨五入にするだけで治るのかと想定します。

RWS(u-blox)のRTKエンジンにはこのような問題はありませんのでどの組み合わせも問題ありません。

負のバイアスと正のバイアス

受信機のクロックが進みがちであれば負のバイアスで、遅れがちかであれば正のバイアスになります。これは受信機の水晶振動子個体の持つ振動周期と温度によって決まります。ただ、u-bloxの場合温度補償付きの水晶ですので温度への依存は少なくなっています。進みがちか遅れがちかは水晶振動子の製造ロットなどによっても異なるかも知れません。

詳しく見ていませんが、たまたまこちらのでテストしたのはすべて正のバイアスでした。そのため現象がでることはありませんでした。問題のないユーザー様、また他社の問題の無いデバイスも正のバイアスでしょう。

このばらつきは製造後に区別はできても作りこむことは簡単ではありません。事前に水晶振動子の固有振動数を調べないとなりません。また、たとえ負のバイアスであってもCHCNAV以外では問題なく不良ではありません。RTKの計算はクロックの誤差を織り込み済みなのでバイアスが正でも負でも精度には影響しません。

u-bloxのRTCM時刻の指定

RTCM時刻を常に.000秒にロックできればよいのですがこれは現状u-bloxのモジュール単体ではできません。

対処法

Drogger Ntrip Serverを使う

Drogger Ntrip ServerはRAWデータをRTCMに変換します。RAWデータもRTCMと同じように毎秒必ず.000というわけではありません。しかし、このソフトウェアの目的がJust 000を要求するRover受信機のためでもあり、変換時に時刻補正をして必ず.000のRTCMを生成します。ですので、NX510で問題を起こすことはありません。

NX510のしきい値の変更

タブレットのNX510の[設定]-[システム設定]-[警告設定]-[GPS精度]の値を0.5とかにすることでこの問題を回避できます。ただし、この値はRTKで使用する場合のみです。単独測位で使用する場合はデフォルトのほうが良いかと思います。RTKの場合、Floatになると停止しますので精度の数値はそれほど問題ではないからです。