QZS L6 ToolのCLASメッセージ対応

category: gnss

はじめに

日本の内閣府が運営する準天頂衛星(QZS: quasi-zenith satellite)みちびきに興味を持ち、その電波を追いかけています。みちびきからの高精度測位メッセージ解読を主眼としたQZS L6 Tool(キューズイエス・エルシックス・ツール)をGitHubにて公開しています。

QZS L6 Toolにて、みちびきがL6周波数帯にて放送するL6D信号のCLAS(centimeter level augmentation service、シーラス)メッセージも解読できるようにしました。サンプルデータも用意しましたので、ご興味のある方は、ぜひお試しください。これから、文書を整備して、少しずつ改良してゆきます。

CLASについては、みちびき公式ページにてメッセージ解読から測位計算まで行えるCLASテストライブラリCLASLIBが公開され、またビスステーションから仮想基準局を生成できるVRSC受信機も販売されています。

これらに対し、QZS L6 Toolは、メッセージ観測に的を絞りました。仕様書を読みながら自らこのPythonコードを記述しましたので、CLASLIBとは独立しています。BSD 2-clause licenceを適用しますので、商用・非商用、修正の有無を問わず、このプログラムを利用できます。

高圧縮な状態空間表現メッセージCompact SSR

例えば、高精度衛星測位の一つの方法であるRTK(realtime kinematic)を利用する際には、RTCM(Radio Technical Commission for Maritime Services)形式のバイナリデータ伝送が広く用いられます。QZS L6 Tool開発のがきっかけは、このメッセージの中身を見たいと考えたからです。QZS L6 Toolは、RTCMメッセージや、L6E信号のMADOCA(multi-GNSS advanced demonstration tool for orbit and clock analysis、マドカ)バイナリ形式メッセージを解読することからはじめました。

測位精度を高めるには、2つのアプローチがあります。観測空間表現OSR(observation space representation)と、状態空間表現SSR(state space representation)です。前者には基準局での衛星信号観測を活用するRTKが含まれます。MADOCAやCLASは後者のアプローチです。

SSR情報を伝送するRTCMメッセージも定義されています。グローバル測位サービス株式会社(GPAS)が有償配信するMADOCAプロダクト、IGS(International GNSS Service)のリアルタイムサービス(中部大学 海老沼先生による利用例)、以前にJAXAが無償配信していたMADOCAプロダクト(利用例)などは、RTCMメッセージにてインターネット経由で配信されます。GPASがみちびきL6E信号を用いて無償配信するMADOCAプロダクトのメッセージ形式は、GPASが公開しています(日本語版英語版)。

RTCMメッセージは、SSR情報伝送にはやや冗長なところがあります。できる限りSSR情報の伝送容量を減らす工夫を行ったバイナリ形式メッセージがCompact SSR(CSSR)です。CSSRをRTCM形式にて伝送するには、三菱電機株式会社の所有メッセージタイプ番号4073を用います。みちびきにて2022年9月30日から試験的に放送される予定の新MADOCA-PPPは、仕様書IS-QZSS-MDC-001にて規定されるCSSRを利用します。CSSRを経験するために、このコードを作成しました。これからは、CSSRが広く用いられるかもしれません。

仕様書IS-QZSS-MDC-001には、信号認証メッセージQZNMA(quasi-zenith satellite navigation message authentication)の記述があり、そのベンダーID(信号種別コード)も定義されていますが、そのフォーマットを規定する仕様書IS-QZSS-SAS(signal authentication service)はまだ公開されていません。

message flows from observation, service provider, and quasi-zenith satellites

すべてのメッセージをそのままの形式で利用するよりもむしろ、RTCM形式に変換して利用する方が、統一性があり便利なようです。

Compact SSRの伝送形式

みちびきのL6メッセージ長は2000ビットであり、L6信号チャネルにて1秒間に1メッセージが放送されます。L6メッセージの内容部分(ペイロード)は1695ビット長の固定長ビット列であり、この部分を「データパート」と呼びます。CLAS、MADOCA、MADOCA-PPP、QZNMAともに、30秒間にてひとつの単位(フレーム)を構成します。みちびきは、くり返しこのフレーム内容を更新し伝送します。

