QZS L6 Tool code name arrangement and Septentrio receiver support
Navigation satellites broadcast superimposing distance measurement signal and navigation message signal so that users can determine coordinates simply by receiving radiowaves. This ranging signal is required to be received by a positioning receiver. On the other hand, navigation messages may be received by a positioning receiver or can be obtained through means such as the Internet.
Furthermore, recent navigation satellites may also provide disaster information message signals, augmentation message signals to improve positioning accuracy, navigation message authentication signals.
I have released a tool QZS L6 Tool (quasi-zenith satellite L6-band tool) to decode the messages broadcast by navigation satellite. In recent years, navigation satellite receivers have been able to output more messages, so I have revised the code name of the QZS L6 Tool to make it compatible with many receivers.
Although QZS L6 Tool includes the L6 band of quasi-zenith satellites in its name, it can also handle other than quasi-zenith satellites. It might be a good idea to change the name, but for now I’m thinking of keeping it as is.
Code name arrangement
For example, to receive Galileo HAS (high accuracy service) messages, I used a receiver Pocket SDRin the article HAS message support for QZS L6 Tool. At that time, only Pocket SDR receivers could receive HAS messages. Since HAS messages do not contain the satellite’s PRN (pseudo random noise) number, I made the HAS decode function only for Pocket SDR logfile (
Later, with a firmware update, the NovAtel OEM729 receiver was also able to receive HAS messages. Therefore, in addition to releasing the HAS live stream, and I added the HAS decode function for OEM729 receivers (
After that, I got Septentrio mosaic receivers that can handle a lot of signals, and also a message decoding receiver as the exciting future is becoming a reality where I might be able to receive more signals with a firmware update. I decided to separate the dependencies.
The following shows the correspondence between the code names of the previous QZS L6 Tool and the updated code names. In addition, the old code is made a symbolic link to the new code, and the new code recognizes its own code name to ensure compatibility. This compatibility has been verified with the test code
do_test.sh located in the
|old code name||new code name with an option||description|
|alst2qzsl6.py||alstread.py -l||Extract L6 messages from Allystar receiver raw data|
|qzsl62rtcm.py||qzsl6read.py||Display content of L6 message|
|showrtcm.py||rtcmread.py||Display RTCM message content|
|pksdr2qzsl6.py||psdrread.py -l||Extract L6 messages from Pocket SDR receiver log files|
|pksdr2has.py||psdrread.py -e | gale6read.py||View HAS message content from Pocket SDR receiver log file|
The following is a summary of the message output functions for each receiver with the new code. It consists of the receiver abbreviation and a word “read,” which indicates reading. In the computer world, the word dump is often used for this purpose, but it also has the meaning of throwing something away, so I avoided using this word.
|new code name||description|
|psdrread.py||yes||yes||yes||for Pocket SDR receivers|
|alstread.py||yes||for HD9310 receivers|
|novread.py||yes||yes||for OEM729 receivers|
|septread.py||yes||yes||yes||for mosaic-CLAS/X5 receivers|
Also, the message decode code is as follows:
|new code name||description||targets||note|
|qzsl6read.py||QZS L6 message decode||CLAS, MADOCA-PPP, old MADOCA||The |
|rtcmread.py||RTCM message decode||NAV, OBS, SSR, and reference station coordinates|
|gale6read.py||GAL E6 (HAS) message decode||HAS|
These can be used alone or via a pipe with the receiver raw data readout code described above. In the future, we would like to add BDS PPP-B2b augmentation messages and analysis code for navigation message authentication.
Settings for extract raw data from Septentrio receivers
I have a Septentrio mosaic-CLAS receiver and a mosaic-X5 receiver. The CLAS type can process Michibiki’s CLAS augmentation information by using navigation satellite signals in the L1 and L2 frequency bands. On the other hand, the X5 type can receive Galileo HAS and BeiDou PPP-B2b augmentation information by using positioning signals in the L1, L2, and L5 frequency bands (it cannot process augmentation information yet). It is possible to output raw data of CLAS, MADOCA-PPP, HAS, and PPP-B2b.
If we can get the raw data output, we can decode the messages with QZS L6 Tool. Furthermore, if we connect the mosaic receiver to a network-connected PC, we can use the receiver from another PC, which is convenient.
On a mosaic receiver, for example, in order to assign TCP port 2000 to the port
IPS1 and output raw data there, select the port from New IP Server in the
Communication->IP Ports menu. add.
For example, in order to output a Michibiki L6 message (CLAS or MADOCA-PPP) to this
IPS1 port on a mosaic-CLAS receiver, select New SBF stream from the
NMEA/SBF Out menu and select message
QZSRawL6. Also, select OnChange for Interval setting to output data as soon as it is received. We can select between CLAS (L6D) and MADOCA-PPP (L6E) in the
GNSS->CLAS menu. Unfortunately, simultaneous reception of CLAS and MADOCA-PPP is not possible.
In order to output Galileo’s HAS message (C/NAV: commercial navigation message in E6B signal) and BeiDou’s PPP-B2b to the
IPS1 port on the mosaic-X5 receiver, we need to create a New SBF stream. To do this, select
QZNMA: Michibiki’s navigation message authentication
The quasi-zenith satellite Michibiki has started test broadcasting of QZNMA: quasi-zenith satellite navigation message authentication from July 31, 2023. This is a broadcast of navigation message authentication information that allows the receiver to verify the correctness of the navigation message.
In QZNMA, the authentication message is transmitted to GPS and Galileo by multiplexing it with MADOCA-PPP using Michibiki’s L6E signal, and by multiplexing the navigation message with the navigation message using L1 signal for Michibiki itself (please refer the interface specifications IS-QZSS-SAS-001_Draft-002 for details). In this test broadcast, navigation message authentication is performed using only L6E signals, that is, for GPS and Galileo.
Regarding navigation message authentication, Galileo’s OSNMA (open service navigation message authentication) is leading (November 18, 2020). Currently, OSNMA seems to only authenticate GPS LNAV and Galileo I/NAV.
On the other hand, QZNMA currently provides authentication services for GPS LNAV and CNAV, and Galileo I/NAV and F/NAV. QZS L6 Tool can also decode QZNMA. For Pocket SDR receivers, specify
-sig L6E, for Septentrio mosaic-CLAS receivers, set the Michibiki reception signal to L6E signal, for Allystar HD9310 receivers, use L6E firmware, or Public stream
ntrip.phys.info.hiroshima-cu.ac.jp:80/MADOCA of Allystar receiver raw data at NTRIP By using this, you can check QZNMA messages.
In the future, I would like to be able to realize the verify function with navigation messages. The public key is required for navigation message authentication. we can obtain a public key by applying as described in IS-QZSS-SAS-001_Draft-002 above, including your affiliation email address, address, name, and purpose.
To the extent that we use navigation satellites in a compatible manner, we can continue to use them as before. However, navigation satellites and their receivers are also in a state of competition to introduce new technologies, and with a little effort we can take advantage of their cutting-edge capabilities. This is an exciting situation for people who love wireless communication technology and satellite navigation technology.
Galileo’s Improved I/NAV, Galileo OSNMA, Michibiki QZNMA (scheduled to start test broadcasting in February 2024 in the L1 frequency band), and other new technologies are being introduced, and it can be said that we are living in an exciting era. I would like to be able to handle this kind of technology with QZS L6 Tool as well.