高須さんのところに
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フラグはクリアです.
やっぱり異常だよな,これ.
(クリックで拡大)