Felipe Tampier Jara

Gdoper: A practical GNSS

post-processing tool for Python

Bachelor of Science thesis

Faculty of Information Technology and Communication Sciences (ITC)
Examiners: Prof. Simona Lohan and Dr. Joonas Säe
May 2021
Abstract
Felipe Tampier Jara: Gdoper: A practical GNSS post-processing tool for Python
Bachelor of Science thesis
Tampere University
International Bachelor’s Programme in Science and Engineering
May 2021

The content of this thesis is focused on the implementation of an open source, easy
to use program created using Python. The program is called Gdoper, which stands
for ”the do-er of GDOP”. The program computes the Geometric Dilution Of Preci-
sion (GDOP) given the positioning data processed by a Global Navigation Satellite
System (GNSS) receiver. In other words, the program reads a file containing posi-
tioning data and with minimal configuration — if any— samples and computes the
GDOP of the positions given by the data.

A theoretical background is established to give a basic understanding about the

shape of Earth, orbital mechanics, and how the Global Positioning System (GPS)
GNSS provides its positioning service. Along with this, the specifics of how the pro-
gram obtains the data required for the GDOP calculation, the calculation itself, and
a variation of it called WGDOP (weighted GDOP), are explained in chapters 3 and
4. With chapter 3 giving the details of the calculations, and chapter 4 describing
the implementation.

Chapter 5 demonstrates potential usage of the program with results obtained

from processing the flight data of drone surveys, along with an analysis of the results
themselves.

Keywords: GPS, Galileo, GDOP, WGDOP, Python, drone, positioning, post-

processing.

The originality of this thesis has been checked using the Turnitin Originality Check
service.
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Background theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Geodesy, the shape of Earth . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Orbital mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Global Positioning System . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 GPS Navigation message . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Receiver Independent Exchange format, RINEX . . . . . . . . . 11
3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Calculation of satellite position . . . . . . . . . . . . . . . . . . . . . 12
3.2 Calculation of receiver FOV . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Calculation of GDOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Program implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 General overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Gdoper modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Scope and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Example results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Analysis of individual flights . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Analysis of a set of flights . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
APPENDIX A.
RINEX format for GPS data record . . . . . . . . . . . . . . . . . . . . . . 31
APPENDIX B.
Algorithms for determining GPS SV position . . . . . . . . . . . . . . . . . 32
List of Figures

2.1 Various levels of flattening. . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Plumb line comparison. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Orbital parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 GPS NAV message structure. . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Example RINEX data. . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 FOV triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 Path of flight 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 Path of flight 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Path of flight 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 DOPs and visible SVs 1. . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5 DOPs and visible SVs 2. . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.6 DOPs and visible SVs 3. . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.7 Several FOV models. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8 Speeds of the set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9 DOP vs visible SVs in set. . . . . . . . . . . . . . . . . . . . . . . . . 27

List of Tables

2.1 Ellipsoid parameters according to WGS 84. . . . . . . . . . . . . . . . 5

2.2 Relation between Cartesian and polar coordinates. . . . . . . . . . . 5
2.3 Orbital parameters description. . . . . . . . . . . . . . . . . . . . . . 8
2.4 GPS ephemeris parameters. . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Functional requirements. . . . . . . . . . . . . . . . . . . . . . . . . . 20

List of Abbreviations
CHN Column Header Name

CNAV Civil Navigation

DOP Dilution of Precision

ECEF Earth-Centered Earth-Fixed

FOV Field of View

GDOP Geometric Dilution of Precision

GNSS Global Navigation Satellite System

GPS Global Positioning System

HCT Harmonic Correction Term

HDOP Horizontal Dilution of Precision

HOW Handover word

IERS International Earth Rotation and Reference Systems Service

IRM IERS Reference Meridian

ISO International Organization for Standardization

LNAV Legacy Navigation

NAV Navigation

RAAN Right Angle of the Ascending Node

RINEX Receiver Independent Exchange Format

SV Satellite Vehicle

TLM Telemetry Word

URA User Range Accuracy

VDOP Vertical Dilution of Precision

WGDOP Weighted Geometric Dilution of Precision

WGS World Geodetic System

List of Symbols
a Semi-major Axis of Earth

e Eccentricity

f Flattening factor of an ellipse

ψ Geocentric latitude

ϕ Geodetic latitude

α Angle between observer and SV positions

ma Mask angle

thp Threshold Point

mv Mask vector

u User/observer Position Vector

O ECEF coordinate system Origin

gpsh Distance between Threshold Point and the Origin

da Angle between User Position Vector and Mask Vector

β Angle between the origin and the observer at SV position

i Inclination of an orbit

ω Argument of the perigee

v True anomaly

Ω RAAN

M0 Mean anomaly

∆n Mean motion difference from the computed value

√
A Square root of the Semi-major Axis

Ω0 RAAN at weekly epoch

i0 Inclination angle at reference time

Ω̇ Rate of right ascension

Cuc Amplitude of the Cosine HCT to the Argument of Latitude

Cus Amplitude of the Sine HCT to the Argument of Latitude

Crc Amplitude of the Cosine HCT to the Orbit Radius

Crs Amplitude of the Sine HCT to the Orbit Radius

Cic Amplitude of the Cosine HCT to the Angle of Inclination

Cis Amplitude of the Sine HCT to the Angle of Inclination

toe Reference Time Ephemeris

IODE Issue of Date, Ephemeris

 1

1 Introduction
Global Navigation Satellite Systems (GNSS) provide positioning services that are
essential to modern everyday applications. One of the most commonly known use
cases of GNSS is its use in mobile phones by map applications, which determine the
user’s position without any input other than opening the application. The position-
ing services provided by GNSS do not limit themselves to consumer applications,
rather, many of them are also key components for the commercial and industrial
sector [1].

GNSS are designed to be as robust as possible, since the constellation of satel-

lites cannot be serviced easily and each satellite has size, mass, and power restraints
that have to perform as efficiently and reliably as possible, all while keeping sensi-
tive instruments safe in the extreme environment of space. The robustness of the
systems is shown not only by the quality of the construction of the satellite but also
in the accuracy and reliability of the positioning service provided to the users. The
level of accuracy and reliability of these systems can be verified by its widespread
use in commercial and industrial environments, as these environments have strict
requirements for both accuracy and quality of positioning.

