先月、GPS の週数ロールオーバーに注意という話を書きましたが、僕の使っているTransystem TripMate 850 は、なんとGPS の週数ロールオーバーに対応していませんでした。
ロールオーバー後に起動してみて、正常に時刻が表示されているのを確認してすっかり油断していました。
ネットを調べてみると、同じ Transystem の 747Pro、747ProS については以下のようなアナウンスを出しているショップがあるので、Transystem の製品全般が同じような症状なのかもしれません。
2019年4月7日に行われたGPS信号に含まれる年月日のリセット(ロールオーバー)により、 旧モデルにて正しい日付を取得できないまたはログデータを取り込めないなどの症状が発生する可能性がございます。
症状発生の確認が取れている機種:トランシステム社製品 747Pro、747ProS
† まずは現状分析から
747Pro、747ProS と違って TripMate 850 は既にディスコンの製品なので対応は望み薄です。
新しい GPS ロガーを買っても良いのですが、プログラマらしく自分で対応をしてみます。
まず、この TripMate 850 は一般的なロガーと違ってmicroSD に nmea ファイルが書き出される仕様になっています。
ファイル自体が生成されていないとどうしようもありませんが、幸いファイルは書き出されているようなので、この内容を解析します。
このファイルの仕様はNMEA 0183*1*2 と呼ばれるもので、日付は $GPRMC で始まる行に入っていることが分かります。
ロガーから出力された nmea ファイルの該当行を見てみると、以下のようになっていました。
後ろから4カラム目の290899 という部分が日付(フォーマットは DDMMYY )なので、デコードすると1999/08/29 ということになります。
そもそもこのフォーマットは西暦が 2 桁なので 2000 年問題にすら対応していませんね。。。。。。
前回のロールオーバーが 1999年8月22日*3だったので、見事に時間が巻き戻ってしまっています。
† 時刻はなぜ大丈夫?
ちなみに、時刻が合っているのは時刻の部分は前から2カラム目の054022.000 に格納(フォーマットは HHMMSS.SSS)されているため。
時刻は UTC になっているので、日本時間 ( JST ) にするためには 9 時間を足す必要がありますから、これらを考慮してデコードすると14:40:22.000 ということが分かります。
うるう秒はきちんと考慮されているようなので、時刻は正確でした(TripMate 850は液晶があるので確認できます)。
† Python で NMEA を書き換えちゃえばよくね?
要は1024 週分の日付がずれているということですから、日付に 1024 週の日数を足してやればよいということになります。
つまり、具体的には以下のようになれば良いというわけですね。
今回は NMEA Parser として以下のライブラリを使って Python で nmea 書き換えプログラムを実装してみることにしました。
[Transystem の GPS が週数ロールオーバーに対応していなかったので対処してみた の続きを読む]今日は向島百花園へ出かけてみました。
百花園だと鮮やかな花に目が向きがちですが、入口近くにちょっと変わった植物を発見。仏炎苞から白い玉のようなものが飛び出しているのはユキモチソウ、曲がったヘラのような形をしているのはムサシアブミ、どちらもサトイモ科のようです。
つつじは早咲きのものは満開になっていますが、藤棚はまだまだという感じですね。