GNSS Data Formats in the GPSTk

• The RINEX Format
• ARL's Extended RINEX Format
• Monitor Station Coordinate File Format
  

CalGPS Application

Description

The CalGPS application prints GPS calendars either to the command line or to a graphics file.

The UNIX cal utility served as the initial inspiration for this tool.

Command Summary

calgps [options]

where [options] can be

-Y, --specific-year=NUM

-p, --postscript=ARG

-s, --svg=ARG

-e, --eps=ARG

Usage examples

Example 1. Printing text calendar to standard output.

user@host:~$ calgps

                       Dec 2007
1455                                             1-335 
1456   2-336  3-337  4-338  5-339  6-340  7-341  8-342 
1457   9-343 10-344 11-345 12-346 13-347 14-348 15-349 
1458  16-350 17-351 18-352 19-353 20-354 21-355 22-356 
1459  23-357 24-358 25-359 26-360 27-361 28-362 29-363 
1460  30-364 31-365                                    

Example 2. Printing a 2002 calendar to standard output.

calgps -Y 2002

                       Jan 2002
1147                 1-001  2-002  3-003  4-004  5-005 
1148   6-006  7-007  8-008  9-009 10-010 11-011 12-012 
1149  13-013 14-014 15-015 16-016 17-017 18-018 19-019 
1150  20-020 21-021 22-022 23-023 24-024 25-025 26-026 
1151  27-027 28-028 29-029 30-030 31-031               

                       Feb 2002
1151                                      1-032  2-033 
1152   3-034  4-035  5-036  6-037  7-038  8-039  9-040 
1153  10-041 11-042 12-043 13-044 14-045 15-046 16-047 
1154  17-048 18-049 19-050 20-051 21-052 22-053 23-054 
1155  24-055 25-056 26-057 27-058 28-059               

                       Mar 2002
1155                                      1-060  2-061 
1156   3-062  4-063  5-064  6-065  7-066  8-067  9-068 
1157  10-069 11-070 12-071 13-072 14-073 15-074 16-075 
1158  17-076 18-077 19-078 20-079 21-080 22-081 23-082 
1159  24-083 25-084 26-085 27-086 28-087 29-088 30-089 
1160  31-090                                           
...

Example 3. Generating a graphical calender in SVG, launching a postscript viewer when done.

e$ ./calgps -s test.svg -v

Going to launch rsvg-view -b white
sh: rsvg-view: not found
... couldn't execute: rsvg-view -b white test.svg
Going to launch ksvg
sh: ksvg: not found
... couldn't execute: ksvg test.svg
Going to launch inkscape

A picture like the attached is generated: cal.svg

Platforms Supported

This application has been successfully used in Linux, Solaris and Windows. This application successfully build under these environments: linux-x86, linux-x86_64, solaris-ppc, Windows/.net2005, MacOS/X-Code.

See also:

• The timeconvert application. It converts a specific time to many formats.
• The poscvt application. It converts a position among coordinate systems.
• A collection of GPS calendars generated by calgps.
  

compSatVis/compStaVis Application

Description

The programs are driven by command-line arguments, a file containing station positions, and a file of SV orbital information in any of several formats.

Command Summary

compSatVis [options]
compStaVis [options]

where [options] can be

Usage examples

Example 1. Generating satellite visibility statistics using the SEM almanac from the USCG Navigation Center.

user@host:~$ compSatVis -ovisout.txt -ncurrent.al3 -tSEM -cstations.msc -e10 -p60 -s"01/16/2008 00:00"

Example 2. Generating station visibility statistics using the SEM almanac from the USCG Navigation Center.

user@host:~$ compStaVis -ovisout.txt -ncurrent.al3 -tSEM -cstations.msc -e10 -p60 -s"01/16/2008 00:00"

Example 3. Generating satellite visibility statistics using the Yuma almanac from the USCG Navigation Center.

user@host:~$ compSatVis -ovisout.txt -ncurrent.alm -tYUMA -cstations.msc -e10 -p60 -s"01/13/2008 00:00" -z"01/16/2008 23:59"

Example 4. Generating satellite visibility statistics using SP3 files.

user@host:~$ compSatVis -ovisout.txt -napc14622 -napc14623 -napc14624 -tSP3 -cstations.msc -e10 -p60

