Display of MADOCA-PPP ionospheric delay information using QZS L6 Tool

category: gnss

Table of contents

Introduction

The Quasi-Zenith Satellite (QZS), petnamed Michibiki, is operated by the Cabinet Office, Government of Japan, and it not only broadcasts positioning signals like GPS, but also broadcasts signals that improve positioning accuracy.

One of these signals is MADOCA-PPP (multi-GNSS advanced orbit and clock augmentation - precise point positioning), which is broadcast in the L6 frequency band. In the future, ionospheric delay information will be broadcast on MADOCA-PPP from the Michibiki satellite.

In addition, the MADOCALIB (MADOCA-PPP test library), which the Cabinet Office has released on GitHub as open source, can handle this ionospheric delay information from version 1.2. This ionospheric delay information enabled high-precision positioning in a short time.

This time, we have updated the open source QZS L6 Tool to observe the contents of this ionospheric delay information.

MADOCA-PPP ionospheric delay information

The Michibiki satellite broadcasts CLAS (centimeter level augmentation service) for Japan using the L6D signal, and MADOCA-PPP, which can be used worldwide, using the L6E signal. From new Michibiki satellites to be launched in the future, it is expected that ionospheric delay information for MADOCA-PPP will be transmitted using the L6D signal. This signal format is described in the specification IS-QZSS-MDC-002.

However, even after reading the specifications, I could not understand how the ionospheric delay information is transmitted. Therefore, I will use the MADOCA-PPP archive data to confirm the transmission method. The archive data also includes data that will be broadcast from the Michibiki satellite in the future. The target PRN (pseudo random noise) numbers here are 200 and 201. Ionospheric delay information will be available from June 28, 2024 at 00:00 UTC.

CLAS and MADOCA-PPP transmit one data part (DP) per second, with 2000 bits per DP. The DP includes a header and Reed-Solomon error correction code, and the net data length excluding these is 1695 bits. Five DPs make up one subframe (SF), and six SFs make up one frame. In other words, this information is transmitted every 30 seconds. The type of data being transmitted is identified by the subtype (ST) number. This ST data is variable length and is transmitted by packing it in front within the SF. One DP may contain multiple ST data, or one ST data may be transmitted across multiple DPs, but ST data is never transmitted across SFs. The remaining bit string at the end of the SF is zero-padded. The 1-bit subframe indicator is turned on in the header of the DP at the beginning of the SF. The 12-bit message number at the beginning of the DP uses a fixed value of 4073.

On the other hand, the new MADOCA-PPP ionospheric delay information uses 1 or 2 as the 12-bit message type (MT, synonymous with the message number mentioned above) at the beginning of the DP. MT1 is a message for defining coordinates, and multiple rectangular or circular planes are defined in one message along with the area number. On the other hand, MT2 transmits the pseudorange correction amount for each satellite within the plane defined by MT1. These are also variable-length data. First, in a DP with subframe indicator on, one MT1 message is transmitted, followed by multiple MT2s for the number of defined plane area numbers. MT1 is transmitted for each 8-bit region ID. I don’t know the relationship between the region ID and the coordinates. Information may be transmitted across multiple DPs, and a DP with subframe indicator off must be concatenated with a DP with subframe indicator on. At this time, the maximum number of DPs to be concatenated is not defined. The remaining bit string is zero-padded, as in CLAS. On the other hand, unlike CLAS, when there is no information to send, a DP with all zeros and subframe indicator on is transmitted. The transmission methods for CLAS, MADOCA-PPP, and MADOCA-PPP ionospheric delay are summarized in the table below.

	CLAS	MADOCA-PPP	MADOCA-PPP ionospheric delay information
PRN number range	193-199	203-211	200, 201
Data identification	ST number (MT number is fixed at 4073)	Same as left	MT number
Data period	30 seconds	Same as left	Undefined
SF head contents	ST1 or ST3	Same as left	MT1

Display of MADOCA-PPP ionospheric delay information using QZS L6 Tool

Now that we know how ionospheric delay information is transmitted, we will create a code to decode the ionospheric delay information. We tried to display it in real time using the Internet Stream Distribution of MADOCA-PPP Reinforcement Information, which also delivers L6 data that will likely be broadcast from the scheduled launches of Michibiki No. 5, 6, and 7. Anyone can use the archive data, but an application is required to use this stream distribution.

In the following video, the left is PRN200, and the right is PRN201. With MADOCA-PPP, one DP is transmitted per second, so this video also changes every second.

