原子時計故障時のデータ解析

OSQZSS受信機での観測が一段落した際に，データ解析の再開は
異常停止したルビジウム原子時計1の再起動のときとコメントして
いましたが，まさかこんな形で再開しようとは．

ルビジウム原子時計2の異常発生時および原子時計1への切り替えを
含むRINEXファイルをアップしておきます．日をまたぐので，2セットに
なります．興味のある方は，解析にご利用ください．

http://www.sensorcomm.co.jp/osqzss/data/20120603/rnx20120603.zip
http://www.sensorcomm.co.jp/osqzss/data/20120604/rnx20120604.zip

さて，前回同様に，GPSのみで受信機クロックのオフセットを推定した後，
その値と既知のアンテナ位置から計算したみちびきの擬似距離と，
観測された擬似距離の差から，衛星クロックの挙動を求めてみました．



それまで安定していた衛星クロックオフセットが，異常が報告された
日本時間の6月4日1時42分すぎに，急激にドリフトしています．

ドリフトを開始した時刻は，1時42分6秒あたりです．これはGPS時刻で
6月3日の16:42:21（TOW 60141）となります．

さて，RINEXのナビゲーションファイルを見てみると，ヘルスフラグが
アクティブとなった受信機時刻はTOW 60319となります．デコードにかかった
時間を考慮しても，異常発生からヘルスフラグがセットされるまでに
2分半から3分弱かかっています．

一方，OSQZSS受信機のログファイルから，航法メッセージのビット列を
読み出してみると，アラートフラグはTOW 60156でセットされていました．
異常発生から15秒後と，30秒以内という仕様を充分に満足しています．

【追記】
もう少し長期の衛星クロックの挙動を解析してみると，日本時間の
4時35分あたりで原子時計2が停止し，8時5分に原子時計1に
切り替わっているようです．

原子時計の不具合、再び

去年の記事を読んでいるのかと勘違いするようなタイミングで
準天頂衛星のルビジウム原子時計2に不具合発生．

準天頂衛星初号機「みちびき」のルビジウム原子時計の冗長系切り替えと測位信号提供の一時中断について

昨年の7月にトラブルが発生したルビジウム原子時計1に切り替える
ことで，測位信号の送信を再開したようです．

昨年のトラブルは原子時計そのものの異常ではなかったようですが，
搭載している原子時計両方にトラブルが発生してしまったのは
何となく複雑な気持ち…

不具合の発生時に日本から観測できていたかどうか不明ですが，
後でログを確認してみよう．

一段落

みちびきの観測も一年経ち，これまでの結果をまとめて
日本航海学会の講演会で発表させていただきました．

一段落つきましたので，何か特別なイベントでもない限り，
データ解析はしばらくお休みです．

次に期待できるイベントは，異常停止したルビジウム
原子時計の再起動でしょうか．

原子時計故障時の信号強度

ルビジウム原子時計故障時にQZSS対応のJAVAD受信機で観測された
L1 C/A，L2，L5，L1-SAIF信号の信号強度を比較してみました．

どの周波数も14:43に信号をロストし，その後，7分間ほどロストと再補足を
繰り返しています．

L5信号は，信号を放送しているようですが，信号強度は極端に低く，
18:17までこの状態が続いています．

L1-SAIF信号は他の信号とは異なるアンテナで放送されているため，
故障時の挙動も異なるかと思ったのですが，あまり違いは見られません．
ただし，原子時計2への切り替え後に信号をロストし，14:10に再補足しました．
この間は，信号そのものを放送していなかったのでしょうか？

先日の衛星クロックオフセットの推定で見られた14:10の変化は，
このL1-SAIF信号の影響かと思われます．

しかし，こうして信号強度を比較してみると，L1 C/A信号の安定度が
他の信号より悪いです．L2C信号とは帯域も同じなのに，なぜでしょう？

衛星クロックオフセット

受信機クロックのオフセットをGPSのみで推定することで，
ルビジウム原子時計切り替え時のみちびきの衛星クロック
オフセットを算出し，プロットしてみました．

初めの赤線が原子時計の故障が検出された時刻で，次の
赤線が原子時計切り替えの時刻を表しています．

14:10あたりで，冗長系のルビジウム原子時計2のオフセットが
急に変化していますが，切り替え以外に何かしたのでしょうか？
その後のクロックオフセットは安定しています．

原子時計故障時のアラートフラグ

放送暦のヘルスフラグがアクティブであることが確認されるまでに
7分を要したという前回の解析結果について，それはみちびきの
測位信号をロストしているために，そもそも放送暦がデコードできて
いないのではないかというコメントをいただきました．

原子時計故障時の測位結果を拡大して確認すると，確かにその通りで，
12:46から12:50まではみちびきの信号をロストし，GPSのみの測位と
なっていました．

その後，信号を再補足し，12:50:42の段階でヘルスフラグがアクティブ
である放送暦を受信しています．

再補足後も，原子時計の故障の影響を受け，高度方向の誤差が線形的に
増加しています．原子時計を冗長系に切り替えた13:07には，その影響で
高度誤差の傾きが反対方向に変化しています．



また，ヘルスフラグとアラートフラグを混同していたので，IS-QZSSを
読み返して確認しました．

ヘルスフラグは，放送暦の一部であるため，サブフレーム1～3が正常に
デコードされなければ認識されません．そのため，デコードに18～90秒
ほど必要となります．

これに対して，アラートフラグはサブフレームの第2ワードであるHOWの
ビット18であるため，6秒ごとに取得することができます．みちびきの
測位信号の異常を検知するには，このアラートフラグを確認することが
最速となります．