Platforms Supported

This application has been successfully used in Linux. This application successfully builds under these environments: linux-x86, linux-x86_64, others tbd.

Assumptions and Defaults

If the time span of the evaluation is not set via the -s and -z commands, the programs default to determining the epoch time of the navigation message data and computing statistics from 0000Z - 2356Z of the corresponding day. This is default is derived from the GPS orbit characteristics which cause the ground tracks to repeat every day minus four minutes. As a result, for a given set of GPS orbital information, the statistics should be nearly identical for successive 23h 56m periods. The -s and -z arguments were added for two reasons, (1.) to support future GNSS constellation that do not have the repeating ground track feature of GPS, (2.) the -s also enables potential ambiguity in the almanac reference week to be resolved (for Yuma and SEM almanac data formats).

The program assumes receivers can track all SVs in view. However, the -m (max-SV) option has been added to help address the limitation of this assumption. The -m option tells compStaVis to report the number of intervals for which the number of SVs in view exceed the specified value. Assuming all receivers in the network under consideration can track the same number of SVs, the -s option provides a way in which the user can obtain information on the amount of time the receiver will be "saturated", i.e. have all tracking channels in use.

The -m option in compSatVis is useful in checking various station networks against desired minimum coverage. compSatVis counts the number of intervals in which the number of stations visible to an SV is less than the number specified in the -m option (default of 2).

Whenever the -i or -x options are invoked, the output file will contain a list of the specific stations used in the analysis. Otherwise, the output file simply notes that all stations in the monitor station coordinates file were used.

See also:

• The Monitor Station Coordinates File Format contains information on how to specify station locations.
  

DiscFix Application

Summary

Platforms Supported

This application successfully build under these environments: linux-x86, linux-x86_64, solaris-ppc, Windows/.net2005, MacOS/X-Code.

Usage examples

Linux/UNIX command line

Example use session from the GPSTk source distribution.

1. Change to the examples directory. cd ~/svn/gpstk/dev/examples
2. Execute DiscFix.

See also:

• EditRinex - generating extended RINEX observation files

Double Difference Analysis

The noise associated with observations collected by a stationary GPS receiver can be characterized by conducting a double difference analysis. This requires a synchronous set of range, phase, and Doppler observations from two receivers connected to a common antenna in what is commonly referred to as a zero-baseline configuration. The double difference being computed is between two SVs and two receivers at a single epoch. The first difference is formed for each receiver by differencing the observations of any two SVs. The second difference is formed by differencing these two first differences.

ddGen

Process

The noise associated with observations collected by a stationary GPS receiver can be characterized by conducting a double difference analysis. This requires a synchronous set of range, phase, and Doppler observations from two receivers connected to a common antenna in what is commonly referred to as a zero-baseline configuration. The double difference being computed is between two SVs and two receivers at a single epoch. The first difference is formed for each receiver by differencing the observations of any two SVs. The second difference is formed by differencing these two first differences.

While the above summarizes the double difference, it is not a sufficient description of the necessary processing steps. There are various corrections that need to be applied, edits to be performed, and statistics to be computed. This processing is implemented in the GPSTk application ddGen. The source code of this program can be found at http://gpstk.svn.sourceforge.net/viewvc/gpstk/dev/apps/reszilla/ . What follows is a description of the processing that ddGen performs.

The following operations are performed at each epoch:

1. The raw pseudorange observations from a receiver are used to compute a pseudorange residual based on the provided ephemeris data for each SV and a provided receiver position. These residuals are averaged together to form a receiver clock estimate at each epoch.
2. This process is repeated for the second receiver.
3. The two clock estimates for the epoch are differenced to form a receiver clock bias.
4. Data that doesn't meet the following criteria is excluded at this point:
   1. Health bits must be set in the ephemeris and must indicate a healthy status
   2. SNR must be greater than 20 dBHz
   3. Observation data for each SV must be provided from both receivers
   4. Flags in the observation data messages must indicate continuous tracking
5. For each unique pair of SVs, a double difference is formed for the range, phase, and Doppler.
6. The double differences are corrected for SV motion by using the Doppler measurement for an estimate of line-of-sight motion and the computed receiver clock bias.