Here, the trace option -t 1 is used to display the contents of the supplementary information. Specifically, str2str -in ntrip://[user id]:[password]@[NTRIP caster address]/[mount point] 2> /dev/null | qzsl6read.py -t 1 is used. When information other than null is transmitted, many characters are displayed. From this video, we can see that different information is transmitted between PRN200 and PRN201. Null DPs are also frequently observed.

Plane coordinate definition using message type 1

As an example, let’s download the PRN 200 data for one hour from 00:00:00 UTC on August 16, 2024 from the Michibiki archive site and observe the MT1 information of PRN200. From the above string, extract the string that starts with MT1 using a text editor or pager.

MT1 Epoch=00:00:30+5 UI=30s(5) MMI=0 IODSSR=2 Region=1  4191bit  NumAreas=3
 # shape lat[deg] lon[deg] lats lons / radius[km]
 5 RECT     -34.0    132.5  3.0  6.5
 6 RECT     -31.5    119.5  4.0  6.5
 8 RECT     -20.5    119.5  7.0  6.5
MT1 Epoch=00:00:33+5 UI=30s(5) MMI=0 IODSSR=2 Region=3  2504bit  NumAreas=2
 # shape lat[deg] lon[deg] lats lons / radius[km]
 1 RECT      17.4    121.4  1.3  1.1
 2 RECT      14.7    120.8  1.4  1.0
MT1 Epoch=00:00:35+5 UI=30s(5) MMI=0 IODSSR=0 Region=4* 77bit  NumAreas=1
 # shape lat[deg] lon[deg] lats lons / radius[km]
 1 RECT      -6.8    107.0  0.9  1.2

Here, three rectangular planes are defined for area ID 1. The first data is a rectangular plane for area number 5, with a span of ±3 degrees latitude and ±6.5 degrees longitude defined based on 34.0 degrees south latitude and 132.2 degrees east longitude (under the sea west of Adelaide, Australia) (generally, span refers to the distance from tip to tip, but here it refers to the angle difference from the center to the tip). Similarly, two planes are defined for area ID 3, and one plane is defined for area ID 4. Here, an alert (represented by an asterisk *) was issued for area ID 4. And MT1 containing these three area IDs was repeatedly transmitted.

Meanwhile, the contents of PRN 201 MT1 are as follows:

MT1 Epoch=00:00:30+5 UI=30s(5) MMI=0 IODSSR=2 Region=2  2614bit  NumAreas=2
 # shape lat[deg] lon[deg] lats lons / radius[km]
 4 RECT     -37.5    146.5  6.5  7.5
 7 RECT     -26.0    132.5  5.0  6.5
MT1 Epoch=00:00:32+5 UI=30s(5) MMI=0 IODSSR=0 Region=5  9936bit  NumAreas=8
 # shape lat[deg] lon[deg] lats lons / radius[km]
 1 RECT      43.7    142.5  2.5  4.3
 2 RECT      39.2    140.5  2.0  3.0
 3 RECT      34.2    140.0  3.0  2.5
 4 RECT      35.2    135.0  3.3  2.5
 5 RECT      32.8    130.3  2.8  2.2
 6 RECT      27.5    129.0  2.5  3.0
 7 RECT      24.5    124.2  1.0  1.8
 8 CIRCLE    26.9    142.2  100

Here, area IDs 2 and 5 are defined repeatedly, with 2 and 8 planes defined, respectively. Area ID 5, area number 8 defines a circular plane with a radius of 100 kilometers centered on the sea halfway between Chichijima and Hahajima in the Ogasawara Islands.

Similarly, the result of reading the PRN200 data 2024162all.200.l6 included in MADOCALIB ver.1.2 is as follows. This is located in sample_data/ in MADOCALIB. The sample data processes Geospatial Information Authority of Japan data near 36.11 degrees north latitude, 140.09 degrees east longitude, and is for the 162nd day (June 10th) from January 1, 2024.

MT1 Epoch=00:00:30+1 UI=30s(5) MMI=0 IODSSR=2 Region=1  4551bit  NumAreas=3
 # shape lat[deg] lon[deg] lats lons / radius[km]
 5 RECT     -34.0    132.5  3.0  6.5
 6 RECT     -31.5    119.5  4.0  6.5
 8 RECT     -20.5    119.5  7.0  6.5
MT1 Epoch=00:00:33+1 UI=30s(5) MMI=0 IODSSR=2 Region=3  2154bit  NumAreas=2
 # shape lat[deg] lon[deg] lats lons / radius[km]
 1 RECT      17.4    121.4  1.3  1.1
 2 RECT      14.7    120.8  1.4  1.0
MT1 Epoch=00:00:35+1 UI=30s(5) MMI=0 IODSSR=0 Region=4  1077bit  NumAreas=1
 # shape lat[deg] lon[deg] lats lons / radius[km]
 1 RECT      -6.8    107.0  0.9  1.2

The contents of this PRN200 MT1 were identical to the contents of PRN200 MT1 one hour from 00:00:00 UTC on August 16th. There were no coordinates in this plane coordinate definition string that matched the above coordinates. It seems that ionospheric delay correction was not effective in the PRN200 calculated with MADOCALILB ver.1.2. Next, let’s display the PRN201 data 2024162all.201.l6.

MT1 Epoch=00:00:30+1 UI=30s(5) MMI=0 IODSSR=2 Region=2  2794bit  NumAreas=2
 # shape lat[deg] lon[deg] lats lons / radius[km]
 4 RECT     -37.5    146.5  6.5  7.5
 7 RECT     -26.0    132.5  5.0  6.5
MT1 Epoch=00:00:32+1 UI=30s(5) MMI=0 IODSSR=0 Region=5  8536bit  NumAreas=8
 # shape lat[deg] lon[deg] lats lons / radius[km]
 1 RECT      43.7    142.5  2.5  4.3
 2 RECT      39.2    140.5  2.0  3.0
 3 RECT      34.2    140.0  3.0  2.5
 4 RECT      35.2    135.0  3.3  2.5
 5 RECT      32.8    130.3  2.8  2.2
 6 RECT      27.5    129.0  2.5  3.0
 7 RECT      24.5    124.2  1.0  1.8
 8 CIRCLE    26.9    142.2  100

The contents of this PRN201 MT1 were also identical to those of PRN201 MT1 on August 16. The plane coordinate definitions that matched the Geospatial Information Authority of Japan coordinates mentioned above were in region ID 5, area number 3. Hiroshima City, located at 34.44 degrees north latitude and 132.41 degrees east longitude, also belongs to PRN201 region ID 5, area number 5.

My plane coordinate notation mentioned above is difficult to understand. I would like to use QGIS or similar to create an easy-to-understand diagram.

Although the number of regions currently included in the MADOCA-PPP ionospheric delay information is limited, there is a lot of spare line capacity. I look forward to the future release of ionospheric delay information.

Calculate the number of days since January 1st

By the way, for this kind of analysis, it is useful to have software that can display the number of days since January 1st and GPS week number in calendar format. I use gpscal, which was previously posted on the Geospatial Information Authority of Japan’s website. It is a 64-line c-shell script credited to Hatanaka Y. on July 20, 1996. The script calculates the number of days with the shell script, calls the cal command, and formats the result with the awk command. It is a great piece of software, so I would be happy if they make it publicly available again.

$ gpscal.csh 06 2024
               June 2024
Week   Sun Mon Tue Wed Thu Fri Sat
2316                             1
                               153
2317     2   3   4   5   6   7   8
       154 155 156 157 158 159 160
2318     9  10  11  12  13  14  15
       161 162 163 164 165 166 167
2319    16  17  18  19  20  21  22
       168 169 170 171 172 173 174
2320    23  24  25  26  27  28  29
       175 176 177 178 179 180 181
2321    30
       182
$

Semantic Versioning

I have decided to adopt semantic versioning for the QZS L6 Tool. This is a versioning scheme that uses three numeric parts: major.minor.patch. The major number is updated when compatibility is lost in the output, the minor number is updated when a feature is added while maintaining backward compatibility, and the patch number is updated when a bug is fixed. I intend to update the patch number when adjusting the number of digits displayed. The current version is the epoch, and the QZS L6 Tool version number is 0.1.0 (in the conventional calendar versioning, it is 20240816upd).

Conclusion

I created a code to decode the ionospheric delay augmentation information of Michibiki MADOCA-PPP.

Ionospheric delay information is scheduled to be transmitted by different satellites using PRN200 and PRN201. When observing archive data and streaming data that have been released in advance, different contents were transmitted by PRN200 and PRN201. At present, it seems that the target area is fixed for each PRN, so it seems that the PRN to be received can be determined from rough coordinates. For example, the Geospatial Information Authority of Japan, which is located near 36.11 degrees north latitude and 140.09 degrees east longitude, will use PRN201, which will be broadcast by Michibiki 7.

In the future, I would like to continue my analysis and consider effective ways to use MADOCA-PPP.

Display of MADOCA-PPP ionospheric delay information using QZS L6 Tool

Introduction

MADOCA-PPP ionospheric delay information

Display of MADOCA-PPP ionospheric delay information using QZS L6 Tool

Plane coordinate definition using message type 1

Calculate the number of days since January 1st

Semantic Versioning

Conclusion

Related article(s):