Regardless of the build quality and engineering prowess involved in building a

GNSS, there are physical limitations that cannot be bypassed to achieve greater
accuracy. Examples of these physical limitations are: blockage of the signals by
building, trees, or massive objects; multipath effects that distort the arriving signal
in ways the receiver cannot decipher; and in general, poor visibility of the sky from
which the satellite signals come from.

Indicators of the positioning quality are usually available to the receiver for
processing in real time. The entire process of receiving a signal, decoding it, and
computing the receiver position is usually done in a closed system. The closed sys-
tem output can simply be: a position estimate, an error margin, plus possibly some
extra information like the number of visible satellites at the time of computation.
To better analyze the positioning quality indicators, post-processing is needed, such
that the information gathered in the closed system can be recreated and accessed.
This thesis describes the implementation of a post-processing program that can
recreate the lost information given only a few data points output from the closed
system of the receiver.
 2

The post-processing program is called Gdoper. The name comes from ”the do-
er of GDOP” (Geometrical Dilution Of Precision), where GDOP is a positioning
quality indicator calculated from the distribution and relative positions of GNSS
satellites in the sky. To obtain the GDOP value for an estimated receiver position,
the positions of the satellites visible by the receiver must be known. The latter can
be computed theoretically, or extrapolated from the number of visible satellites as
output by the receiver, along with the time of the initial position calculation and
publicly available satellite positioning data in RINEX (Receiver Independent Ex-
change Format) v2.11 from trusted online repositories. Gdoper does all the above
mentioned tasks and outputs the GDOP values along with the values used to cal-
culate it, into a .csv formatted file from which further processing can be done.

Specifically, the purpose of this thesis is to describe the functionality of Gdoper

by first providing the background information needed to understand the basics of
how GNSS works, then explaining the methods used in the program to perform its
objectives, and finally, to analyze positioning data obtained from drone surveys as
an example of the use cases for the program. The program is an open source project
and at the time of writing works fully with the Global Positioning System (GPS)
and partially with Galileo.

The main contributions of this thesis are:

• Providing a literature review on GPS and GDOP concepts

• Implementing a Python-based program which takes as inputs drone-based1

.csv files and RINEX files publicly available from ftp://data-out.unavco.
org/pub/rinex/nav

• Implementation of 2 theoretical models for calculating the field of view (FOV)

of a receiver

• Analyzing the relation between amount of visible satellites and GDOP values

1
The drone-based data was obtained from drone surveys at Tampere University by other mem-
bers of the team
 3

2 Background theory
2.1 Geodesy, the shape of Earth

The classical definition of geodesy is: “science of the measurement and mapping
of the Earth’s surface” [2]. Geodesy can be thought of having three main areas
of study: global geodesy, national geodetic surveys, and plane surveying. Global
geodesy is the area of interest for this thesis, as it concerns the geometrical shape
of the Earth and its external gravity field. National geodetic surveys concern the
determination of the surface geometry and the gravity field of a country, and plane
surveying is done at much smaller scales usually with reference to a local horizontal
plane [2].

In the field of Global geodesy, the Earth can be presented as a physical or as a

mathematical surface. The physical representation concerns the border between the
solid and fluid masses of Earth. It is too complicated to be described by a simple
mathematical relation, so it is described pointwise. The mathematical representa-
tion of Earth is called the Geoid. It is a representation of the equipotential (level)
surface of Earth, that is, a theoretical surface that extends from the surface of the
oceans to under the continents such that, at every point, this surface has equal
gravitational potential (hence equipotential). The aforementioned surface does not
take into account tidal effects [2].

A more convenient and universally used model of the Earth, is the mathematical
model of Earth represented as an ellipsoid (also called a spheroid). A sphere is a
relatively accurate representation of the Earth near the equator, however, closer to
the poles, the position on the sphere’s surface starts to deviate significantly from the
real position. The ellipsoid is an ellipse of revolution. The above-mentioned ellipse
can be characterized by the following equation [3].

x2 y 2
+ 2 = 1,
a2 b
where x and y are the Cartesian coordinates of a point on the ellipse, and a and
b are, respectively, the semi-major and semi-minor axes. The following parameters
help determine the shape of an ellipse in a more concise manner.
√
c= a2 − b 2 ,
 4

where c is called the focal distance,

c
e= , (2.1)
a
e is the eccentricity of an ellipse,

(a − b)
f= , (2.2)
a
and f is the flattening.

Flattening represents how much the ellipsoid differs from a circle. A value of
f closer to 1 represents a very oblate ellipse, while a low value describes an ellipse
that resembles the shape of a circle. The following illustration gives an example of
the effect of flattening:

















Figure 2.1 Various levels of flattening.

“Given either of the size parameters a or b, and a shape parameter e or f , the

others may be derived.” [3]. Knowing any two of these parameters, it is possible
to determine the shape of the ellipsoid of rotation that approximates the shape of
Earth. One of the best approximations to the ellipsoid model of earth is given by the
World Geodetic System 1984 (WGS 84) standard, which is used as the main reference
for the GPS standard [4]. WGS 84 defines a set of constants and parameters that
characterize the size, shape, positioning, and gravitational and geomagnetic fields of
Earth. The parameters used for describing the shape of the ellipse from which the
ellipsoid is generated, are presented in Table 2.1.
 5

Table 2.1 Ellipsoid parameters according to WGS 84.

Parameters Notation Value

Semi-major Axis a 6378137.0 meters
1
Flattening factor of Earth f
298.257223563

2.2 Coordinate systems

Using the three-dimensional Cartesian coordinates can be quite difficult to under-

stand when referring to a position on the surface of a spheroid shape such as the
Earth. A more human-readable format to interpret a position on Earth is by us-
ing polar coordinates. Polar coordinates present a latitude-longitude pair that, for
most positioning purposes on Earth, is enough to know. Height is not particularly
relevant when for example looking at a map, however, it is an essential parameter
for conversion purposes, as well as for 3-dimensional localization purposes, as it will
be discussed later on.

The 3D (x, y, z) Cartesian coordinate system defined by WGS 84 is Earth-