CLASとMADOCA-PPPにて用いられるCSSRメッセージは、このフレーム内に格納されます。CSSRは、可変長メッセージであり、現在はサブタイプ1から12までのメッセージ種類が定義されています。サブタイプ1のCSSRメッセージには、扱う衛星(例えばGPS01)と信号(例えばL1 C/A)の組合せがビット表現されています。一方、サブタイプ1以外のメッセージには、この組合せ情報が含まれず、衛星軌道、衛星内部時計、ユーザ観測データの補正量しか記述されません。したがって、CSSRメッセージ解読には、サブタイプ1メッセージの解読と、補強対象情報の保持が必要です。

CSSRでは、複数メッセージを前詰めにて収納します。さらに、CSSRには、明らかなメッセージ長の情報がなく、解読にはメッセージを先頭から順に読み進めなければなりません。複数CSSRメッセージは、複数データパートに連続して配置され、対象衛星や信号によりCSSRメッセージ長が変わります。

CSSRは、5データパートで1サブフレームを構成します。サブフレームは、データ区切り識別に用いられます。サブフレームの先頭に属するデータパートには、ヘッダにある「サブフレーム・インジケータ」がオンになり、ユーザ受信機はこのフラグによりCSSRメッセージ区切りを検出します。CSSRメッセージ群は、フレーム内に閉じて伝送され、残りはゼロ・パディングされます。

message format of CSSR (仕様書IS-QZSS-L6-004より引用したメッセージ送信例。実際のサブタイプ番号順はここに記述された通りではありませんでした)

サブフレーム先頭のCSSRサブタイプ番号割当について、仕様書には明示されていませんが、フレーム先頭にサブタイプ1が配置されるようです。フレーム途中のサブフレーム先頭には、サブタイプ3メッセージ(衛星クロック補正)が配置されていました。

結局、CSSR復号は、サブフレーム・インジケータによりビット列の先頭を見つけ、やっと解読できるようになったCSSRメッセージについてサブタイプ番号を読み、サブタイプ1番のメッセージ解読からの合計30秒間をかけてすべての情報を読み取ることです。サブタイプ1CSSRメッセージ送信後に受信開始となる最悪ケースにおいては、受信開始から30秒後にCSSR復号開始になるので、最初の全メッセージ取得にかかる時間は60秒間です。

Compact SSR復号の実装

CSSRメッセージ復号のひとつの方法は、サブタイプ1のデータパートを発見後、連続する5データパートを受信して復号し、それに続く連続する5データパートを受信して復号する動作をくり返すことです。ビズステーションVRSC受信機の状態表示は、5秒ごとに更新されますので、この方法を採用しているようです。

ここでは、サブタイプ1のデータパートを発見後、その残りビット数をチェックしながらメッセージを読み進めます。ひとつのCSSRメッセージを読み終えたら、データサイズを求めてCRCを付加して、RTCMメッセージを作成します。残りビット数が足りなければ、次のデータパートを読みます。なるべくリアルタイムで情報表示したいからです。

情報理論では、メッセージ伝達終了後に直ちに復号できるような符号を瞬時符号と呼びます。CSSRメッセージは、この瞬時符号に分類されますので、メッセージ復号後すぐにRTCM作成することを目指しました。メッセージ区切りの明瞭な符号を情報理論ではコンマ符号と呼びますが、CSSRはコンマ符号ではないといえます。L6E信号にて伝送される現行のMADOCAは、RTCMメッセージから誤り訂正部分を除き、ビット列をバイトアラインしています。現行MADOCAは、コンマ符号といえる部分がありますので、CSSRよりも復号が容易です。

サンプルを用いたQZS L6 Toolの体験

準備

QZS L6 ToolをGitHubページからダウンロードします。ZIPファイルをダウンロードする方法と、gitコマンドを利用する方法があります。おすすめは、ソースコード更新の容易なgitコマンド利用です。

git clone https://github.com/yoronneko/qzsl6tool

すでにgitコマンドにてダウンロードされている方は(感謝)、そのディレクトリ内でgit pullを実行することにより最新コードに更新されます。

みちびきCLASアーカイブ

CLASのアーカイブデータは、みちびき公式ページにて入手できます。サンプルには、ここから得た2022年1月1日00:00:00 UTCから1時間分のデータをおきました。これを復号してみます。QZS L6 Toolのpythonディレクトリにて、qzsl62rtcm.py(QZS L6 data to RTCM conversion)を実行します。

