JR7CWK'sぶろぐ
GNSS＞ロールオーバーについての詳細
|
「GPS時刻」とロールオーバーについて
GPS(GNSS)は、衛星に積まれた精密な時計の時刻情報を元に、複数の衛星からの距離を算出する事で位置を計測するシステムです。 衛星から送出される時刻情報は、UTCとは別の時系で、UTCの1980年1月6日(日曜日)の00:00:00を00:00:00としてスタートさせたUTCと同じ長さの1秒を刻む時系で、この時系をGPS時系、あるいはGPS時刻などと称しています。 (なお、GPSは開始以来UTCでは挿入されてきた「うるう（閏）秒」を挿入されていません。 2019年時点でUTCと18秒のずれがあります。) GPS時刻は、GPS衛星から送信される航法メッセージのなかで、 1)週番号(WNO:Week Number) ： GPS時刻がスタートしてからの通算の経過週 2)週内番号(TOW:Time of Week) ： 日曜日を 0 とし、土曜日の 23:59:59 までの経過秒数 の２つに分けて２進数で送信されています。 このうち 1)の週番号を表現するビット数が 10ビットであるために、週番号1023週の翌週が 1024週にならずに 0週に戻ってしまいます。 このことを「GPS時刻のロールオーバー」と称しています。 1年は約52週なので、1024週を52週で割ると、約 19.7年。GPSがスタートしてから約 19.7年毎にこのロールオーバーがやってきます。 ロールオーバー発生日時 1回目(1024週目)：1999年8月22日午前9時(JST) 2回目(2048週目)：2019年4月7日午前9時(JST)・・・今回迎える 3回目(3072週目)：2038年11月21日午前9時(JST) ロールオーバー発生後、発生しうる挙動 ソフトウエアの実装により挙動は異なると考えられますが、ロールオーバーが考慮されていない装置では、出力される時刻(年月日)がずれる事が考えられます。 今、発売されている機器は1回目のロールオーバーを迎えた後なので、1999年8月22日を0週目として設計されていると思います。 従って、2019年4月7日を1999年8月22日と出力される可能性があります。 今回迎えるロールオーバーを考慮した機器の場合、特定の週番号を基準週に1024週目台であるか、2048週目台であるか処理を分けるような実装が考えられます。 (基準週がいつであるかは、機器によって異なると思います。) (本件、過去にネットで調べた情報を元にしていますが、情報源のサイトが既に存在しないので、元urlは掲載出来ません。) |
GPS週番号ロールオーバー＞今週の週番号は
GPS週番号ロールオーバー＞うるう秒を考慮した厳密な情報
GPS週番号ロールオーバー＞今週の週番号は2046
GPS週番号ロールオーバー＞2048週になりました
|
昨日4月7日日本時間9時前にGPSの週コードが2048週になりました。
手持ちの機材を極力受信/ログさせて時刻出力の経過を観察しました。 影響のあったもの。(速報版) 1. GPSレシーバー GPS-N103(WONDE PROUD社)のnmea出力 ロールオーバー後の日付が1999年8月22日になった。 2. GPSロガー SKYTRAQフォーマットでログされている機種のlog出力 (GP-101(SKYTRAQチップ機),GT-740FL 共にCanMore社) 使用ツール:PhotoTagger,CANWAY,SkyTraq(SKYTRAQ製Viewre)いずれも (Phototracker及びGPSBabelは未確認) |
GPS週番号ロールオーバー＞挙動詳細
|
確認したGPS(GNSS)receiver及びloggerのlog結果を以下にまとめた。
以下、機器メーカー名(購入当時)，機器名，ChipSETメーカー，ChipSET型名， nmeaの時刻出力，2048週以降対応結果の順で記述している。 但し、「2048週以降対応」とした機器であっても、WNO(週コード)で 1024週台と2048週台を判断していると思われる為、いつまで対応しているかは 不明である。 1.WondeProud GPS-N103(receiver) ChipSET:NEMERIX 私が入手した中で最も設計世代が古いチップを使用したレシーバである。 NMEA出力(GPRMCセンテンス) 235948(HHMMSS)までは060419(DDMMYY)を出力 235949(HHMMSS)から235959まで210899(DDMMYY)を出力 000000(HHMMSS)以降220899(DDMMYY)を出力 結果：2048週以降非対応(但し時刻出力が異なるだけで、位置情報は問題なし) 2.RoyalTek RGM-3800(receiver/logger) ChipSET:SiRF(現CSR) star�� GSC3f/LP NMEA出力(G-mouse)(GPRMCセンテンス) 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 LOG出力(GPRMCセンテンス)・・・DataDownloader V2.6.1.47にて読み込み変換 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 結果：G-mouse，Log出力共に2048週以降対応 3.wintec WPL-1000(logger) ChipSET:u-blox ATR0625 NMEA出力(G-mouse) 出力なし LOG出力(GPRMCセンテンス)・・・WinToolにて読み込み変換 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 235946(HHMMSS)出力欠落 結果：2048週以降対応 4.TranSystem TripMate850(receiver/logger) ChipSET:MTK 3329 NMEA出力(G-mouse) 確認していない (bt接続必要だったのと、元々log方式がchipsetのNMEA出力を そのまま保存する方式と思われ、わざわざ確認する必要性を 感じなかった) LOG出力(GPRMCセンテンス) 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 結果：2048週以降対応 5.CanMore GP-101(Venus6版)(receiver/logger) ChipSET:SkyTraq Venus6 NMEA出力(G-mouse)(GPRMCセンテンス) 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 LOG出力(GPRMCセンテンス)・・・PhotoTaggerにて読み込み変換 235946(HHMMSS)までは060419(DDMMYY)を出力 235947(HHMMSS)から235959まで2108-1(DDMMYY)を出力 000000(HHMMSS)以降2208-1(DDMMYY)を出力 LOG出力(GPRMCセンテンス)・・・SkyTraq 0.4.723にて読み込み変換 235944(HHMMSS)までは060419(DDMMYY)を出力 235945(HHMMSS)から235959まで210899(DDMMYY)を出力 000000(HHMMSS)以降220899(DDMMYY)を出力 注)使用したツールが2007年4月19日リリースの版の為、当時の閏秒により 変換されている模様。 最新版探していません。 ※「PhotoTrackr」及び「GPSBabel」，「CanWay」は未確認。 結果：G-mouse出力は2048週以降対応 log出力は変換ツール次第 (logがWNO(週コード)をそのまま記録するSkyTraqフォーマットで行われて いるので、1024週台と2048週台の判断は変換ツール次第である。) 6.CanMore GP-101(STAR-IV版)(logger) ChipSET:CSR(旧SiRF) STAR-IV NMEA出力(G-mouse) 出力なし LOG出力(GPRMCセンテンス)・・・CanWayにて読み込み変換 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 235948(HHMMSS)出力欠落 結果：2048週以降対応 7.CanMore GP-102+(logger) ChipSET:CSR(旧SiRF) STAR-IV NMEA出力(G-mouse) 出力なし LOG出力(GPRMCセンテンス)・・・CanWayにて読み込み変換 235958(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 ※現在設定がおかしく1秒間隔のlogになっていない 結果：2048週以降対応 8.CanMore GT-740FL(receiver/logger) ChipSET:CSR(旧SiRF) STAR-IV NMEA出力(G-mouse)(GPRMCセンテンス) 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 LOG出力(GPRMCセンテンス)・・・CanWayにて読み込み変換 235944(HHMMSS)までは060419(DDMMYY)を出力 (ここでlog出力分断) 235945(HHMMSS)から235959まで2108-1(DDMMYY)を出力 000000(HHMMSS)以降2208-1(DDMMYY)を出力 LOG出力(GPRMCセンテンス)・・・SkyTraq 0.4.723にて読み込み変換 235944(HHMMSS)までは060419(DDMMYY)を出力 235945(HHMMSS)から235959まで210899(DDMMYY)を出力 000000(HHMMSS)以降220899(DDMMYY)を出力 注)使用したツールが2007年4月19日リリースの版の為、当時の閏秒により 変換されている模様。 最新版探していません。 ※「GPSBabel」は未確認。 結果：G-mouse出力は2048週以降対応 log出力は変換ツール次第 (logがWNO(週コード)をそのまま記録するSkyTraqフォーマットで行われて いるので、1024週台と2048週台の判断は変換ツール次第である。) 9.CanMore GMS6-CR6(receiver) ChipSET:CSR(旧SiRF) STAR-IV NMEA出力(G-mouse)(GPRMCセンテンス) 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 結果：2048週以降対応 10..CanMore GMS6-SR6(receiver) ChipSET:STMicro (型名不明) NMEA出力(G-mouse)(GPRMCセンテンス) 235959(HHMMSS)までは060419(DDMMYY)を出力 000000(HHMMSS)以降070419(DDMMYY)を出力 結果：2048週以降対応 11.手持ちだが未確認機器 CanMore GT-730FL(SkyTraq Venus5)(receiver/logger) SONY PSP-290(SiRF star��) |
GPS週番号ロールオーバー＞TripMate850 NGでした
GPS週番号ロールオーバー＞CanWay対応版リリース
GPS週番号ロールオーバー＞GPSBabel対応を確認
|
SkyTraqフォーマットのlogに対し、GPSBabelが週コードのロールオーバーに対応している事を確認しました。
試したのが「GPSBabel 1.6.0-beta20190413」 SkyTraqフォーマットについてのドキュメントを見ると、 「gps-week-rollover option」でロールオーバーの設定が可能で、過去のログにも対応できるよう任意に設定できる他、「-1」設定で自動判別(gpsbabelが実行されてから過去1024週間以内に入力データが記録されたと想定)となるようです。 他にも、「gps-utc-offset option」でGPS時刻とUTC時刻の間のオフセット(閏秒対応)の設定が任意に可能となっており、この2点でSkyTraqフォーマットのログの時刻に「完全に」対応可能となっています。 SkyTraq純正のツールであっても、この2点はソフトウエア内部の固定パラメータとなっており、改版を待たないと閏秒もロールオーバーも対応できない状態であることから、GPSBabelはスマートで理想的な対応方法だと思います。 CanWayでは非対応となってしまった32bit環境でも問題なく動作するので、32bit環境でSkyTraqフォーマットの週コードロールオーバー対応のツールは事実上GPSBabelのみと思われます。 ロガーからログを直接読み込みが可能で、SkyTraqフォーマットでのファイル保存も可能です。(ファイルに保存されたSkyTraqフォーマットのログも読み込み可能なはずですが、当方の環境ではエラーになり読み込み不可でした。) |
GPS週番号ロールオーバー＞TripMate850 logのtimestamp
|
今頃ですが・・・
TripMate850のlogのtimestampが週番号ロールオーバーの影響を受けるようです。 生成されるlogのファイル名が、log開始の月日時分を元にした MMDDHHMM.nma になっており、そのファイルのtimestampもlog開始時刻に基づいています。 ところが生成されるtimestampの年の上位2桁が"20"固定のようで 2019年4月7日以降のlogのtimestampの年月日は、 20YY/MM/DD (YYはlog開始時刻-2048週の年の下2桁)となり、 さらにややこしい事態を引き起こしています。 例えば・・・ 2019年4月16日にlogしたファイルのtimestampは 2099/08/31 になっていました。 (2019年4月16日-2048週=1999年8月31日) この2099年台のtimestampのファイル、PC内(windows)及び同O/S直下のドライブ (USB接続のHDD等)にある分には問題ないようですが・・・ 某社のNASに移したファイルが正常にアクセスできなくなる現象を経験しました。 ちなみに・・・2099年台のファイルが出来るのは、2019年8月16日分まで。 (2019年8月16日-2048週=1999年12月31日→timestampは2099/12/31) 8月17日分以降は2000年代のファイルになり、NAS上のデータも正常にアクセス 可能です。 (2019年8月17日-2048週=2000年1月1日→timestampは2000/01/01) 古いLOGはバックアップ用のUSB-HDD及び、NASにコピーしていますが、 古いLOGの解析作業をNAS上のデータを使用して進めている際に正しくアクセス 出来ないデータがある事が判明し、詳細を調べた結果timestampの異常に 気がついた次第です。 |
copyright/jr7cwk
GPS関連機器の誤動作が発生しないか、注視する必要がありそうです。
前回話題になったのが、「コンピュータ2000年問題」が騒がれていた1999年のこと。
今年は和暦の変更もあるので、いろいろ注意が必要かも知れません。
'19/4/12訂正
何を勘違いしたのか、ロールオーバーが発生する日を「4月19日」と記載していました。
4月7日に訂正します。