Getting Started Processing GPS Data with
ODTK
1
Introduction
ODTK can process GPS Standard Positioning Service (SPS) or Precise Positioning Service
(PPS) pseudo-range and Doppler phase-count measurements. The measurements may be
input via a RINEX GPS Observation file or through a user-supplied measurement provider.
GPS navigation and space vehicle (SV) data may be input via several message types. These
include the HANU or Auxiliary User (AUX) message, the SP3 message, the RINEX GPS
Navigation message, the SEM almanac message, and the YUMA almanac message (see
section 2.3). This GPS capability has been extended to the ODTK Filter/Smoother, as well
as the ODTK Simulator, the ODTK Least Squares, and the ODTK Initial Orbit Determination (IOD) processes.
ODTK can also process navigation-solution measurements from a space-borne receiver.
These measurements are input via a special format (.NAVSOL) and do not require additional information about the GPS constellation.
The purpose of this guide is to help the user to get started with the GPS capability. It assumes that the user has installed ODTK, has access to the ODTK Help System, and has
some experience with ODTK.
2
2.1
GPS ODTK Inputs
GPS Measurement Types
ODTK can simulate and process GPS pseudo-range and phase-count measurements (the
raw measurements from the GPS receiver) as well as GPS receiver navigation-solution
measurements (a sequence of instantaneous estimates of receiver location generated onboard from pseudo-range measurements).
2.1.1 Pseudo-range and Phase-count Measurements
ODTK can process pseudo-ranges and phase-counts associated with the coarse acquisition
(CA) code on frequency L1 (1575.42 MHz) and, if available, the precise (P) code on frequencies L1 and L2 (1227.60 MHz). The measurements may be modeled / processed directly, or measurements may be combined using “observation-set models.” For pseudoranges, observation-set models include a singly-differenced model (SD) for CA pseudorange and a dual-frequency (DF) model for P1 and P2. A DF SD model is also available for
processing P1 and P2. Similarly for phase-counts, observation-set models include a SD
Processing GPS Data
1
model for phase-count measurements on L1, L2, or LA, and a DF model for combining
phase-count measurements on L1 and L2. A DF SD model is also available for processing
L1 and L2.
Different measurement models are chosen by selecting the appropriate Measurement
Type(s) to process (see attribute MeasurementProcessing.MeasTypes under the Satellite
Object, the attribute MeasTypes under the Filter Object, and the attribute MeasurementStatistics under the GPSReceiver Object). Descriptions of these measurement types follow:
1. CA Pseudo-range: Pseudo-range is processed using CA-code on L1. The User spacecraft / SV range is the modeled measurement. Receiver clock phase error and
clock frequency error are optionally modeled and estimated.
2. P1 Pseudo-range: Pseudo-range is processed using P-code on L1. The User spacecraft / SV range is the modeled measurement. Receiver clock phase error and
clock frequency error are optionally modeled and estimated.
3. P2 Pseudo-range: Pseudo-range is processed using P-code on L2. The User spacecraft / SV range is the modeled measurement. Receiver clock phase error and
clock frequency error are optionally modeled and estimated.
4. CA SD Pseudo-range: Singly Differenced (SD) range model. The modeled measurement is the range difference from two distinct SV CA code range measurements received at the same time. In this case, receiver clock errors are annihilated
from the measurement model, eliminating the need to estimate receiver clock
*
phase and frequency.
5. DF Pseudo-range: Dual-Frequency (DF) range model. Instead of processing P1
pseudo-range and P2 pseudo-range separately, the P1 and P2 pseudo-ranges are
combined into one pseudo-range that is corrected using the ICD-200 20.3.3.3.3.3
Ionospheric Correction model. Note that receiver clock phase error and clock frequency error are optionally modeled and estimated.
6. DF SD Pseudo-range: Dual-Frequency (DF) Singly Differenced (SD) range model.
First, each SV P1 and P2 pair is combined into one (ionospherically-corrected)
pseudo-range. The modeled measurement then becomes the range difference
*
The CA SD Pseudo-range model was added following our initial attempts to process CA
L1 pseudo-ranges from a JPL-designed GPS BlackJack receiver onboard the CHAMP satellite. While processing these data, it was discovered that the BlackJack receiver clock is
steered using onboard navigation solutions to 1 µs of GPS time (Montenbruck [1]), and
that this steering is (apparently) never turned off. Because 1 µs of clock error results in
roughly 300 meters of ranging error, the CA SD pseudo-range model gave improved results relative to the CA pseudo-range model.
Processing GPS Data
2
from two distinct SV corrected pseudo-ranges. Receiver clock phase and frequency
are not estimated.
7. LA Phase: Carrier phase-count on L1 derived from C/A code tracking. Receiver
clock phase error and clock frequency error are optionally modeled and estimated.
8. L1 Phase: Carrier phase-count on L1 derived from P code tracking. Receiver clock
phase error and clock frequency error are optionally modeled and estimated.
9. L2 Phase: Carrier phase-count on L2 derived from P code tracking. Receiver clock
phase error and clock frequency error are optionally modeled and estimated.
10. DF Phase: Dual-Frequency (DF) range model. Instead of processing L1 phasecount separately, L1 and L2 phase-counts are combined into a single phase-count
observation corrected for ionosphere effects. Note that receiver clock phase error
and clock frequency error are optionally modeled and estimated.
11. DF SD Phase: Dual-Frequency (DF) Singly Differenced (SD) phase-count model.
First, each pair of SV L1 and L2 is combined into a single (ionosphericallycorrected) phase-count. The modeled measurement then becomes the phasecount difference from two distinct SV ionosphere corrected observations. Receiver
clock phase and frequency are not estimated.
12. L1 SD Phase: Singly Differenced (SD) range model. The modeled measurement is
the phase-count difference from two distinct SV L1 phase-count measurements received at the same time. In this case, the receiver clock errors are annihilated
from the measurement model, eliminating the need to estimate receiver clock
phase and frequency.
13. L2 SD Phase: Similar to L1 SD Phase except for L2.
14. LA SD Phase: Similar to L1 SD Phase except for LA.
NOTES:
1. Some of these Measurement Types are mutually exclusive for selection with a filter object. Reference the Satellite.MeasTypes attribute within the ODTK Help System for the rules for filter selection.
2. For simulations, only CA, P1, P2, L1, L2, LA are simulated; desired measurements
can be further filtered using the SD and DF models.
2.1.2 Navigation Solutions
ODTK can process the position components of navigation solutions generated by a spaceborne GPS receiver. These position components are reduced in the Earth-Centered Fixed
(ECF) reference frame. The three components of position are considered as independent
measurements with the same noise characteristics.
Processing GPS Data
3
There are two types of navigation solutions which may be used: CA Nav Sol and DF Nav
Sol. Each is the result of using the associated type of pseudo-range in the reduction of the
navigation solution (CA or DF, as defined above). The white noise characteristics for each
measurement type may be defined in the MeasurementStatistics list on the GPS Receiver
object. There are no bias estimates associated with the processing of navigation solutions.
This means that biases in the CA navigation solutions due to un-modeled effects of the
ionosphere can bias the orbit solution.
2.2
Observation files
2.2.1 RINEX
The pseudo-range measurements are input to ODTK via a RINEX GPS Observation file
(Gurtner [2], [3]). Note that the RINEX 2.20 specification identifies 15 different observation types that may be included:
L1, L2 : Phase measurements on L1 and L2
C1
: Pseudo-range using C/A code on L1
P1, P2 : Pseudo-range using P-code on L1, L2
D1, D2 : Doppler frequency on L1 and L2
T1, T2 : Transit Integrated Doppler on 150 (T1) and 400 MHz (T2)
S1, S2 : Raw signal strengths or SNR values given by the receiver for L1, L2
LA
: Phase measurements on L1 derived from C/A code tracking
SA
: Raw signal strengths on SNR for LA
DA
: Doppler frequency on L1 derived from C/A code tracking
CH
: Receiver channel number
Currently the only GPS observation types used by ODTK are C1, P1, P2, L1, L2, LA and, if
available, S1, S2, and SA.
If S1, S2, and SA are available, the user has the option to edit out C1, P1, P2, L1, L2, LA
measurements for low signal-to-noise ratio (SNR). The RINEX format allows a signal
strength “flag” to (optionally) be given with each observable. This flag is used in lieu of
the S1, S2, and SA observations. If given, ODTK maps the SSI flag to these SNR values for
the purpose of SNR editing.
SNR: >500 >100
SSI:
9
8
>50
7
>10
6
>5
5
>3
4
>1
3
>0
2
bad
1
n/a
0
NOTE : RINEX versions higher than 2.2 are not yet supported.
Processing GPS Data
4
2.2.2 NAVSOL
Navigation solutions are input to ODTK via a NAVSOL observation file. ODTK’s NAVSOL
format allows for the specification of the position components and their associated spherical uncertainty (1σ). The format of the NAVSOL observation file is described in the ODTK
Help System.
2.2.3 Connecting a RINEX Observation File to Satellite Receiver
The RINEX file format specification does not actually mandate inputting of a receiver ID,
(i.e., MARKER NUMBER record). However, ODTK requires a method to associate the observations in the given RINEX observation file to the GPS Receiver ID given by the MeasurementProcessing.TrackingID attribute in the GPS Receiver Object (see section 2.4.2). If
no MARKER NUMBER record is included in the RINEX file, then the user must do one of
the following to associate the file to the receiver ID:
•
Manually edit the file to include a MARKER NUMBER record into the header
records, e.g., the line in italics below is inserted to associate this observation
file to satellite GPS receiver ID 3902.
2
BJfmtl_rnx
CHAMP-zenith
3902
•
2.3
OBSERVATION DATA
bai
GPS
RINEX VERSION / TYPE
2002-06-14 01:06:58 PGM / RUN BY / DATE
MARKER NAME
MARKER NUMBER
(Re)name the RINEX observation file to the form SATnnnn_xxxxxx.zzz, where
“nnnn” indicates the receiver ID; that is, begin with “SAT”, followed by a series of digits “nnnn”, followed by underscore “_”, followed by rest of filename
and extension. For example, the name SAT4000_SACC1670.03O associates
4000 to the receiver ID.
GPS Source Data
The CA L1 pseudo-range model takes the following navigation inputs:
1. SV ephemeris and clock correction estimates,
2. SV ephemeris and clock correction estimate error covariance, and
3. Model parameters for high accuracy correlation of GPS time to UTC time (and
TDT time); see Note 2 at the end of this section.
The ephemeris and clock-correction estimates are required. Other inputs can be used if
available from the GPS source. ODTK currently accepts the following GPS source messages:
1. Auxiliary User (AUX) Message aka (HANU) – Defined by ICD-GPS-208. This message type includes a 26-hour post pass Observation Message, a nine-hour high accuracy Prediction Message, and a 40-hour prediction LookAhead Message.
Processing GPS Data
5
2. SP3 – ASCII message containing post pass SV ephemeris, but broadcast SV clock
parameters. Easily obtained, for example, through the NGA at http://earthinfo.nga.mil/GandG/sathtml/ephemeris.html or from the IGS at
http://igscb.jpl.nasa.gov/components/prods.html.
3. RINEX GPS Navigation Message – ASCII message (defined in [2]) containing the
navigation data defined in ICD-GPS-200. Can be accessed, for example, through
ftp://cddis.gsfc.nasa.gov/pub/gps/data/daily.
4. SEM Almanac – ASCII message containing navigation message almanac information in SEM format. Reference
http://navcen.uscg.gov/?pageName=gpsAlmanacs for a definition and catalog of
files.
5. YUMA Almanac – ASCII message containing navigation message almanac information in YUMA format. Reference
http://navcen.uscg.gov/?pageName=gpsAlmanacs for a definition and catalog of
files.
The following table summarizes the types of data available from each data source:
Type
Eph/Clock
Covariance
GPS/UTC
Ionosphere
AUX
Observation
Post Pass
Interpolate
Table
Yes
No
No
AUX
Prediction
High
Precision
Predict
Interpolate
Table
Yes
No
No
AUX
Look Ahead
Predict
Interpolate
Table
No
Yes
No
SP3
Eph –
PostPass
Clock Predict
Interpolate
Table
No
No
No
RINEX NAV
Predict
No
Optional
Optional
SEM
Predict
No
No
No
YUMA
Predict
No
No
No
Element
Propagation
Element
Propagation
Element
Propagation
ODTK allows the user to select one source file to be selected for ephemeris / clock / covariance inputs, and optionally one source file for GPS/UTC high accuracy correlation parameters. GPS source information is entered via the GPS Constellation object (cf. Section
2.4.1).
Processing GPS Data
6
NOTES:
1. Only one source file can be entered for ephemeris/clock/covariance data.
Therefore the filter start/end time span should be limited to be consistent
with the time span of this source file.
2. The GPS/UTC high accuracy correlation parameters refer to the A0 and A1
constants which identify the GPS-UTC offset in addition the leap second offset. For CA L1 pseudo-range processing these can safely be ignored. See
http://tycho.usno.navy.mil/gpstt.html for a nice discussion on GPS time
transfer and http://tycho.usno.navy.mil/gps_datafiles.html for SPS time differences.
3. ODTK expects a file extension of .aux for AUX messages, .sp3 for SP3 messages, .rinex for RINEX NAV messages, .yuma for YUMA messages, and .sem for
SEM messages.
2.4
ODTK Objects Unique to GPS
The following is an example Object Browser view for an ODTK filter/smoother run processing GPS pseudo-range measurements:
The user should note the following two objects unique to GPS processing:
1. A GPS Constellation Object under the Scenario Object
2. A GPS Receiver Object under the Satellite Object
Refer to the Insert Menu in ODTK Help System for instructions on adding objects.
ODTK will only allow one GPS Constellation Object per scenario. ODTK will accept multiple GPS Receiver Objects per Satellite and multiple Satellites with GPS Receivers.
2.4.1 GPS Constellation Object
The GPS Constellation Object is documented in the ODTK Help System contents under OD
Objects & Attributes – GPS Constellation.
Processing GPS Data
7
NOTE: A GPS constellation object is not currently required to filter navigation solutions as measurements, but one is required to simulate navigation solutions.
2.4.2 GPS Receiver Object
The GPS Receiver Object is documented in the ODTK Help System under OD Objects &
Attributes – GPS Receivers.
3
3.1
Sample Procedures for ODTK Run
Procedure for GPS Simulation Run
The following procedure outlines steps necessary to make a simple ODTK Simulation run.
The first part of the process is the same regardless of whether one wishes to simulate a set
of pseudo-ranges and phase-counts or a navigation solution. In the following example
there is one satellite which has one GPS receiver processing CA pseudo-range.
1. The first step is to obtain the GPS navigation data to be used in the simulation. In
this example we assume that we do not have any measurements in hand and will
download data via the Internet. In this example we will download the NIMA GPS
Precision Ephemeris (PE) Antenna Phase Center (APC) SP3 formatted file for
31-May-2010 (included in apc15861.exe).
•
Start with the NGA “GPS Satellite Branch Home Page”:
http://earth-info.nga.mil/GandG/sathtml/
•
Go to the Ephemeris Data Page (http://earthinfo.nga.mil/GandG/sathtml/ephemeris.html) and click the “Antenna
Phase Center (APC)” link under Direct FTP Sites
(ftp://ftp.nga.mil/pub2/gps/apcpe/) to bring up access to dated
NAVSTAR constellation files with position and velocity components referred to Antenna Phase Center (APC). Descend into the 2010 directory.
•
Select and copy .exe file of interest (in this case apc15861.exe) to an appropriate GPS Source folder.
•
DOS execute the .exe file to generate a .APC file (in this case the result
will contain NGA15861.APC).
•
Change the extension of the .APC file to be a .sp3 file for use in ODTK
(NGA15861.sp3 in our case).
2. Start ODTK.
3. Create the ODTK objects necessary for the simulation:
Processing GPS Data
8
•
Create a Scenario Object.
•
Set DefaultTimes.Processes.StartMode to StartTime. Set DefaultTimes.Processes.StartTime to "31 May 2010 GPSG". This date corresponds with the SP3 file from Step 1. (If UTCG units are specified as the
default, the display will automatically change to "30 May 2010
23:59:47.000 UTCG".)
•
Set DefaultTimes.Processes.StopMode to TimeSpan. Set DefaultTimes.Processes.TimeSpan to "4 hr".
•
Add a GPS Constellation Object to the Scenario Object.
•
Add a Satellite Object to the Scenario Object.
•
Add a GPS Receiver Object to the Satellite Object.
•
Add a Simulator Object to the Scenario Object.
The resulting Object structure should be similar to:
4. Open and Edit (if necessary) the Scenario Object attributes. In this example we
will make no further changes and accept the defaults.
5. Open and Edit the Satellite Object attributes. In this example we will accept the
defaults, except as follows:
•
Edit the MeasurementProcessing.MeasTypes attribute by removing all
measurement types except CA Pseudo-range and CA Nav Sol.
6. Open and Edit the GPSReceiver Object Attributes. In this example we will accept
the defaults, except as follows:
•
Edit the MeasurementStatistics attribute.
•
Remove CA SD Pseudo-range (if present).
•
(Navigation Solution Processing Only) Add CA Nav Sol.
Processing GPS Data
9
7. Open and Edit the Simulator Object Attributes. For this example we will accept
the defaults, except as follows:
•
Edit the MeasTypes attribute by removing all measurement types except
CA Pseudo-range.
•
Edit the Output.Measurements.Filename attribute so that the extension of
the output file is consistent with the RINEX plugin (see step 7 above).
NOTE: The CA Nav Sol measurement type is not available in the Simulator because it is not simulated directly. Simulated CA Nav Sol measurements are
created by computing navigation solutions based on simulated pseudo-range
measurements.
8. Open and Edit the GPS Constellation Object Attributes
•
Edit the Source.FileName attribute to select the GPS Source file that we
chose in Step 1. In our case: NGA15861.sp3 from the appropriate GPS
Source directory.
•
Set the Source.BufferBeforeFileStart to 1 minute.
•
For this example we will accept the defaults for the remaining attributes.
9. Save the scenario.
10. Run Simulator.
11. Verify output using Measurement File Preview (GPS) and Measurement Listing
from the Static Product Builder.
12. (Navigation Solution Simulation Only) Generate a file of navigation solutions
based on the simulated pseudo-range.
•
Bring up the ODTK LaunchPad, click on the ODTK Utilities tab, then open
the Installed Utilites folder.
•
Double click on the GenerateNAVSOLutions.htm tool from the list box.
•
Browse to select the RINEX file (.rnx) you just generated as the input for
the tool. A default output name will be generated for you.
•
Click Go! to generate the NAVSOL file.
Processing GPS Data
10
3.2
Procedure for GPS Filter Run
3.2.1 Pseudo-range Processing
The following procedure outlines the steps necessary to make a simple ODTK Filter run. In
this example there is one satellite which has one GPS receiver processing CA pseudorange. This filter object uses the simulation outputs from section 3.1 above.
1. Start with the Scenario and Outputs from the simulation in 3.1 above.
2. Add a Filter Object to the Scenario Object.
3. Open and Edit the Filter Object Attributes. In this example we will accept the defaults, except as follows:
•
4.
Edit the MeasTypes attribute by removing all measurement types except
CA Pseudo-range and CA Nav Sol.
(Optional) To monitor progress of the run, go to View Dynamic Product Selector:
•
•
Then, for example, select:
i. Dynamic Display
= Report
ii. Object Type
= Satellite
iii. Style
= Measurement Update
iv. Satellites
= Satellite1
And/Or, select:
i. Dynamic Display
= Report
ii. Object Type
= GPS Receiver
iii. Style
= Measurement Update
iv. GPS Receiver
= GPSReceiver1
5. Run Filter.
6. Use Static Products to analyze run.
3.2.2 Navigation Solution Processing
Follow the procedure listed above for pseudo-range processing:
1. Start with the Scenario and Outputs from the simulation in 3.1above.
2. Add a Filter Object to the Scenario Object if not already done
Processing GPS Data
11
3. Open and Edit the Filter Object Attributes. For this example we will accept the defaults, except as follows:
•
Edit the MeasTypes attribute by removing all measurement types except
CA Nav Sol or adding CA Nav Sol if necessary.
4.
Open and edit the Scenario Object Attributes. Add the generated navigation solution file (.NAVSOL) to the Measurements.Files list. Remove or disable the RINEX
file which was placed in the list by the simulator.
5.
(Optional) To monitor progress of the run, view Dynamic Reports:
•
Then, for example, select:
i. Dynamic Display
= Report
ii. Object Type
= Satellite
iii. Style
= Measurement Update
iv. Satellites
= Satellite1
6. Run Filter.
7. Use Static Products to analyze the results.
NOTE: The performance of the filter may be poor while processing of navigation solutions, even with simulated measurements. This poor performance is a result of the effect of the ionosphere on the CA navigation solutions and the lack of a precise relationship between the noise on the pseudo-range measurements and the noise on the
navigation solutions. Edit the properties of the GPS Constellation object to turn off the
effects of the ionosphere on the CA pseudo-range measurements and rerun the simulator, navigation solution.
8. Open and edit the properties of the GPS Constellation object to turn off the effects
of the ionosphere (set GPS.Ionosphere.IonosphereModel = none).
9. Run the Simulator.
10. Regenerate the navigation solutions following the process described in last step of
Section 3.1.
11. Reset the Measurements.Files list in the Scenario to use the navigation solutions
and disable the RINEX data file created by the simulator.
12. Run the Filter.
13. Use Static Products to analyze the results.
Processing GPS Data
12
3.3
Simulator and Filter Wizards
The user has the capability to create GPS-related simulation and filter related objects and
scenarios using the ODTK Wizards.
4
References
[1] Oliver Montenbruk, Remco Kroes, In-Flight Performance Analysis of the CHAMP BlackJack GPS Receiver, GPS Solutions, Revision 1, 31 March 2003.
[2] Werner Gurtner, RINEX: The Receiver Independent Exchange Format Version 2.10,
8 June 2001.
[3] Werner Gurtner, and Lou Estey RINEX Version 2.20 Modifications to Accommodate
Low Earth Orbiter Data, April 24, 2001. ftp://ftp.unibe.ch/aiub/rinex/rnx_leo.txt.
Processing GPS Data
13