Quasi-zenith satellite Michibiki's positioning library CLASLIB (Part 3 VRS-RTK positioning by ssr2obs)

categories: gnss
tags: clas qzss

RTK positioning using VRS

This is a continuation of the previous PPP positioning by CLASLIB. This time, I will try ssr2obs of CLASLIB.

CLASLIB’s ssr2obs creates a virtual reference station (VRS) in any space. If you give it an orbit (NAV: navigation) file, a CLAS information file, and the spatial coordinates for which you want to create a VRS, you can get that observation pseudo-distance (OBS: observation) file.

Step 1: Create VRS observation pseudo-distance file with CLASLIB ssr2obs

Reuse the NAV file and CLAS information file created by RTKLIB to execute the previous CLASLIB ssr2osr. Suppose they are stored in the util/ssr2osr/ directory with the names 0200505d.nav and2020126D.l6. In this step, these two files are used to create the observation pseudo-distance file vrs20200505d.obs in VRS.

We also assume that there is a compiled ssr2obs executable in the utils/ssr2obs/ directory. Furthermore, suppose that the RTKLIB rnx2rtkp created in the same way as in Run ssr2osr has been copied to this directory. Compiling RTKLIB’s rnx2rtkp requires gfortran, but with a few changes it can also be created with a C compiler. For this compilation, run make in the lib/iers/gcc/ directory to create iers.a in advance.

First, prepare the ssr2obs configuration file obs.conf.

The changes from the original sample configuration file are that the frequency used (pos1-frequency) is set to 2 frequencies, L1 band and L2 band, and the VRS coordinates expected as the positioning result are changed to those of my RTK reference station. There are two points. The final positioning is done by RTK, so these coordinates can be rough or far away.

When these are ready, run ssr2obs.

./ssr2obs -k ./obs.conf ../ssr2osr/20200505d.nav ../ssr2osr/2020126D.l6 -o vrs20200505d.obs -r -ts 2020/05/05 03:00:00 -te 2020/05/05 04:00:00

Option -k specifies the configuration file, -o specifies the output OBS file, -r specifies the OBS file output in RINEX format, -ts and -te represent the start date and time and end date and time specifications, respectively. The NAV file contains time information about the satellite, but it seems that you have to specify the start and end times each time to create an OBS file.

Step 2: Run VRS-RTK with RTKLIB rnx2rtkp

Then run the RTKLIB version of rnx2rtkp. Before RTK positioning, make sure that the receiver’s OBS file and NAV file can be used for independent positioning.

./rnx2rtkp -p 0 -t -u 20200505d.obs 20200505d.nav

If many positioning results appear on the screen, it can be said that independent positioning has been completed. Option -p 0 is for independent positioning, -t is for date/hour/minute/second display instead of GPS time display, -u is for UTC time display.

Also, make sure that the VRS OBS file created earlier can also be used for independent positioning. If you do not use the option -o, which represents the output of the result to a file, the result will be output to standard output (on the screen).

./rnx2rtkp -p 0 -t -u vrs20200505d.obs 20200505d.nav

After confirming that both can be positioned independently, perform RTK positioning using this VRS. When performing RTK positioning, the VRS coordinates determined earlier must be given by the -l option of rnx2rtkp. This is because the VRS OBS file does not contain those coordinates.

./rnx2rtkp -p 2 -h -t -u ../ssr2obs/20200505d.obs ../ssr2obs/20200505d.nav vrs20200505d.obs -l 34.44010565 132.41478259 233.05 -o 20200505d.llh

During execution, if the characters Q=1 (Fix solution) and Q=2 (Float solution) appear flickering, it is successful. If Q=0 (positioning failure) remains for a while, the VRS OBS file does not contain information and the VRS file creation fails. The option -p 2 represents kinematic positioning and -h represents the use of fix and hold mode for kinematic positioning. The latter was set to make it easier to get a Fix solution with RTK.

From this result, in addition to the time, latitude, longitude, ellipsoidal height, and number of seconds elapsed, the value in the sixth column representing the solution state Q is extracted with awk.

awk '{print $2 "\t" $3 "\t" $4 "\t" $5 "\t" $6 "\t" $14;}' 20200505d.llh

The execution result is as follows.

program :       rnx2rtkp        ver.2.4.3       b33
inp     file    :       ../ssr2osr/20200505d.obs
inp     file    :       ../ssr2osr/20200505d.nav
inp     file    :       vrs20200505d.obs
obs     start   :       2020/05/05      02:59:12.0
obs     end     :       2020/05/05      04:00:11.0
ref     pos     :       34.440105650    132.414782590

(lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=
#       of      satellites)
UTC     latitude(deg)   longitude(deg)  height(m)       Q       age(s)
02:59:28.000    34.440113166    132.414779905   232.3191        2       -29.00
02:59:29.000    34.440112852    132.414779921   232.3097        2       -28.00
02:59:30.000    34.440113023    132.414779813   232.3585        2       -27.00
02:59:31.000    34.440113334    132.414779834   232.3978        2       -26.00
02:59:32.000    34.440113290    132.414779938   232.4193        2       -25.00
... snip ...
02:59:54.000    34.440117295    132.414779707   232.7228        2       -3.00
02:59:55.000    34.440117528    132.414779730   232.7227        2       -2.00
02:59:56.000    34.440106283    132.414783758   232.9184        1       -1.00
02:59:57.000    34.440106378    132.414783738   232.9163        1       -0.00
02:59:58.000    34.440106434    132.414783733   232.9125        1       -0.00
02:59:59.000    34.440106465    132.414783748   232.9092        1       -0.00
03:00:00.000    34.440106576    132.414783740   232.9076        1       -0.00
03:00:01.000    34.440106605    132.414783742   232.9058        1       -0.00
03:00:02.000    34.440106524    132.414783742   232.9084        1       -0.00
03:00:03.000    34.440106532    132.414783755   232.9054        1       -0.00
... snip ...
03:59:42.000    34.440105899    132.414783964   232.9055        1       0.00
03:59:43.000    34.440105859    132.414783949   232.9120        1       1.00
03:59:44.000    34.440105864    132.414783983   232.9231        1       2.00
03:59:45.000    34.440105842    132.414783972   232.9249        1       3.00
03:59:46.000    34.440105820    132.414783992   232.9331        1       4.00
03:59:47.000    34.440105838    132.414784006   232.9333        1       5.00
03:59:48.000    34.440105832    132.414783998   232.9355        1       6.00
... snip ...

This observation pseudo-distance file records data 30 seconds before the scheduled start time in UTC, and this result shows that the Float solution has been used since the first time. Also, it became a Fix solution from 5 seconds ago, and the Fix solution was maintained until the end. The reinforcement data was cut off at the end 18 seconds before the scheduled end time, but the Fix solution was maintained. Since it is fixed to the 6th digit after the decimal point of longitude, it seems that the coordinates can be determined with an accuracy of about 10 centimeters. very nice.

VRS coordinates are given in the config file for ssr2obs and in the config file or command line for rnx2rtkp. With rnx2rtkp, you can do a lot of work without a configuration file. If you can specify the VRS coordinates on the command line, you can easily change the coordinates. I referred to rnx2rtkp.c and modified ssr2obs.c to add the -pos option so that I could specify the coordinates on the command line. Add the following to line 439 of ssr2obs.c.

        else if (!strcmp(argv[i],"-pos")&&i+3<argc) {
            prcopt.refpos=prcopt.rovpos=0;
            for (j=0;j<3;j++) prcopt.rb[j]=atof(argv[++i]);
            matcpy(prcopt.ru,prcopt.rb,3,1);
        }

RTKLIB is a mechanism that allows such extensions with external applications.

Actually, I tried other data, but sometimes VRS observation pseudo-distance data could be created only at some times or not at all.

For one failure example, I added the -x 2 option to rnx2rtkp to output the reason why the VRS observation pseudo-distance data is missing to the trace file.

2 04:00:58.00: point pos error (lack of valid sats ns=4)
2 04:00:59.00: point pos error (lack of valid sats ns=4)
2 04:01:00.00: point pos error (lack of valid sats ns=5)

This indicates a shortage of visible satellites in CLAS.

The measurement data at this time is when the output of the antenna Javad GrAnt G5T is branched into two and measured using the receiver Javad Alpha G3T and Mitsubishi Electric AQLOC-V borrowed from the PFI project of the Cabinet Office of Japan. The result of the above-mentioned shortage of visible satellites is the processing of the observation data of the Alpha G3T. In this measurement, the AQLOC-V was able to maintain the Fix solution even with the antenna mounted on the roof of the car. The coordinate output at rest was fixed to the 7th digit after the decimal point of longitude, indicating that centimeter-order positioning was possible. Therefore, adjusting the CLAS positioning parameters may provide sufficient visible satellites. I will continue reading the CLASLIB source code.

As of May 5, 2020, CLAS satellite reinforcement information is transmitted in subtypes 8 and 9. You can see the contents by observing the CLAS signal file with the dump option -dump attached to ssr2obs etc. The number of satellites to be reinforced in subtypes 8 and 9 is 11. In 2020, we plan to shift from the subtypes 8 and 9 formats to the new subtype 12 formats, increasing the number of satellites to be augmented to 17. I am looking forward to the new CLAS signals.


There are related series posts: