畳み込み符号の素朴な疑問

L1-SAIFのメッセージは，SBASと同様に，符号化率1/2の畳み込み符号で符号化されています．
これによって，250ビットのメッセージは500のシンボルに変換されるわけですが，復号の際に，
どうやってこの2つのシンボルの先頭を見つけるのでしょうか？

Galileoの航法メッセージにも同様の符号化が用いられていますが，符号化されるのはメッセージ
本体だけであり，preambleは符号化されていません．そのため，このpremambleを見つければ
符号化されたメッセージの先頭を見つけることができます．

ところが，L1-SAIFやSBASでは，preambleまで符号化していまします．何を手がかりに復号すれば
良いのだろう？

C/A信号も同時に受信して，航法メッセージのビットと同期を取るのかな？
うーん…

L1-SAIFの拡張メッセージ

23日に取得したL1-SAIFデータのメッセージタイプを調べると，すべてSBAS互換のタイプでした．
L1-SAIFのために拡張されたメッセージ（タイプ52～60）は放送されていないようです．

MSASのデータと同じなのでしょうか？それとも，電離層遅延補正のフォーマットはSBASと互換でも，
そのパラメータは日本周辺で精度が向上するよう，特別に生成しているのでしょうか？

QZ-visionの実験スケジュールを見てみると，L1-SAIF信号では，SPACによる利用実証実験が
始まり，L1-SAIFプラスと呼ばれるデータが放送されているようです．

SPACのwebサイトでL1-SAIFプラスの仕様書を探したのですが，どうも見当たりません．
IS-QZSSによると「準天頂衛星システム利用実証　ユーザーインターフェース仕様書」という
ドキュメントのようですが，どこにあるのだろう？

L1-SAIFのメッセージ（2）

SBASメッセージを解読するためのソースコードがRTKLIBで公開されているので，
それをL1-SAIF対応に改修することにしました．

動作確認を簡単にするために，RTKLIBで読み込み可能なNovAtel社のOEMV受信機の
SBASメッセージ出力と同じフォーマットでファイルを生成します．

L1-SAIFのメッセージは，SBASと同様に250ビットで構成されています．HEXで出力
すると，31バイト＋2ビット必要となります．OEMV受信機の出力は左詰ですので，
始めの1バイトがpreambleになります．最後の1バイトも左詰で，残りの6ビットは
zero paddingになっています．

L1-SAIFメッセージのHEXファイルを以下のアドレスで公開しています．
興味のある方は，デコードにチャレンジしてみてください．

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


530e1ffdffdfffffdffdffc099ffdffc011ffdffdfffbb9fbb3babbb94c8d740
9a61ffdffdffdffdffdfffbbbbb8a00000000000000000000000000039994d00
c60a1ffffe9ffc009ffdffdffdffdffc009ffc03c00bafa3bbbba3b249c41b80
53081ffffe9ffc009ffdffdffdffdffc009ffc03c00bafa3bbbba3b2436645c0
9a0c1ffdffdfffffdffdffc099ffdffc011ffdffdfffbb9fbb3babbb8ab1e880
c669c053a1fc0b6037831c23e1f70ab03f817c07f05b859c48e1560008845100

L1-SAIFのメッセージ

OSQZSSにL1-SAIF信号の受信機能を追加するために，Viterbi復号やCRCの勉強を始めました．

PRN183の信号は，問題なく受信できますので，FECによって符号化された500spsのシンボルを
受信機から出力して記録しておきます．まずは，これをオフラインで処理することで，アルゴリズムの
開発と動作確認を進めます．

Viterbi復号については，原理はともかく後回しで，The Error Correcting Codes Pageのソースを
参考に実装しました．CRCの原理と実装については，Wikipediaの記事が非常に参考になります．

CRCも一致し，L1-SAIFのビットが正常に復号できているようですので，次はメッセージの解読です．


11000110000011010001111111111101111111111101111111
11110000000000000111111111110111111111111111111110
00011111111111011111111111111111111110011111111111
01111111111101111111111111101110111001011110111001
11111011100101111011101110011011000101001001001001
01010011011000011111111111011111111111011111111111
01111111111101111111111101111111111111101110111011
10111011100010010000000110001010000000000000000000
00011111111100000000010011010000100000000001011111
00011111101110000000100000101011111101000100110110
10011010011000011111111111011111111111011111111111
01111111111101111111111101111111111111101110111011
10111011100010100000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000111001100110010100110100

試験信号との複合測位（4）

12月9日に東京海洋大学のアンテナをお借りして取得したデータを後処理してみました．

11月28日の解析と同様に，GPSの軌道とクロック情報にはIGSの精密暦を使用し，
みちびきは放送暦を使っています．

11月には，ばらつきの大きかったみちびきの放送暦ですが，精度も改善され，安定した
複合測位が得られるようになりました．

複合測位で北側に誤差が大きくなるのは，みちびきが南側に位置しているときだけ
低い仰角で観測されるからです．そのため，レンジ方向の誤差が北向きに現れています．

定常運用の開始

みちびきさんによると，15日に初期機能確認を終え，定常運用を開始したそうです．

衛星番号も標準の193番となりました．
おかげで，15日の朝から198番で観測していた24時間データが無駄に…

今週末にでも，取り直します．

正式運用間近！

みちびきさんによると，初期機能確認がそろそろ完了するようだ．
正式運用までもう少し．

複合測位だけでは，測位精度に大幅な改善は見込めないので，
（と言うか，オープンスカイでは劣化するだろう．）
L1-SAIFによる補正情報を取得できるように受信機を改良しないといけないな．

Viterbi復号とか，面倒すぎる…

試験信号との複合測位（3）

12月になったら放送暦の精度が良くなったとの情報をいただいたので，複合測位に再挑戦しました．
今回は，GPSのみでの測位と一致性の高い結果となり一安心．
受信機アルゴリズムのバグではなかったようです．

測位結果のばらつきが大きいのは，受信環境が悪く，マルチパスの影響が大きいためです．
週末にでも，東京海洋大学でアンテナをお借りして，データを取得してみます．

コード追尾ループの帯域も，もう少し狭くして良いかもしれません．
キャリアスムージングも試してみよう．

放送暦の精度

衛星クロックの補正と同様に，同一の基準時刻を持つ放送暦から計算される受信機－衛星間距離から，
IODEおよびIODCが一番若いものを基準とした距離差を計算してみました．

やはりばらつきが大きいです．軌道とクロックの推定が上手くいってないのでしょうか？

解析に利用したデータセットを，以下のリンクで公開します．

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