centered Earth-fixed (ECEF) model where the coordinate system origin, is the el-
lipsoid of revolution’s geometric center [5]. The geometric center coincides with
Earth’s center of mass, that is, the whole terrestrial mass together with the oceans
and atmosphere [4]. The z axis serves as the rotational axis of the ellipsoid of revo-
lution. The plane generated by the x- and z-axis, intersects the IERS (International
Earth Rotation and Reference Systems Service) Reference Meridian (IRM). This is
the meridian of latitude 0º which is maintained by IERS. The y-axis completes the
right-handed orthogonal coordinate system. The formulae shown in Table 2.2 can
be used to convert from Cartesian to Polar coordinates.

Table 2.2 Relation between Cartesian and polar coordinates.

Cartesian parameters Polar equivalent

x r cos ψ cos λ
y r cos ψ sin λ
z r sin ψ

In Table 2.2, ψ is the latitude and λ is the longitude, while r corresponds to the
radius of a sphere. The Earth, however, is not a sphere; therefore, it makes sense
that r is though of as the total distance to a point of the surface, where r = R + h.
Here, h is the altitude or deviation from the sphere (the difference between the
sphere’s radius and the surface of Earth), and R is the polar radius of the Earth [6].
 6

The previous equivalencies from Table 2.2, are not commonly used for repre-
senting a position on Earth. This is because a vector in polar coordinates is not
perpendicular to the tangent at the surface, making the calculations that take into
account the general shape of Earth more difficult.

To clarify the previous reasoning, it is helpful to visualize (see Figure 2.2) a

vector that extends from the center of mass of Earth, out through the surface. It
would seem that this line, protruding from the ground, would be diagonal to the
“up” direction (also called plumb line), because said line would not be normal to
the geoid (the model of the surface of Earth in which a line normal to the surface
pointing outwards is the “up” direction) [6], but rather, normal to a sphere. If said
vector would be perpendicular to the surface of the ellipsoid and have a center dif-
ferent to the origin, it would also be diagonal to the plumb line, however, it would
be a much better representation of the perpendicular to the general surface of Earth.

When the latitude is calculated from the origin, it is called a geocentric lati-
tude. When the latitude is calculated from a place on Earth level to the surface
(normal to the geoid), it is called a geographic (or astronomical) latitude. Finally,
when the latitude is calculated for example, by GPS; it is done in reference to the
ellipsoid representation of Earth, and it is called a geodetic latitude. The latter is
the one commonly referred to when the word latitude is used by itself without a
qualifier (such as geocentric or geographic) and hence it is the one commonly used
for navigation.

Plumb line
Perp. to Sphere
Perp. to Ellipsoid

Surface

Geoi
d

Ellipso
id

Figure 2.2 Exaggerated comparison of plumb line to other perpendiculars.

 7

In order to transform the latitude from geocentric to geodetic, the following

formula [6] can be used:
tan ψ
tan ϕ = , (2.3)
(1 − f )2
where ψ is the geocentric latitude, ϕ is the geodetic latitude and f is the flattening
of earth.

2.3 Orbital mechanics

To properly describe the position of a satellite in time, it is necessary to first char-

acterize the specifics of its orbit. Satellites that have negligible mass (all artificial
satellites) relative to Earth, follow well planned elliptical orbits. These orbits can be
identified by the parameters of the ellipse they follow as well as by the orientation
of the ellipse around Earth [7]. The most common way to describe an orbit is by its
Keplerian elements. The aforementioned elements can be best understood visually,
hence, Figure 2.3 and Table 2.3 present the orbital parameters as Keplerian elements
and their descriptions.

Satellite
position Perigee

Orbital plane v

Ecuatorial plane

ω
Earth

Y
Ω i

Ascending
X
2a Node

Apogee

Figure 2.3 Keplerian elements of an orbit.

 8

Table 2.3 Keplerian elements description.

Description Symbol
Semi-major axis a
Inclination of orbit i
Argument of the perigee ω
True anomaly v
Right Angle of the Ascending Node (RAAN) Ω

In the GPS ephemeris1 , the orbital parameters are delivered in a way that they
have to be computed by the receiver, in other words, the data is not delivered
in terms of conventional Keplerian elements but rather as data from which these
elements can be extrapolated. The orbital parameters delivered by GPS ephemeris
are presented in the following Table 2.4 [8]:

Table 2.4 GPS ephemeris parameters.

Description Symbol
Mean anomaly M0
Mean motion difference from computed value ∆n
Eccentricity e
√
Square root of the semi-major axis A
RAAN at weekly epoch Ω0
Inclination angle at reference time i0
Argument of perigee ω
Rate of right ascension Ω̇
Rate of inclination angle IDOT
Harmonic corrections Cuc , Cus , Crc , Crs , Cic , Cis
Reference time ephemeris toe
Issue of data (Ephemeris) IODE

1
An ephemeris is simply the name of a container of the positions of space objects. Just like a
book may be the container of a story, an ephemeris is the container of positions of objects in space.
 9

2.4 Global Positioning System

GPS is formed by a constellation of Satellite Vehicles (SV, plural SVs) that use
the GPS standard to broadcast coded signals to the ground. These signals contain
information of each SVs’ whereabouts, along with their orbital parameters, satellite
health, amongst other useful information. Receivers on the ground then decode the
signals, giving them the following relevant information: the position of SVs, and
the distance between the receiver and the SVs (also called the pseudorange). This
method of positioning - having reference positions, and the pseudoranges - is called
trilateration. By using this method, GPS receivers deliver an estimated position to
the user (or application) along with other relevant information, such as the number
of satellites used in the trilateration.

The nominal orbital altitude of GPS SVs is 26 559.7 km [9] from the Earth’s
center of mass. This means that signals have to travel over 20 000 km to reach the
receivers on the surface of Earth or on-board of drones. The main source of signal
degradation in the transmission path is the atmosphere, mainly the ionosphere. The
ionosphere extends from around 50 to 1000 km above the Earth’s surface [10] and
causes delays on the signals that vary significantly. However, thanks to advanced
monitoring of the ionosphere, it’s possible to somewhat correct for the aforemen-
tioned delays.

An interesting effect of the ionosphere is that signals of different frequencies are

delayed by different amounts. By having a receiver that supports multiple GPS sig-
nals of different frequencies, the ionospheric delays can be more precisely estimated
and corrected for than in single-frequency receivers. For single-frequency receivers,
there is a part in the signal’s message that contains information about the iono-
sphere. By using this information, the corrections for the single frequency receiver
can correct up to 75% of the ranging2 error [10].

