Quasi-zenith satellite Michibiki's positioning library CLASLIB (Part 1 Understanding the configuration)

categories: gnss
tags: clas qzss

Reference implementation CLASLIB for centimeter-order positioning calculation

The navigation satellite “MICHIBIKI” (QZS: quasi zenith satellite) operated by the Cabinet Office of Japan sends not only positioning signals in the same signal format as GPS, but also three types of augmentation signals that improve positioning accuracy. For utilizing the augmentation signals, open software library CLASLIB (centimeter level augmentation service library, and it pronounces as Cirrus lib) is available in public, and I tried to understand the program structure of CLASLIB.

There are many signal reception modules on the market that receive GPS and QZS navigation signals. Most of the modules receive radiowaves at a frequency of near 1575.42 MHz, which is called the L1-band. In order to use CLAS, we need receiving not only L1 band but also L2 band (1127.60 MHz) or L5 band (1176.45 MHz) naviation signals at the same time, and receiver’s internal information pseudo-distance observation data and navigation data. A module that can output data to the outside is required. Also, since this augmentation signal is transmitted in the L6-band (1278.75 MHz), a receiver that can receive this augmentation signal and decode the contents is required. In addition, navigation software that interprets the decoded augmentation signal and performs positioning calculations is required. Until now, using CLAS signals has been very difficult.

However, the challenges of receiving signals are being resolved. The u-blox ZED-F9P released by u-blox in Switzerland is inexpensive, but can simultaneously receive the L1 band and L2 band and output the internal information. Also, the HD9310 Option C released by Allystar of Chinese company last year can receive and decode Michibiki’s L6 signal.

Regarding positioning software, CLASLIB has been released on the Michibiki website of the Cabinet Office of Japan. Now it’s a good time to try CLAS. Currently, CLAS signals are available free of charge. In addition, CLAS data can be downloaded from the Michibiki homepage, so we can experiment with CLAS without an L6 band receiver.

Configuration of CLASLIB

CLASLIB uses RTKLIB of Prof. Tomoji Takasu and GSILIB of Geographical Survey Institute. There is a copyright notice of Mitsubishi Electric Corporation in the extended part. The version display of CLASLIB that I used was Ver. 0.71.

CLASLIB consists of library software that performs CLAS positioning calculation and the following three application software.

  1. ssr2osr (state space representation to observation state representation)
  2. ssr2obs (state space representation to observation)
  3. rnx2rtkp

Of these, the download version does not include rnx2rtkp. To obtain the compiled application software of rnx2rtkp and its source code, you need to apply by e-mail.

ssr2osr is a program that uses the given observation information and CLAS augmentation information to perform precise point positioning (PPP) calculations and outputs the results.

ssr2obs is a program that creates observation pseudo-distance data at a virtual reference station (VRS) using the information at the grid points included in the CLAS augmentation information in addition to PPP. Give ssr2obs three points: observation information, CLAS augmentation information, and the spatial coordinates for which you want to create a VRS. That is, compared to ssr2osr, ssr2obs performs more complex calculations.

I presume that rnx2rtkp is a program that creates a VRS at that position and performs RTK positioning and calculates the rough position of the observer, since there is the same name application software exists in RTKLIB. There are more steps, but ssr2obs may give similar results to rnx2rtkp in CLASLIB.

Investigation of source code derived

To understand CLASLIB, I separated the downloaded source code into the source code of the extension part in CLASLIB, the RTKLIB part, and the GSILIB part.

Downloading and unziping the ZIP archive from the CLASLIB page above, we will see the src with the library, the data with the CLAS positioning grid data, antenna characteristic data and positioning sample data, and the util directory containing ssr2obs and ssr2osr.

First, I placed the source code in the src directory in each of the CLASLIB, RTKLIB, and GSILIB directories. This is done by downloading the source files for CLASLIB, RTKLIB, and GSILIB and using commands such as diff -q claslib/src rtklib/src to find the files with the same name in each library.


clasgrid.h  cssr.h      grid.c     ssr2osr.c      stec.c
cssr.c      cssr2osr.c  ssr2obs.c




convkml.c    geoid.c    postpos.c  rcvraw.c  rtcm3e.c  sbas.c
convrnx.c    ionex.c    ppp.c      rinex.c   rtkcmn.c  solution.c
datum.c      lambda.c   ppp_ar.c   rtcm.c    rtklib.h  stream.c
download.c   options.c  preceph.c  rtcm2.c   rtkpos.c  streamsvr.c
ephemeris.c  pntpos.c   qzslex.c   rtcm3.c   rtksvr.c  tle.c