The receiver clock estimate is sensitive to errors in the provided antenna position, SV position/clock, ionospheric modeling, and tropospheric modeling. Since errors in the receiver clock estimate have a very weak effect on the double difference, the broadcast ephemeris may be used for the SV position and clock computation. A dual frequency ionospheric correction and a location/time based tropospheric model are applied.

After this process has been completed for all epochs in the input data, the range and Doppler double differences are complete. The phase double differences still include both receivers' integer ambiguity in phase. The removal of this bias occurs as follows:

1. The phase double differences are grouped into tracks, or continuous series of double differences for a specific pair of SVs.
2. A third difference is formed as the difference between successive values in each track.
3. The track(s) for a specific SV pair are further split into smaller tracks based upon discontinuities in the third difference. This accounts for cycle slips and other tracking anomalies.
4. The mean value of each double difference track is computed and removed from the values in the track.

At this point, the double differences for range, phase and Doppler represent samples of the receiver noise. This noise process is generally accepted to be a function of signal strength, and signal strength is a function of elevation. As such, the double differences are grouped into elevation bins where both SVs are in the same elevation range. The elevation bins are often chosen to easily get a significant sample set while being small enough to reflect similar signal strength.

Since this is a stochastic process, descriptive statistics are computed over all the epochs. The first and second order moments (mean and standard deviation) are computed for the data in each of the bins. This results in a table of statistics that is indexed by carrier (L1, L2), code (C/A, Y, P), observation type (range, phase, Doppler) and elevation range. A partial example of this is below.

Development.ObsID         elev    stddev     mean    # obs      # bad   # unk  max good  slips
------------- -----  --------  --------  -------    ------  ------ --------  -----
L1 C/A range   0-10   0.40522    -0.006    44509    1144     342   22.81
L1 C/A phase   0-10   0.00187    -0.000    44247    1406     342    0.10
L1 C/A doppler 0-10   0.42212     0.023    45653       0     342    6.58
L1 Y range     0-10   0.32562    -0.009    41789    2394    1812    8.31
L1 Y phase     0-10   0.00210    -0.000    41734    2449    1812    0.10
L1 Y doppler   0-10   0.40715     0.039    44183       0    1812    6.58

L1 C/A range  10-20   0.21968    -0.043    71231      16      16    7.18
L1 C/A phase  10-20   0.00071     0.000    71231      16      16    0.01
L1 C/A doppler10-20   0.52486    -0.005    71247       0      16    1.41
L1 Y range    10-20   0.20557    -0.061    70634     266     363    7.77
L1 Y phase    10-20   0.00071     0.000    70627     273     363    0.01
L1 Y doppler  10-20   0.52367    -0.006    70900       0     363    1.41
...

The ddGen program has two modes of operation. The first uses a single master SV to form the double difference. The second forms all unique combinations of SV pairs at each epoch. Since memory constraints limit the length of data that can easily be processed using this technique, the length of data analyzed needs to be traded off against the strength of the statistical characterization. This is also why all unique combinations of two SVs are used at each epoch as opposed to just using a single "master" SV to difference all other SVs against. Each combination is a unique observation of the receiver noise. So, instead of getting n-1 observations of noise at each epoch, we get observations, where n is the number of SVs in track. Experience shows that processing more than 24 hours of data in this manner does not affect the standard deviation or the mean. Processing spans less than 24 hours have not been investigated.

The Double Difference

There are many differences that can be formed, each with different properties. The intent of this analysis is to derive a process for examining the receiver noise of a stationary GPS receiver based upon the receiver's raw range measurements. This analysis assumes that two identical receivers are connected to a common antenna in what is commonly referred to as a zero-baseline configuration. While the receivers share an antenna, they do not share a common frequency references or internal clock.

The basic GPS range equation may be written as (see symbol key at end):

A first difference is formed between two receivers () at the same epoch for the same satellite. This difference has the effect of reducing the common mode effects proportional to the inverse of the length of the baseline. For a zero-baseline configuration, this has the desireable effect of removing may sources of errors. Specifically , and and are all canceled out.

This first difference is also formed for a second SV at the same epoch.

Note that in the first difference, the receiver clock offset still is the major term. Forming a second difference () between the two first differences will cancel this term.

