Implementation of a Complete GPS Receiver Using Simulink
description
Transcript of Implementation of a Complete GPS Receiver Using Simulink
FOURTH QUARTER 2009 1531-636X/09/$26.00©2009 IEEE IEEE CIRCUITS AND SYSTEMS MAGAZINE 43
Feature
Digital Object Identifier 10.1109/MCAS.2009.934706
Implementation of a Complete GPS Receiver Using Simulink
Gihan Hamza, Abdelhaliem Zekry, and Ibrahim Motawie
AbstractDuring the past few years a lot of efforts have been exerted to make the inner working of the GPS receiver visible, clear and easy to learn and modify either on the level of software or hardware. This article adds a step on the route toward the implementation of a more visible, clearer, and easier to learn and modify a single frequency GPS receiver using the C/A code on the L1 carrier. Simulink was used in the implementation of such receiver, thereby introducing a new look for the SDR technology that can be ac-complished via a graphical user inter-face environment.
I. Introduction
During the past decade a lot of efforts have been exerted not only
to open the inner working of the GPS receiver but also to facilitate
the education of the design and implementation of such system.
The Software-Defined Radio technique was used as a tool in the imple-
mentation. From the efforts that were exerted in this field are:
The open source GPS project that was initiated in 1995 and leaded by ■
Clifford Killy and Douglas Baker (with collaboration with others) [1].
This project had an educational aims to help any GPS enthusiast to
learn deeply the internal working of the GPS receiver. They developed
both a commercial hardware and software that constitute a complete
GPS receiver. The hardware was introduced by developing two chip-
sets called GP1010 and GP1020. The GP1010 was used as a front-end
and performs the acquisition phase; while The GP1020 was the track-
ing and navigation data extraction chip that has 6 correlators chan-
nels [2][3]. The software of this project was a C program written in
Borland C. This program contained a library of the GPS functions such
as the satellite location by using the almanac, the ephemeris, comput-
ing the navigation solution and decoding the navigation message.
Dick Benson, a consulting application engineer at Mathworks: de- ■
veloped an incomplete single channel GPS receiver using Simulink.
He implemented acquisition, partial tracking, and no pseudorange
in SIMULINK [4].
The efforts of Kai Bore and Dennis Akos (with collaboration with ■
others) fruited a book titled “A Software-Defi ned GPS and GALILEO
© COMSTOCK
Feature
44 IEEE CIRCUITS AND SYSTEMS MAGAZINE FOURTH QUARTER 2009
Receiver A Single-Frequency Approach” [5]. They
introduced the implementation of a complete
8-channels single frequency GPS receiver using
the C/A code on the L1 carrier using Matlab as the
coding language. This book is accompanied with
39 m-fi les that represent the receiver algorithm
and a record for a real GPS signal collected from
a specially designed ASIC-based front-end.
In general, the algorithm of a complete GPS receiver
is considered complicated and long, because it contains
different stages that deals with the processing of RF, IF,
and baseband signals. Previously, to write either a part
or a complete GPS algorithm you must be professional
in C/C11 programming, assembly, or Matlab. These are
the programming languages that researchers used in
the simulation of the GPS receivers. To write a complete
algorithm for a GPS receiver; a teamwork is needed. Ev-
ery person writes the algorithm of a certain part and
delivers the output to the next person to write the next
part of the algorithm. Using a GUI environment instead
of the hand written programming languages was a far
idea due to the algorithm’s complexity and length.
In This article the 39 m-files that are accompanied
with the book titled “A Software-Defined GPS and GALI-
LEO Receiver: A Single-Frequency Approach” are con-
verted to only 5 Simulink models, after modifying the
algorithm of some parts to conform with the GUI envi-
ronment and make the simulation time faster.
This article adds a step on the route toward a clear,
easy, and transparent simulation of GPS receivers imple-
mented with the SDR technology. The implementation of
a complete 8-channel GPS receiver is accomplished via a
graphical environment, which is Simulink. In general, the
graphical environment makes the relation between the sys-
tem modeling, simulation, and implementation clearer and
easier to debug, because we can put test points anywhere
and obtain immediate results. Also, using a graphical pro-
gramming language eliminates the need to a team work
and enables only one person to finish the simulation of the
complete system in a relatively short time. In general, the
success of using a graphical programming language such
as SIMULINK in simulating a complicated system such as
the GPS receiver will open the route for other complicated
systems to be simulated by the same way. This will facili-
tate the education, the modification and the debugging of
many of the complicated electronic systems.
II. Building The Different Stages Of GPS Receiver
A. The Front-End
The Simulink models of acquisition, tracking, pseudo-
range, and position solution are tested and developed
by a real GPS signal that was collected from the SE4110
ASIC-based front end. Its functional block diagram is
shown in reference [6]. The same signal is used in test-
ing and developing the Matlab algorithms. The main
parameters of these data are:-
Sampling frequency: 38.192 MHz.
IF: 9.548 MHz.
Four-bit samples.
B. Representing the Data Collected from the
Front- End in the Different Domains
The digital samples that were collected from the front-
end can be represented in the dif-
ferent domains using the different
types of scopes available in Simu-
link. Fig. 1 shows the Simulink
model for data representation. In
this figure the first branch gives
the time domain representation
of 1,000 samples that is shown
in Fig. 2. The signal is a noise
like and this is the nature of the
CDMA signal. The second branch
gives a histogram of 1,048,576
samples that is shown in Fig. 3. It
is clear that the 4-bit samples are
translated to 16 levels. The third
branch gives the frequency do-
main representation of 1,048,576 Figure 1. Simulink model to represent the collected data in the different domains.
Read Binary File
Submatrix
Data Type
Conversion
Double
HistogramUser
FFT
User
Vector
Scope 1
Spectrum
Scope
Vector
Scope
Time Domain
Representation
of 1,000 Samples
Frequency Domain
Representation
of 1,048,576 Samples
Histogram
of 1,048,576 Samples
Read Binary File
Submatrix
Data Type
Conversion
Double
HistogramUser
FFT
User
Vector
Scope 1
Vector
Scope
vipmen.bin
Gihan Hamza is a research assistant in the National Institute of Standards, Guiza, Egypt (Tel: +202-26356263; E-mail: [email protected]).
Abdelhaliem Zekry is a professor in the Faculty of Engineering, Ain Shams University, Cairo, Egypt (Tel: +202-24840051; E-mail: [email protected].
eg). Ibrahim Motawie is a professor in the National Institute of Standards, Guiza, Egypt (Tel: +202-35715755; E-mail: [email protected]).
FOURTH QUARTER 2009 IEEE CIRCUITS AND SYSTEMS MAGAZINE 45
samples that is shown in Fig. 4. It is clear that the sym-
metry is around the IF frequency.
C. GPS Receiver Architecture
The operation of a single channel GPS receiver is based
on the structure shown in Fig. 5. In acquisition we deter-
mine one of the visible satellites and determine both the
carrier frequency and code phase roughly. In tracking
we track any changes to these values to ensure correct
data decoding. After that both the pseudorange and po-
sition are calculated. Each block in Fig. 5 is translated
into a Simulink model, as shown in Fig. 6. In Fig. 6 there
are two additional models; one provides the demodu-
lation carrier and the other provides the dispreading
code. Both the demodulation and dispreading models
must be simulated first to feed lookup tables existed in
the acquisition model. These tables contain all the pos-
sibilities of the demodulating carrier and dispreading
codes according to a specified sampling frequency that
is a modifiable value reserved in the Workspace.
Figure 2. Time domain representation of 1,000 samples.
6
4
2
0
–2
–4
–6
–80 0.5 1 1.5 2 2.5
× 105Time
Am
plit
ude
Figure 3. Histogram of 1,048,576 samples receiver.
16
14
12
10
8
6
4
2
0 2 4 6Bins
Num
ber
Within
Bin
8 10 12 14 16
× 104
Figure 4. Frequency domain representation of 1,048,576 samples.
40
20
0
–20
–40
PS
D M
agnitude (
dB
)
–60
0 2 4 6 8Frequency (MHz)Frame
10 12 14 16 18
Figure 5. Structure of a single channel GPS receiver.
Acquisition
Tracking
Pseudorange
and Position Calculation
Incoming Signal
X, Y, Z dt
Figure 6. SIMULINK implementation of a single channel GPS receiver.
Demodulation
Carrier.mdl
Acquisition.mdl
Incoming Signal
Dispreading Code.mdl
Tracking.mdl
Pseudorangeand
Position Calculation.mdl
X, Y, Z dt
46 IEEE CIRCUITS AND SYSTEMS MAGAZINE FOURTH QUARTER 2009
D. Acquisition
Acquisition is a two dimensional search process that
results in identifying the code phase with an uncertain-
ty equals to 6½ – chip and the IF with an uncertainty
equals to 6½ the Doppler search bin size. Acquisition
can be implemented by either of 3-standard methods,
which are: the serial search acquisition, the parallel fre-
quency space search acquisition, and the parallel code
phase space search acquisition. It is customary to use
the first two methods in the traditional implementation
of the acquisition phase, which is implemented on an
ASIC. Implementing acquisition according to the SDR
technology is accomplished according to the third
method [7]. Acquisition was implemented with the par-
allel code phase search technique shown in Fig. 7 [5].
In this technique we search through all the possible fre-
quency bins and parallelize the code phase search such
that the total number of searches per satellite equals
the number of frequency bins. The number of frequen-
cy bins in our case was 29 frequency bins for 14 KHz
search band stepped by a 0.5 KHz frequency interval.
In the Simulink model of acquisition the 29 frequency
bins are searched at the same time where the incoming
signal is multiplied by a look up table containing all the
possible IF frequencies. This means that the total num-
ber of searches for the 32 satellites is 32. Fig. 8 shows
the actual implementation of this
block diagram in Simulink where
it is shown the position of both
the demodulation and dispread-
ing models that were mentioned
before in Fig. 6.
The simulation time of the
acquisition phase that was simu-
lated as m-files was about 183
second; while the time for it when
simulated as a Simulink model
was about 200 seconds. The in-
crease in simulation time comes
from that Simulink is optimized to make FFT and IFFT
not a DFT and IDFT, while Matlab able to do both. So, the
DFT and IDFT were built as a Level-2 M-file S-Function
blocks that made them consume larger time than if they
were implemented in Matlab.
The implementation of the Fourier Transform thus af-
fects the simulation time. It is well known that the FFT
and IFFT are faster than the DFT and IDFT but they affect
only sequences that have a radix-2 length. To use the FFT
and IFFT we have to reduce the number of samples per
C/A code from 38192 to the lower radix-2 value, which
is 32768 5 214. This means that we have to resample the
incoming signal by a frequency of 32.768 MHz. SIMULINK
doesn’t have a block that down sample by a fractional
factor. So, we have either of two ways; the first is to use
the “resample” m-function using the Embedded MATLAB
Function in the SIMULINK model to resample by the fac-
tor (32768/38192).
Using a new sampling rate of 32.768 MHz makes the de-
tected code phase be referenced to the new number of
samples per C/A code, which are 32768 samples. To make
the detected code phase to be referenced again to the old
number of samples per C/A code we multiplied the detect-
ed one by an inverse of the factor that was used in sam-
pling down the frequency. This means that each detected
code phase is multiplied by the factor (38192/32768).
The second way is by inter-
polating the input signal by FIR
interpolation filter to increase
the number of samples per 1 ms
(time of a complete C/A code)
from 38192 to 65536 samples [8].
This signal is then punctured
regularly to reach 32768 samples
per C/A code [9]. Resampling by
this way made the detected code
phase referenced to the new num-
ber of samples per C/A code. So,
a mapping block was created to
eliminate the effect of resampling
Figure 7. Parallel code phase search block diagram.
Incoming
Signal×
× ×DFT
90DFT
IDFT |u|2
Local Oscillator PRN Generator
Fine Resolution
Frequency Search Carrier
FrequencyConj
Figure 8. Acquisition.mdl (Implementation of the Parallel code phase search in SIMULINK).
Incoming
Signal×
× ×DFT
90DFT
IDFT |u|2
Demodulation
Carrier.mdl
Dispreading
code.mdl
Fine Resolution
Frequency Search.mdl Carrier
Frequency
Code Phase and
Peak Metric
Conj
FOURTH QUARTER 2009 IEEE CIRCUITS AND SYSTEMS MAGAZINE 47
on the detected code phases. In the mapping block we
apply the reverse process of interpolation and punc-
turing to the detected code phase. In other words, we
obtain code phases that are referenced to the original
number of samples per C/A code, which is 38192, after
the resampling process and consequently we don’t need
to make any changes to the Tracking model.
Both the demodulating carrier and the dispread-
ing code are resampled according to the new sampling
frequency and then FFT and IFFT of a length of 215 are
used instead of the DFT and IDFT. The resolution of the
detected frequencies will not change because both the
sampling frequency and the Fourier transform length
are changed. The resolution of the detected frequency
is calculated according to the following equation:
Df5fs /2N/2
, (1)
where fs is the sampling frequency and N is the Fourier
transform length.
Using FFT instead of DFT made the simulation time
become about 70 seconds. The Fine Resolution Fre-
quency Search block consumes the largest time from
the overall simulation time. So, after building it as an
S-function, the acquisition simulation time became
about 58 seconds, which amounts only to 1/3 of that of
the previous implementation.
Fig. 9 shows the final results obtained from the acqui-
sition model before resampling. The first branch shows
the PRN of the visible satellites. The second branch il-
lustrates that the peakMetric of all the visible satellites
exceeds 2.5, which is a criteria putted to differentiate
between the visible and nonvisible satellite. The third
branch shows the corresponding carrier frequency of
each visible satellite. The fourth branch gives the cor-
responding code phases of the detected ones. Fig. 10
shows the acquisition results after resampling with the
results sorted from the strongest to weakest visible sat-
ellites. These results are stored in the Workspace as in-
puts to the tracking. Comparing the results of Fig. 9 and
Fig. 10, we see that the resampling process has a minor
effect on the acquisition process in spite of reducing the
acquisition time to only its 1/3 of its original value. Fig.
11 and Fig. 12 show the acquisition results for one of the
visible satellites and invisible satellites respectively. It
is clear that the visible satellite has a single dominant
peak while the nonvisible satellite doesn’t have a dis-
tinct peak such that the ratio of the first to second peak
is more than 2.5.
E. Tracking
The main purpose of tracking is to refine the acquisition
results, track any changes that occur to these values,
and demodulate the incoming signal to obtain the 50 Hz
navigation data bits.
Figure 9. Results obtained from the Acquisition.mdl before resampling.
[1]
[1]
[1]
[1]
21 22 15 18 26
Display
Display 1
Display 2
Display 3
6
13.26 12.09 9.4 4.326 4.21614.62
9547399.0249634
13.404 6288 36321 207xxx
9549657.2341919 9549875.7705688 9548200.3250
Detected
PRN
Double [1 × 8]
Double [1 × 8]
Double [1 × 8]
Double [1 × 8]
Peak
Metric
Carr Freq
Code
Phase
Detected
PRN
Peak
Metric
Carr Freq
Code
Phase
Rearranging The Detected
Sats Descendingly
48 IEEE CIRCUITS AND SYSTEMS MAGAZINE FOURTH QUARTER 2009
Tracking consists of a carrier tracking loop imple-
mented as a PLL and a code phase tracking loop imple-
mented as a DLL. The two loops are combined in one
loop to decrease the number of multipliers that con-
sume a lot of time. Fig. 13 shows the combined code and
carrier tracking loops, i.e., a complete tracking channel
[5]. The implementation of these loops in Simulink is
shown in Fig. 14, where it consists of 7 blocks. From left,
the first block is the feedback block of the DLL. The sec-
ond block represent the incoming signal, where we read
a variable data size, determined by the feedback, from
the file that was recorded by the front-end module. The
third block represents the NCO carrier generator and
the PLL feedback. The NCO carrier generator provides
Figure 12. Acquisition plot for a not visible satellite.
12
10
8
6
4
204
32
10 0 5 10
15 2025
30
× 107
× 104
32
100 0 5 10
15 2025
× 107
104
Figure 10. Results obtained from the Acquisition.mdl after resampling.
Detected
PRN
Detected
PRN
Double [8 × 1]
Double [8 × 1]
Double [8 × 1]
Double [8 × 1]
Double [32 × 1]
Double [32 × 1]
Double [32 × 1]
Double [32 × 1]
Peak MetricPeak Metric
Carr Freq
Code Phase
Carr Freq
Detected
PRN
Peak Metric
Carr Freq
Code Phase
Rearranging the Detected
Sats Descendingly
for {...}
Quired Code Phase
or Iterator
26
9
6
3
21
22
15
18
4.421
3.372
3.006
2.938
12.56
12.32
12.15
10.09
26826
4696
28202
34211
13404
6288
36321
20725
9545015.625
9550843.75
9544312.5
9549914.0625
9547429.6875
9549695.3125
9549921.875
9548250
Display
Display 1
Display 2
Display 3
Figure 11. Acquisition plot for a visible satellite.
12
10
8
6
4
204
32
10 0 5
1015 20 25
30
× 107
× 104
FOURTH QUARTER 2009 IEEE CIRCUITS AND SYSTEMS MAGAZINE 49
a refined value for the carrier fre-
quency, the fourth block is the
PRN code generator which pro-
vide the early, late, and prompt
codes. The fifth block is the inte-
grate block at which we integrate
over the number of samples per
C/A code for the early, late, and
prompt codes. This block con-
sists of summing blocks. The
sixth block is the code loop dis-
criminator, which helps in adjust-
ing the code phase. This discrim-
inator was built as a noncoherent
discriminator according to the
following equation:
codeError51 I E
2 1QE2 22 1 I L
21QL2 2
1 I E2 1QE
2 21 1 I L21QL
2 2 , (2)
where IE and IL are the in-phase
outputs of the early and late codes
respectively. QE and QL are the outputs of the quadra-
ture early and late codes respectively.
The seventh and last block is the carrier loop dis-
criminator and loop filter. The carrier loop discrimi-
nator is built as an arctan discriminator. This type of
discriminators is precise but consumes more time.
This discriminator is built according to the follow -
ing equation:
f5 tan21aQ
Ib , (3)
here f is the phase error. I and Q are the in-phase and
quadrature signals of Costas loop.
The comparison between Fig. 13 and Fig. 14 demon-
strates the resemblance between the tracking block di-
agram and its implementation in Simulink. This means
Figure 13. Combined code and carrier tracking loops (complete tracking channel).
Integrate
and Dump
Integrate
and Dump
Data
Incoming
Signal
Integrate
and Dump
Integrate
and Dump
Integrate
and Dump
NCO Carrier
GeneratorCarrier Loop
FilterCarrier Loop
Discriminator
Integrate
and Dump
Code Loop
DiscriminatorPRN CodeGenerator
90°
l
lE
lP
lL
QL
QP
QE
Q
E
E
P
P
L
L
Figure 14. Top view for the Trackink.mdl (the implementation of the tracking loops in Simulink).
fid
Incoming Signal
FeedBackBlockacqFreq
PRN Code
Generator
carrSin
carrCos
carrFreq_N
tcode_P
blkSize
remPhase_N
acqFreq
R
caCode
iBaseband
Signal
qaseband
Signal
uT
uT
carrError
carrFreq
Reset
I_P
Q_P
acqFreq
Code LoopDiscriminator
codeNco
codeFreq
ResetI_EQ_EI_LQ_L
IEQE
ILQLIP
QP
Integrate Resetting
the I/P Is the Dump
IEIPILQEILQL
×
tcode_P
promptCode
lateCode
earlyCode
caCode
PhaseStep
RemPhase
abSample
IncomingSignal
blksize
fid
remPhase
PhaseStep
chNo
Out4
For Iterator
> 37000 Compare To Constant
ForIterator
1 : N 1
4
remPhase
R
U
remPhase_N
PhaseStep
××××××
×fid3
2
Out21
2
3
NCO CarrierGenerator
Carrier
Loop
Discriminator
and Loop
Filter
50 IEEE CIRCUITS AND SYSTEMS MAGAZINE FOURTH QUARTER 2009
easier building, debugging, and modification in SIMU-
LINK environment. Fig. 15 shows a part of the naviga-
tion data extracted from one of the receiver channels.
The simulation time for the tracking algorithm that im-
plemented as m-files (tracking.m) for a single channel was
about 20 minutes while the time for that implemented as a
Figure 17. The block diagram according to which the Pseudorange and position calculation was built in SIMULINK.
Tracking Results Find PreambleSubframe Start
Calculate Pseudorange
Ephemeris
Ephemeris
TOW
Satellite Position
Sat. Position
Sat. Clock
Correction
Pseudorange
Least Square
PositionXYZ, dt
Figure 18. The final results from the Pseudorange_and_position.
Double
Double
Double
pseudoranges
Double [1x8]
Double
Double
Double
[1x8]
[1x8]
[1x8]
[1x4]
[1x8]
[1x4]
[1x8]
[1x4]
[1x4]
[1x4]
pos(1)X
pos(1)Y
pos(1)Z
U Y
U Y
U Y
E
N
U
Display 3
Display 4
Display 5
Display 2
Display 1
21285293.33907
–1288156.1168178 –4720789.6023873 4079720.7646892 519510.63323641
72.558332232667 46.486710475713 57.26070306979 72.483443421818
4429017.6790361
477646.66344317
1403.372632145
22688941.376222
Display
satClkCorr corrected_psuedoranges
navSolutions.channel.correctedP
Coordinate Conversion (cart2geo - findUtmZone - cart2utm)
Succeeded
pos
Figure 15. Part of the navigation data extracted from the Trackink.
–1.51,0009008007006005004003002001000
–1
–0.5
0
0.5
1
1.5x 104
Figure 16. Flow diagram for the pseudorange and position calculation.
Tracking Result
Calculate Pseudorange
Satellite Position and Clock Offset
Least Square Filter (az, el, DOP, xyz dt)
FOURTH QUARTER 2009 IEEE CIRCUITS AND SYSTEMS MAGAZINE 51
SIMULINK model (tracking.mdl)in Simulink was about 37
minutes. The increase in time comes from that the perfor-
mance of the Product blocks in Simulink is not the same as
in Matlab 7.1.
F. Pseudorange and Position Calculation
This phase includes decoding the 50 Hz navigation bits
(message) according to ICD-GPS-200 (1991) to obtain
the pseudorange, the receiver position, and the receiver
clock offset.
A complete navigation message consists of 25 frames/
pages and each frame consists of 5 subframes. Each sub-
frame contains 10 words and each of them has a length
of 30 bits. Subframes 1, 2, and 3 are the same in all the
frames while subframes 4 and 5 are varying from frame
to other. The subframe consumes 6 s as a transmission
time which means that we need 12.5 minutes to receive
a complete navigation message. In our work we decoded
a complete page that has a time of 30 s.
Fig. 16 shows a flow diagram for calculating the pseu-
dorange, the satellite position and clock offset, and the
receiver position. Fig. 17 shows the block diagram ac-
cording to which the SIMULINK model was built. The
first step is to find the subframe start and then begin
decoding the received data bits. By identifying the sub-
frame start we calculate the pseudorange, the ephemer-
is, and the Time Of Week (TOW). After that we calculate
the satellite clock correction and satellite position. The
final step is to calculate the receiver position and the
receiver clock offset. Fig. 18 shows the results obtained
from that model. The first display shows the corrected
pseudorage values for all the visible satellites, the sec-
ond, third, and fourth displays illustrate the coordinate
conversion from the Cartesian to the UTM system.
III. Conclusion
In general, system design becomes easier and clearer if it is
accomplished via a graphical user interface environment.
The simulated model has an educational and commercial
aims. The educational aims come from the transparency
in the design and simulation of any part of the algorithm.
Also, it is very easy to modify, debug, or test any part of
the system. The commercial aims are embedded in the
tools available in Simulink, such as the RTW embedded
coder [10], [11].
Gihan Hamza received her BSc in Com-
munications and Electronics from Ain
Shams University, Egypt in 1998. She
received the MSc degree from the same
university in 2004 in the field of auto-
mating the long-term measurements.
Now, she is a research assistant in the
National Institute for Standards (NIS) in the Time and Fre-
quency Department and a PhD student. She is interested
in the time and frequency dissemination through using
GPS receivers.
Abdelhaliem Zekry graduated from
Cairo University Egypt in 1969. He was
offered the MSc degree in 1973 from
the same university. He worked as a
scientific coworker at TU Berlin, where
he got his PhD at 1981. He worked as an
assistant prof. at Ain Shams University
(ASU), Egypt 1982. He moved to King Soud University
at 1988 and stayed there for 6 years, where he became
a professor of Electronics. Now he is a professor of
Electronics at the faculty of Egypt, ASU.
Dr. Zekry made intensive research on semiconductor
materials, devices, and circuits. He published more than
70 papers in specialized conferences and periodicals in
addition to two books in Electronics. Now, he is driving
research on electronics for communication especially
the implementation of advanced communication stan-
dards using DSP platforms.
Dr. Zekry has been awarded several prizes for out-
standing research as well as the Decoration of distinc-
tion from the Egyptian President. He has been an IEEE
Member since 1991.
Ibrahim Motawie graduated from Cairo
University, Egypt. He was offered the
MSc degree from Ain Shams University,
Egypt. He got his PhD in 1979 from Paul
Seharie University, France. He worked
as an associate professor at Constantine
University, Algeria for about 6 years.
Now, he is a professor in the National Institute for Stan-
dards (NIS). He is interested in the Time and Frequency
measurements and applications. He published more than
20 papers in specialized conferences and periodicals.
References[1] Available: http://home.earthlink.net/~cwkelley/
[2] Available: http://www.zarlink.com/zarlink/hs/82_GP2015.htm
[3] Available: http://www.zarlink.com/zarlink/hs/82_GP2021.htm
[4] Available: www.xilinx.com/publications/magazines/dsp_01/xc_pdf/
p50-53_dsp-gps.pdf
[5] K. Borre and D. Akos, A Software-Defined GPS and GALILEO Receiv-
er—A Single-Frequency Approach. New York: Birkhäuser, Oct. 2006.
[6] SE4110L PointCharger GPS Receiver IC Data Sheet.
[7] J. Tian, W. Ye, S. Lin, and Z. Hua, “Software defi ned radio GNSS re-
ceiver design over single DSP platform,” in Proc. 10th Int. Symp. Spread
Spectrum Techniques and Applications (ISSSTA’08), 2008, pp. 37–41.
[8] J. H. Meclellan, R. W. Schafer, and M. A. Yoder, DSP First A Multimedia
Approach. Englewood Cliffs, NJ: Prentice-Hall, 1997.
[9] Simulink Dynamic System Simulation for Matlab User’s Guide.
[10] Real-Time Workshop User’s Guide.
[11] Real-Time Workshop® Embedded Coder User’s Guide.