Abstract
Comparison of high-performance time scales generated by atomic clocks in laboratories of time and frequency metrology is usually performed by means of the Common View method. Laboratories are equipped with specialized GNSS receivers which measure the difference between a local time scale and a time scale of the selected satellite. Every receiver generates log files in CGGTTS data format to record measured differences. In order to calculate time differences recorded by two receivers, it is necessary to obtain these logs from both receivers and process them. This paper deals with automation and speeding up of these processes.
1. Introduction
GNSS stands for Global Navigation Satellite System. It is a term that is used internationally for satellite navigation systems that provide autonomous geospatial positioning with global coverage. The advantage to having access to multiple satellites is accuracy, redundancy, and availability at all times. Also if the line of sight is obstructed, having access to multiple satellites is also a benefit. The most commonly used GNSS are GPS, GLONASS, Galileo, and Beidou.
Usually, a GNSS receiver is used for determination of the position. However, thanks to the high precision of the time scale of the satellite system it is possible to use receivers as a time reference and time measurement devices. There are also special receivers which are primarily focused on the transfer of the time and frequency. These devices use code and phase measurement on several channels using one or more of the satellite system variants.
Nowadays, most of the specialized GNSS devices use GPS primarily even though they support other systems. This fact is caused by GPS availability, accuracy, ability to make consistent measurements, and mostly long time experience with this system. However, there is an effort to implement measurement using other satellite systems. This effort has an impact on data processing. In this case, the Common GPS GLONASS Time Transfer Standard (CGGTTS) has been extended from version 02 to version 2E to accommodate other satellite systems [1]. Methods described in this paper are designed to be easily expandable in terms of supported satellite systems, types of signal, and channels.
2. State of the Art in Time Scale Comparison
Figure 1 presents the Common View method for remote clocks comparison frequently used in metrology [2]. A comparison of two remote time scales in places and is performed using GNSS receivers and . The 13-minute long measurements are taken in 16-minute intervals (except one each day), following the tracking schedule described in [1]. The measurement results are stored into CGGTTS files. Each receiver measures the difference between local and satellite time scale; it is important that difference is measured directly against an individual satellite and not against a satellite system which can be affected by synchronization error.
The advantage of the Common View method is that multiple satellite systems can be used and that more information from individual measurements is obtained for each time interval. However, to provide any valid results, the two receivers have to have the same satellites visible. Also, they have to receive a signal from the satellites with enough strength and also have correct elevation because low elevations are more susceptible to ionospheric disturbances. As is shown in Figure 1, satellite 18 cannot be used for measurement because it is not visible by receiver B.
3. Calculation of Time Scale Difference
This section describes in detail the operations necessary to calculate the difference between two time scales. Equation (1) is used for calculation of the difference between time scales and using one satellite for interval .
Arithmetic average is calculated for all available satellite measurements in interval using
Standard deviation is also calculated for each using and
If any value of is larger than , then it is removed from the dataset. This value represented false measurement from any of the receivers. False measurements are usually caused by interference from reflected signal. Interference can occur when GNSS antenna is placed in proximity of a large object (e.g., a building, a wall, or a large pole) and sometimes cannot be avoided [3].
4. Data Representation and Storage Format
An example of output log generated by receivers is shown in Figure 1. This log is simplified and does not display all of the stored values, such as the type of the GNSS (e.g., GPS, GLONASS, Galileo, and Beidou), used frequency and measurement type (e.g., L1C, L3P), elevation of the satellite, and ionospheric model correction as discussed in [4, 5]. Modified Julian Date (MJD) is used as a date format and Coordinated Universal Time (UTC) as a time format. New log file with measured data is generated every day and contains a header with information about receiver and measurement setup. These log files are stored in the receiver and are usually publicly obtainable via the Internet. This availability is preferable because files from devices and have to be available to calculate the difference between time scales and .
5. Fast Method of Data Acquisition and Processing
The current method of data processing requires a manual download of GNSS receiver logs and execution of specialized software. This paper presents a new approach which counters these disadvantages and produces results faster. This approach uses a software bundle depicted in Figure 2 running on a computer with network access.
First, to suppress the necessity to download each log file manually, a script was written that downloads publicly accessible data from different GNSS receivers. For each receiver, only an initial configuration has to be made. This necessity is due to incompatibility between receivers, their configuration, and position in network infrastructure.
After data from all receivers are downloaded to the filesystem of the computer the Loader script is called. This script starts processing newly acquired data and stores them into MySQL database. The script supports three most commonly used CGGTTS versions, that is, 01, 02, and 2E. The Downloader and Loader script can be combined to skip storing data locally. However, these files serve as a backup of the GNSS receiver’s measurement and can be uploaded into the database again in case of corruption. Also, GNSS receivers usually delete their logs after a month to save space.
SQL (MySQL in this system) database was selected for data storage because it provides fast access and can store a large amount of data. Database and data indexation when correctly configured allow very fast data processing. All of the previously described processing can be implemented using a single query. Another advantage of the database is the ability to show a statistic of recorder data. This function can be used to discover problems in the data acquisition from individual GNSS receiver quickly, for example, large signal distortion or limited satellite visibility.
6. Storage Format
All data available in the log file are stored in the database including the file header which allows restoration of the original file. Even if this function is not necessary, it provides another possibility of backing up and sharing log files directly. The format of the measurement data had to be altered to improve processing speed. The most significant change was in the timestamp format. The original file uses MJD as the date format and UTC as the time format. When processing, measurements have to be sorted by time and date, so it is important to store time and date in a database-friendly format. For this reason, UNIX timestamp format was selected. It incorporates both date and time with a resolution of one second, and it is represented as an integer. The simple conversion is described by
is a timestamp in UNIX format. is a date in Modified Julian Date format. and are hour and minute in UTC format; seconds are not used in log files. The value of 40,587 represents 1. 1. 1970 in MJD which is the start of the UNIX time scale. The results are converted back to MJD after calculation.
Ionospheric model correction is applied to every measured value in receiver log. This correction is useful when comparing two time scales in distant locations. If the distance between these two receivers is smaller than 300 km, ionospheric corrections increase measurement error because receivers can use different ionospheric model parameters even if they are in almost the same locations (in perspective of satellite system). To prevent measurement error, removing this correction from measured value is necessary. This removal is possible because the correction is also stored in every measured variable.
A web server was deployed for processed data visualization and also for configuration of processing. The user can select which two time scales should be compared and a time interval, used frequencies, and satellite systems and if an ionospheric correction should be used or not.
7. Database Tuning
To speed up calculations, it is necessary to correctly select which of the data columns will serve as indexes for the database. In this case timestamp, satellite number and frequency channel were selected. These values are used for search in the database. Indexation of multiple data columns decreases search time but slightly increases the time necessary to add new data. However, adding data to the database is done by the Loader script, and it is done only once. Another advantage of indexing is that processing time is almost independent of the amount of data stored in the database. Loader and Downloader scripts have been written in Python programming language. The execution time of the Loader script which uploads data to the database is also influenced by the database structure. But when the testing database was created and the Loader script was called for the first time the execution time was only 20 minutes. This execution uploaded one to two year’s worth of data from five different GNSS receivers.
All of the processing described in previous sections was implemented using SQL query. This method transfers all of the computation load to the SQL server. The web server is only used to display the data.
8. Results
Execution time was measured and compared to another method currently used for data processing. Over 35,000 measurements from each receiver were processed for an 80-day interval comparison and over 3,000 for a seven-day interval.
Table 1 shows execution time of three different methods: a program written in C programming language, a script written in Matlab, and the new method using SQL database.
Figure 3 depicts the result of the time scale measurement between the Laboratory of the National Time and Frequency Standard in the Institute of Photonics and Electronics at the Czech Academy of Sciences (IPE CAS) and the time laboratory in the Faculty of Electrical Engineering at the Czech Technical University in Prague (CTU FEE). Both these laboratories use cesium time and frequency standard for their time scales. GTR50 and GTR51 multisystem and multifrequency GNSS receivers were used for measurement.
9. Conclusion
Thanks to the method described it is possible to process and visualize data faster than when using current processing software. It is also possible to automate measurement data acquisition and data backup. Fast result visualization can improve measurement system supervision and can prevent large data loss caused by GNSS receiver malfunction.
The presented software is offered by the authors for free use in metrology institutions or time and frequency laboratories willing to participate in the software’s further development.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the Grant Agency of the Czech Technical University in Prague, Grant no. SGS16/097/OHK3/1T/13. The authors would also like to thank Alexander Kuna, Ph.D., head of the Laboratory of the National Time and Frequency Standard in the Institute of Photonics and Electronics, the Czech Academy of Sciences, for his support and assistance with this project.