binex.c     gw10.c   novatel.c  rcvlex.c  septentrio.c  ss2.c
crescent.c  javad.c  nvs.c      rt17.c    skytraq.c     ublox.c

Actually, the receivers' program belongs to RTKLIB, so the directory rcv should have been placed under the directory rtklib. However, in order to make the source code directory shallow, the directory rcv is placed under the directory src.

Organize compile options

Then I removed options that weren’t used to compile the source code from makefiles of ssr2obs and ssr2osr.

First, consider the optional DLL. In RTKLIB, the following three error display subroutines are to be placed for each application program.

extern int showmsg(char *format, ...)
extern void settspan(gtime_t ts, gtime_t te)
extern void settime(gtime_t time)

ssr2osr.c has these subroutines. On the other hand, ssr2obs.c does not have these subroutines, and the DLL compile option disables the RTKLIB error display subroutine. Since these are for displaying errors, copy these subroutines in ssr2osr.c to ssr2obs.c and remove the DLL option in the Makefile.

Also, in ssr2osr.c, the initial values of the options -ts and -te, which represent the analysis start time and analysis end time, are both fixed at 00:00:00 on January 1, 2020. Was there. In this state, you have to specify the time every time to output the analysis result. On the other hand, in the RTKLIB application and ssr2obs, when these options are not specified, the entire time of the observation file is analyzed. Therefore, I rewrote the 77th line of ssr2osr.c to the start time of January 1, 2020 and the end time of December 31, 2030. Now you don’t have to specify the time every time. It may be es [6] = {0}, ee [6] = {0}.

    double tint=1.0,es[]={2020,1,1,0,0,0},ee[]={2030,12,31,23,59,59},pos[3];

The source code rtkcmn.c derived from RTKLIB has been modified for CLASLIB. Be careful when replacing only the RTKLIB part with the latest version.

Of the compile options in the ssr2obs Makefile, DECODE_CSSR and USR_CSSR were not used, so I removed them. Also, ssr2obs contains stream.c in RTKLIB, but it wasn’t referenced anywhere, so I also removed it from the Makefile. RTKLIB manages various receiver-specific raw data with input_raw () in rcvraw.c. The rcvraw.c included in CLASLIB did not have input_sbr () to handle raw Septentrio receiver data. Therefore, delete septentrio.c from the Makefile as well.

I use the library LAPACK for the matrix calculation part of RTKLIB. On Debian Linux, you can install the LAPACK library by running apt instll liblapack-dev under your root account. To use LAPACK for positioning calculations, add LAPACK to the compile options. After all, the compile option commonly used by ssr2obs and ssr2osr is DLL ENAGAL ENAQZS LAPACK NFREQ=3 TRACE.

Compared to ssr2osr, ssr2obs has more complicated, and CSSR2OSR_VRS ENAGLO ENA_SSR2OSR NEXOBS=2 has been added as a compile option. I didn’t understand why ssr2obs and ssr2osr use GLONASS satellites differently. According to the Michibiki FAQ “augmentation signals included in CLAS”, both of these satellites are GLONASS satellites. I think it is correct not to use for positioning and removing the option ENAGLO.

Common Makefile description

Then I moved the application code ssr2obs.c and ssr2osr.c in the util directory to ./src/claslib/. Because these are CLASLIB originals.

Finally, I rewrote the Makefile that creates ssr2obs as follows. The platform is Debian Linux.

Also, the Makefile for creating ssr2osr is as follows.

In addition, the file name of the data file has been unified to the date and time code.

The Makefile can be shared between ssr2obs and ssr2osr except for the compile options and configuration file. These two programs use the RTKLIB function to determine the data file type by extension, so the order of the data files to be given is arbitrary.

Also, the sample observation file in CLAS Subtype 12 is in BINEX format. This BINEX format file contains information for both OBS and NAV files. Therefore, the December 15, 2019 NAV files in ssr2osr will work even if you don’t specify them. This is also a function of RTKLIB.

As I wrote in the comments of each Makefile, ssr2obs and ssr2osr will not work if they compile with each other’s compile options. If you want to create an original program by sharing objects, you have to read the source code carefully, focusing on the compile option part. I will also use gdb to follow the source code.

Next time, we will try the first step of CLAS positioning, precise point positioning (PPP).

There are related series posts: