Trial delivery of QZSS's MADOCA-PPP started
Introduction
Today, on 2022-08-18, test distribution of augmentation information MADOCA-PPP (Multi-GNSS Advanced Orbit and Clock Augmentation - Precise Point Positioning) began on QZSS (quasi-zenith satellite system, petnamed Michibiki) L6E signals. Until now, MADOCA (Multi-GNSS Advanced Demonstration tool for Orbit and Clock Analysis) was delivered for trial. Due to the change in distribution format, many satellites have been targeted for autmentation and can be said to have been upgraded.
Using the Allystar HD9310 option C receiver and the freeware QZS L6 Tool publish on GitHub, I analyze the state of augmentation information switching and the distribution contents of MADOCA-PPP.
The left screen of the video shows the reception status of the Michibiki L6E signal, and the right screen shows its contents. Since all four Michibiki satellites transmit the same content, the strongest satellite signal is selected for decoding.
Augmentation information change
QZS L6 Tool update
MADOCA-PPP distribution was supposed to start around 08:00UTC, but it changed between 00:00UTC and 01:00UTC. This situation is analyzed with QZS L6 Tool. For QZS L6 Tool, please refer to article Compact SSR display capability on QZS L6 Tool. There is a bug in the previous code qzsl62rtcm.py
, so please update it.
cd qzsl6tool
git pull
Before new transmission
First, I analyzed the HD9310 receiver recorded data 20220817x.alst for one hour from 2022-08-17 23:00 UTC that I observed. Strictly speaking, recording starts 30 seconds before that period and ends 30 seconds after that, so the recording period is 1 hour and 1 minute.
cat 20220817x.alst | alst2qzsl6.py -l | qzsl62rtcm.py
alst2qzsl6.py
receives the raw data of the Allystar HD9310 option C receiver from the standard input and outputs the reception status (left screen in the previous video). The -l
option stands for L6 message output, suppressing the reception status display and printing the message for the strongest L6 signal. qzsl62rtcm.py
receives L6 messages from standard input and decodes their contents.
204 Hitachi-Ota:0* 2022-08-17 22:59:04 RTCM 1062(26) RTCM 1068(18)
205 Hitachi-Ota:0* 2022-08-17 22:59:04
205 Hitachi-Ota:0* 2022-08-17 22:59:06 RTCM 1062(26) RTCM 1068(18)
209 Hitachi-Ota:0* 2022-08-17 22:59:06
209 Hitachi-Ota:0* 2022-08-17 22:59:08 RTCM 1062(26) RTCM 1068(18)
205 Hitachi-Ota:0* 2022-08-17 22:59:08
205 Hitachi-Ota:0* 2022-08-17 22:59:10 RTCM 1062(26) RTCM 1068(18)
205 Hitachi-Ota:0* 2022-08-17 22:59:10
209 Hitachi-Ota:0* 2022-08-17 22:59:12 RTCM 1062(26) RTCM 1068(18)
209 Hitachi-Ota:0* 2022-08-17 22:59:12 RTCM 1057(8) RTCM 1061(8)
...
205 Hitachi-Ota:0* 2022-08-17 23:54:54 RTCM 1063(2) RTCM 1067(2)
205 Hitachi-Ota:0* 2022-08-17 23:54:56 RTCM 1062(26) RTCM 1068(18)
205 Hitachi-Ota:0* 2022-08-17 23:54:56
205 Hitachi-Ota:0* unknown (vendor ID 0b000)
205 Hitachi-Ota:0* unknown (vendor ID 0b000)
The distribution of MADOCA ended a little before 2022-08-18 00:00 UTC, and an undefined vendor ID 000
was broadcast. L6E signals transmit one message per second. Therefore, we find out the period by counting these undefined message lines.
$ cat 20220817x.alst | alst2qzsl6.py -l | qzsl62rtcm.py | wc -l
3659
$ cat 20220817x.alst | alst2qzsl6.py -l | qzsl62rtcm.py | grep unknown|wc -l
305
From this result, 305 undefined messages (about 5 minutes) out of 3659 messages were sent, so we can say that MADOCA delivery ended around 23:55 UTC on 2022-08-18. . Add trace option -t 2
to qzsl62rtcm.py
(1 for more details, 2 for bit images in addition to the details) and see the contents of vendor ID 000.
205 Hitachi-Ota:0* unknown (vendor ID 0b000)
Unknown dump: 010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010
Its payload (body) had an alternating code of 01 in binary.
After new transmission
Next, we analyze the recorded data 20220818a.alst for one hour from 2022-08-18 00:00 UTC.
$ cat 20220818a.alst | alst2qzsl6.py -l | qzsl62rtcm.py|grep unknown | wc -l
2377
Similarly, we can observe MADOCA-PPP when it started at 2022-08-18 00:40 UTC. Here’s a messages at the beginning of MADOCA-PPP transmission:
205 Hitachi-Ota:0* unknown (vendor ID 0b000)
205 Hitachi-Ota:0* unknown (vendor ID 0b000)
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* QZNMA
205 Hitachi-Ota:1* QZNMA
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
206 Hitachi-Ota:1* MADOCA-PPP
206 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* QZNMA
205 Hitachi-Ota:1* QZNMA
206 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP
205 Hitachi-Ota:1* MADOCA-PPP SF1 DP1 (Clock/Ephemeris LNAV) ST1
205 Hitachi-Ota:1* MADOCA-PPP SF1 DP2 (Clock/Ephemeris LNAV)
205 Hitachi-Ota:1* MADOCA-PPP SF1 DP3 (Clock/Ephemeris LNAV) ST2 ST3
205 Hitachi-Ota:1* MADOCA-PPP SF1 DP4 (Clock/Ephemeris LNAV)
205 Hitachi-Ota:1* MADOCA-PPP SF1 DP5 (Clock/Ephemeris LNAV)
In MADOCA-PPP, like MADOCA, the alert flag was on. An asterisk after the station name indicates that the alert flag is on.
(2022-08-22 added)
This alert flag turned off around 06:10:30 UTC.
After that, MADOCA-PPP was being broadcast from Hitachi-Ota station, and I could not observe the one from Kobe station. Michibiki’s augmentation information is created by four systems in total, two systems from the Hitachi-Ota station and two systems from the Kobe station, and it seems that the ground station uploads the information received first to the satellites. In order to be able to switch back to MADOCA at any time after MADOCA-PPP distribution, I presume that the Michibiki operators put on standby the two Kobe station’s information creation, created MADOCA information for one of the Hitachi-Ota system, and prepared creating MADOCA-PPP with another one of the Hitachi-Ota system during the preparation period.
The current MADOCA-PPP is distributing augmented information for clocks and ephemeris. Future MADOCA-PPP will include the ionospheric augmentation information. In addition, the LNAV
(legacy navigation) message used in the L1 C/A signal has been selected as the navigation message (Quasi-Zenith Satellite System Service User Interface Specifications Satellite Positioning Service Edition, in Japanese). In the future, CNAV (civil navigation) augmentation broadcast by Michibiki and GPS L2C signals and L5 signals, and CNAV2 augmentation broadcast by L1C signals may also be selected (displayed as CNAV
).
Augmenting information for MADOCA-PPP
MADOCA transmitted the SSR (space state representation) RTCM message without the CRC (cyclic redundancy check) code part. MADOCA-PPP, on the other hand, transmits messages in CSSR (compact SSR) format. The message content type is identified by a subtype (ST).
CSSR decoding begins by finding the ST1 message. Here, the satellites to be augmented and their signals are expressed as bit images. Subsequent information has a variable-length structure in which only information about satellites and signals whose bits are turned on is continuously transmitted, so if this ST1 message cannot be decoded, subsequent message decoding cannot be performed. Therefore, add the trace option -t 1
to qzsl62rtcm.py
to check this augmentation target satellite and its signal.
$ cat 20220818a.alst | alst2qzsl6.py -l | qzsl62rtcm.py -t 1 | grep -v unknown
ST1 G02 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G03 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G04 L1 C/A L1 Z-tracking L1 L1C(D+P) L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G05 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G06 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G07 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G08 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G11 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G12 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G13 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G14 L1 C/A L1 Z-tracking L1 L1C(D+P) L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G15 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G16 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G17 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G18 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G19 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G20 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G21 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G22 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G24 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G25 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G27 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G30 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 G31 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking
ST1 G32 L1 C/A L1 Z-tracking L2 L2C(M+L) L2 Z-tracking L5 I+Q
ST1 R01 G1 C/A G1 P G2 C/A G2 P
ST1 R02 G1 C/A G1 P G2 C/A G2 P
ST1 R03 G1 C/A G1 P G2 C/A G2 P
ST1 R04 G1 C/A G1 P G2 C/A G2 P
ST1 R07 G1 C/A G1 P G2 C/A G2 P
ST1 R08 G1 C/A G1 P G2 C/A G2 P
ST1 R11 G1 C/A G1 P G2 C/A G2 P
ST1 R12 G1 C/A G1 P G2 C/A G2 P
ST1 R13 G1 C/A G1 P G2 C/A G2 P
ST1 R14 G1 C/A G1 P G2 C/A G2 P
ST1 R15 G1 C/A G1 P G2 C/A G2 P
ST1 R17 G1 C/A G1 P G2 C/A G2 P
ST1 R18 G1 C/A G1 P G2 C/A G2 P
ST1 R19 G1 C/A G1 P G2 C/A G2 P
ST1 R20 G1 C/A G1 P G2 C/A G2 P
ST1 R21 G1 C/A G1 P G2 C/A G2 P
ST1 R24 G1 C/A G1 P G2 C/A G2 P
ST1 E01 E1 B+C E5a I+Q
ST1 E02 E1 B+C E5a I+Q
ST1 E03 E1 B+C E5a I+Q
ST1 E04 E1 B+C E5a I+Q
ST1 E05 E1 B+C E5a I+Q
ST1 E08 E1 B+C E5a I+Q
ST1 E09 E1 B+C E5a I+Q
ST1 E11 E1 B+C E5a I+Q
ST1 E12 E1 B+C E5a I+Q
ST1 E13 E1 B+C E5a I+Q
ST1 E15 E1 B+C E5a I+Q
ST1 E19 E1 B+C E5a I+Q
ST1 E24 E1 B+C E5a I+Q
ST1 E25 E1 B+C E5a I+Q
ST1 E26 E1 B+C E5a I+Q
ST1 E27 E1 B+C E5a I+Q
ST1 E30 E1 B+C E5a I+Q
ST1 E31 E1 B+C E5a I+Q
ST1 E33 E1 B+C E5a I+Q
ST1 E36 E1 B+C E5a I+Q
ST1 J02 L1 C/A L1 L1C(D+P) L2 L2C(M+L) L5 I+Q
ST1 J03 L1 C/A L1 L1C(D+P) L2 L2C(M+L) L5 I+Q
ST1 J07 L1 C/A L1 L1C(D+P) L2 L2C(M+L) L5 I+Q
MADOCA-PPP’s first augmentation information were for 25 satellites for GPS, 17 satellites for Glonass, 20 satellites for Galileo, and 3 satellites for Michibiki, totaling 65 satellites. By the way, the number of satellites MADOCA augmentation information, which was broadcast until just before, was 44 satellites in total, including 26 GPS satellites and 18 Glonass satellites, and Michibiki was not targeted for augmentation. Even in MADOCA-PPP, it seems that augmentation information for QZS-1R (J04), the successor to QZS-1 (J01), has not yet been created.
Next, add the -t 2
option to qzsl62rtcm.py
to see the contents of QZNMA (quasi-zenith satellite navigation message authentication). During the test delivery period, it was announced that this QZNMA information would be set to invalid information. All QZNA messages were observed to broadcast the following identical content:
QZNMA dump: 11110000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000001111000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000
The QZNMA interface specification IS-QZSS-SAS (signal authentication service) has not yet been published. Galileo’s navigational message authentication OSNMA is very complex, so I want QZNMA be a simpler implementation for navigation message authentication.
Offer of the real-time stream of Allystar receiver
Would you like to try MADOCA-PPP reception?
For a limited time, I will publish the HD9310 Option C real-time raw data in NTRIP format. Here is the connection information:
- address: ntrip.phys.info.hiroshima-cu.ac.jp
- port: 80
- mount point: MADOCA
- user name and password: none (leave blank)
For example, to observe MADOCA-PPP using RTKLIB’s CUI application str2str
and QZS L6 Tool, please execute the following command:
str2str -in ntrip://ntrip.phys.info.hiroshima-cu.ac.jp:80/MADOCA 2> /dev/null | alst2qzsl6.py -l | qzsl62rtcm.py
209 Hitachi-Ota:0 MADOCA-PPP
209 Hitachi-Ota:0 MADOCA-PPP
209 Hitachi-Ota:0 MADOCA-PPP
209 Hitachi-Ota:0 QZNMA
209 Hitachi-Ota:0 QZNMA
209 Hitachi-Ota:0 MADOCA-PPP
209 Hitachi-Ota:0 MADOCA-PPP
209 Hitachi-Ota:0 MADOCA-PPP
205 Hitachi-Ota:0 MADOCA-PPP SF1 DP1 (Clock/Ephemeris LNAV) ST1
205 Hitachi-Ota:0 MADOCA-PPP SF1 DP2 (Clock/Ephemeris LNAV)
209 Hitachi-Ota:0 MADOCA-PPP SF1 DP3 (Clock/Ephemeris LNAV) ST2 ST3
209 Hitachi-Ota:0 MADOCA-PPP SF1 DP4 (Clock/Ephemeris LNAV)
209 Hitachi-Ota:0 MADOCA-PPP SF1 DP5 (Clock/Ephemeris LNAV)
209 Hitachi-Ota:0 QZNMA
209 Hitachi-Ota:0 QZNMA
209 Hitachi-Ota:0 MADOCA-PPP SF2 DP1 (Clock/Ephemeris LNAV) ST7 ST3
209 Hitachi-Ota:0 MADOCA-PPP SF2 DP2 (Clock/Ephemeris LNAV)
209 Hitachi-Ota:0 MADOCA-PPP SF2 DP3 (Clock/Ephemeris LNAV)
Enjoy adding -t 1
option to qzsl62rtcm.py
.
Conclusion
The trial delivery of MADOCA-PPP has started on the Michibiki L6E signal. I would like to modify the QZS L6 Tool to convert from CSSR message to RTCM SSR message so that I can perform high-precision positioning with RTKLIB.
Related article(s):
- Display of MADOCA-PPP ionospheric delay information using QZS L6 Tool 16th August 2024
- QZS L6 Tool output format change 14th April 2024
- Health information expression for QZSS 7-satellite configuration 12th April 2024
- Galileo Timing Service Message 6th April 2024
- L1S signal analysis with QZS L6 Tool 11st November 2023
- Galileo HAS live stream 25th July 2023
- HAS message display capability on QZS L6 Tool 5th March 2023
- Capacity analysis of CLAS satellite augmentation information using QZSS archive data 9th June 2022
- QZSS CLAS tropospheric delay augmentation information for remote islands in Japan 17th May 2022
- Compact SSR display capability on QZS L6 Tool 29th March 2022
- Release of QZS L6 Tool, a positioning satellite message display tool 3rd February 2022