ログを取っていた航法メッセージのビット列をデコードしたところ，
Zカウンタが12:44:18（TOW 391458）のHOWで，アラートフラグが
アクティブになっていました．それより前の航法データは，ビット
エラーが頻発して30秒ほどデコードできない状態ですが，それでも
12:43の故障の発生から1分以内でアラートフラグがセットされていた
ようです．

原子時計故障時の放送暦

ルビジウム原子時計故障時に観測されたみちびきの擬似距離データも
使用して，単独測位を実施してみました．JAXAのアナウンスによると，
7月28日の12:43（GPS時刻）に故障が発生し，13:07に2台目の時計に
切り替えています．その後，動作を確認し，19:05にアラートフラグを
解除しています．



電離層遅延誤差の補正をOFFにしているため，高度方向に20mほどの
オフセットがみられますが，故障時には，それを遥かに上回る測位
誤差が観測されています．

みちびきを測位に利用しているユーザは，この故障の発生を放送暦に
含まれるヘルスフラグで判別するしかありません．そこで，今回の
故障時におけるヘルスフラグの挙動について，確認してみました．

J 1 11 07 28 13 00 00.0 -.235158950086D-06  .113686837700D-11 -.277555756200D-16
      .166000000000D+03  .121750000000D+03  .374051294952D-08  .310842571863D+01
      .342726707416D-05  .756974654329D-01 -.566616654325D-05  .649331751505D+04
      .392400000000D+06  .653788447299D-06 -.193394850091D+01 -.745058059600D-07
      .711842166911D+00  .332437500000D+03 -.156866316399D+01 -.352014662756D-08
      .235366946790D-09  .100000000000D+01  .164600000000D+04  .100000000000D+01
      .000000000000D+00  .100000000000D+01 -.419095158570D-08  .678000000000D+03
      .391429000000D+06  .000000000000D+00
J 1 11 07 28 13 00 00.0 -.235158950086D-06  .113686837700D-11 -.277555756200D-16
      .166000000000D+03  .121750000000D+03  .374051294952D-08  .310842571863D+01
      .342726707416D-05  .756974654329D-01 -.566616654325D-05  .649331751505D+04
      .392400000000D+06  .653788447299D-06 -.193394850091D+01 -.745058059600D-07
      .711842166911D+00  .332437500000D+03 -.156866316399D+01 -.352014662756D-08
      .235366946790D-09  .100000000000D+01  .164600000000D+04  .100000000000D+01
      .000000000000D+00  .330000000000D+02 -.419095158570D-08  .934000000000D+03
      .391842000000D+06  .000000000000D+00
J 1 11 07 28 13 00 00.0 -.235158950086D-06  .113686837700D-11 -.277555756200D-16
      .166000000000D+03  .121750000000D+03  .374051294952D-08  .310842571863D+01
      .342726707416D-05  .756974654329D-01 -.566616654325D-05  .649331751505D+04
      .392400000000D+06  .653788447299D-06 -.193394850091D+01 -.745058059600D-07
      .711842166911D+00  .332437500000D+03 -.156866316399D+01 -.352014662756D-08
      .235366946790D-09  .300000000000D+01  .164600000000D+04  .100000000000D+01
      .150000000000D+02  .630000000000D+02 -.419095158570D-08  .934000000000D+03
      .392412000000D+06  .000000000000D+00

ヘルスフラグは7行目のふたつめのパラメータになります．準天頂
衛星のヘルスフラグは6ビットで，MSBから放送暦，L1 C/A信号，
L2C信号，L5信号，L1C信号，LEX信号のヘルスを表しています．
現在の通常運用では，LEX信号のみフラグがアクティブになって
おり，ヘルスフラグは「1=0x01」となります．

放送暦が送信された時刻は，8行目のひとつめのパラメータである
「Transmission time of message」で確認できます．OSQZSS受信機で
記録した放送暦を見てみると，12:50:42（TOW 391842）で放送暦の
フラグがアクティブになり（33=0x21），13:00:12（TOW 392412）には，
すべてのフラグがアクティブになっています（63=0x3F）．

原子時計の故障の時刻が12:43と報告されていますので，約7分ほど，
ユーザーは故障を知ることができません．衛星側の故障による測位
精度の劣化を防ぐためには，受信機側にRAIMなど，観測値の異常を
検知するアルゴリズムが必要になります．

L1-SAIFには，このような異常を迅速にユーザーに知らせる機能が
備わっています．今回のトラブルでは，どのように動作していたのか，
興味があります．

ルビジウム原子時計の故障

みちびきに搭載されているルビジウム原子時計が7月28日に
故障し，2台目の原子時計に切り替わったとアナウンスが
ありました．

「みちびき」のルビジウム原子時計の冗長系切り替えについて

ルビジウム原子時計は，みちびきが放送している測位信号の
基準となる重要な時計です．打ち上げから一年経たずに故障
してしまったのは残念です．

GPS衛星では，故障の対策として3～4台の原子時計を搭載しています．
みちびきは何台搭載しているのでしょうか？

7月28日の擬似距離観測データをアップしておきますので，
興味のあるかたは解析にご利用ください．

http://www.sensorcomm.co.jp/osqzss/data/20110728/

アラートフラグ解除時のデータ

アラートフラグ解除時の観測データをアップしました．
ご活用ください．

http://www.sensorcomm.co.jp/osqzss/data/20110622/

アラートフラグの解除

本日，みちびきの測位信号のアラートフラグが解除されたと
JAXAからアナウンスがありました．

http://www.jaxa.jp/press/2011/06/20110622_michibiki_j.html

QZ-visionでも，エフェメリスがダウンロードできるように
なっています．

これを機に，QZSS対応の受信機が増えると良いのですが…