放送暦のヘルスフラグがアクティブであることが確認されるまでに
7分を要したという前回の解析結果について,それはみちびきの
測位信号をロストしているために,そもそも放送暦がデコードできて
いないのではないかというコメントをいただきました.
原子時計故障時の測位結果を拡大して確認すると,確かにその通りで,
12:46から12:50まではみちびきの信号をロストし,GPSのみの測位と
なっていました.
その後,信号を再補足し,12:50:42の段階でヘルスフラグがアクティブ
である放送暦を受信しています.
再補足後も,原子時計の故障の影響を受け,高度方向の誤差が線形的に
増加しています.原子時計を冗長系に切り替えた13:07には,その影響で
高度誤差の傾きが反対方向に変化しています.
![](https://blogimg.goo.ne.jp/user_image/1b/f4/78329372689c9f0a8b069b76493488bf.png)
また,ヘルスフラグとアラートフラグを混同していたので,IS-QZSSを
読み返して確認しました.
ヘルスフラグは,放送暦の一部であるため,サブフレーム1~3が正常に
デコードされなければ認識されません.そのため,デコードに18~90秒
ほど必要となります.
これに対して,アラートフラグはサブフレームの第2ワードであるHOWの
ビット18であるため,6秒ごとに取得することができます.みちびきの
測位信号の異常を検知するには,このアラートフラグを確認することが
最速となります.
ログを取っていた航法メッセージのビット列をデコードしたところ,
Zカウンタが12:44:18(TOW 391458)のHOWで,アラートフラグが
アクティブになっていました.それより前の航法データは,ビット
エラーが頻発して30秒ほどデコードできない状態ですが,それでも
12:43の故障の発生から1分以内でアラートフラグがセットされていた
ようです.
7分を要したという前回の解析結果について,それはみちびきの
測位信号をロストしているために,そもそも放送暦がデコードできて
いないのではないかというコメントをいただきました.
原子時計故障時の測位結果を拡大して確認すると,確かにその通りで,
12:46から12:50まではみちびきの信号をロストし,GPSのみの測位と
なっていました.
その後,信号を再補足し,12:50:42の段階でヘルスフラグがアクティブ
である放送暦を受信しています.
再補足後も,原子時計の故障の影響を受け,高度方向の誤差が線形的に
増加しています.原子時計を冗長系に切り替えた13:07には,その影響で
高度誤差の傾きが反対方向に変化しています.
![](https://blogimg.goo.ne.jp/user_image/1b/f4/78329372689c9f0a8b069b76493488bf.png)
また,ヘルスフラグとアラートフラグを混同していたので,IS-QZSSを
読み返して確認しました.
ヘルスフラグは,放送暦の一部であるため,サブフレーム1~3が正常に
デコードされなければ認識されません.そのため,デコードに18~90秒
ほど必要となります.
これに対して,アラートフラグはサブフレームの第2ワードであるHOWの
ビット18であるため,6秒ごとに取得することができます.みちびきの
測位信号の異常を検知するには,このアラートフラグを確認することが
最速となります.
ログを取っていた航法メッセージのビット列をデコードしたところ,
Zカウンタが12:44:18(TOW 391458)のHOWで,アラートフラグが
アクティブになっていました.それより前の航法データは,ビット
エラーが頻発して30秒ほどデコードできない状態ですが,それでも
12:43の故障の発生から1分以内でアラートフラグがセットされていた
ようです.
※コメント投稿者のブログIDはブログ作成者のみに通知されます