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のシンボリックリンクを張っておく。

ntp.conf抜粋

# 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付ソースが必要。

ntp.conf抜粋

# 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.

現在の設定確認 : dynModelがデフォルトの0(Portable)になっている

# 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)

Stationary(2)モードに変更

# ubxtool -P 14 -f /dev/gps0 -p MODEL,2
UBX-ACK-ACK:
  ACK to Class x06 (CFG) ID x24 (NAV5)

設定の確認 : dynModelが2(Stationary)に変わった

# 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)