ユーザからの要望で実装してみたleap secondsのバグを諸々修正.
やっと正常に動くようになりました.
GitHub: osqzss / gps-sdr-sim
u-bloxのM8シリーズには,TIMELS (Leap Second Information)という
UBXパケットがあり,シミュレータの動作を確認することができます.
現在,シミュレータには,2016年12月31日に挿入されるうるう秒の
スケジュールがコーディングされています.その3分前からシナリオを生成し,
NEO-M8Nで試してみます.
>gps-sdr-sim -e brdc2270.16n -l 35.658581,139.745433,100 -T 2016/12/31,23:57:00
シミュレーションの開始時点では,次のleap second eventがスケジュール
されていることが確認できます.
(クリックで拡大)
そして,2016年12月31日 24:59:60にうるう秒が挿入されました.
(クリックで拡大)
うるう秒が挿入される日のday numberは日曜日がゼロと思い込んでいて,
しばらくはまりました.ICD-GPS-200Cの20.3.3.5.2.4には日曜日が
"Day one"と書いてあり,日曜日から土曜日まで1から7とカウントされます.
ちなみに,Galileoもこの数え方ですが,BeiDouは0から6でカウントしています.
また,この日が土曜日であるため,丁度week numberもカウントアップされます.
そのおかげで,week numberに関係したバグも見つかり,こちらも修正.
Subframe 1に含まれているWNは,ephemerisのreference timeと思い込んで
いたのですが,これはz-counterとペアの"transmission week number"であると
ICD-GPS-200Cの20.3.3.3.1.1に説明されています.
いろいろと勘違いしているところがあります.勉強になるなあ.RTFM!
やっと正常に動くようになりました.
GitHub: osqzss / gps-sdr-sim
u-bloxのM8シリーズには,TIMELS (Leap Second Information)という
UBXパケットがあり,シミュレータの動作を確認することができます.
現在,シミュレータには,2016年12月31日に挿入されるうるう秒の
スケジュールがコーディングされています.その3分前からシナリオを生成し,
NEO-M8Nで試してみます.
>gps-sdr-sim -e brdc2270.16n -l 35.658581,139.745433,100 -T 2016/12/31,23:57:00
シミュレーションの開始時点では,次のleap second eventがスケジュール
されていることが確認できます.
![](https://blogimg.goo.ne.jp/user_image/7b/d0/d35ac505e2ed84603c0c22e7964bfad4.png)
そして,2016年12月31日 24:59:60にうるう秒が挿入されました.
![](https://blogimg.goo.ne.jp/user_image/34/31/0cc333bf628187fcb6a821712d679007.png)
うるう秒が挿入される日のday numberは日曜日がゼロと思い込んでいて,
しばらくはまりました.ICD-GPS-200Cの20.3.3.5.2.4には日曜日が
"Day one"と書いてあり,日曜日から土曜日まで1から7とカウントされます.
ちなみに,Galileoもこの数え方ですが,BeiDouは0から6でカウントしています.
また,この日が土曜日であるため,丁度week numberもカウントアップされます.
そのおかげで,week numberに関係したバグも見つかり,こちらも修正.
Subframe 1に含まれているWNは,ephemerisのreference timeと思い込んで
いたのですが,これはz-counterとペアの"transmission week number"であると
ICD-GPS-200Cの20.3.3.3.1.1に説明されています.
いろいろと勘違いしているところがあります.勉強になるなあ.RTFM!
※コメント投稿者のブログIDはブログ作成者のみに通知されます