RNX2CGGTTS

RNX2CGGTTS is a command line tool to convert a RINEX context to CGGTTS.

This operation is special and dedicated to high precision timing and time transfer in particular.

CGGTTS is defined by BIPM and supported by the cggtts-rs library.

:warning: This application only works with CGGTTS 2E (latest revision) :warning:

RINEX and sampling context

From a coherent RINEX context generated by a single receiver from which we precisely know the location, RNX2CGGTTS uses the position solver to precisely resolve the receiver clock state.

This operation is the combination of the following libraries :

• RINEX: to define a coherent RINEX context and parse it
• CGGTTS: to generate a CGGTTS file
• the Nyx Space library is used in the position solver
• Nyx Hifitime to define time and timescales accurately

Requirements

RINEX2CGGTTS requires at least one Observation RINEX file, and associated Navigation RINEX. SP3 is also ideal and highly recommended to be provided.

You should always inject data that comes from the same station (unique GNSS receiver).
Thefore, we don't recommend loading Observation data using the -d option, unless you store them in dedicated folders. Loading each individual file with -f is the most reasonnable approach.

Getting started

Build the application with cargo. The RINEX ecosystem has some requirements on the minimal rustc version, refer to the general README :

git clone https://github.com/georust/rinex
cargo build --release
./target/release/rnx2cggtts -h

RNX2CGGTTS uses the same RINEX context definition and loading interface as RINEXCLI. Follow its guidelines to learn how to load your data context.

RNX2CGGTTS shares the same behavior and interface as RINEXCLI with activate positioning. Refer to the positioning part of its documentation and the gnss-rtk solver, to fully understand how to configure and operate the solver.

RNX2CGGTTS can preprocess the RINEX context as the RINXCLI application, learn how to operate the preprocessor to operate this tool efficiently.

Command line example

Use a combination of the following arguments to load your context:

• -f (--fp) to load files individually
• -d to load a directory recursively.

Accepted files :

• RINEX (<= V4)
• SP3

Command line example :

TODO

:Warning: receiver coordinates

TODO

Accurate hardware setup definitions

In CGGTTS we're talking about 0.1 ns errors, therefore every fraction of delay counts.

The GNSS-RTK solver configuration can take into account two hardware induced source of delay [that are defined right here] and need to be correctly characterized and defined in your RNX2CGGTTS ops.

You can either define them in your configuration file (loaded with -c), or define them indivually with

• • use --rf-delay [ns] to define the delay induced by the antenna and the RF cable prior the GNSS receiver
• • use --ref-delay [ns] to define the cable delay between the receiver and its external 10MHz/1PPS source

Note that both delays are always defined in nanoseconds (f64), whether it is through the command line interface or the configuration file.

Generated Data

RINEX2CGGTTS will generate :

• a CGGTTS file named after the station (receiver) being used. The CGGTTS contains one track
• the same txt file you get in RINXCLI with active positioning, but focused on timing components, the spatial coordinates are removed
• txt file visualization, when --no-graph is not specified

Synchronous CGGTTS

RNX2CGGTTS will only form synchronous CGGTTS tracks as defined by BIPM.
Historically, the definition was closely tied to GPS ephemerides and receiver/hardware behavior and limitations.
Nowadays, we can safely say the defined scheduling is only there to provide synchronous CGGTTS tracks on both remote sites.
It is then easier to exchange CGGTTS files and perform the remote clock comparison: you don't need to interpolate anything.

:articial_satellite: Common View Time Transfer using CGGTTS files

Using RNX2CGGTTS (this app) and CGGTTS post processing [that app], we can perform a ""Time Transfer"" using a Common View method.
The need here is to compare two high quality but remote clocks. For that, we use two local GNSS receivers that generate RINEX data. With RNX2CGGTTS we resolve the local clock state against GPST (arbitrary). Do that on both RINEX context and regroup the two CGGTTS tracks so we can compare them.

To illustrate that, we will two complete RINEX contexts from CDDDIS portal. I chose station AJAC located in South Corsica (France) and Nialesun (Norway) on day XXX year 2023.

Resolve the clock state and format it into CGGTTS, on both sites, using RNX2CGGTTS :

provide two examples here please

Compare the two remote clocks to one another using CGGTTSCLI :

example results please