Corrections, however, cannot do anything for physical obstacles that block the
signal such as buildings, trees, or terrain. This is why for simulations or theoretical
models, the Field Of View (FOV) of the receiver is modelled in a way that it excludes
a certain angle - often called a mask angle - from the horizon upwards, such that
the visible area of the sky is reduced. Many authors use between +10º and +20º to
model blockage by obstacles, however, the GPS standard suggests a mask angle of at
least +5º from the horizon [8]. This is because at lower mask angles, signals travel a
much longer path through the ionosphere than at higher angles, hence, the predicted
2
Ranging is the calculation of the distance between the receiver and an SV.
 10

range can have a large error that would not aid in the trilateration calculation.

2.4.1 GPS Navigation message

The way GPS SVs provide information to the receivers about their position in space
is done through what is called a Navigation (NAV) message. The information con-
tained within this message can be legacy NAV (LNAV) data and/or civil NAV
(CNAV) data depending on the SV version. The NAV message contains all the
necessary information for estimating the position of SV in space. For example, it
contains Keplerian-like elements that describe the orbit of the SV along with time
related parameters, as well as information about the SVs health, among other things.
The Keplerian-like elements previously mentioned are stored into an ephemeris that
is broadcast by the SV every 30 seconds (the duration of a NAV frame).

A complete message is made up of 25 frames of 1500 bits each. Each frame is

composed of 5 subframes, which themselves have 10 words of 30 bits each. This
structure can be illustrated in Figure 2.4.



 ...  ... 

  


 ...  ...  

 


 ...  ...   

  


 ...  

Figure 2.4 GPS NAV message structure.

Every subframe will first transmit a telemetry (TLM) word, then a handover
word (HOW), followed by 8 data words. The type of data contained in subframes
1, 2, and 3 relates to data about the individual SV which transmits them and is
in the same format through all 25 frames of the message, while subframes 4 and 5
contain data relevant to the whole GPS constellation and other SV positions, which
is distributed along all 25 frames of the full message. [8]
 11

2.4.2 Receiver Independent Exchange format, RINEX

A compact and helpful way to store the data related to GNSS is using the RINEX
format. Having a standard like RINEX standard allows the positioning data to be
much more widely compatible with software than would otherwise be. This means
that file readers can be faster and more efficient while maintaining compatibility
with many different sources of data. There are several different types of data the
RINEX format supports, however, for the focus of this thesis, only the RINEX NAV
format will be explained.

RINEX NAV files consist of two major parts: the header and the data record.
The former containing information related to the production of the file, ionospheric
conditions, and other relevant data in the form of comments; while the latter, con-
tains the ephemeris in a format specified for each GNSS (such as GPS, Galileo,
GLONASS, or others). The data records supports different GNSS systems depend-
ing on the RINEX format version.

An example of a RINEX 2.11 data record can be seen in Figure 2.5. The format
definition of this example can be seen in Appendix A [11].

Figure 2.5 Example RINEX v2.11 data record.

 12

3 Methods
This section describes the methodology adopted in building the simulator: first,
the calculation of the satellite positions based on drone data is explained; next, the
concept of Field of View (FOV) operation is presented, and finally, the concept of
the Geometric Dilution of Precision (GDOP) is described.

3.1 Calculation of satellite position

By following the ISP-GPS-200L [8] specification its possible to calculate the position
of an SV given a NAV message ephemeris. Because the parameters in the ephemeris
are determined from a curve fit, the resulting calculated position will be an ap-
proximation of the actual position of the SV, hence, it will have a certain degree of
error. This error and several others are accounted for in an index called the User
Range Accuracy (URA)1 index. The real URA varies during the curve fit interval,
and so, the URA index corresponds to the maximum URA expected over the whole
ephemeris curve fit interval.
Since several errors are accounted for in the URA, the position of an SV - as
indicated by itself — can be considered to be a reliable point of reference. To
compute the position of an SV, the GPS standard documentations provides the
required algorithm (See Appendix B). The general idea behind the algorithm is the
following:

• Compute the shape of the elliptical orbit

• Determine rough position of SV in its orbit

• Correct the rough position of SV in its orbit

• Determine precise position of SV in its orbit

• Map position from orbital frame to ECEF

1
URA is a statistical indicator of the GPS ranging accuracy for a specific signal of an SV. It is
a conservative root mean square estimate of the User Range Error (URE)
 13

3.2 Calculation of receiver FOV

As briefly mentioned in section 2.4, the field of view (FOV) of an observer can be
theoretically modeled to gain insight of what an ideal or disturbance-free scenario
could look like. One way in which the FOV can be modeled is by calculating the
angle α (see Figure 3.1) between the observer’s position and an SV’s position — in
the frame of reference of Earth — and finding the value for this angle, in which the
SV is no longer in view. To determine the aforementioned angle, it can be helpful
to imagine a vector that starts at the observer, goes through the atmosphere at the
angle of the mask angle ma , and reaches a point in the orbit of an SV where passing
it lets it into view, and being behind it leaves it out of view. This point will be called
the threshold point thp , and the vector between the observer and the threshold point
will be called the mask vector mv . The threshold point will be different for every
SV’s orbit, however, the angle between the observer and every threshold point is
constant if the horizon is considered to be a plane, tangent to the ellipsoid at the
observer’s position, and SVs are considered visible from the mask angle upwards in
the observer’s frame of reference.

Figure 3.1 Triangle formed between the observer, SV, and threshold point.

The angle between the observer and the threshold point can be represented
as a dot product between the position vectors of the observer and the threshold
point. The dot product operation is computationally efficient and when working
with medium to large amounts of data. Efficiency is a key aspect, hence, it is used
as the main calculation in this algorithm.
 14

To compute the position of the threshold point, it helps to imagine the calcu-
lations in a plane (All positions and vectors used in the calculations correspond to
the 3-dimensional ECEF coordinate system explained in Section 2.2). The plane
is created between the user (observer) position vector u and the z-axis. In this
plane, a triangle (see Figure 3.1) is formed between the position of the user u,
the threshold point thp , and the center of mass of Earth (i.e. the origin O). The
following information is known: the magnitude of u (||u||), the distance between O
and thp as gpsh , and the angle between the mask vector mv and u, which is equal
to da = ma + 90.Before being able to calculate α, the angle (β) at thp needs to be
calculated as seen in Equation 3.1, by using The Law of Sines. With 2 out of the 3
angles known, α can be computed by the following simple equation: α = 180−β−da .

