高須さんのところに
skytraqから送られてきたrawデータ対応の
GPS+BeiDou受信機をお借りして評価しています．
NavSparkのBeiDou版かと思っていたら，モジュールタイプでした．
多分中身は同じで，CAN5125とVenus 8なのでしょう．
ファームウェアはrawデータ対応のカスタム品です．
観測データについては，GPSのrawデータ出力に対応している
S1315F-RAWと同じフォーマットなので，問題なくデコードできます．
しかし，BeiDouの航法メッセージのデコードが面倒なうえに，
ファームウェアがバグだらけ．ほぼskytraqのバグ取り要員です．
バグを指摘すると，次の日には新しいファームウェアが送られてきます．
1週間も経たずに，すでに2回もファームウェアが更新されました．
S1315F-RAWを評価したときを思い出します．
歴史は繰り返される．
ソフトウェア受信機で
BeiDouの単独測位をしてから1年以上経つので，
ほどんど仕様を忘れており，同じところでつまづいています．
そんな訳で，備忘録．
1. 航法メッセージにはD1とD2の2種類がある．MEO/IGSOはD1，GEOはD2を放送．
2. D1が50bpsなのに対して，D2は500bps．
3. D1のサブフレームは6秒毎に繰り返される．一方，D2は0.6秒毎．
4. 5つのサブフレームで1つのフレームを構成．D1は30秒，D2は3秒で1フレーム．
5. D1のSOWは，それが含まれるサブフレームの先頭が送信された時刻を示す．
（GPSの場合は，次のサブフレームが送信される時刻．）
6. D2のSOWは，それが含まれるフレームの先頭が送信された時刻を示す．
（サブフレームではないので注意．5つのサブフレームのSOWは同じ．）
7. D1のephemerisは，サブフレーム1～3に含まれる．
8. D2のephemerisは，サブフレーム1のページ1～10に含まれる．
9. D2のサブフレーム1は最初の150ビットのみが有効．残りはリザーブ．
（リザーブは0と1の繰り返し．）
これだけ思い出すのに，結局BeiDouのICDを再度読み直す羽目に．
almanacをデコードする元気がなくなったので，とりあえずephemerisだけで良しとします．
さて，GPS+BeiDouの評価をしていて気付いたのですが，いくつかの
BeiDou衛星が正常に受信できていません．
2007年に打ち上げられたC30は電波を出していないようで，
そもそも受信ができません．
C13はhealthフラグが立っていました．メンテナンス中でしょうか．
C02は東京からだと仰角が低く，受信が難しいようです．
問題はC04です．受信強度が高く，healthフラグも問題ないのですが，
なぜかephemerisが正常と判断されません．
ephemerisのパラメータをひとつひとつ調べてみると，
Week Numberが3000週を超えるような大きな値を示していました．
今週は，正しくは436です．
これは明らかな異常で，healthフラグを立てるべきなのですが，
普通に運用されています．
結構重大な不具合かと思うのですが，GNSS界隈でもまったく
ニュースになっていません．なにか見落としている？
【追記】Trimble NetR9でモニタしてみると，healthフラグが立っている
C02は正常に認識されて赤く表示されていますが，C04のephemerisは
IODEが認識されていないのにhealthフラグはクリアです．
やっぱり異常だよな，これ．
（クリックで拡大）