If the receiver noise is assumed to be non-correlated between receivers and SVs, the magnitude of this double difference is times the receiver noise of a single receiver.

One significant problem with the preceding analysis is that the two receivers did not take their observations at precisely the same time. When each receiver is taking observations synchronously to its internal clock, the difference in the two receivers' clock offsets ( ) is the difference in the time between when the observations were taken. To account for this, the observations from one receiver may be shifted to align it with the other receiver. The magnitude of this shift is the line-of-sight motion multiplied by the difference in receiver offsets.

The Doppler measurement is an estimate of the line of sight motion so the above equation can be rewritten as:

Symbols

• : true line-of-sight range
• : observed code range
• : observed carrier phase measurement
• : time-adjusted code range measurement
• : observed carrier phase rate of change, an observation of line of sight motion (m/s)
• : receiver noise
• : receiver clock error
• : satellite clock error
• : user range error; represents the uncertainty in knowing the satellite's position
• : ionospheric delay
• : tropospheric delay
• : multipath error

The first numeric subscript is the receiver index while the second one is the SV index. So would be the noise of receiver 1 due to tracking SV 2.

ddStats

Computes statistics on ddGen output. Currently this is done in ddGen.

ddPlot

This tool plots the double difference results. It is written in python and uses matplotlib for generating the graphs. All double differences will be plotted by default, or you may specify plotting criteria using the command line options. A sample plot is show below. Click on the thumbnail to see a larger image.

Options:

ORD Tools

Overview

There is a suite of tools under /dev/apps/reszilla designed to compute observed range deviations (ORDs). The analysis is completed by successively using a combination of the smaller applications. The output of each of the programs is directly processed by another one. This format is called the ORD file, which is a table with time in the left-most column and various other values to the right. All lines that begin with a '#' sign are considered comments and will be ignored. An example of ORD file lines for an epoch:

# Time              Type PRN  Elev         ORD(m) wonky
2007  30 00:01:30.0    0   3  14.8       -4.66283     0
2007  30 00:01:30.0    0   6  15.0       -0.07912     0
2007  30 00:01:30.0    0   7  20.0       -2.51521     0
2007  30 00:01:30.0    0   9  31.8        0.52311     0
2007  30 00:01:30.0    0  14   8.3       -0.69202     0
2007  30 00:01:30.0    0  15  64.2     -217.71875     8
2007  30 00:01:30.0    0  18  61.0        0.41242     0
2007  30 00:01:30.0    0  21  88.6       -0.31408     0
2007  30 00:01:30.0    0  22  30.5       -0.66879     0
2007  30 00:01:30.0    0  24  19.2        2.59300     0
2007  30 00:01:30.0    0  26  36.7        0.35387     0
2007  30 00:01:30.0    0  29  25.3       -0.22743     0
2007  30 00:01:30.0    1                  0.33466     0
2007  30 00:01:30.0   50             115134.44377     0

Currently there are three types of lines that can be in a ord file:

• type 0: Observed range deviation. One line for each SV.
• type 1: Receiver clock offset deviation. One line for each epoch.
• type 50: Receiver clock offset estimate based upon a single epoch of data

Unless the a program is about to exit with an error, all output to stdout/cout is of the table form listed above. If a program is about to terminate with an error (i.e. exit(-1)) any text may be written to stdout. Non-fatal exceptions and such that need to be sent to the user need to be written to stderr(cerr). Often it is desirable to have various status/debugging type of messages to be output during the program executation. If these lines are to be kept in order of the ord file output, they are also be written to stdout. This may be done by proceeding them with a '#' to make them comment lines. See OrdApp.cpp for an example of how this is done during program initialization.

Output that is controlled by the verboseLevel (-v) option follows the rules above. Output that is controlled by the debugLevel (-d) command line option doesn't. That output always goes stdout and does not follow the ordfile format.

All programs accept the following options:

ordGen

This program will take station position, gps observations, wx observations, sv ephemeris and computes the difference between the estimated sv range and observed SV range. Solutions are output as the type 0 lines. No receiver clock adjustment is made, that is a job for ordClock.

Options:

