Exchanging STEC Data

For almost two years now, I have been extracting precise slant ionospheric delays from over 200 permanent GNSS stations in Canada using PPP-AR. Since there is no official data format for storing GNSS-derived slant ionospheric delays, I have developed by trial and error a format that is at least suitable for my own purposes. Since precise ionospheric delays are key to fast PPP convergence, we can certainly foresee a need for exchanging this kind of information in the future. For this reason, I thought it could be useful to share this format and possibly get feedback from the GNSS community.

 

While the RINEX 3 format allows for the inclusion of slant ionospheric delays, I thought it lacked mainly two features: 1) the possibility of specifying the standard deviation of the delay; and 2) the possibility of including several stations in a single file. Also, for the purists, slant ionospheric delays are (typically) processed observations and should therefore fall into the product category.

 

Let's take a look at the proposed format which uses features from several of the existing RINEX formats.

 

HEADER

Let me start with a fictitious example of a header to explain its various subtleties:

While people familiar with the RINEX format will recognize many records, some of them require further explanations:

 

OBSERVABLES USED

While this record comes from the IONEX format, I think that it is important to specify more clearly how slant ionospheric delays were computed. I see the following options for now but this list could easily be expanded:

  • CODE (delays derived e.g. from C1W-C2W only)
  • SMOOTHED/LEVELED CODE (delays derived from phase-smoothed code observations)
  • PHASE (delays derived e.g. from L1W-L2W only and that are thus contaminated by ambiguities)
  • PPP (delays derived from a float-PPP solution)
  • PPP-RTK (delays derived from a PPP-RTK solution, i.e. with ambiguity resolution enabled)
  • MODEL (e.g., delays ray-traced through a 3D model)

SYS / # / OBS TYPES

The observable types that I thought were useful to include are:

  •  I = Ionosphere phase delay (m)
  • S = Ionosphere phase delay standard deviation (m)
  • R = Ionosphere phase delay rate (cm/s)
  • D = Ionosphere phase delay rate standard deviation (cm/s)

All values should be expressed on a specified frequency band. For example, “I1” means slant ionospheric delay on the L1 frequency band (1575.42 MHz for GPS).

 

Of critical importance in the successful use of this format is the value of the ionosphere phase delay standard deviation ("S"). It is highly recommended that this value reflects, as closely as possible, the error in the delay provided. For instance, it is known that the smoothed/leveled code observable contains “leveling” errors caused, among other things, by multipath and/or intra-day variations of DCBs. Therefore, the standard deviation for ionospheric delays derived from this observable should be adjusted consequently.

 

SYS / BIA APPLIED

It is essential for users of this product to know if the slant ionospheric delays provided contain instrumental biases or if they have been removed. If this record is left blank or if it is not specified in the file, it should be assumed that the delays (“I”) contain biases such as DCBs or DPBs.

 

If a file is specified, it involves that some biases have been removed from the delays. If the bias file specified only contains satellite DCBs for example, then it should be assumed that the ionospheric delays still contain station DCBs. If the bias file specified contains both satellite and station DCBs, then it should be understood that unbiased delays are provided.

 

In the case where “OBSERVABLES USED” is set to “MODEL,” then unbiased slant ionospheric delays should be provided without the need for specifying the “SYS / BIA APPLIED” record.

 

SYS / SAT CLK USED

In the event that DCB corrections were not applied to the slant ionospheric delays provided and that the latter are derived from a PPP or PPP-RTK solution, then it is mandatory to specify which source of satellite clock corrections has been used since these delays will contain DCBs/DPBs that could be dependent on this clock file.

 

SYS / PCVS APPLIED

To obtain the utmost precision from slant ionospheric delay corrections, it is essential to maintain consistency in the dispersive corrections applied to the observations during processing. This record, also included in RINEX 3, allows specifying the ANTEX file used to remove phase center offsets/variations from the ionospheric delays.

 

SYS / # / DISP CORR

It is also important to specify any other dispersive corrections applied in generating slant ionospheric delays, such as:

  • WIND_UP: carrier-phase wind-up
  • IONO_2: second-order ionospheric delay
  • IONO_3: third-order ionospheric delay

 

DATA RECORD

Regarding the actual representation of the data, I have struggled a lot to come up with a compact and easy-to-use format. When including data from 200 stations for 32 satellites at a 30-sec data interval, it is needless to say that the file quickly grows in size! One of the culprits is the constant repetition of the time stamp as done, for example, in a RINEX clock file.

 

On the other hand, I must admit that I personally find it quite inconvenient to use a single time stamp per epoch like in the RINEX observation files or in the SP3 format. The reason is that, from a data analyst point of view, it is not trivial to extract information for a certain satellite from the file. When using “grep,” the timing information simply disappears and analysis or plotting becomes problematic. Hence, for the format proposed herein, I strongly recommend that each line contains the time tag, station name and the satellite name. It also makes the process of merging files much easier.

 

A solution that I found for reducing the file size is to specify, in the header, the “TIME OF FIRST OBS”. Then, all data records in the file can be expressed in seconds with respect to this initial time. I also allowed for two decimal places to accommodate up to 100 Hz sampling.

 

The data record can then be defined as:

  • Time tag in seconds with respect to the initial time specified in the header (F9.2)
  • Station name (A4)
  • Satellite number (A1,I2)
  • Observation - repeat within record for each observation (F10.4)
  • DCI (Datum Change Indicator) (I1)

The DCI indicator is used to indicate discontinuities in the satellite or station DCBs/DPBs. When this flag is set to 1, it is not possible to interpolate the slant ionospheric delay between the previous epoch and the current epoch. This situation occurs mainly when ionospheric delays are derived from PPP-RTK solutions. This type of event should not be confused with a reset of the carrier-phase ambiguities, which would potentially be reflected in the standard deviation. An exception for this scenario occurs when using the PHASE observable. In this case, a cycle slip effectively implies a change of datum and should be flagged appropriately.

 

Here is a fictitious example of a data record containing the four fields specified in the header above:

 

 

CONCLUSION

A motivation for such a format could be to perform distributed processing of slant ionospheric delay computations. With thousands of permanent GNSS stations worldwide, it is quite cumbersome for a single organization to process all of this data at a 30-sec (or higher) data interval. Dividing this load among several analysis centers could allow building a database for global PPP-RTK. This will however require careful handling of DCBs, weighting of observations, etc., but this is a story for a later time.

 

How should this format be named? I personally don’t mind its name as long as I can use it, but if I had to suggest one, I would go for SIDEX: Slant Ionospheric Delay EXchange format.

 

In summary, this format was derived from my own experience with producing and using slant ionospheric delays. I am aware that there are still details to iron out, and I am certain that this format will not be suitable for everyone and that some people will even fiercely object to it (as usual). Still, I hope that there are a few nuggets of wisdom in there that can benefit the GNSS community.



Write a comment

Comments: 4
  • #1

    Baocheng Zhang (Friday, 27 January 2017 23:39)

    I personally congratulate you on such a valuable and prospective work. And I am indebted to your acknowledgement that I (perhaps the first one, otherwise feel free let me know ^_^) proposed the use of PPP for STEC retrieval in your series of ION works. I have recently new findings on this matter and will of course let you know when I formulate them in terms of an academic paper. I have the confidence you will be interested in it. Let us keep in touch.

  • #2

    Simon Banville (Saturday, 28 January 2017 14:31)

    @Baocheng Thanks for your support. I'll be looking forward to your new findings!

  • #3

    Miquel Garcia (Monday, 13 February 2017 05:46)

    Nice initiative Simon! I personally find this very interesting. Such format would avoid the need of using mapping functions as it is currently done in IONEX files... Just a brief comment, why specifying the delay and not the STEC directly? Since the delay is 40.3 / f^2 * STEC, there is actually no need of specifying a delay for each frequency...

    Regarding the name... what about SIONEX? (Slant IONospheric content/delay EXchange format).

    Do you already have readers that you could share with the community?

    Many thanks!!

  • #4

    Simon Banville (Monday, 13 February 2017 16:18)

    @Miquel Thanks for your inputs, I like both ideas! Specifying the delay and the frequency came from RINEX 3, but I agree that STEC probably makes more sense.

    I'll try to provide a complete file and perhaps a basic reader in the upcoming weeks.