$ cat ../sample/2022001A.l6 | ./qzsl62rtcm.py | more
193 Hitachi-Ota:0  CLAS SF1 DP1 ST1 ST3 ST2
193 Hitachi-Ota:0  CLAS SF1 DP2 ST4 ST7 ST11 ST6
193 Hitachi-Ota:0  CLAS SF1 DP3 ST12 ST6
193 Hitachi-Ota:0  CLAS SF1 DP4 ST12
193 Hitachi-Ota:0  CLAS SF1 DP5
193 Hitachi-Ota:0  CLAS SF2 DP1 ST3 ST11 ST6
193 Hitachi-Ota:0  CLAS SF2 DP2
193 Hitachi-Ota:0  CLAS SF2 DP3 ST12 ST6
193 Hitachi-Ota:0  CLAS SF2 DP4 ST12
193 Hitachi-Ota:0  CLAS SF2 DP5
193 Hitachi-Ota:0  CLAS SF3 DP1 ST3 ST11 ST6
193 Hitachi-Ota:0  CLAS SF3 DP2 ST12
...

このコードは、標準入力からデータを読み、標準出力に解読結果を表示します。結果表示は、左から、PRN番号(193はみちびき初号機)、管制局(ここでは常陸太田)、管制局2系統の最初の設備(0または1)、ベンダID(CLAS)、サブフレーム番号(SF1)、データパート番号(DP1)、そしてこのデータパートにサブタイプ1・3・2の情報を含むことがわかります。複数データパートに連続するメッセージについては、後の方のデータパートのところにサブタイプ番号(ST1など)が表示されます。

トレースオプション-tとともに自然数を指定すると、より詳細な情報が表示されます。

$ cat ../sample/2022001A.l6 | ./qzsl62rtcm.py -t 1 | more
ST1 G05 L1 C/A L2 L2C(M+L) L2 Z-tracking
ST1 G13 L1 C/A L2 Z-tracking
ST1 G14 L1 C/A L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G15 L1 C/A L2 L2C(M+L) L2 Z-tracking
ST1 G18 L1 C/A L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G20 L1 C/A L2 Z-tracking
ST1 G23 L1 C/A L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G24 L1 C/A L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 E02 E1 B+C E5a I+Q
ST1 E03 E1 B+C E5a I+Q
ST1 E05 E1 B+C E5a I+Q
ST1 E08 E1 B+C E5a I+Q
ST1 E13 E1 B+C E5a I+Q
ST1 E15 E1 B+C E5a I+Q
ST1 E24 E1 B+C E5a I+Q
ST1 E25 E1 B+C E5a I+Q
ST1 J02 L1 C/A L2 L2C(M+L) L5 I+Q
ST1 J03 L1 C/A L2 L2C(M+L) L5 I+Q
ST3 G05  0.5
ST3 G13  0.1
...
ST3 J02 -0.3
ST3 J03  0.2
ST2 G05 IODE= 74 radial=-0.1 along=-0.3 cross=-0.3
ST2 G13 IODE= 13 radial= 0.1 along= 0.2 cross= 0.2
ST2 G14 IODE= 23 radial= 0.2 along= 0.7 cross= 0.7
ST2 G15 IODE= 71 radial= 0.1 along= 0.3 cross= 0.3
...

トレース・オンにより、多くの情報が表示されます。この例において、先頭のサブタイプ1(ST1)メッセージには、GPS05L1 C/A信号、L2C(M+L)信号、L2 Z-tracking信号が対象であることを示しています。L5帯信号に関する情報は含まれません。ST3メッセージには衛星ごとの時刻補正量が、ST2メッセージには衛星ごとの軌道補正量が、それぞれ記述されています。この出力をファイルにリダイレクトすることも可能です。仕様書IS-QZSS-L6-004とネット情報を参考にこのメッセージ解読結果を読み進めると、CLAS高精度受信機のバックヤードを見ることができるような気がします。