||u|| sin da
β = arcsin (3.1)
gpsh
With the threshold point known, the angle between each SV and the observer
will be compared to α to determine if said SV will be within the FOV of the receiver.
To make computations faster, the cosine of α is saved as a variable. This variable is
then compared to the dot product between the normalized positions of the observer
and each SV. The reasoning for using the cosine of α and not the value itself is due
to the formula of the dot product (see Equation 3.2)

u · thp
cos α = (3.2)
||u|| ||thp ||
One limitation of this method, is that the horizon is not the real visible horizon,
but rather an estimation of what it would be if the receiver was on the surface of the
ellipsoid. This means that, if a receiver is e.g. a drone, once the drone surpasses a
certain altitude, the model does not consider the FOV to reach the actual horizon,
(which would now be lower than the horizontal plane of the observer) and hence,
more SVs are considered to be out of view, compared to those which are in theory
detectable by the receiver.

3.3 Calculation of GDOP

Because of the way GPS works, the ranging errors from receiver to SVs occur from
all directions. The most common way to summarize this quality of the directional
ranging errors is by calculating the so-called Dilution Of Precision (DOP) of the
Geometry generated between the receiver and the SVs. This value is called GDOP.
A ”bad” geometry would yield high GDOP values and would come from a clustered
distribution of satellites in the sky. A ”good” geometry will yield low GDOP values
and this happens when the receiver is ”surrounded” by satellites [12].
 15

In the process of calculating the GDOP value, other DOP categories can also be
considered. These are: the Vertical, Horizontal, and Time DOPs (VDOP, HDOP,
and TDOP respectively [10]). All these DOP values represent a value for the preci-
sion of their respective calculations. The lower this value is, the higher the accuracy.

The geometrical interpretation of GDOP is that a polytope is formed by taking

the SVs and the receiver to be its vertices, and the larger the volume of the shape,
the better positioning accuracy, and hence lower GDOP value [10]. To calculate the
GDOP of a position at a certain time, the following equations are used [13]:

ai − a
dai = √ , a = x, y, or z (3.3)
(x − xi ) + (y − yi )2 + (z − zi )2
2

 
dx1 dy1 dz1 1
 
 dx2 dy2 dz2 1
J=   .. .. .. 
 (3.4)
 . . . 1
dxn dyn dzn 1
 
σx2 σxy σxz σxt
σ σyt 
−1  xy σy2 σyz 
Q = [ J T J] =  (3.5)
σxz σyz σz2 σzt 
σxt σyt σzt σt2
√
GDOP ≜ trace(Q) (3.6)

and
GDOP 2 = HDOP 2 + V DOP 2 + T DOP 2 (3.7)

where xi , yi , zi represents the ith satellite position and x, y, z describe the re-
ceiver’s position. Eq. 3.3 represent the direction component of an axis, while eq.
3.4 combines the direction components in each axis, such that each row represent
the direction vector of the SV position in what can be called the design matrix [14].
From the covariance matrix Q in eq. 3.5, the DOP values are visible in the diagonal.
As shown in eq. 3.8, The square GDOP can also be seen as the sum of squares of
the respective segments:
√ √ √
HDOP ≜ σx2 + σy2 , V DOP ≜ σy2 , and T DOP ≜ σt2 .
 16

The previous calculation for GDOP holds true for a single GNSS constellation,
where time biases and reference frames are consistent for all satellites. To calculate
the GDOP for multiple constellations [15], the time differences between these con-
stellations has to be taken into account. The way this is done is by calculating the
weighted GDOP (WGDOP) where the time differences of the different constellations
are represented by a weight matrix W . The weight matrix W is a diagonal matrix
that can be expressed as
WN = diag(σ1 2 . . . σN 2 ) (3.8)

where σi 2 , i ∈ [1, N ] is a value that considers the many different errors in measure-
ments for each satellite [16]. To generate the covariance matrix Q, the design matrix
needs to be defined in the following way

Q = (HN T WN HN )−1 (3.9)

where  
HA 1 A 0 A 0 A ...
 
 HB 0 B 1 B 0 B . . .
HN = 
 HC 0 C 0 C 1 C
 ∈ RN ×(M +3) (3.10)
 . . .

.. .. .. .. ...
. . . .
such that the subcripts γ = A, B, C, . . . represent different constellations, and the
symbols 1γ and 0γ are the appropriately sized one and zero vectors respectively.
The size of Hγ corresponds to the amount of visible satellites Nγ in its constellation,
where N = NA +NB +NC +. . . is the total number of visible satellites. The direction
vector hi of each SV must now be positioned correctly in the design matrix so that
the satellites are grouped by constellation in the following manner,
     
h1 hNA +1 hNA +NB +1
h  h  h 
 2  N +2   N +N +2 
HA =   , HB =  A  , HC =  A B  , . . . (3.11)
 ...   ...   ... 
h NA hNA +NB hNA +NB +NC

where the direction vector hi ∈ R1×3 corresponds to the direction components of

each axis for a given satellite, similar to the rows in Eq. 3.4, Eq. 3.12 presents the
aforementioned direction vector.
[ ]
hi = dxi dyi dzi , i ∈ [1, N ] (3.12)

Now WGDOP can be defined as

√
W GDOP ≜ trace(Q) (3.13)
 17

4 Program implementation
This section describes the implementation of Gdoper, an open source GPS post-
processing program written in Python. The initial idea for the implementation of
this program came from the need to analyze drone positioning data by estimating
its accuracy. To get an indicator of the accuracy of the data output by the drone,
the GDOP value for each position estimate of the drone can be calculated. The
program’s main objective is to perform this computation and acquire all the relevant
data needed to do so, hence its name, Gdoper; which stands for ”the do-er of GDOP”.

4.1 General overview

The Gdoper program is divided into sub-modules (see Section 4.2) that focus on
particular tasks in the GDOP calculation process. To calculate the GDOP, the po-
sition - and the time it was measured - of the receiver needs to be known. This
information is obtained by the reader_pos_data module from a user-specified file.
The time of measurement will allow the program to acquire the ephemeris data for
the GPS constellation, from where the orbits of the SVs can be extrapolated to the
instant in which the receiver’s position was measured. The previous is handled by
the reader_rinex module. Once the state of the constellation is known, the next
step is to filter out the satellites that were not visible by the receiver at that mo-
ment. This can be done in several different ways which in the program are called
Field Of View (FOV) models.

