Test release of RTK reference station observation data archive
Please note that this article was outdated.
The satellite signal observed by the RTK reference station is automatically recorded, and this archive will be released for trial. Since it is published using the https protocol, you can use command line tools such as
curl in addition to web browsers.
We can access to the highly reliable Geospatial Information Authority of Japan (GSI) GNSS signal observation archive. However, while the GSI archive is data every 30 seconds, this archive is data every second. This archive also contains data from BeiDou, and also contains information on signal-to-noise power ratios. I think that the data archive to be published for the test is useful as test data for RTK (realtime kinematic), PPP (precise point positioning), and CLAS (centimeter level augmentation system of the Quasi-Zenith Satellite System).
Please note that some of the observation data may be missing, and the quality may have deteriorated due to antenna or equipment maintenance. It may also be discontinued in the future.
Archiving period, content, archive address, and directory layout
The recording period is from March 1, 2020 to the present. The observation data is divided every hour, and the first and last 30 seconds overlap, so the length of each data is 1 hour and 1 minute.
The contents are a pseudo-distance file (OBS: observation) and navigation file (NAV: navigation) in RINEX (receiver independent exchange format) format, and a satellite file (SBAS: satellite based augmentation system) in text format. Each file is compressed with
gzip. There may not be satellite files.
If you unzip these files with such as
gunzip, you can check the contents with a text editor. RTKPOST of RTKLIB can process files compressed with gzip.
The raw data is also available. The raw data from March 1st to August 20th of 2020 is in RTCM 3 format (the extension is rtcm3), and thereafter in u-blox binary format (ubx).
The address is as follows.
The directory layout is as follows.
YYYYMM/ YYYYMMDDa.obs.gz YYYYMMDDa.nav.gz YYYYMMDDa.sat.gz ... YYYYMMDDx.obs.gz YYYYMMDDx.nav.gz YYYYMMDDx.sat.gz raw/ YYYYMM/ YYYYMMDDa.rtcm3 YYYYMMDDb.rtcm3 YYYYMMDDc.rtcm3 ... YYYYMMDDx.rtcm3 YYYYMMDDa.ubx YYYYMMDDb.ubx YYYYMMDDc.ubx ... YYYYMMDDx.ubx
YYYY is the Christian era, MM is the month, DD is the day, and the next a to x alphabetic characters represent the code from 0:00 to 23:00. The time is coordinated universal time (UTC), which is 9 hours behind Japan standard time (JST).
How it works
The u-blox binary file is recorded by this script for the data output from the serial port of u-blox ZED-F9P. Then, at 3 minutes every hour, let
cron run the following script
cron-f9pconv.sh to convert the u-blox binary format file to a RINEX file and then gzip it.
#!/bin/bash #-------- DIR_F9P=/gnss/f9p CONVBIN=convbin GZIP=gzip #-------- DATE=`date +%Y%m%d --date '10 hour ago'` # year, month, and day YRMO=`date +%Y%m --date '10 hour ago'` # year and month HOUR=`date +%H --date '10 hour ago'` # hour HOUR_NUM=`expr $HOUR + 97` # hour to character number HOUR_CODE=`printf "\x$(printf %x $HOUR_NUM)"` # character number to hour code $CONVBIN -ti 1 -v 3.04 -os -d $DIR_F9P/$YRMO \ $DIR_F9P/raw/$YRMO/$DATE$HOUR_CODE.ubx $GZIP $DIR_F9P/$YRMO/$DATE$HOUR_CODE.*
date command specifies the time 10 hours ago, which is the total of 9 hours before the time difference between UTC and JST and 1 hour before the file time to be processed after the file rotation of