先月、GPS の週数ロールオーバーに注意という話を書きましたが、僕の使っている Transystem TripMate 850 は、なんと GPS の週数ロールオーバーに対応していませんでした。

ロールオーバー後に起動してみて、正常に時刻が表示されているのを確認してすっかり油断していました。
ネットを調べてみると、同じ Transystem の 747Pro、747ProS については以下のようなアナウンスを出しているショップがあるので、Transystem の製品全般が同じような症状なのかもしれません。

GPSロガーの情報サイト【GPSDGPS】

2019年4月7日に行われたGPS信号に含まれる年月日のリセット（ロールオーバー）により、 旧モデルにて正しい日付を取得できないまたはログデータを取り込めないなどの症状が発生する可能性がございます。
症状発生の確認が取れている機種：トランシステム社製品　747Pro、747ProS

† まずは現状分析から

747Pro、747ProS と違って TripMate 850 は既にディスコンの製品なので対応は望み薄です。
新しい GPS ロガーを買っても良いのですが、プログラマらしく自分で対応をしてみます。

まず、この TripMate 850 は一般的なロガーと違って microSD に nmea ファイルが書き出される仕様になっています。
ファイル自体が生成されていないとどうしようもありませんが、幸いファイルは書き出されているようなので、この内容を解析します。
このファイルの仕様は NMEA 0183^*1*2 と呼ばれるもので、日付は $GPRMC で始まる行に入っていることが分かります。

ロガーから出力された nmea ファイルの該当行を見てみると、以下のようになっていました。

後ろから４カラム目の 290899 という部分が日付（フォーマットは DDMMYY ）なので、デコードすると1999/08/29 ということになります。
そもそもこのフォーマットは西暦が ２ 桁なので 2000 年問題にすら対応していませんね。。。。。。

前回のロールオーバーが 1999年8月22日^*3だったので、見事に時間が巻き戻ってしまっています。

† 時刻はなぜ大丈夫？

ちなみに、時刻が合っているのは時刻の部分は前から２カラム目の 054022.000 に格納（フォーマットは HHMMSS.SSS）されているため。
時刻は UTC になっているので、日本時間 ( JST ) にするためには 9 時間を足す必要がありますから、これらを考慮してデコードすると 14:40:22.000 ということが分かります。
うるう秒はきちんと考慮されているようなので、時刻は正確でした（TripMate 850は液晶があるので確認できます）。

† Python で NMEA を書き換えちゃえばよくね？

要は 1024 週分の日付がずれているということですから、日付に 1024 週の日数を足してやればよいということになります。
つまり、具体的には以下のようになれば良いというわけですね。

今回は NMEA Parser として以下のライブラリを使って Python で nmea 書き換えプログラムを実装してみることにしました。

• Knio/pynmea2: Python library for parsing the NMEA 0183 protocol (GPS)

† 実装したプログラム

Parser はあるものを利用したので、内容は非常にシンプルです。
Python では datetime の足し算は datetime.timedelta(weeks=1024) のように直感的に指定できるようになっています。

• hsur/NmeaDateFix: Nmea Date Fix Utility for the GPS Week Number Rollover Problem ( date + 1024 weeks ! )

• ^*1: NMEA 0183 - Wikipedia
• ^*2: NMEA 0183 sentences データ解析 – piyajk.com
• ^*3: 4月7日（日本時間）に2度目の「GPS週数ロールオーバー」｜ニュース/アーカイブ｜みちびき（準天頂衛星システム：QZSS）公式サイト - 内閣府