The most straightforward model is called FOV_view_match. If information about

the number of satellites in view (n) is available from the receiver, it can be used
to select the n satellites which had the best chance of being seen at that moment
by computing the dot product between the receiver’s position and the position of
the satellites, then selecting the n highest absolute values and marking these SVs
as visible. This is likely to be the most accurate model from a practical stand-
point, however, other types of information can be extrapolated by, for example
FOV_constant_mask, which gives an estimate of the largest theoretical number of
visible satellites at ground level, considering the earth to have the shape of the WGS
84 ellipsoid. The explanation of this model was covered in section 3.2.

Once the satellites in view are acquired and the receiver positioning data is
available, the information can be used by Calc sub-classes to process the data. The
main goal of this program was to calculate the GDOP using this information, hence
 18

the name. Other calculations can also be performed on the data by creating a
class to do so. An object of the Calc subclass can then be added to the processing
queue, such that multiple calculations can be performed on the same data set. All
the processed data along with the information used to make the calculations is
then output onto a .csv file in a specified directory with a specified name. By
default, the name of the processed data is the name of the input file, appended
with the _gdoper.csv suffix, and the output directory is the same as the input file’s
directory.

4.2 Gdoper modules

As mentioned in the previous section, Gdoper is implemented in several modules.

The names and functionality of the main modules will be explained in this section.

calc_manager
This is the base module and its function is to merge the functionality of all the
separate modules and provide a functional interface to the underlying processes. It
allows for the processing of a single file and keeps the data of its last processing
operation for potentially further streamlined processing.

reader_pos_data
This reader module has the purpose of reading .csv files and putting them into
python memory in a dict, where the column header names (CHN) are the keys,
and the values are the list of values in the column. This module is used to read the
user-specified file where the positioning data resides but can also be used to read
the results file and make plots.

reader_rinex
This reader takes as an input dates in ISO format and outputs a nested dict con-
taining the positions of every SV in ECEF coordinates at every time instant. The
constellation is obtained from a RINEX file downloaded from a trusted repository
or if available, locally. The RINEX file contains a discrete amount of observations
that need to be extrapolated to the time instant that is required. This module han-
dles the reading and orbit extrapolation as well as possible download and possible
directory creation to store the downloaded files.

fov_models
This module contains the FOV models that have been mentioned in previous sec-
tions. They first need to be setup with certain parameters and then take as a
minimum input the positions of the observer and the constellation at that time, and
outputs the constellation of SVs in view according to the model’s implementation.
 19

calcs
This module holds the calculations that are performed on the data. As of time
of writing, the only available calculation is the several DOPs as mentioned in sec-
tion 3.3. The modular nature of the program, however, allows for any other type of
calculation that requires positioning data and/or constellation data.

4.3 Scope and limitations

The main objective of this program is to provide an easy-to-use interface for calcu-
lations such as the different DOPs which are indicative results that would be very
time consuming to calculate even in a semi-automated manner, meaning that some
manual work would be done. Gdoper is not intended to demonstrate a new technol-
ogy or an innovative implementation of existing frameworks, but rather its intention
is to simplify post-processing of GPS related positioning data by creating an easy
to use interface for the user.

Gdoper is intended to process all types of positioning data logged from a GPS
receiver. This data can come from but is not limited to drones, autonomous vehicles,
mobile devices, and/or remote controlled vehicles.

