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 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 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.