また、CLAS解読結果をRTCMメッセージに変換するためには、オプション-rを指定します。RTCMメッセージを解読するツールはshowrtcm.pyです。しかしながら、CSSR RTCMファイルを測位活用できるコードは、まだ、ないようです。このオプション指定により状態メッセージは出力されなくなりますが、-mオプションにより標準エラー出力に状態メッセージを表示されます。

cat ../sample/2022001A.l6 | ./qzsl62rtcm.py -r > clas.rtcm
cat clas.rtcm | ./showrtcm.py | more
RTCM 4073   CSSR ST1       epoch=518400 iod=13
RTCM 4073   CSSR ST3       hepoch=0 iod=13
RTCM 4073   CSSR ST2       hepoch=0 iod=13
RTCM 4073   CSSR ST4       hepoch=0 iod=13
RTCM 4073   CSSR ST7       hepoch=0 iod=13
...

パイプを使えば、中間ファイルclas.rtcmを作らずに済みます。

cat ../sample/2022001A.l6 | ./qzsl62rtcm.py -r | showrtcm.py | more
RTCM 4073   CSSR ST1       epoch=518400 iod=13
RTCM 4073   CSSR ST3       hepoch=0 iod=13
RTCM 4073   CSSR ST2       hepoch=0 iod=13
RTCM 4073   CSSR ST4       hepoch=0 iod=13
RTCM 4073   CSSR ST7       hepoch=0 iod=13
...

現在は高圧縮なサブタイプ12の情報が送信されていますが、以前はサブタイプ8と9により地域ごとの補正量を表現していました。2018年1月1日 00:00:00 UTCのL6アーカイブデータを復号してみます。

cat ../sample/2018001A.l6 | ./qzsl62rtcm.py
193 Hitachi-Ota:0  CLAS SF1 DP1 ST1 ST3 ST2 ST4
193 Hitachi-Ota:0  CLAS SF1 DP2 ST5 ST7 ST6 ST8
193 Hitachi-Ota:0  CLAS SF1 DP3 ST9
193 Hitachi-Ota:0  CLAS SF1 DP4 ST6 ST8
193 Hitachi-Ota:0  CLAS SF1 DP5 ST9
...

サブタイプ8とサブタイプ9のメッセージが放送されていました。

Allystar HD9310オプションC

Allystar HD9310オプションCは、CLAS受信用ファームウェアと、MADOCA受信用ファームウェアの2種類が公開されていて、これらは排他利用するようになっています。私はこの受信機を2台、所持して、それぞれCLAS受信用とMADOCA受信用にしています。Allystar受信機は、みちびきL6信号について、最大4衛星分を同時に受信できます。現在のところ、すべてのみちび衛星は同一内容のL6情報を放送していますので、ここでは、もっとも電波強度の高い衛星からの情報を採用しています。

allystar receiver signal processing はじめに、2021年3月26日 23:12:00 UTCから1分間、MADOCAファームウェアHD9310受信機にて収録したAllystarバイナリデータを観察します。

cat ../sample/20220326-231200mdc.alst | alst2qzsl6.py | more
209 2022-03-26 23:12:00 43
206 2022-03-26 23:12:00 43
205 2022-03-26 23:12:00 37 RS
204 2022-03-26 23:12:00 43
---> prn 209 (snr 43)
209 2022-03-26 23:12:01 43
206 2022-03-26 23:12:01 43
205 2022-03-26 23:12:01 37
204 2022-03-26 23:12:01 43
...

みちびき2号機(PRN204)、3号機(PRN209)、4号機(PRN205)、初号機後継機(PRN206)の信号を発見しました。次に、このL6メッセージを解読します。

cat ../sample/20220326-231200mdc.alst | alst2qzsl6.py -l | qzsl62rtcm.py |  more
209 Hitachi-Ota:0* 2022-03-26 23:11:44 1062(26) 1068(17)
206 Hitachi-Ota:0* 2022-03-26 23:11:44 1057(8) 1061(8)
206 Hitachi-Ota:0* 2022-03-26 23:11:46 1062(26) 1068(17)
206 Hitachi-Ota:0* 2022-03-26 23:11:46 1057(8) 1061(8)
...

同様に、同一時刻でのCLASファームウェアでのバイナリデータを観察します。

