Week number rollover

gps-sdr-simで20年以上も先の日時を設定すると，受信機から出力される
日時が正常な値にならないとユーザから質問があったので，確認してみました．

正確なところは判りませんが，20年ほど巻き戻った日時が出力されている
ところを見ると，week number rolloverの問題かと思われます．

GPSの航法メッセージに含まれているweek numberは10ビットしかないため，
最大で1024週しかカウントできません．これは，約19.6年に相当し，この周期で
week numberがゼロに戻ってしまいます．

ちなみに，1回目のrolloverは1999年8月21日に発生しています．次のrolloverは
2019年4月7日になります．

このrolloverをどう扱うかは，シミュレータではなく，受信機の問題になります．
そのため，受信機毎に異なった挙動を示すことになります．

手元にあるu-blox社のGNSS受信機では，UBX-CFG-NAVX5で設定した
week numberから，1024週が連続するようにカウントしてくれるようです．

u-blox: What is the GPS week rollover and how is it handled by u-blox GNSS receivers?

デフォルト値を見てみると，1867週（2015年10月18日）に設定されていました．
そのため，このままだと，2035年以降は正常にrolloverが反映されず，
日時が2015年に戻ってしまいます．

そこで，このパラメータを2086週（2019年12月29日）に設定して，さらに未来の
日時である2039年1月1日の信号をシミュレータで生成してみます．

　（クリックで拡大）

　（クリックで拡大）

こうすることで，week number rolloverが解決され，正常な日時で測位結果を
出力できました．

u-bloxの受信機は，細かいところまで手が行き届いていて，関心します．

うるう秒を試す

ユーザからの要望で実装してみた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！

GPS Interference

USCGのNavigation Centerでこんなの公開してたんだ．
どうやら同じPDFのファイル名で，定期的にアップデートされるらしい．

www.navcen.uscg.gov: APPROVED GPS TESTING

【追記】これ，同時に2つの基地から信号を出している．
何の実験をしているのだろう？

FAA: FLIGHT ADVISORY - GPS Interference Testing - Fairbanks, Alaska
FAA: FLIGHT ADVISORY - GPS Interference Testing - Big Delta, Alaska

研究室紹介

明日からのオープンキャンパスでの研究室紹介に向けて
いろいろと準備中．



Rohde & Schwarzに負ける訳にはいかない．

YouTube: POKEMON GO UNBELIEVABLE GPS HACK

Leap seconds

gps-sdr-simにleap secondsのサポートを追加．
RINEX navigation fileのヘッダからパラメータを読み込んで，
Subframe 4のPage 18として放送します．

詳細はICD-GPS-200Cの20.3.3.5.2.4 Universal Corrdinated Timeを
参照してください．

　（クリックで拡大）

　（クリックで拡大）

同じpageに，電離層遅延補正のパラメータも含まれているので，
こちらも一緒に実装．

シミュレートされる疑似距離にも電離層遅延を加えています．
同じ大きさの遅延が受信機側で補正されるので，結果的には
電離層遅延誤差がゼロになるはず．

GPS受信機の輸出規制

firefly GNSS受信機を搭載した小型衛星を海外のロケットで
打ち上げるために，fireflyの輸出が出来ないかという相談が
増えている．

輸出許可申請が面倒で，基本的に対応する予定はないけれど，
日本におけるGPS受信機の輸出管理について復習しておく．

GPS受信機の規制というと，すぐにITARが話題に上るが，
ITARはあくまでも米国における輸出入の規則でしかない．
とはいえ，ITARは「輸入」規制でもあることから，
米国に輸出しようとなると，自国の輸出規制だけではなく，
ITARの輸入規制にも注意する必要はある．

しかし，GPS受信機に関していえば，それまで規制対象と
なっていた高度・速度に関する制限が削除されたため，
宇宙機用GPS受信機の輸出入はITARの規制外となっている．

現在，日本を含めた多くの国で，GPS受信機の性能に関する規制の
唯一の基本合意となっているのが，ミサイル技術管理レジーム
（MTCR: Missile Technology Control Regime）である．

この中で，カテゴリーIIの規制品として，11.A.3に速度600m/sを
超えて測位情報を提供するGNSS受信機がリストアップされている．

MTCR: EQUIPMENT, SOFTWARE AND TECHNOLOGY ANNEX

日本でも，このMTCRの規制に基づき，このようなGNSS受信機を
リスト規制の対象としている．

具体的には，輸出貿易管理令第4項（18）における貨物等省令第3条
第十九号のアビオニクス装置として規制されている．

経済産業省: 輸出令別表第1のマトリクス表

また，人工衛星の場合，打ち上げが日本国内からであっても，その後，
主たる運用者が海外に移管される場合も輸出とみなされるので厄介だ．

そんな訳で，海外への輸出はあきらめて，fireflyを搭載した衛星は
国産ロケットでばんばん打ち上げて欲しい．

XTRX

インターフェイスがPCIeというのが微妙だけれど，
小さいことはいいことだ．

Fairwaves: XTRX



フロントエンドはLimeSDRと同じLime Microsystemsの
LMS7002Mで，2x2 MIMOをサポート．

販売価格はbladeRFと同程度とのこと．

HACKADAY: THE PROBLEM WITH SOFTWARE DEFINED RADIO

未来の時刻でシミュレーション

gps-sdr-simへの要望で多かった未来の時刻における信号の生成に対応．
Almanacをpropagateすることも考えたけれど，面倒だったので単純に
RINEX navigation fileから読み込んだTOCとTOEを上書きしている．

試しに1年ほど未来の2017年7月1日で信号を生成してみたが，
特に問題なく動いているようだ．

　（クリックで拡大）

　（クリックで拡大）

ただし，leap secondsの情報を航法メッセージに入れていないので，
受信機においてUTCへの変換が正常に行われない．

2017年1月1日にうるう秒が挿入されることだし，leap secondsへの
対応もしよう．