1.NMEAドライバwith PPSを基準時刻にした結果
前回、LS22030-V2をNMEAドライバwith PPSで基準時刻として同期させた結果が下図のグラフ。
LS22030-V2(オレンジの線)が0ms付近に移り、このスケールだと線が重なって分からなくなったので拡大。
ポーリング間隔が短く、他の時刻ソースも使っていないのでグラフはほぼ直線。若干、基準としたMFEEDよりも進んでいるようなので、それぞれのoffset平均の差をとって再補正する。
前回設定した補正値 - (MFEEDのoffset平均 - LS22030-V2のoffset平均)
0.105853 - (-0.000566 - 0.000008)
# LS23030-V2
server 127.127.20.2 mode 80 minpoll 2 maxpoll 4 iburst true
fudge 127.127.20.2 flag1 1 time1 0.105278 refid GPS2
あと、UG-353のDynamic Platform ModelsをPortableからStationaryに変更していたので確認。jitterは小さくなっているのだが、同期の基準をポーリング間隔の短いLS23030-V2に変えて条件が変わっているので、割引いてみた方が良いかも知れない。
| 結果 | offset平均[ms] | jitter平均[ms] |
|---|---|---|
| 前々回(送信センテンス限定) | -73.697 | 2.771 |
| 前回(9600→38400bps) | -78.114 | 2.763 |
| 今回(Portable→Stationary) | -78.116 | 2.368 |
2.まとめ
再校正も行ったので、これで構築完了とする。
一応これまで分かったことをまとめておく。
2.1.GPSレシーバー
何度か書いているが、PPS無しだとインターネットタイムサーバよりも精度が落ちる。インターネットに接続できないのでなければ、使わない方がマシ。
USBタイプのGPSレシーバーでPPS信号を出力できる製品は種類が少なく価格も高い。ただ大抵のGPSモジュールはPPS信号を出力ピンを持っているので、機種によっては改造してPPS信号得ることも可能。
例えばBU-353S4のようにシリアル-USB変換IC(Prolific製のPL2303)を使っているGPSレシーバーであれば、DCD信号の入力ピンにGPSモジュールのPPS出力ピンを繋いでやれば、PPS信号が出力されるようになる。残念ながら手持ちのBU-353S4は基板全体が金属プレートでシーリングされていて、ICにアクセスできなかった。Youtubeの分解動画にはシーリングされていないものもあったので、ロット違いらしい。
u-bloxのGPSモジュール使ってる製品だと、GPSモジュール自体が持っているUSB用信号をそのまま使っている製品がほとんどなのでどうにもならない。
2.2.送信センテンスの限定と転送速度
送信センテンスを減らすとjitterが小さくなった。特に転送速度が4800bpsと遅いBU-353S4は影響が大きく表れた。
115200bpsのLS22030-V2も思っていたよりjitterの変化が大きかった。後で調べたら位置情報のGBGSVセンテンスが1サイクル毎に20個と結構な数送られてきていた。GNRMCなどの時刻情報がその後だったりするので、転送速度が速くともセンテンスの送信順序や量によっては影響があるようだ。
いずれにせよntpdのNMEAドライバリファレンスに書かれている通り、センテンスの限定と転送速度のアップは行った方が良い。
2.3.校正に使用するインターネットタイムサーバ
NICTやMFEEDを使っていれば間違いはなさそうだが、ネットワーク環境にも依存するので他のサーバ含めて評価した上で選定する。プロバイダーが提供するインターネットタイムサーバを使う場合も同様。
(大手だがCloudflareのように遅延のあるインターネットタイムサーバもあるし)