cat ../sample/20220326-231200clas.alst | alst2qzsl6.py | more
199 2022-03-26 23:12:00 43
195 2022-03-26 23:12:00 37 RS
194 2022-03-26 23:12:00 43
196 2022-03-26 23:12:00 42
---> prn 199 (snr 43)
199 2022-03-26 23:12:01 43
195 2022-03-26 23:12:01 37 RS
194 2022-03-26 23:12:01 43
196 2022-03-26 23:12:01 42
...

みちびき初号機は、2022年3月25日に待機運用に移行しましたのでPRN193はここに観測されることはなくなりました。

cat ../sample/20220326-231200clas.alst | alst2qzsl6.py -l | qzsl62rtcm.py | more
199 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
196 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS SF1 DP1 ST1 ST3 ST2
196 Hitachi-Ota:1  CLAS SF1 DP2 ST4 ST7 ST11 ST6
194 Hitachi-Ota:1  CLAS SF1 DP3 ST12 ST6
196 Hitachi-Ota:1  CLAS SF1 DP4 ST12
196 Hitachi-Ota:1  CLAS SF1 DP5
194 Hitachi-Ota:1  CLAS SF2 DP1 ST3 ST11 ST6

この例では、受信開始時刻から(15行分なので)15秒経過後に、サブタイプ1のCLASメッセージを発見して、解読が始まりました。

PocketSDR

高須先生のPocketSDRのサンプルデータを処理してみます。ソフトウェア無線なので、収録信号を後処理することにより、自由に対象衛星を選択できるところが嬉しいです。2021年12月26日 08:22:12 UTCに高須先生が収録された30秒間のL6帯データを利用します。オプション指定により、みちびき2号機のMADOCAメッセージを対象にしました。PocketSDRのメッセージ出力からL6メッセージを抽出するコードpksdr2l6.py(PocketSDR message to L6 message conversion)を用います。

cat ../sample/20211226-082212pocketsdr-mdc.txt | ./pksdr2l6.py | qzsl62rtcm.py | more
204 Hitachi-Ota:0* 2021-12-26 08:21:58 1059(24)
204 Hitachi-Ota:0* 2021-12-26 08:22:00 1062(24) 1068(17)
204 Hitachi-Ota:0* 2021-12-26 08:22:00 1059(2)
204 Hitachi-Ota:0* 2021-12-26 08:22:02 1062(24) 1068(17)
204 Hitachi-Ota:0* 2021-12-26 08:22:02 1065(19)
204 Hitachi-Ota:0* 2021-12-26 08:22:04 1062(24) 1068(17)
...
cat ../sample/20211226-082212pocketsdr-mdc.txt | ./pksdr2l6.py | qzsl62rtcm.py -r | showrtcm.py | more
RTCM 1059 G SSR code bias G01 G02 G03 G05 G06 G07 G08 G09 G10 G12 G13 G15 G16 G17 G19 G20 G21 G22 G24 G25 G26 G27 G29 G30 (nsat=24 iod=4 cont.)
RTCM 1062 G SSR hr clock  G01 G02 G03 G05 G06 G07 G08 G09 G10 G12 G13 G15 G16 G17 G19 G20 G21 G24 G25 G26 G29 G30 G31 G32 (nsat=24 iod=4)
RTCM 1068 R SSR hr clock  R01 R02 R03 R04 R05 R07 R08 R12 R13 R14 R15 R17 R18 R19 R20 R21 R22 (nsat=17 iod=5)
RTCM 1059 G SSR code bias G31 G32 (nsat=2 iod=4)
...

次にCLASメッセージを対象に処理します。

cat ../sample/20211226-082212pocketsdr-clas.txt | ./pksdr2l6.py | qzsl62rtcm.py | more
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
194 Hitachi-Ota:1  CLAS
...

ベンダーIDなどは復号できていているのですが、この30秒間にサブタイプ1メッセージがなかったために、CLASメッセージ解読は始まりませんでした。収録時間があと30秒程度長ければ、メッセージが表示される見込みです。PocketSDRに憧れる日々を過ごしています。

自らの観測機器を用いたQZS L6 Toolの利用

TCPパケット読み書きツールncや、オープンソース測位ツールRTKLIBのコマンドライン・アプリケーションstr2strを用いて、QZS L6 ToolにてL6メッセージやRTCMメッセージをリアルタイム観測します。