The ords for each SV (each type 0 line) will have a wart flag in the last field, labeled "wonky" in the ord file header. The flag is created via the bitwise or (|=) assignements defined in OrdEngine.cpp. A summary of the conditions that lead to a wart flag are listed below.

ord.wonky |= 0x0001;

ord.wonky |= 0x0002;

ord.wonky |= 0x0004;

ord.wonky |= 0x0008;

ord.wonky |= 0x0010;

ord.wonky |= 0x0020;

TBD:

1. Define how the smart mode works

ordEdit

Options:

ordClock

Options:

TBD:

1. Defnine how ordClock sets epochs as wonky.

ordLinEst

#  t0                   t1                   t0 offset(m)  t1 offset(m)  slope(m/d)  abdev(m)
#  -------------------  -------------------  ------------  ------------  ----------  --------
>c 2007  30 00:00:30.0  2007  30 23:59:30.0   115134.109   115134.452        0.344      0.337

Options:

ordStats

# wonky epochs   total   % wonky epochs   # wonky ords   total ords   % wonky ords
# ------------   -----   --------------   ------------   ----------   ------------
>w        0       2879          0.00           576         29448          1.96

The second section contains stats for the ORDs, broken up by elevation bins. An example is included below. Again, note that the descriptive lines start with a "#" like any other comment. The lines containing the statistical data start with >r.

#  elev   stddev      mean      # obs   # bad   max    strip
#  ----   ------      ----      -----   -----  -----   -----
>r  0-10   6.04193    -0.892     4505     145  245.80  15006505.96
>r 10-20   1.83456    -0.104     5681      46   22.33  1928587.67
>r 20-60   0.78098    -0.035    13882     163    8.14  2247433.87
>r 60-90   0.64692     0.074     4628     209    3.16  4268100.13
>r 10-90   1.10425    -0.031    24311     418   22.33  2700863.93

The third section contains any clock offsets greater than 1 millisecond that were found. An example is included below. Again, note that the descriptive lines start with a "#" like any other comment. The lines containing the statistical data start with >b.

#  Time                         Offsets > 1ms
# ------                        -------------
>b  12/26/2005 08:30:00         300418.16854
>b  12/26/2005 08:56:00         300418.11752
>b  12/26/2005 08:56:30         300418.24771

Options:

If an output file is specified, lines will not be written with preceding # or > symbols.

ordPlot

This tool plots the ORD results. It is written in python and uses matplotlib for generating the graphs. A sample plot is show below. Click on the thumbnail to see a larger image.

Options:

TBD:

1. Option for plotting symbol size. This is useful if you are going to zoom in on an area - sometimes the default point size looks really tiny once you are looking a less dense area, or when you are printing and want larger symbols for visibility.

Examples

Example 1 - Basic Usage

This example assumes that the user wants to:

• Create a plot SamplePlot.png with residuals and clock offsets
• Provide observation data in a RINEX obs file sampleObs001.07o
• Use precise ephemeris when calculating ORDs
• Edit out data from unhealthy SVs using a RINEX nav file (broadcast ephemeris)
• Mask data from SVs below 10 degrees
• Look at statistics for the resulting ords

This could be done by stringing together the apps like so:

shell:] ordGen -o sampleObs001.07o -e apc14080 -e apc14081 -e apc14082 | ordEdit -e sampleNav001.07n -m 10 | ordClock | ordLinEst | 
          ordStats -o sampleStatsFile.txt | ordPlot -s Development.SamplePlot.png

Notes:

1. Be sure and provide precise ephemeris that spans some before and after your observation data time period. Hence the 3 apc files in the command above.
2. The position in the RINEX observation file will be assumed as the antenna position.

Example 2 - Changing Default Options

This example builds on Example 1 by assuming that the user wants to:

• Use obs data from station 12121 in a smooth file
• Raise the rate used to detect a clock jump from the default value of 10,000 m/day to 12,000 m/day
• Remove ords that do not have corresponding clock estimates
• Discard all data from PRN 15
• Ignore data before 02:00
• Produce stats based on elevation bins of 0-15, 10-40, 40-70,70-90, 15-90
• Use a sigma value of 5 in the data stripping performed by ordStats
• Set the title on the plot to "Greatest Plot Ever"
• Only plot the ords
• Set the y range to +/- 15 meters

