1.GPSモジュールの転送速度を上げた結果
前回、UG-353とBU-353S4の転送速度をそれぞれ38400bpsに上げた結果が下図のグラフ。
デフォルト4800bpsだったBU-353S4の方(青色のグラフ)は140msくらい遅延が改善されている(相変わらず100msくらいoffset変動はあるが)。
デフォルト9800bpsだったUG-353の方はoffsetのグラフでは有意な差がみられなかった。ので、offsetとjitterの平均値をとってみた。
UG-353
| 項目 | 前回[ms] | 今回[ms] |
|---|---|---|
| offset | -73.697 | -78.114 |
| jitter | 2.771 | 2.763 |
BU-353S4
| 項目 | 前回[ms] | 今回[ms] |
|---|---|---|
| offset | -265.664 | -111.959 |
| jitter | 10.217 | 10.071 |
UG-353は4,5ms遅延が大きくなっている。元々20ms程度のoffset変動があるので、遅延が大きくなったのか誤差の範囲なのか判断が付かない。次回もう一度確認する。
BU-353S4は大きな変動の周期が長くなったように見える。こちらも前回同様jitterのグラフを描いてみたが周期性は変わらず。
あと、Cloudflare(灰色)の遅延が急に改善された。Cloudflareの設備かそこまでの回線経路が変わったのかも知れない。とはいえ、まだ10ms程度の遅延はあるので基準にはしない。
2.LS22030-V2をソースにしたタイムサーバの設定
おおよそGPSレシーバーの特性が掴め、設定も出来たので、タイムサーバとしてntpdを構築する。
2.1.補正値の算出
今回時刻の基準にしているのはCloudflare以外のインターネットタイムサーバなので、このうちMFEEDを校正に使うことにする。
補正値 = MFEEDのoffset平均 - LS22030-V2 PPSのoffset平均
求めた補正値をtime1で設定。NMEAドライバでPPSを使うためにflag1 1を指定し、/dev/gpspps2のシンボリックリンクを張っておく。
# LS23030-V2
server 127.127.20.2 mode 80 minpoll 2 maxpoll 4 iburst true
fudge 127.127.20.2 flag1 1 time1 0.105853 refid GPS2
また比較のため、他のGPSレシーバーの設定は変更せず、インターネットタイムサーバはnoselectを付けて時刻同期の候補から外しておく。
2.2.NMEAドライバ + PPSドライバ
実は当初LS22030-V2のPPSとoffset変動の小さいUG-353でタイムサーバを作れないかと試行錯誤したのだが、うまくいかなかった。
こんな感じでPPSとUG-353の補正値を設定、UG-353にpreferを付けて(※1)動かしたが、頻繁に時刻同期候補から外れたり(xマーク)、noselectにしてあるCloudflareが同期候補に挙がった(+マーク)りした。
※1 PPSドライバを使う場合、最低1つprefer付ソースが必要。
# UG-353
server 127.127.20.0 mode 48 minpoll 2 maxpoll 4 iburst prefer
fudge 127.127.20.0 time2 0.077707 refid GPS0
# LS23030-V2 for PPS
server 127.127.22.2 minpoll 2 maxpoll 4 iburst true
fudge 127.127.22.2 time1 0.105853 refid PPS2
候補から外れたのはPPSとUG-353のoffsetに差があるときで、Cloudflareが候補に挙がったのはUG-353とのoffsetが近いときだった。このあたりntpdの理解が不足しているのは否めない。
結局面倒になってNMEAドライバwith PPSで行くことにした。
おまけ
海外のサイトを見ていたらu-blox NEO-M8TでTiming Modeをfixed geographic locationにした方が良いという記述を見つけた。u-blox7のリファレンスを確認したら、Dynamic Platform Modelsのことだった。UG-353でも設定可能だったので、Stationary(静止)に変更することにした。
本当に効果があるのか次回確認。
Dynamic Platform Models
| dynModel | Platform | 説明 |
|---|---|---|
| 0 | Portable | Applications with low acceleration, e.g. portable devices. Suitable for most situations. |
| 2 | Stationary | Used in timing applications (antenna must be stationary) or other stationary applications. Velocity restricted to 0 m/s. Zero dynamics assumed. |
| 3 | Pedestrian | Applications with low acceleration and speed, e.g. how a pedestrian would move. Low acceleration assumed. |
| 4 | Automotive | Used for applications with equivalent dynamics to those of a passenger car. Low vertical acceleration assumed. |
| 5 | Sea | Recommended for applications at sea, with zero vertical velocity. Zero vertical velocity assumed. Sea level assumed. |
| 6 | Airborne with <1g Acceleration | Used for applications with a higher dynamic range and vertical acceleration than a passenger car. No 2D position fixes supported. |
| 7 | Airborne with <2g Acceleration | Recommended for typical airborne environment. No 2D position fixes supported. |
| 8 | Airborne with <4g Acceleration | Only recommended for extremely dynamic environments. No 2D position fixes supported. |
# ubxtool -P 14 -f /dev/gps0 -p CFG-NAV5
UBX-CFG-NAV5:
mask 0xffff dynModel 0 fixmode 3 fixedAlt 0 FixedAltVar 10000
minElev 5 drLimit 0 pDop 250 tDop 250 pAcc 100 tAcc 300
staticHoldThresh 0 dgpsTimeOut 60 cnoThreshNumSVs 0
cnoThresh 0 res 0 staticHoldMaxDist 0 utcStandard 0
reserved x0 0
UBX-ACK-ACK:
ACK to Class x06 (CFG) ID x24 (NAV5)
# ubxtool -P 14 -f /dev/gps0 -p MODEL,2
UBX-ACK-ACK:
ACK to Class x06 (CFG) ID x24 (NAV5)
# ubxtool -P 14 -f /dev/gps0 -p CFG-NAV5
UBX-CFG-NAV5:
mask 0xffff dynModel 2 fixmode 3 fixedAlt 0 FixedAltVar 10000
minElev 5 drLimit 0 pDop 250 tDop 250 pAcc 100 tAcc 300
staticHoldThresh 0 dgpsTimeOut 60 cnoThreshNumSVs 0
cnoThresh 0 res 0 staticHoldMaxDist 0 utcStandard 0
reserved x0 0
UBX-ACK-ACK:
ACK to Class x06 (CFG) ID x24 (NAV5)