例えば、Allystar HD9310オプションC受信機がstr2strによりリモート観測できるようにセットアップされていることを仮定します。私はマイコンRaspberry Piにこの受信機を接続しています。例えば、次のようにして、TCPポート2000番で経由でHD9310オプションC受信機を利用できるようにします。

str2str -in serial://ttyCLAS:115200 -out tcpsvr://:2000

このリモート機器にて観測したデータを表示してみます。例えばIPアドレス192.168.0.1、ポート番号2000の機器に対する観測は次のように行います。

nc 192.168.0.1 2000 | ./alst2qzsl6.py
nc 192.168.0.1 2000 | ./alst2qzsl6.py -l | ./qzsl62rtcm.py
nc 192.168.0.1 2000 | ./alst2qzsl6.py -l | ./qzsl62rtcm.py -r | ./showrtcm.py

例えば、NTRIP(networked transport of RTCM via Internet protocol、エヌトリップ。RTCM以外の情報も伝達できます)キャスタアドレスntrip.phys.info.hiroshima-cu.ac.jp、ポート番号80番、マウントポイントOEM7のRTCMメッセージは、RTKLIBアプリケーションのstr2strを用いて、次のように読むことができます。

str2str -in ntrip://ntrip.phys.info.hiroshima-cu.ac.jp:80/OEM7 2> /dev/null | showrtcm.py
RTCM 1087 R MSM7          R02 R03 R04 R12 R13 R21 R22 R23
RTCM 1097 E MSM7          E02 E03 E05 E08 E11 E12 E24 E25
RTCM 1117 J MSM7          J02 J03 J04 J07
RTCM 1127 C MSM7          C02 C04 C06 C16 C29 C35 C39 C40 C59 C60
RTCM 1127 C MSM7          C01 C03 C10 C21 C45
RTCM 1137 I MSM7          I01 I03 I04 I05 I07 I09
RTCM 1005   Position      34.4401061 132.4147804 233.362
RTCM 1033   Ant/Rcv info  0 "JAVGRANT_G5T NONE" 0 s/n N/A rcv "NOV OEM729" ver OM7MR0800RN0000 s/n N/A

時々、最初の起動時にCRCエラーメッセージが表示されるのは、showrtcm.pyのRTCMパケット先頭判定が甘いからです。ここでは、RTCM開始バイト列\xd3に続くメッセージ長ぶんだけメッセージを読み、CRC(cyclic redundancy check)エラーであれば次の開始バイト列\xd3を探す動作をくり返して、先頭パケットを見つけています。RTKLIBでのRTCMメッセージ解釈コードは、メッセージに含まれるメッセージ長をあてにせず、1バイトずつ読みながら逐次的にCRC符号によるチェックを行っていますので、とても安定して動作します。私も見習わねばと思っております。

もし、Allystar HD9310オプションC受信機生データが出力されるNTRIPキャスタがあり、そのマウントポイント名がわかれば、alst2qzsl6.py -lqzsl62rtcm.pyをパイプする用いる方法でCLASメッセージを観測することも可能です。

仕様書IS-QZSS-L6の解釈にはちょっと苦労しました。変数名が長くて紛らわしいのです。実は、今でもサブタイプ12メッセージにあるSTEC Correction Availabilityの2ビット情報の使い方を調べているところです。コード作成には、みちびき公式ページにあるパフォーマンススタンダード(PS-QZSS)及びユーザインタフェース仕様書(IS-QZSS)にある、説明資料と質疑応答の内容把握が必要でした。CLASメッセージの疑問点解決には、CLASLIBソースコードの参照が役立ちますが、なるべくCLASLIBに頼らない方針です。

おわりに

何とかCompact SSRを解読できました。次は、サブタイプ6、11、12に含まれる地域情報(compact network ID)のリアルタイム地図表示や、地域別の精度低下率DOP(dillution of precision)のリアルタイム表示、自らのコードによる高精度測位に挑戦してみたいです。

Galileo HAS(high accuracy service、ハス)にも興味がありますが、これにはPocketSDRなどのソフトウェア無線の高度な知識が求められます。HASにもCSSRが採用されるそうです。

2022年9月30日のMADOCA-PPP試験電波放送や、認証信号QZNMAの仕様書公開と試験電波放送を楽しみにしています。


関連記事