As of the time of writing, the program is in a working state and meets all the
initial functional requirements (see Table 4.1). In summary, this means that at
the time of writing, the program can read a .csv file containing positioning data
given the names of the columns where latitude, longitude, altitude, amount of visible
satellites, and time of measurement are specified. The program can then use this
data to download the GPS Ephemeris from an online resource (at the time of writ-
ing the main repository is ftp://data-out.unavco.org/pub/rinex/nav). From
the previously acquired data, the satellites that were in view can be estimated, and
finally the GDOP, HDOP, and VDOP can be calculated.

The functionality and implementation of additional features and performance

improvements may continue, as the project is open source (available at https:
//github.com/FelipeTJ/gdoper).
 20

Table 4.1 Functional requirements.

Requirement description Requirement type

The program can calculate GDOP given

receiver position, date and time of measurement initial
and number of visible satellites

Satellite positions at given moment

are downloaded automatically from a initial
trusted online database

The simplest type of calculation requires

only the name of the file that contains initial
the positioning data to be provided

Several file can be processed in a batch

given an input (and optionally an output) initial
directory

Automatically map the column header names

(CHN) of the input data to the default additional
names used through out the program

Calculations (Calcs) can specify

a specific FOV model to use for their additional
calculation
 21

5 Example results
To demonstrate the potential usage of this program, positioning data obtained from
drone surveys was processed by Gdoper and analyzed. This section will show exam-
ples of the data that is output by the program and plots generated from that data.
Finally an analysis of the whole set of flights will be done as processed by Gdoper.

5.1 Analysis of individual flights

To demonstrate how GDOP changes in different scenarios — at different altitudes

and in different surroundings —, three flights with different characteristics were
analyzed (see figures 5.1, 5.2, and 5.3). The path traversed by the flight 1 seems
to be a vertical survey while the other flights seem to be of horizontal nature. The
main difference between the horizontal surveys, is that flight number 2 performed
a survey in a relatively open field, while flight number 3 performed a survey in a
parking lot surrounded by trees.

Drone path

190 Altitude above sea (m)

180
170
160
150
+0
+0.00.010214
+0
8 +0.00.000810
61.4409.0002 4 +0
+0.00.000406
+ 0.000 6
+ 0.000 8 +0.0002 e (°)
Latit + +0.0+000.0010 12 23.8602 ud
git
ude
(°) +0.00 Lon

Figure 5.1 Path trajectory of flight 1.

 22

Drone path

Altitude above sea (m)

170
165
160
155
150
145
+0.00
+0.0020 25
4 +0.001
61.4480.0002 +0.0010 5
+ 0.0004
+ 0.0006 +0.0005
e (°)
23.8545 d
Latit + +0.00008.0010 git
u
ude
(°) +
Lon

Figure 5.2 Path trajectory of flight 2.

Drone path
Altitude above sea (m)

170
165
160
155
150
145
140
135
+0
+0.00.030035
+0.0
2
61.450 .0002 +0.0020025
+0.0
+0 4
+0.000 .0006 +0.0010015 (°)
0 +0.0005 d e
Latit + +0.0008 0010 23.8620 itu
ude +0. ng
Lo
(
°)

Figure 5.3 Path trajectory of flight 3.

From the aforementioned three example flights, the number of SVs in view, along
with the DOPs calculated at each instant, were plotted in the following figures ( 5.4,
5.5, and 5.6).
 23

20

Number of visible satellites 15

10

5 GPS
Galileo
GPS + Galileo
0
0 100 200 300 400 500 600
time (s)
8
GDOP GPS
7 GDOP Galileo
WGDOP GPS + Galileo
6
5
DOP value

4
3
2
1

0 100 200 300 400 500 600

time (s)

Figure 5.4 Computed GDOP values for GPS+Galileo constellations for flight 1.

A trend can be seen that the DOP values are strongly related to the amount of
visible satellites, as for every dip and peak in visible SVs, there is a peak and dip
respectively for all DOP values. The difference of surroundings from flights 2 and
3 can be seen from the number of visible SVs, meaning flight 2 was performed in
relatively open surroundings and therefore had more SVs in view, while the opposite
was true for flight 3 (see Figure 5.5 and Figure 5.6).
 20 20
Number of visible satellites

Number of visible satellites

15 15

10 10

5 GPS 5 GPS
Galileo Galileo
GPS + Galileo GPS + Galileo
0 0
0 50 100 150 200 250 300 350 0 50 100 150 200 250 300
time (s) time (s)
8 8
GDOP GPS GDOP GPS
7 GDOP Galileo 7 GDOP Galileo
WGDOP GPS + Galileo WGDOP GPS + Galileo
6 6
5 5
DOP value

DOP value
4 4
3 3

24
2 2
1 1

0 50 100 150 200 250 300 350 0 50 100 150 200 250 300
time (s) time (s)

Figure 5.5 Computed GDOP values for GPS+Galileo constellations Figure 5.6 Computed GDOP values for GPS+Galileo constellations
for flight 2. for flight 3.
 25

The FOV model used for the previous plots was FOV_view_match, which simu-
lates the GDOP as it would have been during the flight given the amount if visible
satellites as recorded by the drone. To analyze the data in a theoretical manner, the
following FOV models will be presented in Figure 5.7: FOV_constant_mask and
FOV_treeline. The former simulates a mask angle relative to the horizon at the
observers latitude and longitude, and the latter, simulates the ”horizon” relative to
a theoretical treeline that would block the observer’s view.

FOV_treeline fixes the shortcomings of FOV_constant_mask by simulating the

real visible horizon more faithfully in the case when the observer is for example, a
drone that reaches altitudes above the treeline such that its FOV increases dras-
tically past a certain point. Both maximum mask angles were set to 20º, with
FOV_treeline decreasing the mask angle to 5º once the treeline is surpassed. Fig-
ure 5.7 presents the amount of visible satellites (according to the aforementioned
FOV models) of a drone following the path trajectory of flight 1.

30.0
27.5
Number of visible satellites

25.0
22.5
20.0
17.5
15.0 FOV view match
12.5 FOV const. mask
FOV treeline
10.0
0 100 200 300 400 500 600
time (s)
3.0
WGDOP from view match FOV
2.5 WGDOP from const. mask FOV
WGDOP from treeline FOV
2.0
DOP value

1.5

1.0

0.5

0 100 200 300 400 500 600

time (s)

Figure 5.7 Computed WGDOP values for GPS+Galileo constellations for flight 1 with
different FOV models.
 26

5.2 Analysis of a set of flights

A set of 100 flights was processed and analyzed, totaling over 8 hours of data.
The set of flights were all obtained from the same drone only varying the time of
flight and flight path. Since the flights in the set were all of surveying type, the
speeds at which they were flown were moderate, averaging 1.8 m/s, with a median
of 0.94 m/s over 278 955 samples, and using a sampling interval of 100 ± 10 ms. The
speed distribution density of the set can be seen in Figure 5.8 with a logarithmic
scale along the y axis, representing the density.

100

10 1
Sample density

10 2

10 3

10 4

0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 20.0

Speed m/s

Figure 5.8 Speed distribution density of the drone for all 100 flights in the set.
 27

For every instant in the set, the DOP values of the drone were compared to the
number of visible SVs and saved into a bucket. Each bucket represents the number
of visible SVs. The mean and sample variance of each bucket was computed and
plotted in Figure 5.9

DOPs vs Number of visible satellites

1.6 GDOP
VDOP
HDOP
1.4

1.2
Mean DOP values

1.0

0.8

0.6

0.4

0.2
10 11 12 13 14 15 16 17 18 19 20 21 22 23
Satellites in view

Figure 5.9 DOPs as a function of number of visible SVs.

As can be seen in Figure 5.9, between 10 and 14 visible SVs the DOP values
have a significantly high variance, indicating that the positioning of the SVs in the
sky affects the GDOP considerably. From 15 visible SVs and upwards (with the
exception of 17 visible SVs), the variance is quite stable and the DOP values have
a decreasing trend as more SVs become visible. At 17 visible SVs there is a peak,
indicating a potentially interesting geometric occurrence or more probably an effect
that is particular to the geographical location of the measurements.
 28

6 Conclusions
Gdoper is a powerful tool with a simple interface that can be used to process GPS
related positioning data, as well as model the predicted amount of satellites in view
at a given position in a given moment. As demonstrated in the Example results sec-
tion 5, the data output from Gdoper can be used for a variety of different analyses
both for individual trajectory analysis and for analysis of a set of trajectories.

Gdoper meets the initial functional requirements, meaning that it can calculate
the GDOP of a GPS receiver for every instant of a trajectory given the following pa-
rameters: Time of measurement in ISO format, the latitude, longitude and altitude
of receiver, along with the amount of visible GPS satellites at the time of measure-
ment. The latter can be excluded if the user of the program wishes to model the
field of view (FOV) of the receiver and opt for a theoretical estimate of the satellites
in view, along with the DOP values they would generate.

Gdoper is also an open source project (available at: https://github.com/

FelipeTJ/gdoper) that will continue to grow thanks to its modular implemen-
tation, meaning it can be expanded upon in a scalable way. As more features are
added and more use cases are discovered, the standalone program can some day
become a python library for the entire open source community to enjoy.
 29

References
[1] Kamil Maciuk. “The applications of GNSS systems in logistics”. In: Budown-
ictwo i Architektura 17.3 (Dec. 2018), pp. 181–188. doi: 10 . 24358 / Bud -
Arch_18_173_13. url: https://ph.pollub.pl/index.php/bia/article/
view/378.
[2] Wolfgang Torge. Geodesy. eng. 2. ed. Reprint 2015. Berlin ; De Gruyter, 2015.
isbn: 3-11-154268-8.
[3] Arthur L Allan. Principles of geospatial surveying. eng. Whittles, 2017. isbn:
9781904445210.
[4] World Geodetic System 1984. https://www.unoosa.org/pdf/icg/2012/
template/WGS_84.pdf. 2012.
[5] Ahmed. El-Rabbany. Introduction to GPS The Global Positioning System.
eng. Norwood: Artech House, 2006. isbn: 1-58053-547-X.
[6] Michel. Capderou. Handbook of Satellite Orbits From Kepler to GPS. eng. 1st
ed. 2014. Cham: Springer International Publishing, 2014. isbn: 3-319-03416-2.
[7] Guochang Xu. GPS: Theory, Algorithms and Applications. ger ; eng. 2. Aufl.
Berlin, Heidelberg: Springer-Verlag, 2007. isbn: 9783540727149.
[8] Anthony Flores. NAVSTAR GPS Space Segment/Navigation User Segment
Interfaces. https : / / www . gps . gov / technical / icwg / IS - GPS - 200L . pdf.
2020.
[9] Global Positioning System Precise Positioning Service Performance Standard.
https://www.gps.gov/technical/ps/2007-PPS-performance-standard.
pdf. 2007.
[10] Jan Van Sickle. GPS for Land Surveyors. eng. Boca Raton: Taylor & Francis
Group, 2015. isbn: 9781466583108.
[11] Werner Gurtner. RINEX: The Receiver Independent Exchange Format Version
2.11. https://files.igs.org/pub/data/format/rinex211.txt. 2007.
[12] I Sharp, Kegen Yu, and Y.J Guo. “GDOP Analysis for Positioning System De-
sign”. eng. In: IEEE transactions on vehicular technology 58.7 (2009), pp. 3371–
3382. issn: 0018-9545.
[13] Shuqiang Xue and Yuanxi Yang. “Understanding GDOP minimization in
GNSS positioning: Infinite solutions, finite solutions and no solution”. eng.
In: Advances in space research 59.3 (2017), pp. 775–785. issn: 0273-1177.
[14] Alfred Leick, Lev Rapoport, and Dmitry Tatarnikov. GPS satellite surveying.
John Wiley & Sons, 2015.
 30

[15] Yunlong Teng, Jinling Wang, Qi Huang, et al. “New characteristics of weighted
GDOP in multi-GNSS positioning”. eng. In: GPS solutions 22.3 (2018), pp. 1–
9. issn: 1080-5370.
[16] Nuria Blanco-Delgado and Fernando D Nunes. “Satellite selection method for
multi-constellation GNSS using convex geometry”. In: IEEE Transactions on
Vehicular Technology 59.9 (2010), pp. 4289–4297.
 31

APPENDIX A.
RINEX format for GPS data record
 32

APPENDIX B.
Algorithms for determining GPS SV position
1 // WGS 84 value of the earth 's gravitational constant for GPS user
2 u = 3.986005 x 10^14 meters ^3/ sec ^2
3

4 A = (\ sqrt{A})^2 // Semi - major axis

5 n_0 = \sqrt {\ frac{u}{A^3}} // Computed mean motion (rad/s)
6

7 t_k = t - t_oe // Time from Ephemeris reference epoch

8 n = n_0 + \Delta n // Corrected mean motion
9 M_k = M_0 + n*t_k // Mean anomaly
10

11 // Solve eccentricity anomaly (E_k) by iterating

12 // Kepler 's equation at least 3 times
13 E_0 = M_k
14 E_j = E_{j -1} +
15 \frac{M_k - E_{j -1} + e*\ sin{ E_{j -1} }}
16 {1 - e*\ cos{ E_{j -1} }}
17

18 E_k = E_j // Final eccentricity anomaly

19

20 // Computed True anomaly

21 v_k = 2*\ arctan { \sqrt {\ frac {1+e}{1-e}} \tan {\ frac{E_k }{2}} }
22

23 \ Phi_k = v_k + \omega // Argument of Latitude

24

25 // Argument of Latitude Correction

26 // Radius Correction
27 // Inclination Correction
28 \ sigma u_k = C_{us}\ sin {2*\ Phi_k} + C_{uc}\ cos {2*\ Phi_k}
29 \ sigma r_k = C_{rs}\ sin {2*\ Phi_k} + C_{rc}\ cos {2*\ Phi_k}
30 \ sigma i_k = C_{is}\ sin {2*\ Phi_k} + C_{ic}\ cos {2*\ Phi_k}
31

32 u_k = \Phi_k + \sigma u_k // Corrected Argument of Latitude

33 r_k = A(1- e*\ cos{E_k }) + \sigma r_k // Corrected Radius
34 i_k = i_0 + \sigma i_k + (IDOT )* t_k // Corrected Inclination
35

36 // Positions in orbital plane

37 {x_k}' = r_k * \cos{u_k}
38 {y_k}' = r_k * \sin{u_k}
39

40 // Corected longitude of ascending node

41 \ Omega = \ Omega_0 +
42 (\ Dot\Omega + \Dot\ Omega_e )* t_k -
43 \Dot\ Omega_e * t_{oe}
 33

44

45 // ECEF coordinates of GPS SV position

46 x_k = {x_k}' \cos {\ Omega_k } - {y_k}' \cos{i_k} \sin {\ Omega_k }
47 y_k = {x_k}' \sin {\ Omega_k } + {y_k}' \cos{i_k} \cos {\ Omega_k }
48 z_k = {y_k}' \sin{i_k}

Program 1 Algorithm for determining SV position