(THEORY)
(ANALOG)
(DIGITAL)
(SOFTWARE)
(HOME)
A homemade receiver for GPS & GLONASS satellites
Matjaz Vidmar, S53MV (ex YU3UMV, YT3MV)
5. GPS & GLONASS receiver software
5.1. GPS/GLONASS receiver software overview
Satellite navigation is one of the first applications
that totally depends on the availability of suitable computers
and the corresponding software. Although initially the digital
computer was only intended to solve the navigation equations,
other tasks were being gradually added to simplify
the hardware in front of and behind the computer itself.
In the described GPS/GLONASS receiver even most of the signal
processing is performed in software, just to keep the analog
front-end and dedicated DSP hardware as simple as possible.
The software running in a GPS or GLONASS receiver is
therefore very complex and includes a variety of very
different functions. For example, digital signal processing
requires quick but simple integer arithmetics while solving
the navigation equations requires high-accuracy floating-point
arithmetics. The latter does not need to be as quick as the
former signal processing, but a considerable number of
operations still need to be performed in a limited amount of
time.
To make a fair comparison one should consider the
development time for the hardware and for the software.
In the case of the described navigation receiver, the
development of the software required between two and three
times the amount of time required to develop the hardware!
Unfortunately it is much more difficult to describe down
to the smallest detail the software than the hardware. For the
hardware one can draw the circuit diagrams and prepare
detailed parts lists. On the other hand, detailed descriptions
of the software tend to become boring and minor details tend
to hide the real problem being solved.
Therefore only the major functions performed by the
software will be described in this article. These include
signal acquisition and processing, almanac and precision
ephemeris data collection, time and frequency measurements,
solving the navigation equations and data display in a
suitable format for the user. At the end the user interface:
display menus and user commands, will be described in detail.
The overall software is written in different languages
due to the differing functions to be performed: MC68010
assembly language, DSP computer high-level language and even
directly in machine code.
The digital signal processing software is written in
the MC68010 assembly language. The corresponding file has
the extension .ASM. This file is first compiled into machine
code and then into hexadecimal format, so that it can be
easily inserted in the DSP computer high-level language.
The orbital mechanics and navigation equation part is
written in the DSP computer high-level language. The latter
supports a floating-point format with a 32-bit mantissa and
a 16-bit exponent. A 32-bit mantissa is generally sufficient
considering the accuracy of the data obtained from the GPS
or GLONASS satellites. The corresponding file has an extension
.SRC and can be compiled into an .EXE file and executed on a
DSP computer equipped with the described dedicated DSP
hardware board, but with an unmodified CPU board!
In a portable GPS/GLONASS receiver all of the software
is stored in a 27C256 EPROM. The latter includes a starting
program, the high-level language compiler and a version of
the .SRC file with all of the comments and other unnecessary
symbols removed. When the portable receiver is turned on,
the program will be compiled in the RAM. This operation
takes around 10 seconds and is necessary to save EPROM space,
since the compiled program in the RAM takes around 100kbytes.
The present discussion applies to the current software
versions V122 (GPS) or V39 (GLONASS). When running the
software on a DSP computer, the type of display may be
selected by the TOTAL/PARTIAL RESET switch while starting
the program: switch open (TOTAL RESET) selects the LCD
while switch closed (PARTIAL RESET) selects the CRT display.
Of course the LCD can only be selected in a stand-alone,
portable receiver and the corresponding input on the CPU
board MUST BE LEFT OPEN!
5.2. Real-time tasks: signal acquisition & processing
The signal acquisition and processing tasks run under the
1kHz interrupts requested by the dedicated DSP hardware
module. The tasks include the multiplexing of the
single-channel hardware among four different satellites,
the C/A-code synchronization acquisition and tracking,
the carrier lock acquisition and tracking, the 50bps
navigation-data demodulation, bit synchronization and frame
synchronization with parity check and finally the averaging
of the measured code phase, code rate and carrier frequency.
After an interrupt request is received from the dedicated
DSP hardware, the interrupt-servicing routine will first latch
the content of all of the counters in the dedicated hardware.
It will then read the latched content and reset and arm the
interrupt request flip-flop. The hardware counters are never
reset. The actually integrated value is computed from the
difference between the actual counter content and the previous
sample content. The four differences are further normalized
using the result from the reference 1ms divider. Finally,
the interrupt-servicing routine also increments a 32-bit
millisecond counter, which is later used to relate the
measurements to the 50bps navigation data.
The single-channel hardware is multiplexed among all of
the satellites received. However, due to the limitations of
the hardware, switching to another satellite will corrupt
one millisecond of data. Therefore, the basic multiplexing
period includes one millisecond to switch the hardware
followed by 8 milliseconds to collect the data from a given
satellite. After this 9-millisecond period the hardware is
switched to another satellite. The multiplexing rate is
therefore 111 hops per second.
The multiplexing rate and especially the multiplexing
sequence have to be chosen carefully. The navigation data
is transmitted at a speed of 50bps, so one bit is 20ms long
and lasts exactly 20 interrupt periods. If the navigation data
is to be collected from a given satellite, then this satellite
should get at least a few 1ms samples of data from each 20ms
bit period. Further, the multiplexing period should not be an
integer submultiple of the bit period, so that the bit
transitions can be detected.
Considering the limitations of the single-channel
hardware, the multiplexing sequence can not allow collecting
the navigation data from more than two satellites at a time.
In practice, since four satellites need to be received for a
navigation solution, the navigation data can only be collected
from a single satellite at a time using half of the
single-channel hardware time. The remaining hardware time
is split among the remaining three satellites. The privileged
satellite that gets more hardware time of course needs to be
periodically exchanged to allow collecting the navigation data
from all four satellites.
There is yet another constraint on the multiplexing
sequence. If a certain satellite only gets a few sampling
periods, then false locks of the carrier recovery loop
become very likely. In order to avoid this, the following
multiplexing sequence is used in the described GPS/GLONASS
receivers (1 = privileged satellite, 2, 3 & 4 = others):
121213141412131314 121213141412131314 ...
The complete multiplexing sequence therefore repeats after
18 multiplexing periods or 162 milliseconds.
The C/A-code synchronization is always obtained from the
signal magnitude obtained from the dedicated hardware. The
signal phase information is intentionally not used for this
purpose since the carrier phase lock is a much more critical
operation. Therefore, for the C/A-code synchronization, the
early and late magnitudes are computed from the related I and
Q sums for every 1ms accumulation period. These sums are then
averaged over the 8 milliseconds containing valid data in a
9-millisecond multiplexing period.
The initial state of the receiver is unlocked and the
C/A-code synchronization acquisition has to be obtained first.
The hardware variable delay will therefore be scanned through
all possible C/A-code phases (1023 for GPS and 511 for
GLONASS) by incrementing the variable-delay counter in suitable
steps (6 for GPS or 9 for GLONASS). When a signal magnitude
above threshold is detected, the software switches to the
synchronization maintaining routine. A suitable time constant
is built-in to prevent the loss of lock on short signal
interruptions. In the synchronization-tracking mode, the
software performs as a second-order phase-locked loop,
computing the C/A-code phase and rate from the measured
early-minus-late difference.
The signal carrier still includes the 50bps 0/180 BPSK
navigation data, so a Costas-loop demodulator is required
to obtain both the regenerated carrier for doppler
measurements and the 50bps navigation data. The Costas-loop
demodulator operates on every 1ms signal sample I & Q
components computed as an average of the early/late data.
The loop feedback is a second-order network computing the
carrier phase and frequency.
The carrier-lock operation is not simple. Initially,
the whole frequency range from -500Hz to +500Hz is
scanned. To prevent false locks, the scanning is stopped
only when the residual loop error becomes small enough.
Finally, the locking point needs to be checked for the
+/-500Hz ambiguity caused by the 1kHz sampling rate. The
latter ambiguity is resolved by counting the number of
transitions in the demodulated data stream in every
8 milliseconds of valid data in a multiplexing period. Since
valid GPS data only has transitions every 20ms (GLONASS
every 10ms), there can be at most one transition in 8ms
of data. If the frequency is wrong, there are at least 6
transitions and this can be detected easily.
Of course, the phases of both code and carrier PLLs
need to be adjusted for the following multiplexing period,
accounting for all of the time spent by the hardware
processing the signals from other satellites.
In a navigation receiver the code phase and the carrier
frequency are the main parameters to be measured and these are
supplied by the corresponding phase-locked loops. In addition
to this, the code rate is also used by the software to
compute a rough approximation for the carrier frequency and
eliminate the ambiguity caused by the 1kHz signal sampling
rate. Before further processing, the code phase, code rate and
carrier frequency are averaged over 16 multiplexing periods
corresponding to a time span of 288ms (privileged satellite)
or 864ms (other satellites). The averaged measurements are
placed in a FIFO memory together with 1ms time tags, to be
read by the main program.
The last task performed by the interrupt routine is
navigation data processing. The latter includes yet another
PLL for bit synchronization. This PLL locks on the transitions
in the data stream. The demodulated 1ms samples containing
the transitions are rejected while all of the other available
samples for a given satellite are accumulated into bits (GPS)
or half-bits (the GLONASS manchester phase is not known yet).
The following navigation data processing depends on the
data format and this is slightly different between GPS and
GLONASS. The GPS data is formatted into 30-bit words
containing 24 true data bits and 6 parity-check bits. The word
synchronization is obtained by checking the parity bits,
including the last two bits of the previous word, for any
possible word phase. The BPSK polarity ambiguity is also
resolved by the parity bits. The synchronized and checked
GPS data words are placed in another FIFO memory together with
1ms time tags, to be read by the main program.
The GLONASS data is formatted into lines with 85 data
bits in manchester format and a non-manchester sync pattern,
for a total duration corresponding to 100 bits. The sync
pattern is not used in the described GLONASS receiver. The
synchronization is obtained by checking the 8 parity bits for
any possible half-bit phase (200 possible phases), to resolve
the manchester phase ambiguity as well. Since the data bits
are differentially encoded, there is no polarity ambiguity to
be resolved. Like in the GPS receiver, the correctly received
data lines are placed in another FIFO memory together with 1ms
time tags, to be read by the main program.
5.3. Main program loop tasks
Since most of the functions performed by the main program
loop require high-accuracy floating-point arithmetics, the main
program is mainly written in the DSP computer high-level
language. Of course all of the interfaces to the interrupt
routine and to the various peripherals (initialization of the
dedicated DSP hardware, LCD drive, real-time clock chip) are
at least partially written directly in the MC68010 machine
code and are inserted in hexadecimal format in the program
source code.
The main program loop executes once for every new set
of averaged measured data. The latter is available every
864 milliseconds for the three satellites that get less
hardware time. The privileged channel supplies three
separate sets of averaged data in the same time period, but
the excess data is not used by the main program loop.
The main program loop also updates the LCD or writes a
new line on a CRT display. The internal operation of the
program is however independent of the selected menu on the
display. The menu only affects the keyboard functions and
some computations closely related to the format of the
displayed data, like coordinate conversions.
The first task of the main program loop is to write the
look-up tables in the dedicated DSP hardware memory. This
operation is done at receiver power-up, when changing
satellites, when adjusting the carrier frequency (in 1kHz
steps) or when switching the privileged satellite. The
satellites can be selected manually, but usually the software
is set to automatically select visible satellites.
When a given satellite is selected, the receiver
requires some time to lock on its signal. The software will
first look for all possible C/A-code phases. If the lock is
not achieved, the main program loop will change the hardware
look-up table frequency in 1kHz steps in a given frequency
range (20kHz in the GPS receiver or 25kHz in the GLONASS
receiver). Of course the look-up table frequencies for all
four satellites can also be preset manually.
The look-up tables are rewritten when switching the
privileged satellite for several reasons. When all four
satellites have been acquired, this happens every minute,
synchronized to the major data frames transmitted every 30
seconds from both GPS and GLONASS satellites. Since switching
the privileged satellite includes some loss of data, other
operations that corrupt the data, like rewriting the look-up
tables, may be performed at the same time without any
additional losses. The look-up tables are rewritten to correct
for large variations of the doppler shift or local reference
oscillator drift. Further, the new look-up tables are
rewritten with a randomly chosen phase relationship between
the carrier phase and code phase, to avoid any possible
interferences between the carrier and the code when averaging
the measured data over a longer period of time.
The main loop will then process all of the navigation
data accumulated in the corresponding FIFO memory. The
software looks for the frame sync and formats the data into
frames. Additional checks are made before the formatted
data is used. Correctly received frames are used to collect
the precision ephemeris orbital data for the given satellite,
to update the almanac containing less accurate data about the
whole satellite navigation system and to set the GPS/GLONASS
receiver real-time clock chip.
The next task is to collect the code phase and carrier
frequency measurement results from the corresponding FIFO
memory. The most recent data is always used together with the
previous sample to relate all of the data to a single time
point using linear interpolation. This simplifies the
following computations, since the positions and velocities
of all four satellites need to be calculated for a single
point in time.
The measured data and the satellite positions and
velocities (computed from the precision ephemeris data) are
then assembled into the navigation equations. A set of
three time-difference navigation equations is obtained from
code-phase differences and another set of three
doppler-difference navigation equations is obtained from
carrier-frequency differences.
The time-difference navigation equations are solved
first, using the Newton's method. The starting point is taken
in the Earth's center (x=y=z=0). From this starting point
the Newton's method requires between three and four iterations
to converge to the final result for a user located on the
Earth's surface. The result in Cartesian coordinates x,y,z
is then converted to longitude, latitude and height.
The position obtained may now be corrected for the
propagation anomalies in the ionosphere and troposphere.
The present software does not apply any correction for the
ionosphere. The navigation equations are only corrected for
the troposphere at the calculated height and the Newton's
method is iterated once again to obtain the final result.
Since the position is already available from the
time-difference navigation equations, the doppler-difference
navigation equations are solved to obtain the velocity of
the user. Solving the doppler-difference equations for the
velocity does not require a numerical iterative method, since
the equations result linear for this unknown. The computed
velocity vector is converted into magnitude, azimuth and
elevation on the display.
The accuracy of the navigation solution depends on the
geometry of the satellites. In place of the GDOP the software
only computes the determinant of the linearized system of
equations at the calculated position. This determinant is
a dimensionless quantity. The higher the determinant, the
more accurate the solution. If the determinant is too low,
an error condition is signalled. The doppler-difference
equations have the same determinant if solved for velocity.
The main program loop also performs data averaging.
Both position and velocity are averaged. Only good data
with no error signalled is added to the average. The
determinant of the system of equations is used as a weight
for each new data set added to the average. Of course the
averaging buffer may be manually reset if desired.
The display includes several different menus and two
of them are devoted to the immediate and averaged data. The
position may be displayed in different formats: degrees
only, degrees, minutes and seconds or Gauss-Krueger
rectangular grid. Other menus are used to show the receiver
status and the almanac data.
Finally, the main program loop usually also performs an
automatic satellite selection. This function is triggered
if an error condition is signalled continuously for a certain
period of time (100 main loops). The software then uses the
almanac data and the real-time clock to find the visible
satellites at the averaged user location. The receiver is
then programmed for the four visible satellites with the
highest elevations on the sky. Although this procedure does
not yield the best GDOP, its operation is foolproof.
5.4. Software menus and commands
Since a portable GPS/GLONASS receiver only has a small
keyboard with a few keys and a small alphanumeric display,
the various user commands need to be arranged into several
different menus. The organization of the commands in the
different menus is shown on Fig. 62.
The keyboard has 8 different keys. Four of them
(corresponding to ASCII characters "4", "5", "6" and "7") are
used to select the four main menus. Depressing these keys
only changes the content of the display and the functions of
the other keys, but does not affect the internal operation
of the GPS/GLONASS receiver. Some of these keys have
additional functions if depressed more than once. Depressing
key "4" cyclically shows all four virtual receiver channels
(satellites) on the display. Depressing key "7" cyclically
shows the general receiver status and the almanac data for
all currently visible satellites.
The remaining keys (ASCII "0", "1", "2" and "3") are
called parameter keys. Depressing these keys affects the
internal operation of the GPS/GLONASS receiver as a function
of the current menu. The mode of operation of these keys is
also dependent on the actual menu. Some functions allow a
repeated action of these keys during just one main program
loop (864ms), like setting the channel IF. Other functions
are intentionally slowed down, like the total reset of the
receiver. The latter requires depressing the corresponding
key for at least 9 times and just one entry is allowed for
each main program loop, to avoid unintentional loss of data.
In order to understand the commands of a GPS/GLONASS
receiver it is necessary to understand the internal operation
of the latter. A GPS/GLONASS receiver includes a nonvolatile
RAM to store the almanac data and a real-time clock that
are always powered by a small internal NiCd battery. The
nonvolatile RAM is used to store the almanac data and the
approximate user position as a result of previous receiver
operation. At power-up this data is used together with the
real-time clock data to find all visible satellites and
speed-up the acquisition of four usable satellite signals.
When a GPS or GLONASS receiver is first powered up,
all of the nonvolatile RAM contains random data and a total
reset is required. The total reset erases all almanac data
and puts the receiver in the manual satellite select mode.
All receiver virtual channels are set to a central carrier
frequency and GPS PRN#16 or GLONASS CHN#13. The menu "4"
is selected to show the virtual channel #1 data.
The initial satellite signal acquisition without any
almanac data may take a large amount of time, especially in a
single-channel receiver. The receiver does not know which
satellite to look for nor its frequency offset caused by the
doppler shift and by the unknown frequency drift of the
receiver itself. The current software for the described
GPS/GLONASS receiver is not able to select different
satellites automatically without any almanac data, so this
has to be done manually.
After manually selecting the satellite(s), the software
is going to try to achieve C/A-code lock. If the latter does
not occur on the given IF frequency, the receiver is going to
scan the expected IF frequency range in 1kHz steps by writing
the corresponding look-up table. Only the privileged satellite
IF is scanned in the range from 2310kHz to 2330kHz (GPS) or
from 1675kHz to 1700kHz (GLONASS).
While searching for the initial signal acquisition there
is a small difference between the GPS and GLONASS receivers.
The GPS constellation is now complete and more than four
visible satellites can be found at any time, so the GPS
receiver is only going to switch the privileged channel after
a satellite signal is acquired. On the other hand, the GLONASS
constellation is not complete and sometimes there is just one
visible satellite, so the GLONASS receiver is going to try
a different virtual channel with a different satellite if the
current privileged satellite was not acquired.
After a satellite signal has been acquired, the key "4"
menu shows the most important receiver parameters:
RX: virtual channel number SV: GPS satellite PRN code number CH# GLONASS satellite RF channel number CF: look-up table preset central IF frequency (kHz) R: measured IF frequency (kHz, from code rate) S: signal level (S-meter) SVH: satellite health flag (0=OK) URA: GPS user range accuracy (m) ASF: GPS anti-spoofing flag (0=OFF) En: GLONASS ephemeris upload age (days) AOE: GLONASS ephemeris age (s)
If the receiver has been turned on for the first time or
has not been used for a considerable period of time (more than
one week), the best thing to do is to collect the complete
almanac data first. To speed-up the almanac data collection
it is recommended that the remaining three receiver virtual
channels are set to the same satellite and to the same IF
frequency as the channel that already acquired a satellite.
After all four virtual channels achieved signal lock, the
almanac data collection takes 12.5 minutes for GPS or
5 minutes for GLONASS, since the GLONASS receiver does not
make use of half of the almanac frames.
The accumulated almanac data can be checked by repeatedly
pressing key "7". The almanac data includes the satellite
name/number plus the following information:
CH# GLONASS RF channel number EL: elevation (degrees) AZ: azimuth (degrees) DF: doppler frequency shift (Hz, polarity as in the IF) A/E GPS almanac/precision ephemeris data SVH: satellite almanac health flag (GPS 0=OK, GLONASS 1=OK) ASF: GPS anti-spoofing & configuration flag UTC: UTC date and time
The elevation, azimuth and doppler shift are computed for
the reference user position as obtained from the averaged data.
After a total reset this reference position is set in central
Europe. Checking the almanac it is possible to find out when
the receiver can be switched to automatic satellite selection.
In the automatic satellite selection mode, the program selects
the four satellites with the highest elevations and sets the
corresponding central IF values in the hardware look-up tables.
This selection can be done immediately by pressing key "0" in
menu "7" or by switching the program to do this automatically
after a period of bad data (key "3" in menu "7").
After four satellites have been acquired, the display may
be switched to menu "5" or "6", to show respectively the
immediate or averaged data. These menus show the following:
DET: determinant of the system of equations (menu "5" only) AVG: averaging weight (menu "6" only) V: velocity vector magnitude (km/h), azimuth & elevation LAT: latitude (degrees or m, north) LON: longitude (degrees or m, east) H: height above ellipsoid (m)
At the beginning of all menus (except the almanac) the receiver status error codes appear, as shown on Fig. 63. These codes show the general receiver status, the current privileged virtual channel and the status of the single virtual channels. Most of the codes used are obvious, but three of them require further explanation. In the general receiver status, code "P" means that the computed position deviates too much from the previous main program loop. On the other hand, code "E" is only activated after the averaging weight gets larger than 5 and means that the equations themselves deviate too much from the already computed average position. Finally, code "T" in the virtual channel status appears quite frequently since the current software does not handle the overflow of the C/A-code variable-delay counter correctly.
Finally, the general status menu (key "7") shows some
interesting data about the receiver: the satellites currently
selected, AUTomatic or MANual satellite selection, the
measured nominal IF frequency of the receiver (without the
doppler shift), the measured receiver master oscillator
frequency and the UTC date and time.
6. Conclusion
The GPS and GLONASS systems are mainly intended for
navigation, but there are many other less advertised but not
less important nor less interesting applications of these
systems. Since these systems are known and the technology to
use them is available to anyone, we radio-amateurs should
consider our own applications of these systems [13].
Although the navigation itself is not of much interest to
radio-amateurs, it would probably make much more sense to
transmit GPS or GLONASS coordinates of a contest location
rather than the inaccurate EU or WW locator, which is
already not accurate enough for serious microwave or laser
communications. By the way, GPS and GLONASS use almost the
same coordinate system and a long time average shows
differences in the order of only 10m between the two
systems.
A side product of both GPS and GLONASS is accurate
time and frequency broadcast. In order to achieve the
specified navigation accuracy, the timing measurements have
to be performed to an accuracy of about 10ns. The same
requirement applies to the on-board satellite atomic clocks.
The final user time transfer accuracy ranges between 30ns
and 100ns, depending also on the knowledge of the exact user
location. Thus the user should also compute his position
even if he only needs accurate time.
Radio-amateurs could use this time transfer capability
of both GPS or GLONASS every time when accurate synchronization
is required. Coherent communications are just an example, the
accuracy of GPS or GLONASS offers more than this: for example,
the actual propagation path of the radio signal and the
propagation mechanism could be investigated in this way.
The frequency broadcast accuracy of both GPS and GLONASS
is in the range of 10^-12, far better than can be achieved
with HF or LF standard frequency transmitters. The accuracy
of the latter is limited to around 10^-7 by the propagation
effects alone, and this is not enough for serious microwave
work. GPS and GLONASS are also available globally 24 hours
per day and are not limited by the transmitter range,
propagation effects or low-frequency electronic pollution.
Finally, GPS and GLONASS represent a step away from
being just an operator of black-box amateur-radio equipment.
Although there are several ready-made GPS receivers on the
market, we will probably have to develop our own receivers
for our experiments, both the hardware and the software.
Building such a receiver may be an interesting challenge as
well. The receiver shown in this article is perhaps just
the first step, other related projects or better receivers
will hopefully follow soon.
7. References
[1] Matjaz Vidmar: "Digitale Signalverarbeitungs-Techniken fuer Funkamateure, Teil 2: Ein DSP-Computer fuer Amateurfunk-Anwendungen", pages 2-25/1-89, UKW-Berichte/VHF-Communications. [2] Matjaz Vidmar: "Digitale Signalverarbeitungs-Techniken fuer Funkamateure, Teil 3: Bau und Inbetriebnahme des Computers", pages 66-88/2-89, UKW-Berichte/VHF-Communications. [3] Jonathan S. Abel, James W. Chaffee: "Existence and Uniqueness of GPS Solutions", pages 952-956/6-91, VOL.27, IEEE TRANS. ON AEROSPACE AND ELECTRONIC SYSTEMS. [4] "Interface Control Document MH08-00002-400, rev. E", (84 pages), August 7th, 1975, Rockwell International Corporation, Space Division, 12214 Lakewood Boulevard, Downey, California 90241, USA. [5] "Interface Control Document GPS-200", (102 pages), November 20th, 1981, Rockwell International, Space Operations and Satellite Systems Division, 12214 Lakewood Boulevard, Downey, California 90241, USA. [6] "Global Satellite Navigation System GLONASS Interface Control Document", (46 pages), 1988, Research-and-Production Association of Applied Mechanics, Institute of Space Device Engineering, GLAVKOSMOS, USSR. [7] Robert C. Dixon: "Spread Spectrum Systems", (422 pages), 1984, Second Edition, John Wiley & Sons, New York, USA. [8] Matjaz Vidmar: "Digital Signal Processing Techniques for Radio Amateurs, Theoretical Part", pages 76-97/2-88, VHF-Communications/UKW-Berichte. [9] P. Mattos: "Global Positioning by Satellite", (16 pages), Inmos, Technical note 65, July 1989. [10] J. B. Thomas: "Functional Description of Signal Processing in the Rogue GPS Receiver", (49 pages), June 1, 1988, Jet Propulsion Laboratory, California Institute of Technology, Pasadena, California, USA. [11] Charles C. Kilgus: "Shaped-Conical Radiation Pattern of the Backfire Quadrifilar Helix", (pages 392-397), IEEE Transactions on Antennas and Propagation, May 1975. [12] Matjaz Vidmar: "Ein sehr rauscharmer Antennenverstarker fuer das L-band", pages 163-169/3-91, UKW-Berichte/VHF-Communications. [13] Matjaz Vidmar: "Radio-amateur applications of GPS/GLONASS satellites: Using GPS/GLONASS satellites as an accurate frequency/time standard", strani 186-190/Scriptum der Vortraege, 37. Weinheimer UKW Tagung, 19.-20. September 1992.
GPS/GLONASS RECEIVER HARDWARE & SOFTWARE UPDATE #1
Matjaz Vidmar, S53MV
Since the publication of the series of articles about the GPS/GLONASS receiver in UKW-Berichte/VHF-Communications there have been a few modifications of the hardware and software of these receivers. The original articles describe the operation of the GPS software V122 and GLONASS software V39. The current update describes the new GPS software V125 and GLONASS software V42. The new GPS V125 and GLONASS V42 include the following modifications:
(1) Improved internal operation of the software. The new software is able to handle the overflows of the hardware counters correctly thus almost eliminating the occurrence of the "T" error. (2) Additions to the command set: (2.1) In menu #5, key #0 will shift the privileged RX channel. (2.2) In menu #7, key #0 has a new function: in AUT mode it operates as before while in MAN mode this command sets the carrier frequencies of the currently selected satellites. (2.3) In menu #7, key #1 has an additional function: the receiver will display the Keplerian elements of the GPS/GLONASS satellites as decoded from the almanac data before entering the total RESET sequence. (3) A simple bidirectional RS-232 interface is included, requiring only a few additional hardware components to be installed in the receiver. (3.1) The RS-232 interface output circuit is shown on Fig.1. Because of hardware limitations, the bit rate can only be set to 1000bps. The output data format is a serial asynchronous transmission including a start bit, 8 data bits, no parity and one stop bit. The output signal level ranges from 0V to +5V only, although these levels are usually accepted by most RS-232 receivers. The signal polarity is inverted as usual in RS-232: 0V represents a logical "1" while +5V represents a logical "0". The data output matches the LCD display content, the display clear command being replaced by a CR/LF combination.
(3.2) The RS-232 interface input circuit is shown on Fig.2. Because of hardware limitations, the bit rate can only be set to 100bps or 10 times slower than the output rate. The RS-232 input can be used to issue commands identical to those coming from the 8-key keyboard. Only ASCII characters "0", "1", "2", "3", "4", "5", "6" and "7" are therefore accepted as valid commands. All other codes are simply ignored. The data format is 8 bits, no parity, one or more stop bits. The signal polarity is inverted as usual in RS-232.
Since the PC6 input is now used for the RS-232 interface input,
it can no longer be used to select the display type, CRT or
LCD. The latter selection is thus preset in the software.
The new receiver software is supplied in three files. The .SRC
file is intended to be compiled and executed on a DSP computer,
equipped with a GPS/GLONASS hardware board. The .BIN file is
a compressed version of the program to be burned in a 27C256
EPROM for a stand-alone GPS/GLONASS receiver. Finally, the .ASM
file is only supplied as an information about the internal
operation of the main interrupt routine that includes all of
the digital signal processing. GTERM is a 1000bps RX, 100bps TX
RS-232 terminal program for the DSP computer.
Software download
Full-size drawings
* * * * *