This could be done by stringing together the apps like so:

shell:] ordGen -o sampleSmooth001.07o -e apc14080 -e apc14081 -e apc14082 -m 12121 -c sampleCoordsFile.txt | ordEdit 
       -e sampleNav001.07n -m 10 -p -15 | ordClock | ordLinEst -m 12000 | ordEdit -k --start="01/01/2007 02:00:00" | 
       ordStats -o sampleStatsFile.txt -b 0-15 -b 10-40 -b 40-70 -b 40-70 -b 70-90 -b 15-90 -s 5| ordPlot -y 15 -t 
       "Greatest Plot Ever"  -o -s Development.SamplePlot.png

The source files

• OrdEngine.?pp - A function object that is used to handling computing the ords.
• OrdApp.?pp - This is a class that all ord applications should inherit from. It includes initializing of the input and output streams, and reading and writing of ord files.
• RobustLinearEstimator.?pp - Computes a robust linear estimate of a time-ordered series.
• ObsReader.?pp - A class that reads 'all' types of observation data and generates ObsEpochs from them.
• EphReader.?pp - A class that reads 'all' types of observation data and generates an EphemerisStore object containing the data from all files read.
• MetReader.?pp - A class that reads Rinex met files and generates a WxObsMap object that contains the data from all files read.
  

TECMaps Application

Summary

Platforms Supported

This application successfully build under these environments: linux-x86, linux-x86_64, solaris-ppc, Windows/.net2005, MacOS/X-Code.

Usage example for Linux/Solaris/Mac Command Shell

Example use session from the GPSTk source distribution.

1. Change to the examples directory. cd ~/svn/gpstk/dev/examples
2. Generate azimuth and elevation extended RINEX observation files.
3. Execute TECMaps.

See also:

• EditRinex - generating extended RINEX observation files
• RinexPlot - plotting results
  

Timeconvert Application

Description

This application allow the user to convert between time formats associated with GPS. Time formats include: civilian time, Julain day of year and year, GPS week and second of week, Z counts, and Modified Julian Date (MJD).

Command Summary

calgps [options]

where [options] can be

    --z29 = TIME

    --input-format = ARG

    --input-time = ARG

Usage examples

Example 1.

user@host:~$ timeconvert -R "85 05 06 13 50 02"

Month/Day/Year                    5/6/1985
Hour:Min:Sec                      13:50:02
Modified Julian Date              46191.576412037
GPSweek DayOfWeek SecOfWeek       278 1 136202.000000
FullGPSweek Zcount                278 90801
Year DayOfYear SecondOfDay        1985 126 49802.000000
Unix_sec Unix_usec                484235402 0
Zcount: 29-bit (32-bit)           145842865 (145842865)

Example 2.

timeconvert -o "01 1379 500"

Month/Day/Year                    1/25/2026
Hour:Min:Sec                      00:08:20
Modified Julian Date              61065.005787037
GPSweek DayOfWeek SecOfWeek       355 0 500.000000
FullGPSweek Zcount                2403 333
Year DayOfYear SecondOfDay        2026 25 500.000000
Unix_sec Unix_usec                1769299700 0
Zcount: 29-bit (32-bit)           186122573 (1259864397)

Example 3.

timeconvert -o "01 1379 500" -a "86400"

Month/Day/Year                    1/26/2026
Hour:Min:Sec                      00:08:20
Modified Julian Date              61066.005798600
GPSweek DayOfWeek SecOfWeek       355 1 86900.999000
FullGPSweek Zcount                2403 579333
Year DayOfYear SecondOfDay        2026 26 500.999000
Unix_sec Unix_usec                1769386100 999000
Zcount: 29-bit (32-bit)           186180173 (1259921997)

Example 4.

timeconvert -w "1381 500" -s "200"

Month/Day/Year                    6/25/2006
Hour:Min:Sec                      00:09:10
Modified Julian Date              53911.006365741
GPSweek DayOfWeek SecOfWeek       357 0 550.000000
FullGPSweek Zcount                1381 366
Year DayOfYear SecondOfDay        2006 176 550.000000
Unix_sec Unix_usec                1151194150 0
Zcount: 29-bit (32-bit)           187171182 (724042094)