-
Notifications
You must be signed in to change notification settings - Fork 51
/
INTRO.txt
510 lines (400 loc) · 23.2 KB
/
INTRO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
\page INTRODUCTION INTRODUCTION
- \subpage GPSNutshell
- \subpage FileFormats
- \subpage Conversion
\page GPSNutshell GPS in a Nutshell
\tableofcontents
The Global Positioning System is actually a U.S. government satellite
navigation system that provides a civilian signal. As of this writing,
the signal is broadcast simultaneously by a constellation of 32
satellites each with a 12 hour orbit. From any given position on the
Earth, 8 to 12 satellites are usually visible at a time.
\section GPSNutshellSec GPS in a Nutshell
Each satellite broadcasts spread spectrum signals at 1575.42 and
1227.6 MHz, also known as L1 and L2, respectively. Currently the civil
signal is broadcast only on L1. The signal contains two components: a
time code and a navigation message. By differencing the received time
code with an internal time code, the receiver can determine the
distance, or range, that the signal has traveled. This range
observation is offset by errors in the (imperfect) receiver clock;
therefore it is called a pseudorange. The navigation message contains
the satellite ephemeris, which is a numerical model of the satellite's
orbit.
GPS receivers record, besides the pseudorange, a measurement called
the carrier phase (or just phase); it is also a range observation like
the pseudorange, except (1) it has an unknown constant added to it
(the phase ambiguity) and (2) it is much smoother (about 100 times
less measurement noise than the pseudorange!), which makes it useful
for precise positioning. Because of the way it is measured, the phase
is subject to random, sudden jumps; these discrete changes always come
in multiples of the wavelength of the GPS signal, and are called cycle
slips.
\subsection GPSPosSol The Position Solution
The standard solution for the user location requires a pseudorange
measurement and an ephemeris for each satellite in view. At least four
measurements are required as there are four unknowns: 3 coordinates of
position plus the receiver clock offset. The basic algorithm for the
solution is described in the official GPS Interface Control Document,
or ICD-GPS-200. The position solution is corrupted due to two sources
of error: errors in the observations and errors in the ephemeris.
\subsubsection GPSErrReduct Reducing Measurement Errors
The GPS signal travels through every layer of the Earth's
atmosphere. Each layer affects the signal differently. The ionosphere,
which is the high-altitude, electrically charged part of the
atmosphere, introduces a delay, and therefore a range error, into the
signal. The ionosphere delay can be predicted using a model. However,
the accuracy of ionosphere models is limited. A better alternative is
to measure and remove the ionosphere delay. Measurement of the
ionosphere delay is possible by taking advantage of the fact that the
delay is frequency dependent. It can be directly computed if you have
data on both the GPS frequencies. There is also a delay due to the
troposphere, the lower part of the atmosphere. Like the ionosphere
delay, the atmosphere delay can be either predicted or derived from
measurements. There are many other errors associated with the GPS
signal: multipath reflections and relativistic effects are two
examples.
More precise applications reduce the effect of error sources by a
technique referred to as differential GPS (DGPS). By differencing
measurements simultaneously collected by the user and a nearby
reference receiver, the errors that are common to both receivers (most
of them) are removed. The result of DGPS positioning is a position
relative to the reference receiver; adding the reference position to
the DGPS solution results in the absolute user position.
The alternative to DGPS is to explicitly model and remove
errors. Creating new and robust models of phenomena that affect the
GPS signal is an area of active research at ARL:UT and other
laboratories. The positioning algorithm can be used to explore such
models. Essentially, the basic approach is to turn the positioning
algorithm inside out to look at the corrections themselves. For
example, observations from a network of receivers can create a global
map or model of the ionosphere.
\subsubsection GPSImpEph Improved Ephemerides
The GPS position solution can be directly improved by using an
improved satellite ephemeris. The U.S National Geospatial-Intelligence
Agency (NGA) generates and makes publicly available a number of
precise ephemerides, which are more accurate satellite orbits
\cite ion:gnss04, \cite nga:website. Satellite orbits described by
the broadcast navigation message have an error on the order of meters;
the precise ephemeris has decimeter accuracy. The International GNSS
Service (IGS) is a global, civil cooperative effort that also provides
free precise ephemeris products \cite igs:reference. Global networks
of tracking stations produce the observations that make generation of
the precise ephemerides possible.
\section GPSDataSources GPS Data Sources
GPS observation data from many tracking stations are freely available
on the Internet. Many such stations contribute their data to the
IGS. In addition, many networks of stations also post their data to
the Internet; for example the Australian Regional GPS Network (ARGN)
\cite argn:website and global cooperatives such as NASA's Crust
Dynamics Data Information System (CDDIS) \cite cddis:website.
\subsection GPSFileFormats GPS File Formats
Typically GPS observations are recorded in a standardized format
developed by and for researchers. Fundamental to this format is the
idea that the data should be independent of the type of receiver that
collected it. For this reason the format is called Receiver
INdependent Exchange, or RINEX. Another format associated with GPS is
SP-3, which records the precise ephemeris. The GNSSTk supports both
RINEX and SP-3 formats.
\see FileFormats
\subsection GPSRxProto Receiver Protocols
GPS receivers have become less expensive and more capable over the
years, in particular handheld and mobile GPS receivers. The receivers
have many features in common. All of the receivers output a position
solution every few seconds. All receivers store a list of positions,
called waypoints. Many can display maps that can be uploaded. Many can
communicate with a PC or handheld to store information or provide
position estimates to plotting software.
Typically communication with a PC and other systems follows a standard
provided by the National Marine Electronics Association called
NMEA-0183. NMEA-0183 defines an ASCII based format for communication
of position solutions, waypoints and a variety of receiver
diagnostics. Here is an example of a line of NMEA data, or sentence:
\verbatim
$GPGLL,5133.81,N,00042.25,W*75
\endverbatim
The data here is a latitude, longitude fix at 51 deg 33.81 min North,
0 deg 42.25 min West; the last part is a checksum.
As a public standard, the NMEA-0183 format has given the user of GPS
freedom of choice. NMEA-0183 is the format most typically used by open
source applications that utilize receiver-generated positions.
Closed standards are also common. SiRF is a proprietary protocol that
is licensed to receiver manufacturers. Many receiver manufacturers
implement their own binary protocols. While some of these protocols
have been opened to the public, some have been reverse engineered.
\page FileFormats Supported File Formats
A variety of file formats are supported within the GNSSTk. The file
formats generally store GPS observation data or data related to
processing of GPS observables. In this section, a summary of the file
formats supported within the GNSSTk is presented along with a brief
rationale of why each format is supported within the GNSSTk and where
to find additional information on the format.
\section FileFormatsRINEX RINEX
The Receiver INdependent EXchange (RINEX) format was developed by the
National Geodetic Survey (NGS) in the U.S. and the University of Berne
in Switzerland. RINEX is actually three format definitions that allow
storage of GPS observations, GPS navigation message information, and
meteorological data associated with GPS observations. GNSSTk contains
classes to both read and write RINEX V2.1 and V3 data files of all
types (observation, navigation message, and meteorological). RINEX
has undergone a number of revisions since its inception. Each revision
is defined using a standard \cite rinex1format, \cite rinex2format,
\cite rinex211format, \cite rinex300format.
\section FileFormatsSP3 SP-3
The SP-3 format stores ephemeris information for satellites.
Usually SP-3 is used for storage of GPS precise ephemerides.
GNSSTk supports both SP-3a and SP3-c formats. SP-3 was originally designed
by NGS. Standards documents describe the specific details of the SP-3 formats
\cite sp3format:ngs, \cite sp3format:igscb.
\page Conversion Converting Coordinates & Time
\tableofcontents
\section ConvertTrans Transformations
Let \f$\mathbf{i}_{x}\f$, \f$\mathbf{i}_{y}\f$, \f$\mathbf{i}_{z}\f$
and \f$\mathbf{i}_{\varepsilon}\f$, \f$\mathbf{i}_{\eta}\f$,
\f$\mathbf{i}_{\zeta}\f$ be two sets of orthogonal unit vectors
\f[\mathbf{i}_{\xi}=l_{1}\mathbf{i}_{x}+m_{1}\mathbf{i}_{y}+n_{1}\mathbf{i}_{z}\f]
\f[\mathbf{i}_{\eta}=l_{2}\mathbf{i}_{x}+m_{2}\mathbf{i}_{y}+n_{2}\mathbf{i}_{z}\f]
\f[\mathbf{i}_{\zeta}=l_{3}\mathbf{i}_{x}+m_{3}\mathbf{i}_{y}+n_{3}\mathbf{i}_{z}\f]
\f[ \left[ \begin{array}{c} x \\ y \\ z \end{array} \right] = \mathbf{R}\left[ \begin{array}{c} \varepsilon \\ \eta \\ \zeta \end{array} \right] \mbox{or}
\left[ \begin{array}{c} \varepsilon \\ \eta \\ \zeta \end{array} \right] = \mathbf{R^{T}}\left[ \begin{array}{c} x \\ y \\ z \end{array} \right] \f]
\f[\mathbf{R}=\left[ \begin{array}{ccc}
\mathbf{i}_{x}\mathbf{\cdot}\mathbf{i}_{\varepsilon} & \mathbf{i}_{x}\mathbf{\cdot}\mathbf{i}_{\eta} & \mathbf{i}_{x}\mathbf{\cdot}\mathbf{i}_{\zeta} \\
\mathbf{i}_{y}\mathbf{\cdot}\mathbf{i}_{\varepsilon} & \mathbf{i}_{y}\mathbf{\cdot}\mathbf{i}_{\eta} & \mathbf{i}_{y}\mathbf{\cdot}\mathbf{i}_{\zeta} \\
\mathbf{i}_{z}\mathbf{\cdot}\mathbf{i}_{\varepsilon} & \mathbf{i}_{z}\mathbf{\cdot}\mathbf{i}_{\eta} & \mathbf{i}_{z}\mathbf{\cdot}\mathbf{i}_{\zeta}
\end{array} \right] = \left[ \begin{array}{ccc}
l_{1} & l_{2} & l_{3} \\
m_{1} & m_{2} & m_{3} \\
n_{1} & n_{2} & n_{3}
\end{array} \right] \f]
\f[ \mathbf{R^{T}}=\mathbf{R^{-1}} \f]
Equations found here \cite battin:imma [pp. 81-82]
\section ConvertTimeSystems Time Systems
\subsection ConvertSolarSidereal Solar & Sidereal Time
Since the beginning time has been kept by counting the days. An
apparent solar day is the minimum time elapsed between the sun
crossing a specified meridian and then recrossing the same
meridian. This form of time keeping is problematic because no two
apparent solar days are of the same duration due to Earth's rotation
around the sun as well as around its axis (the Earth does a little
more than one rotation per apparent solar day). Also, Earth's
rotational speed is not constant and its axis of rotation is tilted
23.5° to the orbital plane. These imperfections call for
correction, and thus mean solar time was created. A day in mean solar
time is defined as one revolution of a hypothetical sun that orbits at
the equator, and is more commonly known as Greenwich Mean
Time. Another solution is to base our day on the crossing of a star
much farther away thus minimizing the effect of the Earth's orbital
movement, this method of time keeping is known as sidereal time. A
sidereal day is about 4 minutes shorter than a solar day, and is used
heavily by astronomers. Sidereal time is not truly stable either so
mean sidereal day was introduced, and is known as Greenwich Apparent
Sidereal Time. Universal Time (UT) refers to any time scale based on
the Earth's rotation. UT0 refers to the mean solar time at the prime
meridian as obtained from astronomical observation, and UT1 is UT0
corrected for polar motion. Briefly ephemeris time was introduced to
standardize the second, which was defined as 1/31556925.9747 of the
year 1900. This was soon replaced by atomic
time\cite me:gsmp[pp. 84-86].
\subsection ConversionAtomicTime Atomic Time
The second is now defined by an atomic standard that is based on the
resonance frequency of the cesium atom. To be precise, the second is
defined as "9,192,631,770 periods of the radiation corresponding to
the transition between the two hyperfine levels of the ground state of
the cesium-133 atom," whose duration happens to exactly match the
ephemeris second discussed in the previous section. The problem with
detaching our time keeping method from the Earth is that as the Earth
slows its rotation noon will move closer to midnight (over the
duration of thousands of years, of course). Coordinated Universal Time
(UTC) was introduced to prevent this. UTC is a compromise between the
precision of atomic time and the groundedness of Earth based time
keeping, it uses the atomic second but introduces leap seconds
(positive or negative) when necessary to keep UTC within .9 seconds of
UT1\cite me:gsmp[pp. 86-87].
\subsection ConversionTimeFormats Time Formats
We are used to dealing with months, days, years, hours, minutes, and
seconds, but such a time format makes for difficult epoch calculations
over long periods. To solve this problem Julian Date (JD) was
introduced. JD consists of a day count (days since noon UT on January
1, 4713 B.C.) and a fraction of the current day. This makes for easy
time differencing, but the length of the date can become cumbersome
and the fact that a new day starts at noon confusing. To make things
even easier Modified Julian Date (MJD) was created whose origin is
midnight November 17, 1858.
\f[ \mbox{MJD}=\mbox{JD}-2400000.5\f]
In order to make Julian Date useful we need an easy way to go between
calendar dates and JD. \ref timeconvert does this and more with
ease. The equations to convert from calendar date to JD are
\f[ \mbox{JD}=\mbox{INT}[365.25y]+\mbox{INT}[30.6001(m+1)]+D+\mbox{UT}/24+1720981.5\f]
\f[ \begin{array}{lll}
y=Y-1 & \mbox{and}~m=M+12 & \mbox{if}~M \leq2 \\
y=Y & \mbox{and}~m=M & \mbox{if}~M > 2
\end{array} \f]
where \em M is the month, \em D is the day, \em Y is the year, and
INT[\em x] returns just the integer part of the number. To go from JD
to calendar date
\f[ a=\mbox{INT[JD}+0.5] \f]
\f[ b=a+1537 \f]
\f[ c=\mbox{INT}[(b-122.1)/365.25] \f]
\f[ d=\mbox{INT}[365.25c] \f]
\f[ e=\mbox{INT}[(b-d)/30.6001] \f]
\f[ D=b-d-\mbox{INT}[30.6001e]+\mbox{FRAC[JD}+0.5] \f]
\f[ M=e-1-12\mbox{INT}[e/14] \f]
\f[ Y=c-4715-\mbox{INT}[(7+M)/10] \f]
where FRAC[\em x] returns just the fractional part of a real
number. MJD Conversion found here\cite me:gsmp[p. 88]. All other date
conversions were found here\cite hlc:gtp[pp. 36-37]
\subsection ConvGPSTime GPS Time
GPS Time (GPST) is a continuously running composite time kept by
cesium and rubidium frequency standards aboard the satellites and at
monitor stations. While there are no leap seconds in GPST as there are
in UTC, it is steered to stay within 1 μs of UTC, that is the
difference between GPST and UTC is an integer number of seconds plus a
fraction of a μs. GPST is formatted in terms of GPS weeks and the
number of seconds into the current week. Finding these values is done
easily if the Julian Date is known.
\f[ \mbox{GPS WEEK}=\mbox{INT[(JD}-2444244.5)/7] \f]
\f[ \mbox{SOW}=\mbox{FRAC[(JD}-2444244.5)/7]\times 604800 \f]
where INT[\em x] returns the integer part of a real number, FRAC[\em x]
returns the fractional part, and SOW stands for Second of Week.
Other useful quantities such as Day of Week and Second of Day can be
found using \ref timeconvert or the following equations.
\f[\mbox{DOW}=\mbox{modulo\{INT[JD}+0.5],7\}\f]
\f[\mbox{SOD}=\mbox{modulo\{FRAC[JD}+0.5],7\}\times 86400\f]
where DOW=0 corresponds to Monday, DOW=1 corresponds to Tuesday, and
so on.
JD and GPS Week equations were found here\cite hlc:gtp[pp. 36-37], SOD
derived from DOW equation.
\subsection ConvZcount Z-Count
Satellites keep internal time with Z-count, whose epoch period is 1.5
seconds (a convenient unit for communications timing). The full
Z-count is 29 bits, the 10 bit GPS week folloed by a 19 bit Time of
Week (TOW) expressed in Z-counts (or 1.5 second units). The truncated
Z-count has a 17 bit TOW that is expressed in units of 6 seconds, or
the length of one subframe's transmission time. Simply multiply the
truncated TOW by 4 to get the full TOW\cite tsui:fgpsr[pp. 86-88].
\f[ \mbox{TOW}=\mbox{FRAC[(JD}-2444244.5)/7]\times 403200 \f]
\f[ \mbox{Truncated TOW}=\mbox{FRAC[(JD}-2444244.5)/7]\times 100800 \f]
Equations derived from SOW equation above
\section ConvECEF Earth Fixed Coordinates
\subsection ConvECItoECF ECI to ECF
\f[\left[\begin{array}{c} x \\ y \\ z \end{array}\right]_{ECF}=T_{XYZ}^{xyz}\left[\begin{array}{c} X \\ Y \\ Z \\ \end{array}\right]_{ECI}\f]
\f[T_{XYZ}^{xyz}=WSNP\f]
P - applies precession, from epoch 2000.0 to the current time;
N - applies nutation, from epoch 2000.0 to the current time;
S - applies rotation to account for true sidereal time;
W - applies polar motion;
Equations found on page 85 of Fundamentals of Orbit Determination paper book.
\subsection ConvWGS84 WGS-84
The World Geodetic System 1984 (WGS-84) is a fixed physical model of
Earth produced by the Department of Defense to which many different
reference frames can be attached. WGS-84 consists of two parts, a
model of Earth's gravitational field, and an ellipsoid describing the
Earth's general shape. When dealing with locations on the Earth's
surface the ellipsoid provides the foundation for the geodetic
coordinate system used by GPS. The ellipsoid's cross-sections parallel
to the equatorial plane are circular while those orthogonal are
elliptical. The ellipses are parameterized by an eccentricity \f$e\f$, a
flattening \f$f\f$, and sometimes a second eccentricity \f$e'\f$
\f[e=\sqrt{1-\frac{b^{2}}{a^{2}}}\f]
\f[f=1-\frac{b}{a}\f]
\f[e'=\sqrt{\frac{a^{2}}{b^{2}}-1}=\frac{a}{b}e\f]
where \f$a\f$, the semimajor axis, is the value of the mean equatorial
radius of Earth (6,378.137 km) and \f$b\f$, the semiminor axis, is the
value of the polar radius of Earth (6,356.7523142 km)
\cite kaplan:ugpspa[pp. 25-26].
\subsection ConvCoord Coordinate Systems
Now that WGS-84 is defined it is important to understand what
coordinate systems can be attached to the ellipsoid and how to move
between these different systems. The GNSS Toolkit comes with \ref
poscvt, an application that gives users the ability to easily convert
coordinates in one reference frame to another. The coordinate systems
that \ref poscvt recognizes are Cartesian (or XYZ), geodetic,
geocentric, and spherical coordinates. These systems and the formulas
to convert between them are discussed below.
\subsubsection ConvCart Cartesian (XYZ) Coordinates
The Earth Centered Earth Fixed (ECEF) Cartesian coordinate system is
fixed to the WGS-84 ellipsoid and is the common ground that makes
going between the Earth Centered Inertial (ECI) reference frame used
by the satellites and the systems we are used to (such as latitude,
longitude, and height) manageable. The equatorial plane makes the
\f$xy\f$-plane with the \f$+x\f$-axis pointing toward \f$0^{\circ}\f$
longitude and the \f$+y\f$-axis pointing toward 90° E
longitude. The \f$z\f$-axis is normal to the equatorial plane and
points to the geographical north pole. The conversion formulas
presented in the next sections will convert to and from this Cartesian
reference frame, and so to convert between two non-Cartesian
coordinate systems the XYZ system will be used as an
intermediary \cite kaplan:ugpspa[p. 24].
\subsubsection ConvGeodetic Geodetic Coordinates
The geodetic coordinate parameters are longitude \f$\lambda\f$,
latitude \f$\phi\f$, and height \f$h\f$. Longitude is defined as the
angle between the position and the \f$x\f$-axis in the equatorial
plane, and is easily computed given a position in Cartesian
coordinates. Let a user's position
\f$\mathbf{U}=(x_{u},y_{u},z_{u})\f$, then
\f[ \lambda = \left \{ \begin{array}{ll}
\arctan \left( \frac{y_{u}}{x_{u}} \right), & \mbox{$x_{u} \geq 0$} \\
180^{\circ} + \arctan \left( \frac{y_{u}}{x_{u}} \right), & \mbox{$x_{u} < 0$ and $y_{u} \geq 0$} \\
-180^{\circ} +\arctan \left( \frac{y_{u}}{x_{u}} \right), & \mbox{$x_{u} < 0$ and $y_{u} < 0$}
\end{array}
\right. \f]
where negative angles signal west longitude.
Latitude and height are not so straight forward. Latitude is
determined by drawing a vector normal to the ellipsoid, beginning
somewhere on the equatorial plane and terminating at the users
position, we will call this the user vector. The smallest angle
between this vector and the equatorial plane is the user's latitude,
it is a North latitude for positive angles and South for
negative. Notice that unless the user is at a pole or on the equator
the vector does not pass through the center of the Earth. The users
height is found by taking the magnitude of the vector originating on
and normal to the ellipsoid and terminating at the user's
position. Latitude \f$\phi\f$ and height \f$h\f$ are found using the
following equations
\f[ \phi = \arctan\left(\frac{z_{u}+e'^{2}z_{0}}{r}\right) \f]
\f[ h = U \left(1-\frac{b^{2}}{aV}\right) \f]
where
\f[ r = \sqrt{x_{u}^{2}+y_{u}^{2}} \f]
\f[ E^{2} = a^{2} - b^{2} \f]
\f[ F = 54 b^{2} z_{u}^{2} \f]
\f[ G = r^{2} + (1-e^{2}) z_{u}^{2} - e^{2} E^{2} \f]
\f[ c = \frac{e^{4} F r^{2}}{G^{3}} \f]
\f[ s = \sqrt[3]{1+c+\sqrt{c^{2} + 2c}}\f]
\f[ P = \frac{F}{3 \left( s + \frac{1}{s} + 1 \right)^{2}G^{2} } \f]
\f[ Q = \sqrt{1+2e^{4}P} \f]
\f[ r_{0} = -\frac{Pe^{2}r}{1+Q}+\sqrt{\frac{1}{2}a^{2} \left(1+\frac{1}{Q}\right)-\frac{P(1-e^{2})z_{u}^{2}}{Q(1+Q)}-\frac{1}{2}Pr^{2}}\f]
\f[ U = \sqrt{(r-e^{2}r_{0})^{2}+z_{u}^{2}}\f]
\f[ V = \sqrt{(r-e^{2}r_{0})^{2}+(1-e^{2})z_{u}^{2}} \f]
\f[ z_{0} = \frac{b^{2}z_{u}}{aV} \f]
Going back to Cartesian coordinates from the geodetic system
(\f$\lambda\f$ \f$\phi\f$ \f$h\f$) can be done more compactly
\f[ \mathbf{u} = \left[ \begin{array}{c}
\frac{a\cos\lambda}{\sqrt{1+(1-e^2)\tan^{2}\phi}}+h\cos\lambda\cos\phi \\
\frac{a\sin\lambda}{\sqrt{1+(1-e^2)\tan^{2}\phi}}+h\sin\lambda\cos\phi \\
\frac{a(1-e^{2})\sin\phi}{\sqrt{1-e^{2}\sin^{2}\phi}}+h\sin\phi
\end{array}
\right] \f]
where \f$\mathbf{u}\f$ is the user's position vector\cite kaplan:ugpspa,me:gsmp[pp. 26-28, p. 76].
\subsubsection ConvGeocentric Geocentric Coordinates
\f[x=r\cos\phi\cos\lambda\f]
\f[y=r\cos\phi\sin\lambda\f]
\f[z=r\sin\phi\f]
where \f$\lambda\f$ and \f$\phi\f$ are geocentric longitude and latitude
found on page 82 in the Fundamentals of Orbital Determination paper book
\subsubsection ConvTopo Topocentric Coordinates
\f[\mathbf{r}_{t}=T_{t}(\mathbf{r}-\mathbf{r}_{s})=T_{t}\rho\f]
\f$\mathbf{r}\f$ and \f$\mathbf{r}_{s}\f$ are the position vectors of
the observer and satellite respectively in the Earth-fixed system
\f[T_{t}=\left[ \begin{array}{ccc}
-\sin\lambda & \cos\lambda & 0 \\
-\sin\phi\cos\lambda & -\sin\phi\sin\lambda & \cos\phi \\
\cos\phi\cos\lambda & \cos\phi\sin\lambda & \sin\phi \end{array} \right] \f]
where \f$\lambda\f$ and \f$\phi\f$ are geocentric longitude and latitude
found on page 84 in the Fundamentals of Orbital Determination paper book
to find \em azimuth (Az) and \em elevation (El)
\f[ \begin{array}{ll}
\sin\mbox{El}=\frac{z_{t}}{r_{t}} & -90^{\circ} \leq \mbox{El} \leq 90^{\circ} \\
\sin\mbox{Az}=\frac{x_{t}}{r_{xy}} & \\
\cos\mbox{Az}=\frac{y_{t}}{r_{xy}} & 0^{\circ} \leq \mbox{Az} \leq 360^{\circ}
\end{array} \f]
Equations found on pages 84-85 in Fundamentals of Orbit Determination
paper book