GNSS Engineers Handbook
World leader in GNSS test and simulation systems
GNSS Engineer’s
Application Handbook
letter
2
Fundamental GNSS Receiver Characterisation page 5
Application Note DAN003 Issue 1-01
Testing GNSS System Errors page 17
Application Note DAN002 Issue 1-01
Simulator to receiver RF connection page 31
Application Note DAN006 Issue 1-00
Simulating Multipath page 43
Application Note DAN004-TM Issue 1-00
Using receiver NMEA data in a simulator test scenario page 65
Application Note DAN007-TM Issue 1-00
Testing GNSS systems for Automotive Applications page 75
Application Note DAN001 Issue 1-01
Testing GNSS for Railway Applications page 95
Application Note DAN011 Issue 1-00
Simulating UTC leap second insertion events page 111
Application Note DAN009-TM Issue 1-00
Contents
3
GNSS Engineer’s
Application Handbook
4
Fundamental GNSS Receiver Characterisation
Application Note DAN003 Issue 1-02
Fundamental GNSS Receiver Characterisation
5
Table of contents
1. Audience
2. Introduction
3. RF simulation
4. Typical GPS simulators
5. The GNSS environment
6. Fundamental receiver performance parameters
6.1. Cold Start Time To First Fix
6.1.1. Simulator test
6.2. Warm Start TTFF
6.2.1. Simulator test
6.3. Hot Start TTFF
6.3.1. Simulator test
6.4. Acquisition sensitivity
6.4.1. Simulator test
6.5. Tracking sensitivity
6.5.1. Simulator test
6.6. Reacquisition Time
6.6.1. Simulator test
6.7. Static Navigation Accuracy
6.7.1. Simulator test
6.8. Dynamic Navigation Accuracy
6.8.1. Simulator test
6.9. Radio Frequency Interference
6.9.1. Simulator test
7. Conclusions
8. Referenced Documents
9. Definition of Terms
10. Further Information
Fundamental GNSS Receiver Characterisation
6
1. Audience
This Application Note is for designers, developers, integrators and testers of GNSS receivers or systems, who
need to ensure their products will perform in the intended environment.
Spirent recommends you have a basic understanding of satellite navigation principles and awareness of
RF simulation as a test method is desirable.
2. Introduction
There is a steady growth in the use of GNSS navigation systems in new and existing markets. The increasing use
of GNSS brings an increasing reliance on the technology. Individuals, businesses and organisations are relying
on the technology for personal pleasure and safety to commercial advantage. With this in mind, it is important for
designers, manufacturers and consumers of these products to understand what to expect from GNSS systems,
which requires an understanding of the limitations and problems of what can often be a fragile, prone to error,
and easily disabled technology.
This Application Note discusses some of the fundamental receiver performance parameters applicable to GNSS
systems. Complementary to this, it demonstrates how Spirent’s range of GNSS Test Solutions enable you to
create and run controlled and repeatable simulations and benchmark your receiver’s performance when
subjected to these errors. It demonstrates that a GNSS RF Simulator is able to generate the conditions required
for performing suitable tests. The application determines the test criteria, and the importance of each criteria
may vary significantly from one application to another. For example, short TTFF performance may be vital in
automotive applications, but not so important for static position surveying. Re-acquisition is probably not a
primary consideration for marine applications, where little physical external signal obscuration exists, but is
important in automotive applications where tunnels and bridges frequently block signals.
3. RF simulation
An RF Constellation Simulator reproduces the environment of a GNSS receiver on a dynamic platform by
modelling vehicle and satellite motion, signal characteristics, atmospheric and other effects, causing the
receiver to actually navigate according to the parameters of the test scenario.
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full richness
of real world conditions. A common misconception is the need to exactly replicate real world conditions for a
GNSS test to be valid. However, application of representative effects via simulation is proven (over some 25 years
of testing) to exercise receivers and adequately identify their limitations allowing for design centring and
optimisation. More importantly, it gives complete repeatability, control and exact knowledge down to bit level –
of the signal stimulating the receiver. This is not possible when using real GNSS signals for test purposes. We
should look upon simulator testing as representing the real world, rather than replicating it. Spirent simulators
include statistical models enabling simulation of richer multipath environments, but consideration of these is
outside the scope of this document.
Figure 1 shows the concept of simulation (using a GSS6560 simulator)
Fundamental GNSS Receiver Characterisation
7
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
Figure 1 RF Simulation Flow
4. Typical GPS simulators
All the tests discussed in this Application Note can be performed using any of Spirent’s multi-channel simulators.
SimGEN is the control and scenario definition software for GSS6560 and GSS7000 series simulators. SimPLEX is
the scenario replay and control software for the STR4500 simulator. For further information on Spirent’s range of
Simulators, please contact your local Spirent representative, or visit www.spirent.com/positioning, or
www.spirent.com and click the Satellite Navigation link.
5. The GNSS environment
A GNSS receiver works well when it has a clear, un-interrupted view of the orbiting satellites transmitting the
ranging and navigation signals. In many situations this is not the case, and ranging measurements to the
satellites are affected. The degree that performance is affected depends on the application and the environment
of the receiver. However, in terms of general receiver performance, there are a few fundamental parameters,
which if optimised will ensure good baseline performance, allowing the design to be tailored for a specific
application.
6. Fundamental receiver performance parameters
This Application Note focuses on testing the key parameters to determine a GNSS receiver’s general performance.
Unless otherwise stated, GPS L1 C/A code signals are implied.
6.1. Cold Start Time To First Fix
TTFF is a measure of how quickly a receiver performs the signal search process. The search process, or ‘signal
acquisition’, has two dimensions. The C/A code dimension associated with the replica PRN code, and the
Fundamental GNSS Receiver Characterisation
8
Doppler dimension associated with the carrier. When performing the search process a cold-starting receiver
could have a code uncertainty of up to 1023 chips (the total number of code phase states for the GPS C/A
code), and approximately +/-11 kHz for the Doppler uncertainty. Some receivers use a serial search process,
others a parallel (multi-correlator) process. Faster designs use matched filter or FFT techniques. The newest
techniques use a combined replica of several codes instead of separate ones.
A Cold Start TTFF is defined (in Reference 1) as the time between application of power to a receiver and it
obtaining the first valid navigational data point, when the following criteria are met:-
a73
Time unknown
a73
Current almanac and ephemeris unknown
a73
Position unknown
Due to the stochastic nature of the process several (Reference 1 suggests 20) TTFF measurements are taken
with different satellite geometries and then averaged.
6.1.1. Simulator test
Using a simulator to perform a Cold Start TTFF test is very simple. First simulate a static vehicle position
with satellite power levels set so the power into the receiver’s antenna is -120 dBm. With the scenario
running (and the receiver connected to the simulator), power is applied to the receiver. Once the receiver
has obtained its first fix, stop the scenario rewind it (if applicable) and advance the scenario time by at
least 8 hours to ensure the simulated constellation geometry of visible satellites has changed.
Alternatively, change the simulated location by several thousand km achieves the same effect. Clear the
receiver of all navigational data and time information and remove the power. Re-run the modified
scenario and re-apply power to the receiver. Repeat this process the required number of times, and
average the TTFF results.
If you are not certain that the receiver’s memory has been completely erased, you can select very
different locations and/or times (years apart) for the scenario. In this way, even if the receiver retained
some prior navigation information, it would not be of use.
6.2. Warm Start TTFF
A Warm Start TTFF is defined in Reference 1 as the time between application of power to a receiver it
obtaining the first valid navigational data point when the following criteria are met:-
a73
Time unknown
a73
Almanac is known
a73
No ephemeris (or the data is more than 4 hours old)
a73
Position within 100km of last fix
6.2.1. Simulator test
For a simulator test, you can use the same scenario as for the Cold Start TTFF, as the criteria (such as
clearing the ephemeris, but not the almanac) are all set using the receiver.
Fundamental GNSS Receiver Characterisation
9
If it is not possible to clear only the ephemeris, the receiver must first be allowed to collect the almanac
from the full navigation message (this takes approximately 12.5 minutes). Advance the scenario time by 4
hours (to age the ephemeris), and set the receiver time to match.
6.3. Hot Start TTFF
A Hot Start TTFF is defined in Reference 1 as the time between application of power to a receiver and it
obtaining the first valid navigational data point when the following criteria are met:-
a73
Time is known
a73
Almanac is known
a73
Ephemeris is known
a73
Position within 100km of last fix
6.3.1. Simulator test
As with Warm Start, you can use the same scenario. There is no clearing of data from the receiver memory
and no need to stop the scenario in order to alter any parameters. Power cycle the receiver for each TTFF
test. As with Warm start, allow the receiver to collect the full navigation message
(Approximately 12.5 minutes).
6.4. Acquisition sensitivity
Acquisition sensitivity is the minimum received power level at which a ‘First Fix’ can occur. The sub-sets
of this are separate measurements for each of the cold, warm and hot start-up conditions.
6.4.1. Simulator test
For a simulator test, you can use a simple static scenario. The simulator software allows you to control the
power level of the simulated signal in various ways, to a high degree of resolution, and over a wide
dynamic range.
Power control can be in real-time while the scenario is running, or using a pre-scripted set of commands.
Real-time control can be applied using the SimGEN GUI or using remote commands (if the simulator is
being controlled by a remote system).
It is possible to control the power independently on individual satellites, or on all satellites, and level can
be displayed as absolute power, or relative to a reference. The resolution of power control (for the
GSS6560 simulator) is very fine, being 0.1dB over the range -130 dBm (+15dB, -20dB). This allows
accurate determination of a receiver’s acquisition sensitivity. As with TTFF, you should run several tests
with different satellite geometries (DOP) and average the results.
6.5. Tracking sensitivity
Tracking sensitivity is the minimum power level at which a receiver can continue to maintain lock. The
tracking threshold is closely related to measurement errors due to error sources in the receiver’s PLL
tracking loops. Phase error, dynamic stress error and thermal noise are the dominant sources of error.
Minimising these parameters will enable the receiver to continue to track signals at a much lower power.
In all cases, the tracking threshold should be lower than the acquisition sensitivity.
Fundamental GNSS Receiver Characterisation
10
6.5.1. Simulator test
For a simulator test, you simply lower the power on all satellite channels simultaneously until the receiver
looses lock. This should be repeated for different satellite combinations and geometries, using the
techniques described in section 6.1
6.6. Reacquisition Time
Reacquisition time is the time necessary for a receiver to regain its first valid navigational data point after
total loss of all received signals.
Fast reacquisition time is important for in-vehicle navigation systems. Consider a car emerging from a
tunnel, in which it has lost all satellite signals. Immediately after the tunnel is a junction at which the
driver must make an exit. The navigation system needs to be navigating again quickly in order for it to
give the correct “Exit Now” instruction.
6.6.1. Simulator test
For a simulator re-acquisition time test, power must be reduced on all satellites by a minimum of 60 dB.
The best way to achieve this is to specify ‘off’ for each satellite. SimPLEX and SimGEN allow you to turn off
all satellites while the scenario is running. With SimGEN you can also create a pre-defined ‘User Actions’
file which has a time-ordered list of commands. One such command is ‘Power on/off’.
With SimPLEX, you can record real-time actions and replay them from a file. Set the duration for which all
satellites are off so that the receiver loses complete lock to ensure a valid reacquisition.
6.7. Static Navigation Accuracy
Static Navigation Accuracy is the accuracy to which a receiver can determine its position with respect to a
known location. It can be split into three categories:-
Predictable – The accuracy of a receiver’s position solution with respect to the charted solution. Both
the position solution and the chart must be based upon the same geodetic datum.
Repeatable – The accuracy with which a user can return to a position whose coordinates have been
measured at a previous time with the same receiver.
Relative – The accuracy with which a user can measure position relative to that of another user of
the same receiver at the same time.
It is possible to perform an estimate of position error (EPE) for a receiver given certain conditions.
The following formula applies:
EPE (1-sigma) = HDOP * UERE (1-sigma) (1)
Multiplying the HDOP * UERE * 2 gives EPE (2drms) as given in equation (2) and is commonly taken as the
95% limit for the magnitude of the horizontal error. The probability of horizontal error is within an ellipse of
radius 2drms ranges between 0.95 and 0.98 depending on the ratio of the ellipse semi-axes.
EPE (2drms) = 2 * HDOP * SQRT [URE
2
+ UEE
2
] (2)
Fundamental GNSS Receiver Characterisation
11
HDOP, GDOP, PDOP and VDOP are determined by the geometry of the current satellites visible above the
receiver's mask angle with respect to user receiver's antenna. DOPs can be degraded (made larger) by
signal obstruction due to terrain, foliage, building, vehicle structure, and so on.
URE is an estimate of "Signals in Space" errors, such as ephemeris data, satellite clocks, ionospheric delay
and tropospheric delay. These errors can be greatly reduced by differential and multiple frequency
techniques. Differential correction sources include user provided reference stations, community base
stations, governmental beacon transmissions, FM sub-carrier transmissions and geosynchronous satellite
transmissions.
UEE includes receiver noise, multipath, antenna orientation, EMI/RFI. Receiver and antenna design can
greatly reduce UEE error sources.
Position error can range from tens of metres (recreational applications) to a few millimetres (survey
applications) depending on equipment, signals and usage. Professional mapping and survey equipment
often includes user-settable minimum thresholds for parameters such as SNR, mask angle, DOP, number
of SVs used, etc.
UERE is User Equivalent Range Error, and is computed (for L1 C/A) as shown in Table 1
Error source Bias RandomTotal DGPS
Ephemeris Data 2.1 0.0 2.1 0.0
Satellite Clock 2.0 0.7 2.1 0.0
Ionosphere 4.0 0.5 4.0 0.4
Troposphere 0.5 0.5 0.7 0.2
Multipath 1.0 1.0 1.4 1.4
Receiver measurement 0.5 0.2 0.5 0.5
UERE (1-sigma RMS) 5.1 1.4 5.3 1.6
Filtered UERE, RMS 5.1 0.4 5.1 1.5
Vertical 1-sigma errors (VDOP = 2.5) 12.8 3.9
Horizontal m1-sigma errors (HDOP=2.0) 10.2 3.1
Table 1 L1 C/A User Equivalent Range Error (UERE)
6.7.1. Simulator test
For a simulator test, you can eliminate UERE and certain UEE errors by disabling the effects of the
atmosphere, and deliberately not including any ephemeris, clock errors, multipath or EMI/RFI in the
simulation. This is not possible using real satellite signals. For this reason, it is not possible to physically
measure a receiver’s absolute navigation accuracy with any method other than using a GNSS simulator.
To measure Static Navigation Accuracy you define a scenario, with a static position (0 degrees Latitude, 0
degrees Longitude and 0 metres height is always a good location as it is easy to see any divergence that
will be highlighted in non-zero digits). The scenario should run for at least 24 hours (as stated in
Reference 1) and the power level must not exceed -160 dBw (the Received Minimum RF Signal Strength
as defined in Reference 3).
Fundamental GNSS Receiver Characterisation
12
Some receivers have a mode that fixes the position if the detected velocity falls below a certain
threshold. This so-called ‘static mode’ is useful for in-car receivers, to prevent display ‘jitter’ when the
vehicle is stationary. However, when performing a static position accuracy test, this mode must be
disabled to prevent a falsely good result.
Reference 4 gives a detailed explanation of how to measure accuracy performance.
6.8. Dynamic Navigation Accuracy
Dynamic Navigation Accuracy is the same as Static Navigation Accuracy, except the receiver is undergoing
motion in either or all of the three axes of movement x, y, z
6.8.1. Simulator test
For a simulator test, define a scenario with a simple trajectory defined using SimGEN’s internal vehicle
model commands. To ensure data de-correlation, run the test over a minimum of three time periods of
duration no less than one hour each. Each period must contain at least 1000 valid navigation data
points. The three tests should be equally spaced during a 24-hour period.
For application specific dynamic accuracy performance, a simulator can perform almost any dynamic
trajectory profile you desire. The high dynamic performance of Spirent’s simulators enables testing of
receivers for any application where dynamic motion is required, from emergency beacons drifting in the
sea, to military ordnance shells spinning at several hundred revolutions per second.
6.9. Radio Frequency Interference
RFI is defined as any unwanted signal that causes degradation in performance, partial loss, or full loss of
navigation. Such signals are often referred to as ‘Jamming’ signals. Jamming, being a widely used term
describing a signal that prevents the wanted radio communication from being received.
Jamming can either be intentional or un-intentional. Intentional Jamming is a result of a deliberate attempt to
deny a GNSS receiver use of the GNSS system. An example may be found within the theatre of
war, where an enemy is trying to attack the other’s capability. An advanced form of intentional jamming,
called ‘Spoofing’ involves re-transmission of GNSS-like signals that make a receiver think it is navigating
in a way which, in reality it is not.
Un-intentional jamming results from unknown interference. It is less specific, and can come from a wide
variety of sources. Examples include: harmonics from commercial TV broadcast stations or pulsed
interference from Aircraft VOR/DME navigation beacons.
The main vulnerability of GNSS signals with respect to both types of jamming is that they are extremely
low power when arriving at the receiver’s antenna (typically -120 dBm). The signals are, in fact some
20 dB below the level of background noise, necessitating the use of signal processing gain (correlators)
in the receiver to extract the signal from the noise.
To emphasise the vulnerability of a receiver to jamming, it is estimated that an airborne 1-watt CW
jammer signal on the L1 frequency (1.57542GHz) can deny GPS tracking to an already locked receiver at
up to 10km away, and prevent an un-locked receiver acquiring lock at up to 85km away. Reference 5
discusses this in detail.
Fundamental GNSS Receiver Characterisation
13
6.9.1. Simulator test
For a simulator test, there are several options. Simple non-coherent jamming is easily achieved with
Spirent’s GSS6560 and GSS77xx/78xx and 79xx series of simulators, as they have an RF ‘Jammer’ input
port that allows you to inject an external RF signal into the main GNSS signal path in a controlled way
(using a directional coupler within the simulator). Figure 2 shows this concept.
Figure 2 Typical interference simulation set-up
A signal injected from a third-party signal generator would not be coherent with the simulators GNSS
signal. However, the Spirent GSS7765 Interference Simulation System option is available for GSS6560
and GSS77/78/79xx series simulators. This allows specific signal generators to be controlled using
SimGEN in either a coherent or non-coherent way with a variety of signal modulation types and with
modelled power, which simulates the relative distance effects of the interference source with respect to
the simulated GNSS position (for example, a jamming source flying over a receiver’s location).
For more information regarding the GSS7765 interference simulation option, see Reference 6.
7. Conclusions
This Application Note describes the fundamental performance parameters that apply to all GNSS receivers. These
parameters must be optimised at an early stage in a receiver design. Optimisation requires suitable testing. This
Application Note shows that a GNSS simulator allows you to develop tests that optimise receiver design. SimGEN
offers very high resolution control of signals and bit-level manipulation of data, reproducing the most complex
error effects while its easy-to-use interface allows straightforward tests to be carried out with the same powerful
modelling taking place in the background.
It shows that there are no practical alternatives to simulator testing in situations where the receiver must be
tested while undergoing high-dynamic motion.
Fundamental GNSS Receiver Characterisation
14
8. Referenced Documents
1. ION STD 101 Recommended Test Procedures For GPS Receivers, [I.O.N]
2. IS-GPS-200D Navstar GPS Space Segment/Navigation User Interface Specification, Revision D, 7th Dec 2004
3. ICD-GPS-200 Navstar GPS Space Segment/Navigation User Interface Control Document, Revision
IRN-200C-004, 12th April 2000
4. GPS SPS Signal Specification, Annex C, Means of measuring GPS performance
5. Vulnerability assessment of the transportation infrastructure replying on the Global Positioning System
[John A. Volpe, NTSC, Aug 29th, 2001]
6. MS3026 Latest Issue GSS4765 Interference Simulation System Product Specification
7. DGP00902AAA Latest Issue SimPLEX Standard Scenario Descriptions
9. Definition of Terms
C/A Code – The GPS SPS Coarse Acquisition ranging code
Chip – The time between transitions in the C/A code (not referred to as a ‘bit’ because the code does
not carry information)
DOP – Dilution of Precision (GDOP = Geometric DOP, HDOP = Horizontal DOP, VDOP = Vertical DOP, PDOP
= Position DOP, TDOP = Time DOP
EMI – Electro-Magnetic Interference
EPE – Estimated Position Error
FFT – Fast Fourier Transform
GNSS – Global Navigation Satellite System – For example: GPS, Glonass & Galileo
PPS – GPS Precise Positioning Service, employing the P-code
PRN – Pseudo-Random Number code. A code which appears completely random when a portion of it is
viewed, but which in reality repeats (for the GPS C/A code the repetition is 1mS, the GPS P-code
takes 7 days to repeat)
RF – Radio Frequency
RFI – Radio Frequency Interference
Scenario – In this context, a GNSS simulation running on either SimGEN or SimPLEX simulator control
software.
SNR – Signal-to-Noise Ratio
SPS – GPS Standard Positioning Service, employing the C/A-code
SV – GPS Satellite Vehicle
TTFF – Time To First Fix
UEE – User Estimated Error
UERE – User Estimated Range Error
Valid A single, time-tagged estimate ‘fix’ of Latitude, Longitude and Altitude referenced to the WGS-84
Navigational (for GPS) coordinate system, computed while in 3D navigation mode
Data Point –
VOR/DME – VHF Omni-directional Range/Distance Measuring Equipment
Fundamental GNSS Receiver Characterisation
15
10. Further Information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Please visit www.spirent.com/positioning, or www.spirent.com and click the
Satellite Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more
information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies, which can be found by logging into the Support website:
www.positioningtechnology.co.uk/support
Fundamental GNSS Receiver Characterisation
16
Testing GNSS System Errors
Application Note DAN002 Issue 1-02
Testing GNSS System Errors
17
Testing GNSS System Errors
Table of contents
1. Audience
2. Introduction
3. RF simulation
4. Typical GPS simulators
5. The GNSS environment
6. A Typical GNSS System
7. Sources of Error
7.1. Ephemeris errors
7.2. Satellite clock errors
7.2.1. Intentional Satellite Clock Noise (ISCN)
7.2.2. Receiver Autonomous Integrity Monitoring (RAIM)
7.3. Satellite Geometry
7.4. Navigation Data Errors
8. Referenced Documents
9. Glossary of Terms
10. Further Information
18
Testing GNSS System Errors
1. Audience
This Application Note is for designers, developers, integrators and testers of GNSS receivers or systems, who
need to ensure their products will perform in the intended environment.
Spirent recommends you have a basic understanding of satellite navigation principles and awareness of RF
simulation as a test method is desirable.
2. Introduction
There is a steady growth in the use of GNSS navigation systems in new and existing markets. The increasing use
of GNSS brings an increasing reliance on the technology. Individuals, businesses and organisations are relying on
the technology for personal pleasure and safety to commercial advantage. With this in mind, it is important for
designers, manufacturers and consumers of these products to understand what to expect from GNSS systems,
which requires an understanding of the limitations and problems of what can often be a fragile, prone to error,
and easily disabled technology.
This Application Note discusses some of the sources of error inherent in GNSS systems. Complementary to this, it
demonstrates how Spirent’s range of GNSS Test Solutions enable you to create and run controlled and repeatable
simulations and benchmark your receiver’s performance when subjected to these errors. It demonstrates that a
GNSS RF Simulator is able to generate the conditions required for performing suitable tests. The application
determines the test criteria, and the importance of each criteria may vary significantly from one application to
another.
3. RF simulation
An RF Constellation Simulator reproduces the environment of a GNSS receiver on a dynamic platform by
modelling vehicle and satellite motion, signal characteristics, atmospheric and other effects, causing the receiver
to actually navigate according to the parameters of the test scenario.
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full richness
of real world conditions. A common misconception is the need to exactly replicate real world conditions for a
GNSS test to be valid. However, application of representative effects via simulation is proven (over some 25 years
of testing) to exercise receivers and adequately identify their limitations allowing for design centering and
optimisation. More importantly, it gives complete repeatability, control and exact knowledge – down to bit level –
of the signal stimulating the receiver. This is not possible in the real world. We should look upon simulator testing
as representing the real world, rather than replicating it. Spirent simulators include statistical models enabling
simulation of richer multipath environments, but consideration of these is outside the scope of this document.
Figure 1 shows the concept of simulation (using a GSS6560 simulator).
19
Testing GNSS System Errors
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
Figure 1 RF Simulation Flow
4. Typical GPS simulators
All the tests discussed in this Application Note can be performed using any of Spirent’s multi-channel simulators.
For further information on Spirent’s range of Simulators, please contact your local Spirent representative, or visit
www.spirent.com/positioning, or www.spirent.com and click the Satellite Navigation link.
5. The GNSS environment
A GNSS receiver works well when it has a clear, un-interrupted view of the orbiting satellites transmitting the
ranging and navigation signals. In many situations this is not the case, and ranging measurements to the
satellites are affected. The degree that performance is affected depends on the application and the environment
of the receiver. Common to all applications, are additional sources of error from the GNSS system infrastructure.
These errors are produced by inaccuracies in the satellites and in control equipment, deficiencies in monitoring
and prediction systems and data processing anomalies. Finally, the receiver generates its own errors.
6. A Typical GNSS System
Basically, a GNSS comprises three main parts: The Space Segment:- the constellation of orbiting satellites that
transmit ranging and navigation data signals. The Control Segment:- the Master Control Station and associated
monitoring and data uplink stations/facilities that measure and predict space segment performance and provide
the corrections broadcast in the navigation data. The User Segment:- GNSS receivers and systems that
autonomously navigate using the GNSS signals.
20
Testing GNSS System Errors
The most important performance characteristics for all GNSS systems are:
a73
Accuracy
a73
Availability
a73
Integrity
a73
Continuity
The quality of these depends on the particular GNSS system.
Each characteristic is defined (in reference 2) as follows:
Accuracy – for a given constellation, how close to the theoretical true position you can get in three dimensions.
For several measurements taken in a static position, it is normally specified as the error magnitude sphere
containing 95% of measurements. For GPS SPS, 95% vertical Position Accuracy is 22.7m (based on a 24-satellite
constellation with VDOP of 1.6, and system UERE of 7.1)
Accuracy is a complex topic, and can be defined in a number of ways. Reference 2 discussed accuracy in detail.
Availability – the percentage of time the services of the system are useable.
Integrity – the ability of the GNSS to provide timely warnings and alerts to users that advise when they should
not use the system.
Continuity – the probability the specified system performance will be maintained for the duration of a phase of
operation.
Unless otherwise stated, details refer to the Global Positioning System.
7. Sources of Error
This section describes the main sources of error, and how a simulator can be used to reproduce each error. The
contribution of errors from each segment is summarised in Table 1.
Segment Error Source GPS 1s Error (m)
SPACE Satellite Clock Stability 3.0
Satellite perturbations 1.5
CONTROL Ephemeris prediction error 4.2
Other (thruster performance etc) 0.9
USER Ionospheric Delay 2.3
Tropospheric Delay 2.0
Receiver noise resolution 1.5
Multipath 1.2
Other (interchannel bias, etc) 0.5
TOTAL System UERE Total (RSS) 6.6
Table 1 GNSS Error Sources
21
7.1. Space Segment Errors
7.1.1. Satellite clock errors
Fundamental to GNSS operation is the radio ranging that ultimately depends upon predictability of
satellite clock stability. Although satellites have accurate atomic clocks, a 1 millisecond error equates to
a 300km pseudorange error, so even small clock errors are significant. Errors 24 hours after an upload of
navigation data can be in the order of 1 to 4 m (see Reference 2). Ephemeris error and clock error are
progressive, getting steadily worse over time, until corrected for in the next control segment navigation
data upload.
For a simulator test, you can define a scenario in which the clock correction terms transmitted in the
navigation data diverge from the clock behaviour as represented by the simulated RF signal. On Spirent’s
SimGEN software, for any satellites, you can enter zero - first - and second-order ‘Af’ terms for the clock
corrections, which will be transmitted in the navigation data AND modelled in the simulated RF signal;
plus ‘Delta-Af’ terms, describing a signal timing error, which are modelled only by the simulated RF signal
and NOT declared in the navigation data. A receiver applying these Delta-Af corrections will see the effect
of an incorrect pseudorange due to clock error.
7.1.1.1. Intentional Satellite Clock Noise (ISCN)
Selective Availability (S/A) is an intentional satellite clock noise error. It is the only intentional error
associated with the GPS system. As at 2008, S/A has not been enabled since May 2000, but is a
potential source of error to C/A code receivers.
S/A is the deliberate degradation of the SPS signals by a time varying bias. S/A is controlled by the US
DoD to limit accuracy for non-U.S. military and government users. The accuracy of the C/A code is
reduced to 100 metres (two standard deviations).
The S/A bias on each satellite signal is different, therefore the resulting position solution is a function of
the combined S/A bias from each SV used in the navigation solution. Because S/A is a changing bias
with low frequency terms in excess of a few hours, position solutions or individual SV pseudo-ranges
cannot be effectively averaged over periods shorter than a few hours.
While the US government has stated they will not re-enable S/A and future satellites will not have the
capability, denial on a regional basis is theoretically possible. Spirent recommends you test for this
potential occurrence.
Spirent simulators controlled by SimGEN allow you to test your receiver in the presence of ISCN. You can
apply a number of different models to all satellites or selected satellites that will generate S/A-like effects
on the simulated RF signal that are not declared in the navigation data.
7.1.1.2. Receiver Autonomous Integrity Monitoring (RAIM)
RAIM is a technology developed to assess the integrity of GPS signals in a GPS receiver system. It is of
special importance in safety-critical GPS applications, such as aviation or marine navigation. RAIM
detects faults with redundant GPS pseudorange measurements. That is, when more satellites are
available than needed to produce a position fix, the extra pseudoranges should all be consistent with the
Testing GNSS System Errors
22
computed position. A pseudorange differing significantly from the expected value may indicate a fault
with the associated satellite (such as a clock failure) or another signal integrity problem (such as
ionospheric dispersion). Traditional RAIM uses Fault Detection only (FD); however newer GPS receivers
incorporate Fault Detection and Exclusion (FDE) which enables them to continue to operate in the
presence of a GPS failure.
Spirent simulators controlled by SimGEN have a Pseusorange Ramp feature, that allows you to change the
simulated position of the satellite in a controlled, but abnormal way and is not declared in the navigation
message. A receiver with a RAIM algorithm should detect this abnormality and either initiate an alert or
exclude the offending satellite from its solution. The speed of the pseudrorange change can be adjusted
(gradually reduced) until the receiver’s detection threshold is reached.
7.1.2. Orbital Perturbations
Orbital perturbations are caused by external influences that alter the satellite orbits. Such influences
include;
a73
Non-central gravitational force due to the Earth being slightly elliptical (it is 20km larger in its
equatorial radius than its polar radius): This causes orbital plane rotation and harmonic
perturbations with a 6-hour period corresponding to the satellite’s transition over the equator,
where its velocity increases.
a73
Gravitational fields of the Sun and Moon. The Moon dominates, as it is much closer to the earth.
Visual examples of this are the tides. In a similar way, the Moon (and negligibly the Sun) pull on
the satellite’s orbit. The effect is very small, but cumulative, and must be corrected for in the
control segment’s orbital predictions. If left un-corrected, a 25 m error would result after just one
hour (see reference 5).
a73
Solar radiation pressure: Photons from the sun’s radiation exert a minute force on it. The force
depends on the mass of the satellite and how much of it is exposed to the sun.
For the GPS system, the navigation data contains six parameters relating to cyclic perturbation:
Cuc, Cus - Amplitude of the cosine and harmonic correction terms to the argument of latitude
Cic, Cis - Amplitude of the cosine and sine harmonic correction terms to the angle of inclination
Crc, Crs - Amplitude of the cosine and sine harmonic correction terms to the orbit radius
In SimGEN, apply perturbations using these six terms to one or more satellites. These are errors, as they
are not declared in the navigation message.
7.1.3. Satellite Geometry
The relative positions of visible satellites, as observed by the receiver, determine a ‘quality parameter’
called Dilution Of Precision (DOP). If a receiver sees four satellites and all are arranged, for example, in
the north-west, this leads to a “bad” geometry. In the theoretical worst case, no position determination is
possible, because all distance determinations point to the same direction. Even if a position is
determined, the error of the positions may be up to 100 – 150 m. If the four satellites are well distributed
over the whole sky the position is much more accurate.
Testing GNSS System Errors
23
Depending on the factors used for calculation of DOP values, different variants of DOP are used:
a73
GDOP (Geometric Dilution Of Precision); Overall accuracy; 3-D coordinates and time
a73
PDOP (Positional Dilution Of Precision) ; Position accuracy; 3-D coordinates
a73
HDOP (Horizontal Dilution Of Precision); horizontal accuracy; 2-D coordinates
a73
VDOP (Vertical Dilution Of Precision); vertical accuracy; height
a73
TDOP (Time Dilution Of Precision); time accuracy; time
HDOP values below 4 are good, above 8 bad. HDOP values become worse if the received satellites are
high in the sky. VDOP values become worse the closer the satellites are to the horizon and PDOP values
are best if one satellite is positioned vertically above and three are evenly distributed close to the
horizon. To determine accurate positions, the GDOP value should not be less than five. The satellite
geometry does not cause inaccuracies in the determination of position, so DOP is unitless. DOP values
amplify other inaccuracies and high DOP values amplify other errors more than low DOP values.
The error in position caused by the satellite geometry also depends on the latitude of the receiver.
For a simulator test you can subject a receiver to different combinations of satellites by deliberately
excluding certain satellites from the simulated visible constellation. SimGEN will identify the four
satellites in a given constellation that will give the best DOP performance, depending on the selection
criteria, which will be one of the five DOP types. If, for example these satellites are deliberately excluded,
this will force the DOP to be worsened. This feature is useful for identifying a receiver’s ability to use
satellites that are not ideally positioned. For example, in an urban canyon environment a receiver will
probably see only satellites that are directly above. This means the HDOP will be poor so the receiver or
system developer must optimise the design to work in these conditions.
There are several different methods for restricting a receiver’s visibility of certain satellites, including
manualy enabling and disabling satellites or using scripted commands to enable and disable satellites,
using terrain obscuration and by using antenna patterns (See reference 4).
7.2. Control Segment and User Segment errors
7.2.1. Ephemeris prediction errors
These are errors in the declared position of a satellite (as transmitted in the navigation data message). In
other words; the satellite wasn’t where the system said it was when you made a measurement on its
signal. Radial and cross-track errors contribute to ephemeris errors. Ephemeris corrections are calculated
using a curve-fit of the control segment’s best prediction of each satellite’s position at the time of an
upload and contain inherent errors. In addition, the errors tend to grow over time from the last control
segment navigation data upload.
For a simulator test, you can define a scenario in which the ephemeris prediction data in the navigation
message gradually diverges from being correct according to a specified ‘graceful degradation of accuracy’
curve as defined in Reference 1. When you enable the Diverge Ephemeris feature SimGEN applies errors
to the data for each satellite, but does not alter the simulated signal. This is opposite to the real world,
where the physical satellite position (and signal) changes; however, the effect is identical.
Testing GNSS System Errors
24
Another effect you can apply is a Track Error, where you specify the orbit trajectory of a given satellite to
have an error in either or all of the three axes; Along (forward or backward on the trajectory), Across (left
or right on the trajectory) and Down (up or down from the trajectory). Figure 2 illustrates this principle
Figure 2 Satellite orbital track errors
7.2.2. Navigation data errors
Navigation data is a key part of any GNSS system. For GPS, each satellite broadcasts this as a 50 bps
message formatted into 25 frames of 1500 bits. Each frame takes 30 seconds to transmit. The frames are
sub-divided into five sub-frames, each containing ten, 30-bit words and taking six seconds to transmit.
The last 6 bits of each word are parity bits employing a 32,26 Hamming code that allows the receiver
equipment to detect bit errors during demodulation. It takes 12.5 minutes to transmit the complete
navigation message. The data content is updated by the Control Segment approximately twice a day for
each satellite.
The content of the message sub-frames is summarized as follows:
a73
1: satellite clock corrections, health indication, age of data.
a73
2 and 3: satellite ephemeris parameters.
a73
4: ionosphere model parameters, UTC data, almanac & health status data for satellites
numbered 25 and higher.
a73
5: almanac & health status data for satellites numbered 1 to 24.
Reference 1 gives a detailed description of each bit of the navigation message.
Because the navigation message contains information vital to the operation of the receiver, any errors in
the message not detected by the parity check may corrupt the receiver’s calculation of PVT. you can
replicate such errors using a simulator. SimGEN lets you simulate errors and apply various post-parity
corruptions to selected words/sub-frames at certain times and on certain satellites. This tests a receiver’s
error detection & correction algorithms.
You can also modify any of the navigation message to maintain parity.
Testing GNSS System Errors
25
Another feature relevant to the navigation message is scheduling an upload. It is possible to simulate
control segment uploads to each or all satellites and specify the subsequent upload times, apply various
health status settings, L1/L2 delays and URA. Specifying an abnormally long time between uploads will
make the age of the data increase and for example, clock corrections will be less and less accurate. This
tests a receiver’s satellite exclusion algorithm, where it reads the IODC value and determines that a
particular satellite is bad due to the age of the clock correction data.
7.2.3. Ionospheric prediction error
Sub-frame 4, page 8 of the GPS navigation message contains the data describing the ionospheric model
used by single frequency L1 receivers (L1 + L2 receivers can all but eliminate ionospheric delay)
This model was developed by Klobuchar in 1996 (see Reference 5). The GPS Master Control Station selects
a set of coefficients from a database of 370 such sets associated with different seasons and levels of solar
activity. The model is constrained by the number of parameters that can be used and the frequency of
updates (one per day maximum) therefore it is not completely accurate and any receiver using it to correct
for the ionospheric delay will benefit from a 50% reduction in error compared to a completely un-
compensated delay.
For a simulator test you can simulate the inaccuracies inherent in the control segment’s ionospheric
predictions. SimGEN allows you to enter a model to be applied to the RF signal, and a different model to
be broadcast in the navigation message. In addition, it is possible to enter different broadcast models
depending on the control segment navigation data upload, simulating either an improvement of
degradation due to the change in data. It is also possible to fix the ionospheric delay and even disable
the ionosphere. A receiver can navigate far more accurately than it would in real life if its ionospheric
model is disabled and the simulator’s model is also disabled. Disabling the ionosphere can help to
benchmark the receiver’s true theoretical performance and quantify the relative performance of its
atmospheric modelling capabilities when they are re-enabled.
7.2.4. Tropospheric delay
The lower part of the atmosphere is known as the Troposphere. This contains the ‘weather region’ in the
lowest part and a ‘dry region’ in the uppermost part. Unlike the Ionosphere, the Troposphere is a non-
dispersive medium where radio signals are refracted equally, regardless of frequency. Given this, it is not
possible to use GPS measurements on L1 and L2 to estimate the delay and you have to rely on a model.
The navigation message does not provide Tropospheric prediction as tropospheric effects are too regional.
A Simulator applies a Tropospheric model to the RF signal to simulate the effects of the Troposphere. In
SimGEN, the STANAG, Bean-Dutton 2, RTCA96 and RTCA98 models are available, together with a surface
refractivity index data entry. As with the Ionosphere model, the Troposphere model can also be disabled.
7.2.5. Multipath
Multipath, is a phenomenon where a signal that takes one line-of-sight path from the satellite to the
receiver, in practice undergoes a reflection(s) and a receiver sees multiple versions of the direct signal,
each with different time of arrival and signal level.
The receiver has no way of determining which signal is the ‘real’ non-delayed one, as it cannot
Testing GNSS System Errors
26
distinguish them as discrete ‘rays’. Usually, a receiver can readily resolve a multipath signal if the path
travelled is greater than twice the spreading code symbol period for the BPSK modulation. This is
because the direct (wanted) signal arrives much earlier than any multipath. The problem is when
multipath reflections from nearby objects arrive very soon after the arrival of the wanted signal. Such
signals (with delays as small as 10 to 100 ns) distort the correlation function between the received signal
and the locally generated reference in the receiver. They also distort the composite phase of the received
signal, introducing errors in pseudorange and carrier phase that vary between different satellites.
These errors contribute to an overall error in the receiver’s PVT solution.
Figure 3 shows the concept of a simple single-reflection multipath.
Figure 3 Multipath concept
There are many types of multipath, and a detailed discussion is beyond the scope of this document.
Reference 6 gives an in-depth look at multipath, and how to test a receiver under multipath conditions.
7.2.6. Receiver errors
Another source of user segment errors are those due to the receiver.
Modern receivers have multiple digital receiver channels, and with silicon chip integration densities
continually increasing, more parallel processing is possible, leading to, for example, shorter time to first
fix performance.
However, with increased processing comes increased noise, and new designs are still susceptible to
classical error sources such as LNA noise, PLL/FLL thermal noise, oscillator phase noise and ADC aliasing.
Testing GNSS System Errors
27
An average modern receiver should contribute less than 0.5 m rms error in bias and less than 0.2 m in
noise, according to Reference 2. As the receiver under test is obviously part of the test set-up, it will
contribute its own errors and there is no requirement for the simulator to replicate receiver errors.
8. Conclusions
This Application Note describes some of the many sources of error within the GNSS system. These errors are
common to all applications and are in addition to application-specific errors due to the local environment. This
Application Note identifies the principal sources of error and shows that a GNSS simulator allows you to
introduce these errors in a test scenario, enabling the receiver under test to be fully exercised. SimGEN offers very
high resolution control of signals and bit-level manipulation of data, reproducing the most complex error effects
while its easy-to-use interface allows straightforward tests to be carried out with the same powerful modelling
taking place in the background.
9. Referenced Documents
1. ICD-GPS-200 Navstar GPS Space Segment/Navigation User Interface Control Document,
Revision IRN-200C-004, 12th April 2000
2. Understanding GPS – Principles & Applications, [E. Kaplan, C. Hegarty, 2nd Ed, 2006]
3. White House Press Release on the disabling of S/A [Office of the Press Secretary, 1st May 2000]
4. DAN001 Testing GNSS for automotive applications [Spirent Application Note]
5. Global Positioning System – Signals, Measurements & Performance [P. Misra, P. Eng, 2004]
6. DAN004-TM Simulating Multipath [Spirent Application Note]
10. Glossary of Terms
ADC – Analogue to Digital converter
BPSK – Binary Phase Shift Keying modulation
DoD – United Stated Department of Defence
DOP – Dilution of Precision (GDOP = Geometric DOP, HDOP = Horizontal DOP, VDOP = Vertical DOP,
PDOP = Position DOP, TDOP = Time DOP)
Ephemeris – precise satellite orbital information
Firmament – the heavens, the sky
FLL – Frequency Locked Loop
GNSS – Global Navigation Satellite System (GPS, Galileo, GLONASS etc.)
IODC – Issue Of Data Clock, The issue number for the clock correction data set that identifies its age
LNA – Low Noise Amplifier
Navigation – In the context of a GNSS, the data transmitted by the satellite to the user conveying system
Data information necessary for navigation
Pseudorange – a radio-measure of satellite to user distance
PLL – Phase Locked Loop
PVT – Position Velocity & Time, the three navigational parameters calculated by a GNSS receiver
RSS – The square root or the sum of the squares of a range of values
SPS – Standard Positioning Service of GPS
SV – Satellite Vehicle
URA – User Range Accuracy
UERE – User Estimated Range Error
Testing GNSS System Errors
28
11. Further Information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Please visit www.spirent.com/positioning, or www.spirent.com and click the
Satellite Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more
information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies, which can be found by logging into the Support website:
www.positioningtechnology.co.uk/support
Testing GNSS System Errors
29
30
Simulator to receiver RF connection
Simulator to receiver RF connection
Application Note DAN006 Issue 1-01
31
Simulator to receiver RF connection
Table of contents
1. Audience
2. Introduction
3. RF Simulation
4. Typical GPS Simulators
5. Simulator to receiver interconnection
5.1. Direct connection
5.1.1. The 50 Ohm transmission line
5.1.2. Active antennas
5.1.3. Devices with optional external antenna connections
5.1.4. The Monitor/Calibration or ‘MON/CAL’ port
5.2. Radiated coupling
5.2.1. RF shielded enclosures
6. Conclusions
7. Definition of terms
8. Referenced documents
9. Further Information
32
1. Audience
This Application Note is for designers, developers, integrators and testers of GNSS receivers or systems, who are
users of Spirent’s range of GNSS RF simulators.
Spirent recommends you have a basic understanding of satellite navigation and RF communications principles,
an awareness of RF simulation as a test method, and some familiarity with Spirent products.
2. Introduction
The transfer of RF energy from one device to another requires special consideration. The methods that must be
employed are significantly different to those employed at DC.
A GNSS receiver is normally connected (either permanently or via removable connection) to a suitable receiving
antenna. However, when testing using a GNSS RF Simulator, this connection may need to be broken or altered in
order to inject the L-band (1.5 GHz) test signals into the receiver.
This Application Note discusses some of the issues relating to simulator-receiver interconnection, and highlights
some common problems, which may be wrongly attributed to the receiver.
3. RF simulation
An RF Constellation Simulator reproduces the environment of a GNSS receiver on a dynamic platform by
modelling vehicle and satellite motion, signal characteristics, atmospheric and other effects. The receiver will
then navigate according to the parameters of the test scenario.
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full richness
of real world conditions. A common misconception is the need to exactly replicate real world conditions for a
GNSS test to be valid. However, application of representative effects via simulation is proven (over some 25 years
of testing) to exercise receivers and adequately identify their limitations, allowing for design centring and
optimisation. More importantly, it gives complete repeatability, control and exact knowledge – down to bit level –
of the signal stimulating the receiver. This is not possible in the real world. With this in mind, we should look
upon simulator testing as representation, rather than replication of the real world. Continued, successful
deployment of receiver designs in many applications, prove that the simulators being used for their development
and verification are accurate in their implementation of the GNSS environment.
Figure 1 shows the concept of simulation (using a GSS6560 simulator).
Simulator to receiver RF connection
33
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
Figure 1 RF Simulation Flow
4. Typical GPS Simulators
All the topics discussed in this Application Note apply to one or more of Spirent’s multi-channel simulators. For
information on Spirent’s range of Simulators, please contact your local Spirent representative, or visit
5. Simulator to receiver interconnection
There are two methods for transferring RF signals from a simulator to a device under test; direct physical
connection (this is the most controlled method for repeatable results), or radiation. This section discusses each
method, including things to be aware of.
5.1. Direct connection
5.1.1. The 50 Ohm transmission line
The industry standard method for physically interconnecting RF devices and test equipment is by the use
of a transmission line with a characteristic impedance (Zo) of 50 or 75 ohms. Such transmission lines
can be microstrip, stripline or coaxial inside RF devices, but are predominantly coaxial (coax) for external
interconnection between test equipment. 50 Ohms is used, as it is an impedance that enables a coax
cable with practical physical proportions to be used. Coax cable is considered a transmission line,
because the propagation of energy along it at RF frequencies cannot be described simply as a flow of
current, as at DC. Energy is propagated down the coax as an electro-magnetic wave. The coax looks like a
continuation of series inductors and parallel capacitors. The signal voltage charges each capacitor while
the current charges each inductor. The charge is then transferred to the next inductor and capacitor, and
so on, at the velocity of propagation (which is approaching the speed of light). Figure 2 illustrates this
principle, and shows additional elements representing a realistic transmission line with losses.
Simulator to receiver RF connection
34
Simulator to receiver RF connection
Figure 2 Transmission line equivalent circuit
The characteristic impedance (Z
o
) of the transmission line is equal to the square root of the ratio of the
line's inductance per unit length divided by the line's capacitance per unit length, as shown by the
following formula:
, where, L is the inductance per unit length, and C is the capacitance per unit length.
In an ideal, theoretical transmission line, all the power inputted will propagate along it and be delivered
to the load. This is called “Maximum Power Transfer”. In practice, this does not happen. All real
transmission lines suffer loss. Power is dissipated along the length of the line and the power delivered to
the load is less than power leaving the source. At frequencies in the microwave L-band region, (as used
by GNSS), this loss is significant, and can typically be tens of dB per metre.
Another problem is mismatching. For a transmission line to work efficiently, it must have a load at the
end, which has the same characteristic impedance as the line. If this doesn’t happen, some of the
energy will be reflected back down the line to the source. When a mismatch of impedance occurs,
reflected waves will be produced and they will interact with the incident waves. The total voltage and
current on the line are no longer the result of a single travelling wave from the source to the load.
Instead, it is the algebraic sum of two waves travelling in opposite directions. This interaction results in
standing waves. The waves remain in fixed positions along the line while they vary in amplitude and
polarity. A wave of any shape can be transmitted along the line without any change of wave-shape or
magnitude. The importance of these effects becomes apparent, particularly when connecting test
equipment (such as GNSS simulators) to a device under test. The simulator output power is carefully
adjusted during its alignment using a power meter, which terminates the input in precisely 50 ohms.
Therefore, it is very important that the coax cable carrying the signals to the device under test is of good
quality, and that its characteristic impedance is 50 ohms. Its other specifications (such as loss, phase
stability and VSWR) must also be well understood, or the absolute accuracy of the simulator will be
masked, and power level dependant tests may be compromised. Please refer to the user manual for your
model of simulator to check the required performance for devices connected to the RF ports of the
simulator.
35
5.1.2. Active antennas
Many GNSS receivers use active antennas, which include an LNA. The LNA typically provides pre-
amplification gain of 20 to 30 dB, and has a low noise figure, which determines the main contribution to
the cascaded noise figure for the receiver. It is important that the LNA is as close to the antenna as
possible, which is why it is incorporated in the same housing. The antenna and LNA are normally
connected to the receiver unit by a coax cable. In order to operate the LNA, DC power is required, which
is normally fed through the same coax to save having a second cable.
When a receiver is connected to the output of a simulator, the antenna is removed. The DC voltage on the
coax centre conductor is still present, but is not a problem because the RF output of the simulator is DC
protected. However, by removing the antenna you are also removing the gain of the LNA and this needs
to be compensated for. Compensation can be made using the simulator’s signal control, but this may
impact the simulator’s dynamic range. The best solution is to use an LNA with the same noise figure and
gain as the one in the removed antenna, on the output of the simulator. This way the simulator can
remain operating in the centre of its power control range, and the receiver will have the correct signal
level at its input.
Figure 3 shows an LNA connected in the RF signal path.
Figure 3 SImulator RF output fed through LNA to receiver
5.1.3. Devices with optional external antenna connections
Some devices (such as PDAs and pocket PCs) have, as well as a built-in antenna, a 50 ohm miniature RF
connector which allows an external active antenna to be connected. Very often, the device is able to
detect when the external antenna is connected, because it detects a resistance to ground of a few
kilo-ohms. This enables the power supply for the external antenna (which is otherwise disabled, mainly
to conserve battery power), and switches the RF input from the internal antenna to the external one. In
normal operation this is fine, but if the external antenna connection is being used to input signals from a
simulator, a problem can occur. If the simulator RF output is DC isolated (as most are), the device under
test will not detect a DC resistance to ground, and will not switch its RF input to the external connection,
preventing the simulator’s signals reaching the device under test’s RF front end. The solution to this
problem is to introduce a DC resistance to ground into the connection between the simulator and the
Simulator to receiver RF connection
36
device under test. This can be done with a simple ‘current sink’ circuit, comprising of a couple of
components on a small piece of 50 ohm microstrip circuit board.
Figure 4 shows this circuit.
Figure 4 DC current sink circuit
Component values
The resistor, R provides the DC path to ground. The inductor (or ‘choke’), L is required to prevent the RF
signal leaking to ground.
The inductor needs to have an inductive reactance, X
L
, of approximately 1k Ω at the operating frequency,
so using the formula:
Where: f = the operating frequency of 1.5x10
9
Hz, and X
L
= 1000, giving us;
nHHL1061.5x10 x 6.2831810009==(use 100nH)
For the resistor, we need to know the voltage of the external antenna power supply, and the nominal
current. Let’s assume they are 5V and 10 mA. The resistor is simply 5/0.01 = 500 Ω (use 510Ω)
The resistor and inductor are surface-mounted. 0805 or 1206 sizes are suitable for 1.5 GHz operation.
The entire circuit is best placed in an RF shielded enclosure (with the connectors protruding at either
end), to minimise stray RF signals.
The circuit should be placed in the set-up as shown in Figure 5
Simulator to receiver RF connection
37
Figure 5 Set-up including DC current sink circuit
5.1.4. The Monitor/Calibration or ‘MON/CAL’ port
Spirent’s multi-channel simulators are equipped with a MON/CAL port. This port is used during
alignment at the factory, to set the power output on the calibrated front panel RF output port. The
MON/CAL port allows you to obtain the simulator’s RF signal at a level 50~60 dB higher than the front
panel. This higher-power signal can be used to overcome missing LNA gain as discussed in section 5.1.2,
or where the signal is split (and halved in power) between two receivers. The MON/CAL port must be
used with caution, for the following reasons:
a73
The MON/CAL port is not DC isolated on earlier STR4760 series simulators, and damage to the
simulator can occur if a DC block is not placed on the MON/CAL port.
a73
The receiver’s equivalent input noise will be artificially low, as the noise contribution from the
antenna LNA is missing. This may result in abnormal Carrier-to-Noise (C/N
o
) readings on some
receivers navigating using signals from the MON/CAL port. Care must be taken if you are
performing Time-To-First-Fix (TTFF) or sensitivity tests that involve taking C/N
o
readings from a
receiver. In these cases, the methods discussed in section 5.1.2 should be adopted
a73
The absolute power level is not calibrated at the MON/CAL port, unlike the front panel RF output
port, which will output the exact level displayed in SimGEN.
Care must also be taken if resistive coaxial attenuators are used. You must ensure that a DC block is used
to protect these devices if the receiver under test supplies DC power to its antenna, and this cannot be
switched off. This is because an attenuator appears to a DC power source, as 50 ohm resistor to ground.
Without a DC block, any DC current will flow to ground via the attenuator, which may damage it. This may
also damage the receiver as it may not be capable of supplying enough current. Figure 6 shows the right
and wrong order of components when attenuators are used.
Simulator to receiver RF connection
38
Figure 6 Right and wrong use of resistive attenuators
You are advised to read Spirent’s simulator hardware manual (reference a), as it gives the performance
specification and limits for the ports on each simulator type.
5.2. Radiated coupling
Sometimes, it may not be possible to physically connect to the input of a receiver. Some devices (like mobile
phones and PDAs) have built-in antennas with no external access. For these, the only way to get the RF signal
from the simulator to the device under test is to radiate it.
The simplest way to radiate is to connect a
1
/
2
-wavelength dipole antenna to the output of the simulator,
and place the device under test near to this antenna.
A suitable dipole antenna can be easily made, either using PCB material, or by simply separating the inner
conductor from the screen by the correct length. Figure 7 shows a dimensioned drawing of a simple dipole
for 1.5 GHz.
Figure 7 Simple L-band dipole antenna
Simulator to receiver RF connection
39
There are however, some important points to note with this simple method:-
a73
In many countries, radiation of GNSS signals is not legal.
a73
It is not well controlled.
a73
It is subject to interference from other sources (including the real GNSS signals).
a73
It can potentially interfere with other systems/equipment.
a73
Unlike the direct connection method in 5.1, the device antenna is included, but no spatial
performance tests can be carried out on it, as the RF energy is arriving from one direction, rather
than different directions as per satellites in a real constellation.
a73
Strong multipath can be experienced due to nearby RF reflective objects.
These factors can all reduce the effectiveness and/or validity of tests, so a more robust method is required.
5.2.1. RF shielded enclosures
RF radiation is a suitable method, if it is well controlled. The ideal requirement is to transfer all of the RF
energy from the simulator to the device under test, with no distortion or interference. This requirement
will never be met entirely, but steps can be taken to minimise problems.
Placing the device under test and transmitting antenna in an RF shielded enclosure is a valid method,
but enclosure must have the following attributes:
a73
RF shielding of at least 40dB at 1.5GHz
a73
Internal surfaces covered in suitable Radio Absorbing Material (RAM) to minimise internal
reflections and multipath
Enclosures like this are available in various sizes, depending on the application. For some applications,
large anechoic chambers are required. Some of these chambers are large enough to completely enclose
railway locomotives or aircraft, and cost millions of pounds. Other enclosures are much smaller, and fit
on a bench in a laboratory. The smaller enclosures are typically referred to as TEM cells. TEM means
‘Transverse Electric Mode’ and refers to the mode of coupling within the enclosure. It is not possible to
establish a far-field mode of propagation in smaller enclosures. GNSS typically uses Right-Hand Circular
Propagation (RCHP) but this can only be established in larger anechoic chambers. For this reason, the
spatial properties of a device’s antenna cannot be tested in a TEM cell enclosure.
A certain amount of characterisation is required when using an enclosure. Placement of the device under
test in slightly different positions within the enclosure will affect the coupling loss, even in a TEM cell,
which is designed to give a consistent TEM field within the enclosure. However, this inconvenience is
small compared with the problems associated with an open radiated test set-up.
A typical mid-sized (2m long) TEM cell enclosure is shown in Figure 8
Simulator to receiver RF connection
40
Figure 8 TEM cell enclosure (Image courtesy of Accelonix Ltd)
6. Conclusions
In this Application Note, we have discussed the different methods of transferring the simulator’s RF signal to the
device under test, and the problems that need to be addressed.
Direct connection is always the preferred method, because it is well controlled and protected against external
influences. Radiated coupling is less controlled, but is the only method available for devices with no external
coaxial connection. Radiated coupling can be a reliable method, if it is carried out in an RF shielded enclosure,
and well controlled.
A good understanding of these methods, and the potential problems, will add integrity to your testing, and help
to preserve the high fidelity inherent in the signals of a precision RF simulator.
7. Definition of terms
dB – Decibel, is a logarithmic unit of measurement that expresses the magnitude of a physical quantity
(usually power or intensity) relative to a specified or implied reference level.
DC – Direct Current
GNSS – Global Navigation Satellite System
LNA – Low Noise Amplifier
PCB – Printed Circuit Board
PDA – Personal Digital Assistant
VSWR – Voltage Standing Wave Ratio
8. Referenced documents
a) DGP00703AAA, latest issue, Signal Generator Hardware User Manual
9. Further Information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Visit www.spirent.com/positioning, or www.spirent.com and click the Satellite
Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies, which can be
Simulator to receiver RF connection
41
42
Simulating Multipath
Simulating Multipath
Application Note DAN004-TM Issue 1-01
43
Simulating Multipath
Table of contents
1. Audience
2. Introduction
3. RF Simulation
4. Typical GPS Simulators
5. The GNSS environment
6. What is Multipath?
7. Simulating Multipath
7.1. Multipath implementation in the simulator
7.2. Methods of applying a multipath
7.3. Fixed Offset Multipath
7.4. Ground Reflection Multipath
7.5. Doppler Offset Multipath
7.6. Reflection Pattern Multipath
7.7. Legendre Multipath
7.8. Polynomial Multipath
7.9. Sinusoidal Multipath
7.10. Land Mobile Multipath (LMM)
7.11. Fader Multipath
8. Conclusions
9. Referenced Documents
10. Definition of Terms
11. Further Information
44
Simulating Multipath
1. Audience
This Application Note is for users of Spirent simulators who are designing, developing, integrating and testing
GNSS receivers or systems, and need to ensure their products will perform in the intended application.
Spirent recommends you have a basic understanding of satellite navigation principles and RF simulation as a test
method.
2. Introduction
There is a steady growth in the use of GNSS navigation systems in new and existing markets. The increasing use
of GNSS brings an increasing reliance on the technology. Individuals, businesses and organisations are relying on
the technology for personal pleasure and safety to commercial advantage. With this in mind, it is important for
designers, manufacturers and consumers of these products to understand what to expect from GNSS systems,
which requires an understanding of the limitations and problems of what can often be a fragile, prone to error,
and easily disabled technology.
This application note discusses the problem of Multipath, which is a phenomenon that can cause serious
reductions in a GNSS receiver’s performance in a range of applications. Complementary to this, it demonstrates
how you can use Spirent’s range of GNSS Test Solutions to create and run controlled and repeatable simulations
that include multipath modelling. It also includes test methodology specifically for users of Spirent’s simulation
systems.
3. RF Simulation
An RF Constellation Simulator reproduces the environment of a GNSS receiver on a dynamic platform by
modelling the vehicle and satellite motion, signal characteristics, atmospheric and other effects, such that the
receiver will actually navigate according to the parameters of the test scenario.
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full richness
of real world conditions. A common misconception is the need to exactly replicate real world conditions for a
GNSS test to be valid. However, application of representative effects via simulation is proven (over some 25 years
of testing) to exercise receivers and adequately identify their limitations allowing for design centring and
optimisation. More importantly, it gives complete repeatability, control and exact knowledge – down to bit level –
of the signal stimulating the receiver. This is not possible in the real world. We should look upon simulator testing
as representing the real world, rather than replicating it. Continued, successful deployment of receiver designs in
many applications, prove that the simulators being used for their development and verification are accurate in
their implementation of the GNSS environment.
Figure 1 shows the concept of simulation (using a GSS6560 simulator.)
45
Simulating Multipath
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
Figure 1 RF Simulation Flow
4. Typical GPS Simulators
All the tests discussed in this Application Note can be performed using any of Spirent’s multi-channel simulators.
For further information on Spirent’s range of Simulators, please contact your local Spirent representative, or visit
www.spirent.com/positioning, or www.spirent.com and click the Satellite Navigation link.
5. The GNSS environment
A GNSS receiver works well when it has a clear, un-interrupted view of the orbiting satellites transmitting the
ranging and navigation signals. In many situations, this is not the case, and ranging measurements to the
satellites are affected. The degree that performance is affected depends on the application and the environment
of the receiver. A variety of factors can affect a receiver’s performance, some specific to or emphasised by certain
applications. Multipath is a potential problem, which is worse in some application environments than others. The
discussions in this document are with regard to GPS, unless otherwise stated.
6. What is Multipath?
Multipath is described to some extent by its name. A radio signal conveying information or on which radio
ranging measurements are performed, should travel in a direct, single and un-altered path from the transmitter to
the receiver. Often this is not the case. Radio signals can be diffracted and reflected by physical structures in the
vicinity of the receiver, creating unwanted replicas of the original, desired, LOS signal. The composite signal is
said to take “multiple-paths” to the receiver. For GNSS, the problem of replica signals is significant, as
measurement of transit time for the signal (in order to determine pseudorange), is fundamental for calculating the
navigation solution.
46
Several reflections may take place, and their relative phase delays (to each other and the LOS) combine in either
a constructively (enhancing the multipath) or a destructively (cancelling-out the multipath) The perceived ‘coming
and going’ of the composite multipath is called fading. According to Reference 5, a multipath completely in-phase
with the LOS signal generates the largest error, and one which is 180 degrees out-of-phase generates the
smallest error. A simple representation of a single-ray multipath reflection is shown in Figure 2. In this example, a
reflection of the wanted signal takes place on the surface of the building. The receiver sees this delayed and
attenuated signal as well as the direct wanted signal. It also shows the two opposing sates that create full
constructive interference and full destructive interference.
Figure 2 Example of a simple multipath
The delay of the reflected signal compared to the direct signal depends (by trigonometry) on the proximity of the
receiver to the physical object causing the reflection. It may be obvious to assume that the greater the delay, the
greater the error in pseudorange. However, constructive addition of signals results in a correlation that gives a
measured pseudorange longer than it should, alternatively, if the multipath is out of phase, destructive addition
results in a correlation that gives a measured pseudorange shorter than it should.
Figure 3 shows the effect of constructive and destructive multipath on a single correlator peak.
Simulating Multipath
47
Simulating Multipath
Figure 3 Correlation peak with in-phase and anti-phase interference
You may also logically assume that the longer the delay (regardless of phase addition or subtraction) the greater
the pseudorange error, but the operation of the receiver’s spread-spectrum correlation process means that
reflections with long delays are attenuated and often completely eliminated. If the delay of the multipath signal is
long compared to a chip width (approx 300m, or 1microsecond for C/A code), the auto-correlation properties of
the code suppress the effect.
Short-delay reflections however, are much more of a problem, which is unfortunate as most real-life multipath
tends to be the close-in, short delay type.
There are several multipath mitigation techniques employed by receivers. Narrow correlators, first introduced in
the 1990’s, are probably one of the best known techniques. Other more up-to-date techniques include Strobe &
Edge Correlators, High Resolution Correlators (HRC) and Gated Correlators. The latest developments include A-
Posteriori Multipath Estimation (APME), which relies on an a-posteriori estimate of the multipath error through
use of a fourth replica of the PRN code (see Reference 1). Other mitigation techniques include Carrier Smoothing
and Multipath Limiting Antennas (such as choke-rings).
If the relative phase between the LOS and reflected signals changes rapidly, the receiver can average (carrier
smooth) the pseudorange measurements, attenuating the erroneous measurements.
A Multipath Limiting Antenna can reduce ground reflections from satellites that are very low on the horizon by
attenuating or blocking signals below a certain elevation. GNSS signals can also be reflected from below ground.
They travel through dry ground and then reflect off more moist layers further below and can be particularly
troublesome at high-quality DGPS reference stations, where specialised antennas are essential (See References 2
and 3). In marine environments, strong multipath from low-elevation satellites is created by the surface of the
sea, which is a very efficient surface for reflecting L-band signals.
There are many techniques for mitigating multipath, too numerous for discussion here. However, there are also
many books on the subject. References 2 and 5 provide good introductions to multipath in relation to GNSS.
48
7. Simulating Multipath
Proper multipath mitigation in receiver designs for all applications is essential. Complementary to this is the need
for proper testing. Real world testing presents very complex and un-quantifiable multipath environments that are
un-repeatable and can be time consuming and costly to trial. A GNSS simulator provides you with powerful
methods for generating multipath signals in a variety of different ways, but unlike the real world, these are fully
quantified and controlled by the simulator user.
This section provides a set of test methodologies giving step-by-step instructions on you can create simulator
scenarios that include multipath effects. Spirent’s SimGEN software contains several multipath features and a
demonstration of each one is given.
7.1. Multipath implementation in the simulator
With the exception of fader multipath, all multipath signals that are simulated in addition to a given LOS are
considered as discrete signals. This means that the simulator uses a separate hardware channel to generate
each signal. For example, a LOS with three multipath echoes will require four simulator channels. It is
important to remember this, as there is a limit to the number of channels in the simulator (12 for the Spirent
GSS6560 for example). In general, this is not a problem as there are usually fewer visible satellites in
environments where there are more multipaths (urban canyons for example), and less multipaths where there
are more visible satellites, so the overall number of required hardware channels balances out.
Fader Multipath techniques, available on some Spirent systems, uses digital replica signals, giving up to four
multipaths per LOS, while using just one simulator hardware channel.
7.2. Methods of applying a multipath
SimGEN offers you several ways of setting up multipath. These are common to all multipath types.
The methods available are:
a73
Channel Assignment – allows manual application during scenario run-time
a73
User Actions – allows you to set up multipath via pre-scripted commands which are executed in
a time-ordered manner
a73
Remote Control Commands – You can perform complex signal modification at high iteration
rates using specific commands
Channel Assignment
To access the Channel Assignment window, click on the Channel Assignment button on the toolbar
This brings up the Channel Assignment window as shown in Figure 4.
Simulating Multipath
49
50
Click on the ‘state’ drop-down arrow to reveal the various
state options. Select the ‘Multipath’ state to bring up the
Manual Multipath Settings window, as shown in Figure 5
Simulating Multipath
Figure 4 Channel Assignment Window
Figure 5 Manual Multipath Settings window
Select the multipath type and add the required number of echoes, setting the parameters for each as required.
User Actions
To apply a multipath signal using the User Action File, first edit the file from the scenario tree > options
branch, then select the ‘Switch Simulated Satellite’ from the Command Type drop-down list. Specify the time
into the scenario when you want the multipath to begin, and set the vehicle/antenna and which SV PRN you
want the multipath to apply to. Set the ‘State’ parameter to ‘Multipath’ and click the Settings button to open
the settings window. Select the multipath type and add the required number of echoes, setting the
parameters for each as required. Figure 6 illustrates the method.
Figure 6 Setting up multipath using the User Actions File
Remote Commands
SimGEN’s SimREMOTE feature allows you to set-up multipath using the ‘SWITCH_SAT’ and ‘MP_SWITCH’
commands. Remote commands can be sent in real time over a selection of interfaces, or from a file which is
either locally or remotely stored. Reference 4 gives full details for setting up multipath via SimREMOTE.
7.3. Fixed Offset Multipath
The most basic multipath model used in SimGEN is the Fixed Offset. For this type of multipath, the simulator
produces an ‘echo’ signal, with constant user-defined range and power offsets from the normal (LOS) signal.
Once defined, the settings remain ‘fixed’ in relation to the LOS during the scenario run. The variable fields are
as follows:-
The Attenuation field specifies the difference in level between the main signal and the reflected echo.
The Range Offset field specifies the delay in meters of the multipath signal compared to the LOS (always a
positive number – the delayed multipath signal cannot arrive before the LOS!) The change in relative phase
between the reflected and LOS signals (due to the vehicle and satellite motion) is not modelled in this simple
case, so the net interference between these signals remains fixed.
Simulating Multipath
51
Additional echo signals with different attenuation and delay values can be added. The limitation is the
number of channels available in the simulator hardware (As stated in section 7.1, the simulator allocates a
single separate hardware channel for each multipath echo added).
It is possible to remove the LOS signal from the simulation by ticking the ‘Remove LOS’ box. This simulates
the situation where the LOS is completely obscured.
Figure 7 shows a multipath signal defined for satellite PRN4 that is 3dB lower than the LOS and delayed by
30 m. It is not sensible to define more than one multipath signal for a given satellite using this method.
Figure 7 Fixed offset multipath
7.4. Ground Reflection Multipath
Ground Reflection Multipath simulates the echo signal that may be caused by the LOS signal reflecting from
the ground (or sea surface), in terms of the relative geometry of the transmitting satellite and the receiver.
The signal generated is based on the arrival angle at the WGS-84 ellipsoid height. A flat, plane surface is
assumed for the reflection. The receiver antenna position must have some height (relative to the ellipsoid
height) associated with for the ground-reflected signal to exist. The amount of delay is automatically
modelled as a function of the receiver antenna height and arrival angle of the satellite signal. Figure 8 shows
this concept.
Figure 8 Concept of a ground reflection multipah
Simulating Multipath
52
As with Fixed Offset Multipath, you can adjust the power level attenuation in dB of the Ground Reflection
Multipath signal relative to the LOS. This allows the reflection loss of the ground/sea to be accounted for. The
relative delay in the reflected signal will vary with satellite position, and as a result, the interference with the
direct signal will also vary.
You can remove the LOS signal from the simulation by ticking the ‘Remove LOS’ box.
It is not sensible to define more than one multipath signal for a given satellite using this method.
7.5. Doppler Offset Multipath
This multipath type was originally developed to support a specific test in the 3GPP Mobile Phone test
standard 3GPP TS25.171. However, it is also useful for other testing. It is an enhancement of the Fixed Offset
Multipath type. In addition to the level and initial delay, you can set a Doppler frequency offset between the
multipath and the LOS, which causes the delay between the multipath and LOS to change (dependent on the
amount of Doppler applied). You can set the difference in initial carrier phase between the LOS and the
multipath echo to a fixed value or randomised. If the box is ticked, the initial carrier phase difference will vary
run to run. If un-ticked, it will remain fixed. You can set up Doppler Offset Multipath in the same way as the
previous examples. Figure 9 shows the settings window. Note you can set the Initial Delay in either C/A chips
(code transitions are 1millisecond) or in metres (one chip is approx, 293m) If you specify several multipaths,
for the same satellite, with different Doppler values, a greater disturbance of the LOS signal will result.
Figure 9 Settings window for Doppler Offset Multipath
7.6. Reflection Pattern Multipath
In order to explain the function of Reflection Pattern Multipath, we must first look at the Antenna Pattern
feature of SimGEN, as both use the same editor and principles.
The Antenna Pattern function allows you to model the electrical properties of a ‘simulated’ antenna in your
test. When you are connecting the RF output from the simulator to the input of the receiver with a suitable RF
coaxial cable, the receiver’s antenna is omitted. GNSS signals arrive at the receiver’s antenna from different
directions, because the satellites are spatially separated in their constellation. Any variation of performance
over the antenna’s aperture (its ‘field of view’) should be accounted for, as signals arriving at the antenna
from some directions may be affected differently to those arriving from other directions.
The Antenna Pattern Editor in its default state defines an omni-directional isotropic spherical antenna
(theoretical antenna with uniform gain in all directions). It takes the surface area of this sphere and divides it
into equal-sized portions (minimum resolution 1
o
by 1
o
). The Antenna Pattern Editor represents the spherical
antenna as a 2-D array, in the same way that a globe map of the world can be represented as a 2-D map.
Simulating Multipath
53
Figure 10 show the Antenna Pattern Editor.
Figure 10 Antenna Pattern Editor
You can enter attenuation (and phase) values for each field, so that if the satellite signal falls on that part of
the antenna, it is modified according to the settings for that field. As the satellites and antenna move, the
signals will fall upon different parts of the antenna, and will be adjusted accordingly.
Similarly, in the context of Reflection Pattern Multipath, the settings are attenuation and delay. If you specify
a Reflection Pattern Multipath on SV12 for example, then an echo signal is generated according to the arrival
vector of the signal for this satellite relative to the vehicle’s reflection pattern, and the appropriate delay and
attenuation values are applied. This does not imply that the multipath signal comes from the same direction
as the LOS, but that this LOS gives a reflection with these characteristics. The LOS will be unaffected. As the
antenna and satellites move, multipath signals will be varied as the LOS moves with respect to the reflection
pattern. This method can be useful where the source of the multipath signals is predominantly from the host
vehicle. The receiver antenna pattern can be used to attenuate signals which are blocked by parts of the
vehicle structure, and the reflection pattern used to give consistent changes in multipath signals as the
vehicle changes its orientation. Another benefit is that exactly the same multipath signals will be generated
at exactly the same times when the scenario is rewound and re-run. This repeatability is not possible with
‘live-sky’ testing. It is sensible to define only one multipath signal for each LOS using this model.
7.7. Legendre Multipath
This model enables you to specify multipath signals using a fifth-order Legendre Polynomial, for the relative
amplitude and delay of the multipath signal. This is typically used to model multipath signals in a fairly static
environment, with gradually changing multipath characteristics. The advantage of this model is that the same
polynomial coefficients can be used over any period of time, so the characteristics of the multipath signal are
Simulating Multipath
54
always kept within the same bounds. In this model, the reflected signals are not particularly representative of
the relative geometry of the satellites & the receiver, but give a typical effect. The more multipaths defined, the
more complex the interference.
TThe polynomials used are:-
R(t') = A
0
P
0
(t') + A
1
P
1
(t') + A
2
P
2
(t') + A
3
P
3
(t') + A
4
P
4
(t') + A
5
P
5
(t')
τ (t') = D
0
P
0
(t') + D
1
P
1
(t') + D
2
P
2
(t') + D
3
P
3
(t') + D
4
P
4
(t') + D
5
P
5
(t')
Where:
R(t') = Relative amplitude of the reflected signal (with respect to the direct signal), expressed as a ratio.
Limited to the range 0 to 1.
τ (t') = Delay of the multipath signal relative to the direct signal (seconds), and:
t' = Normalised time = 2(t - t
0
)/T - 1
t = Time into simulation (seconds).
t
0
= Time into scenario at which to start generation of the multipath signal (seconds).
T = Duration of the multipath signal (seconds).
P
i
(t') = Legendre polynomial of i'th order (i = 0 to 5):
P
0
(t') = 1
P
1
(t') = t'
P
2
(t') = 1.5t'
2
- 0.5
P
3
(t') = 2.5t'
3
- 1.5t'
P
4
(t') = 4.375t'
4
- 3.75t'
2
+ 0.375
P
5
(t') = 7.875t'
5
- 8.75t'
3
+ 1.875t'
The A
i
and D
i
terms are the multipath coefficients. These are in the i'th coefficients of the expansion of the
relative amplitude and delay functions (respectively) in terms of Legendre polynomials, determined using the
following equations, for known R(t') and T(t') profiles.
For each Legendre multipath, you must enter values for the following polynomial coefficients in the
Manual multipath settings dialog:
A0 to A5 - coefficients A
0
to A
5
in the Legendre polynomial for R(t').
D0 to D5 - coefficients D
0
to D
5
in the Legendre polynomial for D(t').
Duration (s) - the period of the Legendre cycle. It is the period between which the echo is modelled. Once a
period has expired the echo pattern is continually repeated.
Successive periods are images of the first period, for example:
You define the first period to be T0 b2rightT1
T1 b2rightT2 is identical to T0 b2rightT1
T2 b2rightT3 is identical to T0 b2rightT1
T3 b2rightT4 is identical to T0 b2rightT1
Figure 11 shows the Legendre Multipath settings window.
Simulating Multipath
55
Figure 11 Legendre Multipath settings window
7.8. Polynomial Multipath
The Polynomial Multipath model is similar in application to the Legendre method. In this case, the
polynomial coefficients may be more intuitively defined, but the corresponding disadvantage is that the
multipath profile is no longer bounded, so for different durations, the coefficients may need to be revised to
prevent un-realistic multipath offsets being applied.
In the Polynomial multipath model, the following functions represent the relative amplitude and delay of the
multipath signal:
RelAmp = a
0
+ a
1
t+ a
2
t
2
+ a
3
t
3
+ a
4
t
4
+ a
5
t
5
Delay = d
0
+ d
1
t+ d
2
t
2
+ d
3
t
3
+ d
4
t
4
+ d
5
t
5
Where:
RelAmp = Relative amplitude of the reflected signal (with respect to the direct signal), expressed as a ratio,
limited to the range 0 to 1.
Alternatively, the relative amplitude in dB, dB
rel
, is -20 x log
10
(RelAmp).
Delay = Delay of the multipath signal relative to the direct signal, seconds
t = seconds
For each Polynomial multipath, you must enter values for the following polynomial coefficients in the Manual
multipath settings dialog:
A1 to A5 - coefficient a
0
to a
5
in the polynomial for RelAmp.
D1 to D5 - coefficient d
0
to d
5
in the polynomial for Delay.
Duration (s) - the period of the polynomial cycle. It is the period between which the echo is modelled and
prevents the echo going to infinity. Once a period has expired the echo pattern is continually repeated.
Successive periods are mirror images of the first period, for example:
You define the first period to be T0 b2rightT1
Simulating Multipath
56
T1 b2rightT2 is identical to T1 b2rightT0
T2 b2rightT3 is identical to T0 b2rightT1
T3 b2rightT4 is identical to T1 b2rightT0
Figure 12 shows the Polynomial Multipath settings window.
Figure 12 Polynomial Multipath settings window
7.9. Sinusoidal Multipath
This model allows you to apply a sinusoidal variation to the delay and amplitude of a multipath sigwith the
Legendre and Polynomial models, this method simulates a representative effect for the multipath signals,
rather than being based on the vehicle and satellite geometry. This method has
advantage that it gives a time-varying multipath signal which is well bounded and easily defined. For each
Sinusoidal multipath, you Manual multipath settings dialog:
Attenuation Peak (dB) – The min and max peak levels of the attenuation of the sinusoid
Attenuation Freq (Hz) – The frequency of the sinusoidal variation of the multipath
Attenuation Phase (deg) – The start phase of the attenuation of the sinusoid.
Attenuation Bias / offset – The offset between the sinusoid and the LOS signal level.
Delay Peak (ns) – The peak offset delay to the sinusoid.
Delay Freq (ns) – The frequency of the offset delay to the sinusoid.
Delay Phase – The phase of the offset delay to the sinusoid.
Delay Bias / offset – The offset delay to the sinusoid.
The representation of the attenuation parameters is shown in Figure 13
Simulating Multipath
57
Figure 13 Sinusoidal Multipath attenuation parameters
Figure 14 shows the settings window for Sinusoidal Multipath parameters
Figure 14 Sinusoidal Multipath settings window
7.10. Land Mobile Multipath (LMM)
The Land Mobile Multipath model was developed to fulfil the need to simulate the signal environment effects
experienced by a portable device (such as a mobile phone). The multipath models so far discussed are
analytical in their approach, which could present a significant challenge to the mobile phone tester, as such
tests per handset can number many hundreds.
The LMM model allows you to automatically define the signal conditions through selection from a database
of pre-defined environments for each test. The analytical data relating to the delay and amplitude variation
associated with the LOS signals and the multipath reflections are replaced with statistical models commonly
used in laboratory testing of wireless communication equipment, together with a bespoke channel allocation
algorithm for management of the simulator hardware. This allows the following effects to be realised:
Simulating Multipath
58
a73
Direct LOS signals with Rician fading
a73
Reflections (echoes) with Rayleigh fading, power decay and exponential delay
a73
Deep fading of echoes, giving a carrier Doppler offset
The relative numbers of the direct and reflected signals are determined using a satellite visibility category
mask, which uses the azimuth and elevation of the LOS signal.
Reference 5 gives an in-depth description of the approach taken in developing the LMM model.
The LMM model is enabled in SimGEN in a different way to the other models described in this note. It is only
available for use with the Static Vehicle model, and is not available via the Channel Assignment settings
window as described in section 7.2. You can also use User Actions and there is a SimREMOTE command
‘LMM_SELECT’ that allows you to define the LMM environment category mask. You can also use these
methods to change the category mask settings while the scenario is running. See Reference 4 for more details
of the remote command.
To enable LMM, select Options, and tick Land mobile multipath file to include the Land Mobile Multipath
model in the scenario. The Active Configuration area displays the selected Active multipath environment and
Active multipath category mask. The current selections define the environment and mask that apply at the
start of the scenario. Select the Environment editor, or Category mask editor, to view or edit the settings.
Environment Editor
The Environment editor is used to define the characteristics of the Rician and Rayleigh models as a function
of satellite elevation. The operation of the multipath model is controlled by the contents of a number of look-
up tables, driven by satellite elevation angle and satellite selection interval.
Figure 15 shows the Environment editor window.
Figure 15 LMM Environment Editor window
Simulating Multipath
59
The Rician, Rayleigh and Deep Fade model parameters are manually entered in the corresponding boxes.
These models are described as follows:
Rician Fading Model
The Rician model is used to describe the fading on line-of-sight signals.
where
v is the received signal amplitude relative to the direct path.
K is the ratio of direct to multipath power received and is a constant.
I
0
is the 0th order modified Bessel function of the first kind.
Rayleigh Fading Model
A modified Rayleigh model is used to describe the fading on echo channels. There is a deterministic mean
power function, an amplitude noise function (Rayleigh) and a delay function.
The deterministic mean power reduction in addition to Rayleigh noise, is given by
where P
h
(0) and d are provided by a look-up table, and τ = the delay of the echo signal
The amplitude noise on the echo channel, determined on every user defined iteration period, is randomly
calculated from a Rayleigh distribution given by:
The user can define the iteration period (minimum 10ms with a resolution of 10ms). It is listed as Power level
update interval in the land mobile multipath environment editor.
The delay on the echo channel is calculated at random with an exponential distribution:
where b is taken from a look-up table. An upper limit is imposed as determined by the Maximum Near Echo
Delay parameter in the land mobile multipath environment editor window. When the satellite is unchanged
and satellite position modelling not enabled, the delay remains fixed.
Deep Fade Model
On all echoes that are not the primary echo, a carrier Doppler offset is applied:
Where:
ψ is the conversion factor from m/s to offset rate
v is the velocity being emulated, (listed as User velocity value in the land mobile environment editor)
a
e
is the elevation angle of the satellite
B is the bias value for zero speed (listed as Zero speed offset in the land mobile environment editor).
Simulating Multipath
60
Category Mask Editor
You can use the Category Mask Editor to define a mask which is applied over the simulated antenna. It is
similar to the Antenna Pattern editor described in section 7.6, in that it represents the receiver’s view of the
sky as an array of azimuth and elevation. It allows you to define the signal-affecting properties of each
portion of the ‘sky view’ as one of the following four categories. You can apply each of these categories
independently for different test cases. The signal arrival angle is resolved into satellite elevation and azimuth
in 5-degree increments for positive elevations only. The reference frame is local geographic, and the
orientation of the hemisphere created may be rotated in the azimuth plane:
a73
Category A – Complete obscuration.
Satellites arriving at these segments are not simulated at all and hence this category represents
a visibility mask. All satellites with elevation angles less than 5 degrees are automatically
excluded.
Segments would be allocated with this category to simulate obstructions at low
elevation angles at particular azimuth angles, such as adjacent buildings, or at high elevations
to simulate the case for a user positioned within a tall building.
Use of these segments maximises use of the available channels for meaningful signal
simulation.
a73
Category B – LOS only
Satellites arriving at these segments are simulated with a line-of-sight (LOS) signal only. These
signals represent signals that are generally unobstructed and not subject to reflections.
Satellites within category B suffer Rician fading.
a73
Category C – LOS + Echoes
Satellites arriving at these segments are simulated as a LOS plus echoes, depending upon the
number of channels available. These signals represent unobstructed signals that are subject to
reflections. Satellites within category C suffer Rician fading on the LOS channel and modified
Rayleigh fading on the echoes.
a73
Category D – Echoes only
Satellites arriving at these segments are simulated as echoes only (the LOS signals are
obstructed), depending upon the number of channels available. Satellites within category D
have modified Rayleigh fading applied for the echoes.
You can create representative environments surrounding the receiver antenna. Figure 16 shows a simple
urban environment where three buildings of different height are surrounding the receiver’s antenna. Four
masks are present by default; Default, Urban Canyon, Trees, and Highway Flyover. You can make copies of
these and edit and save them as user-defined environments.
Simulating Multipath
61
Figure 16 Land Mobile multipath Category Mask Editor
7.11. Fader Multipath
The implementation of the multipath models so far described is accomplished by assigning an independent
simulator hardware channel to each multipath echo signal (As highlighted in section 7.1).. The compromises
made are also discussed. Spirent’s Fader Multipath implementations use a different approach, where you can
simulate up to four multipath signals for each single simulator hardware channel. Digital replica ‘sub-
channels’ are created in the signal generator FPGAs, and the level, delay and phase of each can be
independently defined. The Fader Multipath model is currently only available via a SimREMOTE command and
is not available on all systems. Reference 4 has more information on this model.
8. Conclusions
This application note has introduces the subject of multipath in the context of GNSS. It presents the various
multipath models included in Spirent’s SimGEN simulator control software. These models offer the receiver tester
a range of methods for simulating multipath conditions representative of different situations, and simulating
multipath signals in an analytical way. It also presents the test methodology for each model.
9. Referenced Documents
1. Mitigating Short-Delay Multipath: a Promising New Technique [Sleewsegen, Boon, Septentrio Satellite
Navigation]
2. Understanding GPS – Principles & Applications, [E. Kaplan, C. Hegarty, 2nd Ed, 2006]
3. Global Positioning System – Signals, Measurements & Performance [P. Misra, P. Eng, 2004]
4. DGP792AAA SimREMOTE User Manual (and ICD) [Spirent]
5. Proposed Models and Methodologies for Verification Testing of AGPS-Equipped Cellular Mobile Phones in the
Laboratory [P. Boulton, A. G. Read Et. Al]
62
Simulating Multipath
10. Definition of Terms
3GPP – 3rd Generation Partnership Project
C/A code – Coarse Acquisition code used by Standard-service GPS receivers
Chip – the time between transitions in the C/A code (not referred to as a ‘bit’ because the code does not
carry information)
DGPS – Differential GPS
GNSS – Global Satellite Navigation System
LOS – Line of Sight
PRN – Pseudo-Random Number
PVT – Position, Velocity, Time
Scenario – In this context, a GNSS simulation running on either SimGEN or SimPLEX simulator control software.
SV – GPS Satellite Vehicle
WGS-84 – World Geodetic Survey 1984
11. Further Information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Visit www.spirent.com/positioning, or www.spirent.com and click the Satellite
Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies, which can be found by logging into the Support website:
www.positioningtechnology.co.uk/support
Simulating Multipath
63
64
Using receiver NMEA data in a simulator test scenario
Using receiver NMEA data in a simulator test scenario
Application Note DAN007-TM Issue 1-01
65
Table of contents
1 Audience
2 Introduction
3 RF Simulation
3.1 Typical GPS Simulators
4 NMEA data
4.1 Capturing and using NMEA in a simulator scenario
4.1.1 Capturing NMEA data
4.1.2 SimGEN’s NMEA data to motion conversion utility
4.1.3 Points to note with recorded NMEA
5 Conclusion
6 Referenced Documents
7 Definition of Terms
8 Further Information
Using receiver NMEA data in a simulator test scenario
66
1. Audience
This Application Note is for users of Spirent simulators who are designing, developing, integrating and testing
GNSS receivers or systems, and need to ensure their products will perform in the intended application.
Spirent recommends you have a basic understanding of satellite navigation principles and RF simulation as a test
method and the use of Spirent’s SimGEN and SimPLEX45 simulator control software. See reference 2 and 3.
2. Introduction
There is a steady growth in the use of GNSS navigation systems in many existing and new markets.
The increasing use of GNSS brings an increasing reliance on the technology. Individuals, businesses,
organisations are relying on the technology for anything from personal recreation and safety to commercial
advantage. With this in mind, it is important for designers, manufacturers and consumers of these products to
understand what to expect from GNSS systems, which requires an understanding of the limitations, problems and
test requirements of what can often be a fragile, prone to error, and easily disabled technology.
This application note explains how the use of a GNSS simulator can drastically reduce test times associated with
performing ‘real-world’ drive testing. Taking a receiver into the open, subjecting it to dynamic motion while
navigating from real GNSS signals, recording the NMEA data and analysing the results takes time, but continual
repeating of this process takes significantly longer, and in almost all cases places a large burden on the
associated project time and budget. In addition to this, test conditions on subsequent re-runs can never be
faithfully repeated and often provides data of little use to the design optimisation and iteration process.
A test methodology is described that takes a file of recorded receiver NMEA data and converts it into a motion
trajectory file allowing a re-run of the original navigation sequence to be made, which can then be repeated
exactly, time and again. It also shows how satellite visibility from the NMEA’s GSV message can be used to
control power of the simulated satellites, so replicating the signal obscuration experienced by the receiver when
it logged the data.
3. RF Simulation
An RF Constellation Simulator reproduces the environment of a GNSS receiver on a dynamic platform by
modelling the vehicle and satellite motion, signal characteristics, atmospheric and other effects, so that the
receiver will actually navigate, in the lab, according to the parameters of the test scenario.
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full richness
of real world conditions. A common misconception is the need to exactly replicate real world conditions for a
GNSS test to be valid. However, application of representative effects via simulation is proven (over some 25 years
of testing) to exercise receivers and adequately identify their limitations allowing for design centring and
optimisation. More importantly, it gives complete repeatability, control and exact knowledge – down to bit level –
of the signal stimulating the receiver. This is not possible when using real GNSS signals for test purposes. We
should look upon simulator testing as representing the real world, rather than replicating it. Continued,
successful deployment of receiver designs in many applications proves that the simulators being used for their
development and verification are accurate in their implementation of the GNSS environment.
Figure 1 shows the concept of simulation (Using a Spirent GSS6560 simulator)
Using receiver NMEA data in a simulator test scenario
67
Using receiver NMEA data in a simulator test scenario
Figure 1 RF Simulation Flow
3.1 Typical GPS Simulators
All the test methodologies discussed in this Application Note can be performed using any of the multi-
channel simulators in Spirent’s range that are controlled by Spirent’s SimGEN or SimPLEX45 software. For
further information on Spirent’s range of Simulators, contact your local Spirent representative, or visit
www.spirent.com/positioning, or www.spirent.com and click the Satellite Navigation link.
4 NMEA data
The National Marine Electronics Association is a non-profit US organisation that has developed a specification
called NMEA-0183 that defines the interface between various pieces of marine electronic equipment. The
standard permits marine electronics to send information to computers and to other marine equipment. GPS
receiver communication is also defined in this specification and over time has been adopted as the standard
communication protocol for all commercial GPS receivers, not just ones used in the marine sector.
Under the NMEA-0183 standard, all characters used are printable ASCII text (plus carriage return and line feed).
NMEA-0183 data is sent at 4800 baud. The data is transmitted in the form of "sentences".
Each sentence starts with a "$", a two letter "talker ID", a three-letter "sentence ID", followed by a number of data
fields separated by commas, and terminated by an optional checksum, and a carriage return/line feed. Reference
1 gives the full specification of NMEA message formats for GPS.
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
68
4.1 Capturing and using NMEA in a simulator scenario.
SimGEN gives you the ability to construct a motion trajectory for your simulated vehicle using a suite of
commands that are entered into a file in a sequential manner. These commands are then executed when the
scenario is run, and the simulator dynamically changes the RF signal to represent this motion (in addition to
the modelled satellite motion). This provides a powerful method of stimulating the receiver under test in a
dynamic way. The receiver will navigate in the same way as if it were physically moving. The dynamic
performance of the simulator is such that motion can be generated for any situation from a sub-millimetre
movement to very high dynamics.
There may however be situations where you might want to subject your receiver to motion that represents a
real-life trajectory. This could be a journey along a real road, railway line, flight path, shipping lane or forest
walking trail. Such ‘real’ trajectories are necessary in situations for example, where the receiver being tested
is reporting its position on an electronic map, and so its navigated trajectory must ‘match’ the map database.
With recorded NMEA data, and a simulator you can test a receiver under these conditions.
4.1.1 Capturing NMEA data
Most commercial GNSS receivers have the ability to record to a file, or output NMEA data describing their
navigation state. Using these features you can log the motion that the receiver underwent and use this
information to create a motion file that can be replayed in a simulator scenario.
When recording the data, it is important to ensure that the receiver antenna is located in a position
where it has as good a view of the sky as possible. This will ensure the receiver’s navigation is as
accurate as is possible, given its local operating environment. For example, if you are using an in-car
receiver with an external antenna option, it is always better to use an external antenna mounted on the
roof of the vehicle. If the option exists, you should also set the NMEA message rate o the fastest
available. (normally 1 second, but some receivers have a higher rate). Section 4.1.3 discusses some
other considerations regarding the quality of the captured NMEA data.
4.1.2 SimGEN’s NMEA data to motion conversion utility
This utility is designed to enable you to take logged NMEA data and use the PVT and satellite visibility
information contained within it to re-create motion and signal power variations in a simulator scenario.
The utility exists as part of the standard SimGEN software package. It can be accessed under the ‘Tools >
General Utilities’ menu. Alternatively, it exists as a tool within SimPROCESS, which is a compiled MATLAB
standalone data processing application, also supplied as standard with SimGEN. SimPROCESS is
accessed via the ‘Tools’ menu in SimGEN. Figure 2 shows the NMEA to Motion conversion utility window.
Using receiver NMEA data in a simulator test scenario
69
Figure 2 NMEA to Motion Conversion utility
The utility converts your receiver’s logged file of NMEA GGA messages into a motion file (*.umt) for replay
in SimGEN. The motion file contains motion commands at 100 ms intervals.
Also, the utility can generate a command file that SimGEN will use to control satellite visibility and
receiver power level. It uses satellite information from NMEA GSV messages to replicate the satellite
visibility.
The utility is easy to use by performing the following steps:-
a73
Enter the path of the current scenario in the ‘Directory’ entry box.
a73
Select the location of your recorded NMEA data file.
a73
Specify the desired location for the converted output file (it is normally the scenario folder, but
does not have to be).
a73
If satellite visibility control is required, tick the ‘Enabled’ box and specify the location for the
generated ‘command’ file.
a73
Click the ’Run’ button, the utility processes the data, giving progress information displayed to
the right of the ‘Run’ button.
a73
When done, you can close the utility.
In SimGEN, you can now select and enable the files you have just converted and they will then be used in
the scenario. The steps are shown below. Reference 2 gives detail on how to use SimGEN.
Motion File
a73
On the main GUI page of SimGEN, in the scenario tree, under Vehicle > Motion, right-click on the
‘User Motion File’ and click ‘select’. This brings up the ‘Select file dialog’ window. If you opted to
save the converted file in the current scenario directory, then it will appear at the top of the list
under ‘Files available from the current scenario’
a73
Click on the file, and click ‘Select’
a73
The name of the file you selected (e.g. ‘motion.umt’) now appears in the scenario tree and will
be used when the scenario runs. See Figure 3.
Using receiver NMEA data in a simulator test scenario
70
Using receiver NMEA data in a simulator test scenario
Figure 3 SimGEN scenario file tree
Satellite visibility
If you asked the utility to create a user actions file for satellite visibility from GSV messages, you must
select it in a similar manner to the user motion file.
a73
In the scenario tree, under Options, right-click on the ‘User Actions’ file, and click select. This
brings up the ‘Select file dialog’ window. If you opted to save the converted file in the current
scenario directory, then it will appear at the top of the list under ‘Files available from the current
scenario’
a73
Click on the file, and click ‘Select’
a73
The name of the file you selected (e.g. ‘sat visibility.cmd’) now appears in the scenario tree next
to User Actions file, and will be used when the scenario is run.
The scenario is now set-up to run with motion data from the converted NMEA file and with a user actions
file that will change satellite power levels according to the satellite visibility that was experienced by the
receiver which logged the NMEA data.
The final action you need to take is to ensure that the satellite constellation being used by the simulator
matches the one visible to the receiver when it recorded the NMEA. If this is not done, then the user
action file commanding power changes to satellites will be meaningless, as it will be calling for changes
to satellites that may not be present. (If only motion is used, not satellite visibility, this step is not required).
SimGEN allows you to load a YUMA or SEM formatted almanac which replaces the internal one. GPS
YUMA and SEM almanacs for past dates are available via the United States Coast Guard Navigation
Centre at: www.navcen.uscg.gov/gps/almanacs.htm
To load an almanac that corresponds to the date on which you recorded your NMEA data:
a73
Double-click the ‘Signal Sources file’ under ‘GPS Constellation’ in the scenario file tree. This
brings up the Signal Sources file window.
a73
Under ‘Motion’ in the list on the left, click on ‘Orbits’, this brings up the orbital data for SV1.
a73
At the bottom of the window is a ‘Load YUMA’ and ‘Load SEM’ button. Click on the desired
button, and enter the path for the almanac file you have downloaded from the website.
a73
Click OK.
a73
Click OK in the Signal Sources file window and enter a name (e.g. ‘week 123’) and click OK
71
Figure 4 shows the Orbits page in the Signal Sources File.
Figure 4 Signal Sources Orbits page
You now need to set the start date and time of the scenario to match the date and time that the NMEA
data was recorded. To do this:
a73
Double-click ‘Start Time’ at the top of the scenario file tree. The ‘Start time and duration’ window
pops up, as shown in Figure 5.
a73
Enter the date and time in the appropriate fields. Click OK.
Figure 5 Start Date, time & duration window
When the scenario is started, the simulator will be simulating signals from a constellation that matches
the one seen by the receiver when it underwent the motion recorded as in the NMEA data, including any
obscuration of power level changes experienced by the receiver due to external obstructions.
Using receiver NMEA data in a simulator test scenario
72
4.1.3 Points to note with recorded NMEA
Accuracy
The accuracy of the final motion data used in the SimGEN scenario ultimately depends on the accuracy of
the PVT solution calculated by the receiver when it recorded the original NMEA data. The NMEA to motion
conversion utility faithfully converts the data it is given – including any inherent errors. This is important
when testing devices with ‘snap-to-road’ algorithms. Data with large position errors may, when run in a
test scenario cause problems for a receiver that is supposed to be navigating along a specific route, but
is receiving a signal that makes it navigate along a different, erroneous trajectory.
Sometimes this is beneficial, as the error can be deliberately used to test the ability of the receiver’s map
software to remain snapped to the route while experiencing poor navigation accuracy. In any case, the
accuracy of the NMEA must be understood, and if necessary, any erroneous lines of data deleted or
corrected.
Replication of real-life situations
Re-creating the actual trajectory and satellite visibility may help to re-create a real-life scenario (for
example, one in which a receiver experienced some problems navigating), but it is important to note that
being able to re-produce the trajectory and satellite obscuration is only a partial representation. The
signal environment (multipath, atmosphere and so on) is not recorded in the NMEA data. Therefore, it is
not safe to assume the problem can be replicated using this method alone. This is another example of
how attempting exact replication of real conditions must be done with caution. Representation is very
often better than replication for test purposes, as it allows control and repeatability of effects to meet
test objectives.
5. Conclusion
We have seen that it may, in some instances, be desirable to replicate in a simulator scenario, a real motion
trajectory as travelled by a receiver. This application note has shown how to take the PVT and satellite visibility
information from receiver-logged NMEA data and convert it into a motion file and user actions command-file
respectively, using the supplied utility within SimGEN and use it in a simulator scenario.
It has also explained some of the limitations of this approach where replication of erroneous events is desired,
and why controlled and representative testing is usually a far more beneficial method than exact replication of
the real world.
6. Referenced documents
1. The NMEA 0183 Interface Standard Version 3.01 [National Marine Electronics Association]
2. DGP00686AAA latest Issue SimGEN Software User Manual [Spirent Document]
3. DGP00895AAA latest issue SimPLEX45 Software User Manual [Spirent Document]
7. Definition of Terms
GNSS – Global Navigation Satellite System
GUI – Graphical User interface
NMEA – National Marine Electronics Association
Using receiver NMEA data in a simulator test scenario
73
PVT – Position Velocity and Time solution from a GPS receiver
Scenario – In this context, a GNSS simulation running on either SimGEN or SimPLEX simulator control software.
SEM – Systems Effectiveness Model GPS satellite almanac
SV – GPS Satellite Vehicle
YUMA – GPS Almanac (named after the town of Yuma, Arizona where early receiver tests were carried
out in 1977)
8. Further Information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Visit www.spirent.com/positioning, or www.spirent.com and click the Satellite
Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from other Test Methodologies,
which can be found by logging into the Support website: www.positioningtechnology.co.uk/support.
74
Using receiver NMEA data in a simulator test scenario
Testing GNSS systems for Automotive Applications
Testing GNSS systems for Automotive Applications
Application Note DAN001 Issue 1-02
75
Testing GNSS systems for Automotive Applications
Table of contents
1. Audience
2. Introduction
3. The automotive GNSS environment
3.1. External obscuration
3.2. On-vehicle obscuration
3.3. Multipath
3.4. Signal loss
3.5. Radio frequency Interference
3.6. GNSS system errors
3.7. Receiver errors
3.8. Integrated GNSS / INS navigation systems
3.9. INS errors
4. Simulating the automotive GNSS environment
4.1. Re-producing the effects
4.1.1. External Obscuration
4.1.2. On-vehicle obscuration
4.1.3. Multipath
4.1.4. Signal Loss
4.1.5. Radio Frequency Interference
4.1.6. GNSS + INS
4.1.7. Reproducing real drive tests
5. Conclusions
6. Referenced Documents
7. Glossary of terms
76
1. Audience
This Application Note is for designers, developers, integrators and testers of GNSS receivers or systems, who
need to ensure their products will perform in the automotive environment.
Spirent recommends you have a basic understanding of satellite navigation principles and awareness of RF
simulation as a test method is desirable.
2. Introduction
There is a steady growth in the use of GNSS navigation systems in all areas of the automotive marketplace. A
variety of GNSS receivers, commonly referred to as ‘Sat Nav’ systems, are now found in vehicles used for private
and recreational purposes, as well as commercial and public transport. In some cases, these systems rely solely
on standalone GNSS operation, in other cases they are coupled with an Inertial Navigation System (INS).
The increasing use of GNSS brings an increasing reliance on the technology. Individuals, businesses and
organisations are all relying on the technology for anything from personal pleasure and safety to commercial
advantage. With this in mind, it is important for designers, manufacturers and consumers of these products to
understand what to expect from GNSS systems, which requires an understanding of the limitations and problems
of what can often be a fragile, prone to error, and easily disabled technology.
This application note discusses some of the main sources of error both specific to the automotive environment,
and more generally applicable to GNSS systems. Complementary to this, it demonstrates how Spirent’s range of
GNSS Test Solutions enable the simulation of these conditions in a controlled and repeatable way, allowing a
GNSS receiver and/or GPS + INS system to be properly tested for use in automotive applications.
3. The automotive GNSS environment
A GNSS receiver works best when it has a clear, un-interrupted view of the orbiting satellites transmitting the
ranging and navigation signals. In the automotive environment, this is often not the case, and ranging
measurements to the satellites are affected. As ‘radio ranging’ is the basis of satellite navigation, any
degradation of the ranging measurement will cause degradation in the PVT solution calculated by the receiver.
Various environmental factors contribute to a receiver not being able to receive the necessary signals, generally
referred to as obscuration. The main causes are as below:
3.1. External obscuration
External obscuration can be defined as everything outside the confines of the host vehicle that blocks the
LOS signal, preventing it reaching the receiver’s antenna. The automotive environment presents obscuration
in a number of ways. Some are described as follows:
Roadside buildings
a73
Any structure that is adjacent to the roadway that stands in the way of the receiver’s direct view
of the satellites.
Bridges
a73
Obstruction of the sky occurs progressively as a vehicle passes under a bridge. The duration of
the signal blockage depends on the physical characteristics of the bridge combined with the
speed of the vehicle.
Testing GNSS systems for Automotive Applications
77
Testing GNSS systems for Automotive Applications
Tunnels
a73
We can consider tunnels as an extension of a bridge. However, complete obscuration occurs for
a period of time, and changes in vehicle direction can also occur while the vehicle is in a curved
tunnel.
Underground and multi-storey car parks
a73
Affect a receiver in a similar way to tunnels. Disorientation is often a primary concern,
particularly upon exit from the car park, when a quick navigational decision is required.
Cuttings
a73
Many roads are placed in cuttings, which reduce the visibility of low elevation satellites.
Natural terrain (hills, mountains, valleys, trees and vegetation)
a73
As with the above effects, obscuration is determined by the characteristics of the terrain. Hills,
mountains and valleys block signals as a function of their height or depth. Trees and vegetation
attenuate and block signals according to the type, density and water content of the foliage and
structure of the trunk/branches.
Adjacent and passing vehicles
a73
Very dependant on the relative speed of the vehicles. The obscuration may be momentary, or last
longer (for example a high-sided vehicle passing at a speed that is only slightly higher than the
receiver’s host vehicle)
Highway equipment (street lighting, signs, gantries)
a73
Issues with periodic signal obscuration, causing complex signal disturbance effects.
3.2. On-vehicle obscuration
This is particularly a problem in the case of in-car, dashboard-mounted receivers with no external receive
antenna. The physical structure of the vehicle blocks the signals. Most obvious is any metal area, but features
such as heated front windscreens or metallic window tinting films can render receivers inoperable if their only
view of the sky is through glass equipped with these features.
3.3. Multipath
Multipath usually occurs in conjunction with one or more of the above factors. Receivers track more than one
version of the same signal, each one taking a different path to the receiver (for example: a multi-path). The
additional signals are reflections of the ‘real’ signal from surrounding objects. A receiver can struggle to
discern which signals are real and which are reflected as both look identical in terms of code and frequency.
The result may include distortion of the real correlation peak, fading and phase addition, resulting in a false
correlation of the unwanted multipath signal. The distorted properties of the reflected signal (such as phase
and delay) cause signal tracking problems and positional errors. For more detail see Reference 12.
3.4. Signal loss
Signals passing through materials that attenuate, but do not block them, can cause problems in the reception
of the very low power GNSS signals. Contributors can include tinting film on windows, vegetation and tree
foliage, and certain non-ferrous materials used in motorway sound barriers and car park canopies. A
receiver’s sensitivity performance will dictate its ability to navigate and is a fundamental characteristic that is
relevant to all applications of GNSS receivers.
78
3.5. Radio frequency interference
GNSS signals travel tens of thousands of kilometres before they reach a receiver’s antenna, and, they are very
low in power (typically -120 dBm). They are some 20 dB below the level of background noise, necessitating
the use of signal processing gain (correlators) to extract the signal from the noise. This makes them
particularly vulnerable to interference from other sources of RF energy. Reference 13 discusses vulnerability of
a typical GNSS receiver. Vehicle ignition systems, vehicle electronic and control systems, other
communications devices (for example: mobile phones and PMR radios) can produce spurious RF energy
falling in-band within a GNSS receiver’s RF front end or down-conversion stages. This is unwanted noise, and
is considered an interference signal.
3.6. GNSS system errors
Apart from the effects of the local automotive environment exist errors due to the GNSS system, (satellite
constellation and control/monitoring systems). These are beyond the focus of this application note, which
concentrates the automotive environment. However, they should not be ignored. For more information on
GNSS system errors, and how to simulate them, see Reference 12.
3.7. Receiver errors
Another source of errors can be attributed to the receiver itself.
Modern receivers have multiple digital receiver channels, and with silicon chip integration densities
increasing, more parallel processing is possible, leading to shorter time to first fix performance.
However, with increased processing comes increased noise, New designs are still susceptible to classical
error sources such as LNA noise, PLL/FLL thermal noise, oscillator phase noise and ADC aliasing.
Reference 11 states that an average modern receiver should contribute less than 0.5 m rms error in bias and
less than 0.2 m in noise.
3.8. Integrated GNSS + INS navigation systems
The use of GNSS + INS in automotive navigation systems is increasing, largely due to operational
performance issues caused by some of the errors described above. These errors cannot be completely
eliminated, even with an optimised standalone GNSS receiver. In many systems, primary navigation is based
on signals from existing on-vehicle sensors (odometers, ABS wheel sensors, gyro’s and so on) with GNSS
position, velocity and time information providing a reference or ‘calibration factor’ that regularly corrects the
diverging errors inherent in the INS system.
A classic automotive environment problem is that of a curved road tunnel. GNSS receivers can become
confused when they emerge from a tunnel heading in a different direction to that travelled upon entering the
tunnel. With an INS coupled into the navigation system, information from the wheel sensors or gyroscope,
corrects the heading change in the absence of the GNSS information. Navigation throughout the tunnel and
beyond is maintained, without having to rely solely on the GNSS system which could be trying to correct itself
from the confused state just described. This advantage is also true in other environments, for example
underground car parks.
Testing GNSS systems for Automotive Applications
79
3.9. INS errors
Although a combined GNSS + INS navigation system solves many of the problems that inhibit standalone
GNSS, they are still subject to errors that can corrupt the navigation solution.
This is particularly true in commercial automotive applications, which use cheaper, less accurate devices
instead of the expensive, high accuracy sensors used in the aviation sector. In some cases, wheel sensors
are the sole method of calculating vehicle heading rate, as 3-D gyros are prohibitively expensive. See
Reference 10.
Common examples of errors include:
a73
Wheel slips – pulses from wheel sensors are sent to the navigation system at a particular rate-
per-revolution. If a wheel looses contact with the road and spins, the rate of pulses increases,
and is no longer matched to the physical distance travelled. Introducing an error.
a73
Skidding – When a skid occurs, the wheel slows down, or stops completely, leading to reduced
or no pulses.
a73
Dead-band error – Active wheel speed sensors employ Hall-effect transducers, That have a
minimum speed below which no motion is detected - the so-called ‘dead-band’ (in the order of
3 to 5 kph),The dead band can present real problems in urban areas, where the vehicle is
progressing very slowly in traffic congestion and the navigation system’s ‘dead reckoning’
algorithms are not able to cope with the condition.
a73
Stuck gyroscope – Gyros are mechanical devices and prone to failure or imperfections. Gyro-
compasses output the difference between the fixed gyro heading and the physical vehicle
direction, if however the gyro becomes stuck (due to a failure of the gimbal for example) the
signals fed to the navigation system will be in error.
4. Simulating the automotive GNSS environment
In this section we look at how a GNSS RF Constellation Satellite Simulator enables the simulation of the conditions
we have discussed in a controlled and repeatable way. This allows testing of a GNSS receiver and/or GNSS + INS
system for use in automotive applications. An RF Constellation Simulator reproduces the environment of a GNSS
receiver on a dynamic platform by modelling the vehicle and satellite motion, signal characteristics, atmospheric
and other effects causing the receiver to actually navigate according to the parameters of the test scenario.
We consider the errors highlighted in section 3.1 to 3.5. There is no need to simulate receiver errors as the
receiver is included in the test and will contribute its own real errors. In all cases, we consider simulation of a
Land Vehicle with one GPS antenna receiving GPS L1 C/A code signals using Spirent’s GSS6560 12-channel L1
CA-code GPS/SBAS simulator with SimGEN for Windows™ software. For more information on SimGEN software,
see references 1 and 2, for the GSS6560 see reference 3.
4.1. Reproducing the effects
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full
richness of real world conditions. A common misconception is the need to exactly replicate real world
conditions for a GNSS test to be valid. However, application of representative effects via simulation is proven
(over some 25 years of testing) to exercise receivers and adequately identify their limitations allowing for
design centring and optimisation. More importantly, it gives complete repeatability, control and exact
knowledge down to bit level of the signal stimulating the receiver. This is not possible in the real world.
Testing GNSS systems for Automotive Applications
80
With this in mind, we should look upon simulator testing as representing the real world, rather than
replicating it. Spirent simulators include statistical models enabling simulation of richer multipath
environments, but consideration of these is outside the scope of this document.
Figure 1 shows the concept of simulation, using a GSS6560, L1 C/A code GPS simulator.
Figure 1 RF Simulation Concept
4.1.1. External Obscuration
In this section we consider simulation of physical objects external to the vehicle that obscure the
GNSS signals.
Roadside Buildings and cuttings
Simulation of obscuration due to roadside buildings is possible using the Vertical Planes feature of
Spirent’s SimGEN for Windows
®
software. Vertical Planes allows you to define a series of vertical,
rectangular obstructions or planes to the left and right of the vehicle, relative to the direction of travel.
You define the distance, height and width (defined as duration). Signals will be obscured if the planes
occur in the LOS path between the satellites and the vehicle antenna. Very high planes at a short
distance from the vehicle will obscure more signals than low-height planes at an increased distance from
the vehicle. Vertical Planes are a good way of simulating buildings in an urban canyon environment. You
can increase the complexity of the obscuration by adding more planes with differing proportions. If the
simulation is run at a different time and/or date, different obscuration will be seen, as the satellite
geometry will have changed. Given this, you can build up a series of tests that give a complete ‘picture’
of the obscuration resulting from your set of vertical planes over a 12-hour period (which equates to one
complete orbit for all satellites). Figure 2 shows an illustration of Vertical Planes positioned to the right of
the vehicle (left-side planes omitted for clarity).
Testing GNSS systems for Automotive Applications
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
81
Figure 2 Vertical Planes concept
SimGEN automatically considers the vehicle and satellite motion when determining which signals are
obscured by the planes (and not present on the simulator RF output).
Cuttings can be simulated in a similar way to roadside buildings. Using Vertical Planes, you can replicate
the obscuration of low elevation satellites by specifying a continuous plane either side of the vehicle at a
height and distance that causes the same masking angle as the cutting. Figure 3 shows how two planes
can be defined at left/right distance x and height y to provide the same masking effect as the cutting
profile. The green shaded area indicates no obscuration. The un-shaded area represents obscuration.
Testing GNSS systems for Automotive Applications
82
Testing GNSS systems for Automotive Applications
83
Figure 3 Example of obscuration due to a cutting
Bridges
SimGEN can perform a representative simulation of a bridge, by simply turning off, and then on, all
satellite signals for a certain period of time. The obscuration effect of the bridge is determined by the
length of time the satellites are switched off. It is possible to switch off satellites in real-time, using the
power control window in SimGEN, in a pre-ordered file of commands, or even using a remote command,
if this method is being used to control the simulator.
Tunnels and covered car parks
In much the same way as bridges, tunnels and car parks are simulated by switching off all satellites, but
for a longer period. During the off time, the vehicle may change heading, for example, representing a
curved tunnel, or a car driving around in an underground car park.
Natural surrounding terrain
SimGEN’s Terrain Obscuration feature allows you to apply omni-directional terrain obscuration with a
profile modelled according to data sets you can modify. The terrain properties have Minimum Height
and Maximum Height fields. The current obstacle height is pseudo-randomly selected between these
limits each time an obstacle width period is completed.
The terrain properties also have both Minimum Width and Maximum Width fields to further improve the
realism of the effects. The obstacle width maps directly to distance travelled by the simulated vehicle
and its period is dictated by vehicle speed.
The essential scheme of this feature is that when a specified trajectory is executed at different speeds,
the obscuration pattern is repeated at an appropriately different rate, simulating a vehicle moving
through the same terrain but at a different speed.
The terrain obscuration is omni-directional, so is at the same distance from the vehicle in all horizontal
directions. It is analogous to a circle, where the vehicle is at the centre, and the terrain is around the
circumference. Regardless of speed or trajectory, the vehicle remains at the centre of the ‘terrain circle’
Figure 4 illustrates this principle and shows the terrain definition in detail for one obstacle width period.
Figure 4 Omnidirectional terrain Obscuration
Testing GNSS systems for Automotive Applications
84
Adjacent and passing vehicles, highway equipment.
These are effects that are simulated using Vertical Planes. While the exact effect of an adjacent vehicle
approaching, passing and receding, or passing street lights/sign gantries is not modelled precisely, a
representative effect is applied. As already stated, exact replication is not necessary in order to ‘exercise’
the receiver appropriately, and determine its limitations.
For a passing vehicle such as a high-sided goods vehicle, you simply set up a vertical plane with a
suitable height and distance offset. Equally, for highway equipment, you set up a vertical plane with the
appropriate characteristics representing the object’s physical form.
4.1.2. On-vehicle obscuration
So far we have considered physical obstructions existing externally to the host vehicle, that are changing
as a function of vehicle motion. On-vehicle obscuration is, in almost all cases fixed and does not vary
with vehicle motion. With this in mind, the best way of simulating such effects is by using SimGEN’s
Antenna Pattern features. The simulator considers the receiver’s antenna as the point at which signals
are modelled. All pseudoranges, power, signals types, delays, motion and other effects are referenced to
this point. The electrical properties of the antenna are most obviously and appropriately defined by its
antenna pattern, but in this case so too are the fixed physical obscuration properties of the immediate
environment surrounding the antenna like the vehicle body. The orientation of the antenna pattern is
always fixed with respect to the orientation of the vehicle, just as the GNSS receiver’s antenna is fixed to
the vehicle.
The Antenna Pattern Editor allows you to define the signal power level attenuation and phase delay for
elevations of +90 to -90 for the full 360 degrees of azimuth around the antenna. The resolution can be as
fine as 1 degree x 1 degree, allowing you to model the obscuration created by the vehicle’s bodywork
(doors, door pillars, roof etc.) and to specify areas where the antenna has a view of the sky (windows,
windscreen, sun roof) Attenuation due to window tinting or de-mister/heater elements can also be
factored in.
Figure 5 shows the Antenna Gain Pattern Editor with a simple representation of masking that might be
experienced by an in-car dashboard mounted GNSS receiver.
Figure 5 Antenna Pattern Editor
Testing GNSS systems for Automotive Applications
85
4.1.3. Multipath
Simulation of multipath effects is possible in a number of ways using SimGEN. Some advanced
techniques enable complex multipath to be created.
SimGEN allows you to create the following types of multipath
a73
Fixed offset multipath
a73
Ground reflection multipath
a73
Doppler offset multipath
a73
Reflection Pattern multipath
a73
Vertical Plane multipath
a73
Polynomial multipath
a73
Legendre multipath
a73
Sinusoidal multipath
a73
Land mobile multipath
We will briefly consider two of these types here; Fixed Offset Multipath and Vertical Plane Multipath.
Reference 8 looks in more detail at simulating multipath types.
Fixed Offset Multipath
This is the simplest method of simulating a multipath signal. For a given satellite, it allows you to define
an exact copy of the LOS signal from that satellite. It allows you to specify both a range offset in metres
and attenuation in dB with respect to the LOS. The simulator will then, using a separate hardware
channel, create this signal. The range offset is always positive, representing the multipath signal having
travelled a longer path to the receiver than the LOS. The level can only be equal or lower power compared
to the LOS, representing reflection loss experienced by the multipath signal.
Using User Actions, you can define a Fixed Offset Multipath(s) either in real time using the GUI or remote
control, or prior to the scenario run. User Actions is a file of pre-scripted commands executed at set
times in the scenario. A receiver without multipath mitigation trying to track both signals will not be able
to determine which one is the real signal, and will generate a range measurement error. You can then
determine the receiver’s multipath performance by - for example – lowering the power of the multipath
until the correlator for that channel stops trying to track the unwanted signal.
Vertical Plane Multipath
We have already seen how SimGEN’s Vertical Planes feature is useful for simulating the effects we have
discussed, along with the associated multipath capability. Vertical Plane Multipath adds to the
obscuration capabilities by allowing the geometric modelling of satellite signal reflections from the
surfaces of the planes, that represent buildings in an urban environment. For pre-determined multipath
signals, SimGEN calculates whether a reflection is possible based on the relative geometry of the
selected satellites, vehicle and reflecting surfaces. Depending on this geometry, the receiver’s antenna
may ‘see’ just the LOS signal, LOS and multipath, just the multipath or no signals at all. With more
complex planes and vehicle motion, more complex multipath will result. The key point is that all signals
are calculated and therefore quantified. The combination of signals, however complex, will be repeated
exactly run after run. Figure 6 shows an example of Vertical Plane Multipath.
Testing GNSS systems for Automotive Applications
86
Testing GNSS systems for Automotive Applications
87
Figure 6 Vertical Plane Multipath
4.1.4. Signal Loss
The sensitivity of the GNSS receiver will determine how well it can track satellite signals. Very sensitive
receivers will be able to track attenuated signals better than ones with poor sensitivity.
Generally, there are two parameters of concern: Acquisition Sensitivity and Tracking Sensitivity.
a73
Acquisition Sensitivity is the power level at which the receiver can recognise the signal as a
GNSS signal within the noise (That is recognise the code).
a73
Tracking Sensitivity is the power level at which the receiver is able to track the signal and
determine the satellites azimuth and elevation. In practice, this is usually a lower level than the
Acquisition Sensitivity.
SimGEN allows you to control the power level of the simulated signal to a high degree of resolution and
over a wide dynamic range.
Power control can be carried out either in real-time while the scenario is running, or using a pre-scripted
set of commands. Real-time control can be applied using the SimGEN GUI or remote commands (if the
simulator is being controlled by a remote system)
It is possible to control the power independently on individual satellites, or on all satellites. Level can be
displayed as absolute power, or relative to a reference. The resolution of power control (for the GSS6560
simulator) is very fine, being 0.1 dB over the range -130 dBm +15 dB, -20 dB.
This fine control allows you to accurately test a receiver’s acquisition sensitivity and tracking sensitivity
as well as other fundamental parameters such as TTFF in cold, warm and hot start conditions. For further
reading on the subject of fundamental receiver performance characterisation, see reference 9.
We have already seen how the Antenna Pattern feature can be used to simulate obscuration and signal
attenuation due to the vehicle. It is also useful for simulating signal attenuation due to external objects.
Because SimGEN allows definition of up to four different antenna patterns, it is possible to take the
baseline pattern that includes the on-vehicle obstruction, and add extra attenuation at certain elevations
and azimuths to simulate, for example high-sided motorway sound barriers of the type found adjacent to
primary routes through urban areas. You can instruct SimGEN to switch to the modified pattern and
switch back to the baseline pattern at discrete times in the scenario.
Figure 7 shows the concept of signal attenuation caused by motorway sound barriers and how the
barriers are represented by an antenna pattern.
Figure 7 Signal Attenuation and associated pattern
4.1.5. Radio Frequency Interference
Spirent’s GSS6560 and GSS77xx/78xx and 79xx series of simulators have an RF ‘Jammer’ input port that
allows you to inject an external RF signal into the main GNSS signal path in a controlled way using a
directional coupler inside the simulator.
Depending on the characteristics of the interference signal, you will be able to stop the receiver from
navigating correctly. As we have seen in section 3.5, a relatively small interfering signal will stop a
commercial GNSS receiver from working.
A signal injected from a third-party signal generator would not be coherent with the simulator’s GNSS
signal. However, an Interference Simulation System option (GSS4765) is available for GSS6560 and
GSS77/78/79xx series simulators. This allows specific signal generators to be controlled by SimGEN in
either a coherent or non-coherent way, with a variety of signal modulation types, and with modelled
power, which simulates the relative distance effects of the interference source with respect to the
simulated GNSS position.
Testing GNSS systems for Automotive Applications
88
For more information regarding the GSS4765 interference simulation option, see reference 4.
Figure 8 shows the concept of injecting an interference signal into the simulator.
Figure 8 Interference signal injection concept
4.1.6. GNSS + INS
Spirent Simulators that are controlled by SimGEN have an optional capability called SimAUTO. This
option provides the ability to simulate signals that would normally come from dead-reckoning vehicle
sensors.
SimAUTO comprises of software features in SimGEN and Digital and Analogue IO cards fitted to the
SimGEN host PC. Signal and data cable sets are also provided.
SimAUTO has the ability to generate simulated signals for the following parameters:
a73
Vehicle Heading Rate - This bipolar analogue voltage output can be used to simulate the output
of a Rate Gyro. The voltage of the signal is proportional to the angular rate at which the vehicle
heading is changing.
a73
Vehicle Absolute Heading - This bipolar analogue voltage output can be used to simulate the
output of a gyro or compass. The voltage of the signal equates to the vehicle heading.
Testing GNSS systems for Automotive Applications
89
a73
Turntable Control - As an alternative to emulating sensor outputs, and with suitable safety
precautions taken, built in sensors may be stimulated on a rate table. SimAUTO supports this
application with a suite of calibration procedures to aid in the determination of the appropriate
scale factors and DC offsets. Analogue voltage signals representing turntable speed and
positions are also provided.
a73
Vehicle Speed and Direction - Seven digital outputs are allocated to the simulation of vehicle
speed, four of which can be directly mapped to represent independent wheel speed sensors.
a73
Digital Speed Pulses - Seven digital outputs are allocated to the simulation of vehicle speed,
four of which can be directly mapped to represent independent wheel speed sensors. Table 1
shows the mapping of the seven outputs.
The signals presented are square waves (50% duty cycle) where the frequency is proportional to the
vehicle speed and a user-specified scaling factor. A separate, independent scale factor can be specified
for each of the seven signals though the four wheel sensor outputs would normally use a common scale
factor.
Output Signal
1 Vehicle Centre speed.
2 Front Wheel Odometer (speed calculated as average of the 2 front wheels)
3 Rear Wheel Odometer (speed calculated as average of the 2 rear wheels)
4 Front left wheel speed
5 Front right wheel speed
6 Rear left wheel speed
7 Rear right wheel speed
Table 1 Speed sensor output allocation
SimAUTO is capable of simulating various ‘events’ which cause a disturbance or error on the signals.
a73
Wheel Speed Events – You may simulate zero wheel speed, such as during a skid where one or
more wheels lock up. Faster or slower wheel speed, such as occurs during a wheel slip or partial
skid. Algorithmic errors, simulating randomised and systematic errors defined by a formula.
a73
Gyroscope Events – You may simulate a stuck gyro, randomised gyro noise and giro bias in
sympathy with a temperature ramp or fixed value.
a73
CAN-Bus Messages – SimAUTO can generate CAN messages consistent with modelled sensor
behaviour. Spirent can modify these to your requirements.
Figure 9 gives an overall schematic showing the principle of SimAUTO’s operation in conjunction with the
standard SimGEN + RF Simulator system.
Testing GNSS systems for Automotive Applications
90
Figure 9 SimAUTO operational overview
4.1.7. Reproducing real drive tests
We have seen how powerful a simulator can be in allowing you to define representative tests to simulate
many different conditions. However, a standard SimGEN application allows you to take data from real
field tests and convert it into a motion file, that is used to simulate the vehicle motion trajectory. Without
leaving the lab you can reproduce an identical journey. This is a very useful feature that can dramatically
reduce the cost, eliminate the un-repeatability and save the time associated with real drive tests. It also
allows reproduction of signal obscuration through use of appropriate data.
NMEA 0183 messages
Most GNSS receivers output data in the NMEA format for position, velocity, SNR, satellite visibility etc.
This data is used by the receiver’s control software, for example, to provide a navigation solution to a
display. For more information, see the National Marine Electronics Association website: www.nmea.org
NMEA Conversion Utility
NMEA conversion is performed using a tool within the SimGEN application called SimPROCESS
(see reference 1)
The SimPROCESS application is a compiled MATLAB standalone application that uses a full encrypted
component-runtime installation of MATLAB. As such it makes available a very powerful set of data
analysis and visualisation functions free of charge to SimGEN users.
Testing GNSS systems for Automotive Applications
91
SimPROCESS itself should be seen as a software toolbox which uses a standardised user interface for
accessing any number of SimPROCESS tools which will be made available in the future. The NMEA to
motion utility converts your receiver log file containing NMEA GGA messages into a motion file (*.umt) for
replay in SimGEN. The motion file contains motion commands at 100 ms intervals.
The utility also uses satellite CNR data from the NMEA GSV messages to replicate the satellite power
levels as seen at the receiver’s antenna. You can replicate a real drive test, where the receiver is
subjected to obscuration, which will be reflected in the GSV message of the logged data, (and can
therefore be replicated by the simulator).
With this capability, you can replicate any obscuration present on the real route without using SimGEN’s
features.
The limitation of this approach is that the simulated trajectory will not necessarily be exactly the same as
the receiver position when the NMEA data was recorded, this is because it is based on NMEA data
recorded from a real receiver subjected to all the environmental conditions and signal errors already
described. Of course, manual manipulation of the NMEA data to remove obvious gaps or errors is always
possible (and Spirent recommends this approach). However, SimGEN will faithfully convert the data it is
given, regardless of its original accuracy.
The key principle here is the simulation can be repeated time and again. While the data may not
represent the physical route precisely, the repeatability is precise.
In some cases, having inaccurate but repeatable trajectory data is actually beneficial. Many in-car GNSS
systems employ map matching algorithms and snap-to-road features, you can test the robustness of
these features using imperfect trajectory data and subsequent attempts at improving the algorithms can
be re-tested using the same data.
5. Conclusions
This Application Note has explored some of the main problems experienced by GNSS receivers operating in the
automotive environment. It has shown how proper product testing during design, development, integration and
production phases is of paramount importance to prove its suitability for the intended application. This
Application Note has highlighted the ways in which an RF Simulator can readily be used to perform representative
tests addressing each of these problems. By using a simulator you can reproduce the effects exactly either one-
by-one, in any combination or all together with absolute control of the simulation parameters. The approaches
described will maximise test effectiveness and ensure maximum fitness for purpose of the developed product
while minimising your development cycles.
6. Referenced Documents
Unless otherwise stated, reference to the latest issue of each document is inferred.
1. DGP00686AAA SimGEN Software User Manual
2. MS3008 SimGEN for Windows Product Specification
3. MS3003 GSS6560 Multi-Channel GPS-SBAS Product Specification
4. MS3026 Issue GSS4765 Interference Simulation System Product Specification
Testing GNSS systems for Automotive Applications
92
5. MS3023 SimAUTO Product Specification
6. MCD00065AAA SimAUTO data sheet
7. DAN002 Testing GNSS System Errors [Spirent Application Note]
8. DAN004 Simulating Multipath [Spirent Application Note]
9. DAN003 Fundamental GNSS receiver characterisation [Spirent Application Note]
10. Turn Turn Turn, Wheel-speed dead-reckoning for vehicle navigation. [C. Hay, GPS World Oct 2005]
11. Global Positioning System: Theory and Applications [Bradford W. Parkinson, James J. Spilker Jr]
12. Understanding GPS – principles & applications [E. Kaplan, C. Hegarty]
13. Vulnerability assessment of the transportation infrastructure replying on the Global Positioning System
[John A. Volpe, NTSC, Aug 29th, 2001]
7. Glossary of terms
Almanac – Approximate satellite orbit information
CAN Bus – Controller Area Network Bus
Ephemeris – Detailed satellite orbital positional data
GPS – Global Positioning System
GNSS – Global Navigation Satellite System
GUI – Software Graphical User Interface
INS – Inertial Navigation System
IVNS – In-Vehicle Navigation System
LOS– Line of sight
Navigation Data – 50bps data message broadcast by GPS satellites
Pseudorange – Satellite to receiver distance as measured by radio ranging
PVT – Position Velocity & Time
Scenario – A pre-defined test running on SimGEN software
SNR – Signal to Noise ratio, as measured at baseband by a receiver
TTFF – Time To First Fix
8. Glossary of terms
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs. To that end we are actively producing Application Notes and Test Methodologies on a wide
variety of GNSS test subjects. Regularly visit www.spirent.com/positioning, or www.spirent.com and click the
Satellite Navigation link to find the latest articles or ask your Spirent Sales representative for more information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies that can be found by logging into the Support website: www.positioningtechnology.co.uk/support
Testing GNSS systems for Automotive Applications
93
94
Testing GNSS for Railway Applications
Testing GNSS for Railway Applications
Application Note DAN011 Issue 1-01
95
Table of contents
1. Introduction
2. The Environment
3. Using the right system
4. Testing is essential
4.1. Test methodologies
5. Test Standards
6. Example test
6.1. Typical test set-up
6.2. Scenario description
6.3. Alternative methods
7. Pushing the boundaries
8. Next Steps
9. Referenced documents
10. Further information
Testing GNSS for Railway Applications
96
1. Introduction
The use of Global Navigation Satellite Systems (GNSS) in the Railway industry is increasing rapidly. GPS
technology is already being used in several areas, from Fleet Management to Passenger Information Services. In
some countries, GNSS navigation is being considered for use in safety of life applications such as:
a73
PTC (Positive Train Control) on low-density lines, as a supplement, or even a replacement for
conventional line-side signalling and control systems.
a73
Automatic door operation
a73
Train integrity and separation control
a73
On Train monitoring & Recording (OTMR)
a73
Train Protection & Warning Systems (TPWS)
a73
Off-train infrastructure protection (level crossing operation, End of line stop limits)
Two important characteristics for GNSS operating in the railway environment are integrity and availability, both of
the GNSS and of the user equipment. An on-train navigation or control system which is to be relied on for safety,
must operate reliably and with integrity. In addition, the availability and integrity of the GNSS itself must be
quantified and understood. Suitable robustness must be built in, whether in the form of augmentations or other
complimentary navigation sensor inputs. For these and other reasons, proper testing is not only desirable, it is
essential, especially if the test results provide an input to certification of GNSS systems for safety-critical
applications.
This Application Note is for designers, developers, integrators and testers of GNSS receivers or systems, who
need to ensure their products will perform in the intended environment. It also provides key information
regarding the importance of proper testing for those responsible for developing test standards for certification of
GNSS equipment in the railway sector.
Spirent recommends you have a basic understanding of satellite navigation principles and awareness of RF
simulation as a test method is desirable.
2. The Environment
The railway environment is a varied one. In the application of GNSS navigation, it presents many different
conditions. Some of these conditions affect the way navigation works, and in some cases severely limits or even
prevents its use. The primary issue concerns the reception of the line-
of-sight RF signals from the satellites. The amount the reception of
these signals is degraded directly affects the availability of the signal
and the degree of navigational error experienced by the GNSS user.
The main characteristics in a railway environment that are likely to
affect the ability of a given GNSS receiver to receive, process and
resolve the satellite signals - include (among others):
Testing GNSS for Railway Applications
97
Obscuration
The line-of-sight satellite signal path is blocked by physical obstructions such as bridges, tunnels, station roofs
and canopies, steep-sided cuttings, trees, surrounding geographical features, signal gantries, Overhead Line
Equipment, trackside buildings, parts of the railway vehicle, passing or adjacent vehicles etc.
Figure 1 The receiver's view off all but the highest-elevation satellites is severely restricted by deep cuttings
Multipath
The receiver sees a repeat(s) of the direct line-of-sight signal, due to the signal reflecting off the obstructions
listed above. This is complicated by the movement of the train and satellites relative to these objects and each
other, which results in multipath signals with dynamically changing phase and amplitude characteristics. The
combined complex effect of these changes is called often referred to as fading.
Figure 2 Overall roofs such as this at London’s St. Pancras station not only attenuate satellite signals, but the complex metallic
frames that form the structure can also cause multipath problems
Interference
GNSS signals travel tens of thousands of kilometres from the satellites and are extremely low in power
(approximately –120dBm nominal) when they reach the receiver. This makes them particularly vulnerable to
interference from other sources. These sources could include: Overhead Line Equipment, or third-rail power
systems, on-train electrical systems: generators, motors etc. Other radio communication systems, both within the
railway operation and external (TV, mobile phone transmitters) and possibly intentional or un-intentional jamming
of the GNSS signals.
Testing GNSS for Railway Applications
98
Figure 3 Locomotive pantographs can cause high-strength electro magnetic interference, especially when arcing occurs.
Careful positioning of GNSS antennas is important
3. Using the right system
Currently, GPS is the only fully-operational GNSS system that can be effectively used for navigation. GPS, when
working with augmentations such as SBAS and RTCM Differential Corrections, or coupled with an Inertial
Navigation System (INS), can provide fairly repeatable and accurate navigation. However, there are limitations
when it comes to the guarantee of service, and for many applications the lack of integrity presents a problem,
especially where safety critical systems are relying on continuous availability and accuracy. Future GNSS systems,
such as Galileo, will provide (for a fee) signals and services that are guaranteed to operate within a certain
specified performance. At the time of writing, there is much discussion on the certification of these services for
use in different applications. Safety-critical operations in Railway applications are considered to be in the ‘top-
four’ sectors where high-integrity terrestrial navigation is demanded. The other sectors are Maritime, Aviation
and Road.
The other aspect requiring careful consideration is that of the receiving equipment. There are many types of GNSS
receiving equipment available from different manufacturers, and with these many types come varying levels of
performance and suitability for different applications. It is important to ensure the ‘system’ (receiver, antenna,
cabling and interfaces) being used is the best suited and most optimised for the particular application.
For a typical railway environment, the considerations that should be made when selecting a GNSS system could
include:
Performance – How well does the system need to cope with:-
a73
Availability of the signal due to the environment?
a73
Integrity of the signal due to the environment?
a73
The characteristics highlighted in 1?
Standalone or augmented – Is the system independent of other navigational aids, or does it need to be used as
part of another navigation system? (DGPS corrections or inertial sensor inputs for example). Does it require WAAS
or EGNOS capability?
System data outputs – what format does the position-velocity-time information need to be to be used by other
systems, is there compatibility between the interfaces?
Testing GNSS for Railway Applications
99
Maximum separation between antenna and receiver – is the receiver likely to be located far from the receiving
antenna? If so, is the signal loss acceptable? Is the coaxial cable suitable?
Robustness – will the equipment stand up to the environmental conditions it will be subjected to? – Vibration,
heat, dust, rain ingress etc.
4. Testing is essential
With so many variable conditions in which the GNSS system has to work, it is essential that comprehensive
testing is carried out. This gives a measure of how the system will perform when in operation, but the scope of
testing is not limited to this. Testing can be used in a number of ways:
a73
Performance assessment both in nominal and adversarial conditions
a73
System testing from R&D to verification, production and deployment
a73
System or unit calibration
a73
System verification and certification to prescribed standards
a73
Repair and fault diagnosis for equipment in the field
Testing is important, but more important is the right kind of testing – that which is relevant to the particular
application. GNSS system manufacturers will no doubt test their products to ensure they function generically, but
may not test them thoroughly for specific applications.
4.1. Test methodologies
Perhaps the most obvious way to test a GNSS system is to take it into the environment in which it will be used
and try it out. Often called ‘Live-Sky’ or ‘Real-World’ testing. In theory this sounds the most effective way.
However, there are many constraints that rule out the feasibility of this approach. Live sky can never be more
than a ‘quick check’ and should certainly never be adopted as a reliable test method. From the perspective of
a railway application - the following constraints may apply:
a73
Cost – Running test trains is very expensive. The capital cost of non revenue-earning rolling
stock, train crews (driver etc) Running costs (fuel, maintenance, hire of equipment, hire of test
tracks or paths on ordinary lines). While R&D work may be funded at technology concept stage,
equipment manufacturers are unlikely to be able to afford this method on an ongoing basis.
a73
Access – It is often difficult to take possession of a section of busy railway line for the purpose
of running non revenue-earning test trains. Permanent Way possessions are often restricted to
night hours or weekends when there is less traffic. There is often a lot of pre-planning required
that involves other departments or even companies within the railway infrastructure (signalling
staff for example) again; cost is an issue – access charges applied by the network operator is
another example.
a73
Regulations – There are a plethora of regulations that make carrying out tests difficult. Approvals
from the relevant Vehicle Acceptance Bodies (VABs) are necessary for fitment of test equipment
to the railway vehicle. If service rolling-stock is used then access to the equipment while a train
Testing GNSS for Railway Applications
100
is in service may be difficult. The need to use approved personnel to fit the equipment in a way
that will not compromise safety may have to be considered.
a73
Repeatability of the tests – It may only be possible to run a test once, and even if repeat tests
were possible, the conditions will never be the same twice, not least in respect of the GNSS
signals, where the satellite positions (and orbits) will be different, the atmospheric conditions
will be different etc. With regard to the railway vehicle, it is impossible to run the train in exactly
the same way (speed, wheel-slips, braking conditions will always vary)
a73
Integrity of the tests – Live sky testing is, in reality, limited in its worthiness to no more than a
quick confidence check. Testing in relation to qualification, type-approval and certification
activities certainly cannot rely on this kind of testing. These activities demand levels of accuracy,
repeatability and accountability that can only be offered by a test methodology based on
precision test equipment in a well-controlled environment.
The test methodology most suitable in these circumstances is RF Simulation.
Simulation immediately solves the constraints listed above, and provides an effective alternative to many
others. Simulation that involves stimulating the GNSS receiver or system with actual RF signals is the most
effective way of testing. GNSS simulators are fully capable of accurate replication of the signals-in-space
through modelling of the satellite constellation motion and that of the receiver. The RF navigation signals
generated by a GNSS simulator are also fully controllable: for example, satellites can be switched on and off,
power varied and if required, known, controlled errors introduced. This allows receiver deficiencies to be
quickly isolated. Simulation has a number of distinct advantages over other methods, some of the more
obvious benefits are:
a73
Repeatability – The same tests under the same conditions can be repeated again and again –
something that can never be achieved in the real-world test environment. With simulation, you
have complete knowledge of the ‘truth data’ i.e. the bit-by-bit parameters being used to
generate the RF signals. With this, you are therefore able to know exactly what you are
stimulating your receiver with. This level of repeatability is essential for meaningful and reliable
testing of GNSS equipment for railway applications.
a73
Time and Cost effectiveness – As we have seen already, the cost of conducting real field tests, in
a timely and efficient manner with expensive assets on an increasingly crowded railway
infrastructure is high, but is greatly reduced if a simulation test methodology is used. In
comparison, the capital investment in a simulation system is in fact quite low when compared to
the real-world approach, and the initial investment is soon recovered in cost savings. Often,
funding for field trials in the early stages of a research project is available through official
programmes. However, such funding is usually limited and normally disappears once the project
gains commercial momentum. Test campaigns are then influenced by normal business
processes, which will seek to reduce costs.
Testing GNSS for Railway Applications
101
a73
Simplification – In the real-world, the GNSS receiver or system is experiencing many error-
inducing effects simultaneously, so it is very difficult to identify which phenomenon may be
causing the system performance to be degraded. With Simulation you can apply the effects in a
precisely controlled, ordered and accountable way, greatly increasing ease of characterisation of
the GNSS system under test. A common misconception is to assume you need to replicate the
real-world as closely as possible. This would in actual fact reduce the effectiveness of the testing
for the reasons already given. Controlled representation is in fact the method required.
a73
Pushing the limits – In the Real-World, you have no control over the satellites or signals, no
control over the signal conditioners be they atmosphere, multipath, obscuration, satellite errors,
data corruption, and no way of running the test train at higher than permitted line speeds to
enable the dynamic performance of the receiver or system to be tested beyond its normal
operating limits. As such you have no way of building in any system design margins, be they
redundancy, safety or reliability. With Simulation, you are able to control any parameter you wish.
You are able to remove the atmosphere effects, add or remove Multipath and obscuration or test
the receiver under much more controlled dynamic motion than is possible in the real-world.
a73
The only option – In some cases, RF simulation is the only option for testing because the real
GNSS signals do not yet exist. Galileo is an example today, as GPS was in the early 1990s before
full operational status was achieved. Systems and equipment will need to be developed ahead
of the operational of the actual GNSS system, requiring RF simulators capable of producing all
the specified signals.
These are just some of the benefits that can be obtained by using Simulation to test in a way that either
cannot be done, or can only be done with unacceptable measurement uncertainty, timescales or cost in the
real-world.
Table 1 attempts to provide a summary comparison between Real-World and Laboratory test.
Real World Test Laboratory Test
Actual unquantifiable Environment Modelled, representative known environments
Test in nominal use conditions Test nominal and extreme, off-design performance
Different conditions for each test Exactly repeatable
Often takes time and costs too much Generally more efficient
Not reliable for formal certification Quantifiable and certifiable
Table 1 Real-World vs Laboratory simulation summay
Testing GNSS for Railway Applications
102
5. Test Standards
The use of GPS and its limitations as a standalone technology in various safely-critical applications has been well
documented. Where it has been deemed acceptable, comprehensive evaluation of its suitability and performance
has taken place. The result of this has been the issuing of directives by various ‘responsible authorities’ that set
out the Minimum Operational Performance Specifications (MOPS) that navigation equipment being deployed in
the respective applications must meet. International standards organisations have then taken these MOPS and
developed appropriate test standards to allow equipment to be certified for use against the requirements.
Given the facts already highlighted in this Application Note concerning test methodologies and their suitability, it
is important that simulation as a test methodology is understood and adopted in these test standards. This not
only requires an awareness of the philosophy of laboratory simulation, but an understanding of the test methods
and their development, and how to best implement them in the test descriptions within the standards.
The development of Galileo will naturally drive the need for new test standards, and those responsible for their
development will need to understand simulation as a test methodology. Some test standards are already well
advanced, and take full advantage of RF simulation in their test procedures. An example from the maritime sector
is IEC 61108-3 Galileo – Receiver equipment – Performance requirements, methods of testing and required test
results. All the navigation related tests are performed using an RF simulator. Equipment manufacturers are able to
base their development on simulator testing using the same test methodologies that are employed in the test
standards, which ensures their designs are much more likely to meet the requirements.
6. Example test
This chapter describes an example test scenario created using Spirent’s SimGEN for Windows
®
software, which is
designed to test a GNSS receiver in a railway-like RF signal environment. The test scenario enables the
characteristics already described in this Application Note to be applied to a navigation system.
SimGEN is Spirent’s powerful scenario creation and simulation control software. It is designed to operate with a
number of simulator hardware platforms. One such simulator is called the GSS6560.
The GSS6560 is a 12 independent channel (satellite) GPS
L1 C/A code simulator, particularly suited to the
commercial environment. It has complete scenario
generation capability using the SimGEN software that
offers the user class leading accuracy; fidelity and
reliability; full user control of GPS constellation, errors and
atmospheric effects; control of vehicle motion, antenna
modelling. It also supports Space Based Augmentation
System (SBAS) signals
(WAAS/EGNOS/MSAS) as standard.
Testing GNSS for Railway Applications
103
6.1. Typical test set-up
Figure 4 shows a typical receiver test set-up in its basic form. The simulator shown in this example is a
GSS6560.
Figure 4 Typical test set-up
6.2. Scenario description
This scenario example simulates a non-stop express train journey along
the Great Western Main Line from Reading Station, Berkshire to
Paddington Station, West London, UK. The scenario begins on 28th Feb
2007 at 1200. The motion trajectory follows the route of the railway as
defined by the Ordnance Survey 1:50,000 scale map for South East
England (region 2). The speed profile involves a 120 second stationary
period at Reading station, followed by a steadyacceleration to near-
maximum line speed of 123mph followed by a deceleration at the end of the scenario on arrival at London
Paddington station. The scenario demonstrates how navigation degrading effects can be applied without the
need to venture into the real environment to collect data, another key benefit of simulation.
Terrain effects
The following local terrain effects are applied. These effects simulate physical obstruction to the satellite
signals in specific locations as observed from the Ordinance Survey map.
Cuttings are simulated using SimGEN’s Vertical Planes feature. Vertical
Planes aresimulated at 30m Left & Right distance relative to the vehicle,
height 20m, Time of occurrence and duration are varied, and
determined from the map.
Testing GNSS for Railway Applications
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
104
The vertical Planes block the LOS signal path from the satellite to the receiver. SimGEN’s Vertical Plane file
editor is shown in Figure 5. As can be seen, a list of time-ordered planes is displayed in a list on the left side,
the Vertical Plane characteristics are applied using the fields on the right.
Figure 5 SimGEN’s Vertical Plane editor
Stations are also simulated using Vertical Planes at 10m L & R distance,
height 30m, duration – 5 seconds assumed for all stations. As with the
cuttings, the location of each station is determined from the map.
Line-side buildings are simulated using Vertical Planes at varying
distances, heights and durations determined from the map.
Bridges are simulated by switching off all satellites for 1 second when they occur, as
observed from the map.
There is one tunnel (at Ealing, 17 min 42 sec) simulated by switching off all satellites
for 7 seconds. SimGEN’s User Action file is used to define the off an otimes for the
satellites. For each bridge the satellites are switched off and back on again. The User
Action File editor is shown in Figure 6. As with the Vertical Plane editor, a list of
action is displayed on the left, and the command entry is shown on the right.
105
Testing GNSS for Railway Applications
Figure 6 SimGEN's User Action file editor
Terrain Obscuration which is not due to stations, bridges or cuttings, but due to general urban terrain (mainly
multi-storey buildings) is applied using SimGEN’s Terrain Obscuration file editor. The general surrounding
terrain becomes more close-urban after Southall (16 min 14 sec) so at this point Urban-Canyon directional
obscuration is applied (to the end of the scenario). The Terrain Obscuration file editor is shown in Figure 7
Figure 7 SimGEN’s Terrain Obstruction editor
Testing GNSS for Railway Applications
106
On-train obscuration is applied via SimGEN’s Antenna Pattern Editor. The simulated position is on theroof of
the train, so the antenna pattern provides an un-obstructed view of the sky above zero degrees elevation,
and blocks all signals below that elevation, representing the obscuration due to the trainThe Antenna Pattern
Editor is shown in Figure 8. It is a 2-D display of the antenna’s attenuation characteristics over all angles of
elevation and azimuth. Each cell represents one degree of elevation by one degree of azimuth.
Figure 8 SimGEN's Antenna Pattern Editor
Testing GNSS for Railway Applications
A three-dimensional view of the antenna pattern is shown in Figure 9. As can be seen, all signals below zero
degrees elevation will be obscured.
Figure 9 3-D Antenna Pattern view
At the destination (Paddington Station) there is an overall roof (iron girders and glass panels). The effect of
this is simulated by a 6dB reduction in power on all satellites. This is achieved using the User Action File
shown in Figure 6.
107
Testing GNSS for Railway Applications
108
6.3. Alternative methods
The example described in this Application note is just one of the possible methods that can be used to create
the simulator test. This particular test was developed without the need to leave the laboratory at all. In some
cases it may be desirable to use real data. This real data might be actual route trajectory data based on
receiver NMEA data, or obscuration profiling information based on actual video capture techniques whereby
the ‘skyline’ around the train is determined from images, which are then converted into obscuration elevation
angles along the route thereby determining satellite visibility. Examples of this type of data capture include
the PREDISSAT tool developed by the French National Institute for Transport and Safety Research (INRETS) See
Reference 1.
It is possible, with simple manipulation to translate such obscuration data into commands that SimGEN will
then execute to control satellite visibility. Figure 10 illustrates the process.
Huge benefits can be gained from this kind of approach. The main benefit is that only one test run is required
to capture the data – all subsequent testing being carried out on the simulator in the lab, saving significant
time and money, and providing repeatable tests for evaluation of subsequent design iterations.
Figure 10 Capture to simulation process
7. Pushing the boundaries
The methodology discussed in this Application Note goes a long way towards testing a GNSS system in a railway-
like environment, without the expense or time involved in collecting real data. However, with the GNSS simulator
it is possible to add many more characteristics to the simulated signal to further extend the test complexity, once
the initial fundamental performance characteristics of the GNSS equipment are well understood.
The scope of the SimGEN test scenario could easily be extended to include:
Multipath simulation
SimGEN has several ways of applying different multipath signals in a controlled way. Multipath can be applied in
real time while the scenario is running or via pre-scripted commands. Various types of multipath can be applied
and characteristics such as code and carrier phase and attenuation of the signal can be varied.
Interference Simulation
Controlled interference signals can be added to the GNSS test signals using Spirent’s GSS7765 system. The
GSS7765 allows interference with different signal modulation and power characteristics to be applied.
Interference can also be modelled with respect to the proximity of the interferer source and the receiver position
such that the power level of the interfering signal varies appropriately.
109
Testing GNSS for Railway Applications
Navigation system errors outside of the receiver environment (system and satellite errors)
Imperfections in the actual GNSS system were eluded to in the abstract at the beginning of this paper, and these
exist in all GNSS systems. A receiver needs to be able to deal with such imperfections, even if only to detect and
warn of a problem. SimGEN has several ways of adding pre and post parity-checked errors to the navigation
message broadcast by the simulated satellites, satellite clock drift and errors, as well as orbit and ephemeris
errors, both nav-data-declared and un-declared. These can be scripted to occur at specific times, and receiver
behaviour observed for cause and effect appropriately.
Atmospheric conditions (RF signal delay and fading due to the ionosphere and troposphere)
One of the largest randomly varying source errors in any standalone GNSS system comes from the effect of the
atmosphere on GNSS signals. These effects can be modelled in SimGEN to varying degrees by defining the
ionospheric and tropospheric models.
Simulation of augmentation systems
SBAS (WAAS, EGNOS, MSAS) is fully supported by SimGEN and can be added into the test scenario. SBAS
enabled receivers can then be tested fully.
RTCM differential corrections (DGPS) commensurate with the simulated signal can also be output from SimGEN,
and receivers with DGPS data inputs can then be tested.
8.Next Steps
Spirent Communications PLC is the world leader in providing GNSS test solutions. Our experience and pedigree
spans more than 20 years, and our current range of RF Constellation Simulation systems benefit fully from this
heritage. Our solutions and expertise are therefore invaluable to anyone with a GNSS test need.
Spirent offers a comprehensive range of RF satellite signal generators and full-constellation RF simulators for GPS,
Galileo and GLONASS GNSS systems, and we can advise on the most suitable approach you should take to
facilitate the testing required for your application.
Spirent is always keen to work with organisations to help them develop their products and services, and to help
develop the use of GNSS in new and emerging markets.
Examples of where we could work in such a way include:
a73
Evaluation of real-world data with a view to using it to create scenarios for the simulator.
a73
Comparison of field test results with simulated results.
a73
Provide expertise to support standards and certification development for GNSS railway
applications.
We welcome dialogue with interested parties. Please contact us if you are interested in such cooperation.
9. Referenced documents
1. Satellite propagation analysis in a masking environment for GNSS applications [J. Marais, INRETS-LEOST]
Testing GNSS for Railway Applications
110
10. Further information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Please visit www.spirent.com/positioning, or www.spirent.com and click the
Satellite Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more
information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies, which can be found by logging into the Support website:
www.positioningtechnology.co.uk/support
111
Simulating UTC leap second insertion events
Simulating UTC leap second insertion events
Application Note DAN009-TM Issue 1-01
112
Simulating UTC leap second insertion events
Table of contents
1. Audience
2. Introduction
3. RF simulation
4. Typical GPS simulators
5. Time
5.1. GPS time (GPST)
5.2. GPS leap second event implementation in the navigation message
6. Simulating a leap second event
6.1. Navigation data modification
6.1.1. Specifying WNlsf
6.1.2. Specifying of DN
6.1.3. Specification of ΔtLS and ΔtLSF
6.1.4. Example leap second insertion using navigation data modification
6.1.5. Simulating a leap second insertion using GUI data entry
6.1.6. Simulating a leap second insertion using SimGEN’s User Defined Data (UDD) facility
6.1.7. Simulating a leap second insertion using the UDD Global Nav-Data FIle
7. Referenced Documents
8. Further Information
9. Appendix
113
1. Audience
This Application Note is for designers, developers, integrators and testers of GNSS receivers or systems who need
to ensure their products will perform in the intended environment.
Spirent recommends you have a basic understanding of satellite navigation principles and awareness of RF
simulation using Spirent simulators controlled by SimGEN software is desirable.
2. Introduction
There is a steady growth in the use of GNSS navigation systems in new and existing markets. The increasing use
of GNSS brings an increasing reliance on the technology. Individuals, businesses and organisations are relying on
the technology for personal pleasure and safety to commercial advantage. With this in mind, it is important for
designers, manufacturers and consumers of these products to understand what to expect from GNSS systems,
which requires an understanding of their operational characteristics, error sources, limitations, problems and the
environment in which a receiver navigating from their signals is operating.
This Application Note discusses UTC leap second insertion events in relation to the GPS system, why they are
necessary, how they are managed by the system, and how to test a GPS receiver using an RF constellation
Simulator to ensure it handles a leap second insertion event correctly.
3. RF simulation
An RF Constellation Simulator (RFCS) reproduces the environment of a GNSS receiver on a dynamic platform by
modelling vehicle and satellite motion, signal characteristics, atmospheric and other effects, causing the receiver
to actually navigate according to the parameters of the test scenario.
By its very nature, simulation is a representation of the real world. Simulation cannot reproduce the full richness
of real world conditions. A common misconception is the need to exactly replicate real world conditions for a
GNSS test to be valid. However, application of representative effects via simulation is proven (over some 25 years
of testing) to exercise receivers and adequately identify their limitations allowing for design centring and
optimisation. More importantly, it gives complete repeatability, control and exact knowledge – down to bit level –
of the signal stimulating the receiver. This is not possible when using real GNSS signals for test purposes. Also,
testing of a receiver’s ability to handle certain events such as leap second insertions, cannot be accomplished
using real GNSS signals because the events occur rarely and their application certainly cannot be requested for
test purposes!
Figure 1 shows the concept of RF simulation (using a Spirent GSS6560 simulator)
Simulating UTC leap second insertion events
114
Simulating UTC leap second insertion events
Figure 1 shows the concept of RF simulation (using a Spirent GSS6560 simulator)
4. Typical GPS simulators
All the tests discussed in this Application Note can be performed using any of Spirent’s multi-channel simulators
from the GSS6560, GSS77xx and GSS8000 series. SimGEN is the control and scenario definition software for
these simulators. SimGEN can also create scenarios to be run on SimPLEX, which is the scenario replay and
control software for the STR4500 simulator. For further information on Spirent’s range of Simulators, please
contact your local Spirent representative, or visit www.spirent.com/positioning, or www.spirent.com and click the
Satellite Navigation link.
5. Time
Since the introduction in the late 1950s of the first atomic clocks based on the resonance of the caesium atom,
available clock accuracy improved by orders of magnitude. Today, the International Bureau of Weights and
Measures, or Bureau International des Poids et Measures (BIPM), in France is charged with providing the time
standard: Coordinated Universal Time (UTC). The BIPM collects data (interestingly, via GPS in part) from more than
200 atomic clocks and a few primary "absolute" frequency standards from more than 50 institutions around the
world. Once a month, BIPM uses this data to produce the standard international references for frequency and
time, International Atomic Time (TAI) and UTC, which is equal in rate to TAI, but adjusted every so often by an
integer number of seconds to account for variations in the rotation of the Earth.
5.1. GPS time (GPST)
GPST is a composite time scale defined on the basis of measurements from a number of atomic frequency
standards in use at monitoring stations and on-board the satellites. It began on the 6th January 1980, and is
defined in real-time and is continuous (no leap second insertions). GPST is ‘steered’ to within 1 microsecond
of the real-time realisation of UTC which is provided by the United States Naval Observatory (UNSO). In
Control PC
Proprietary
control data
RF signal
generator
RF signals
Device under test
Define:-
Signal Conditions & Errors
Vehicle Location & Motion
Date & Time
Etc..
Run Scenario:-
Change parameters in
real time
Plot and log data:-
For vehicle motion
Signal data
Reciever data
Etc..
115
practice, GPST has been maintained to within approximately 10 nanoseconds of UTC(UNSO). However,
because of its continuity, GPST is a certain number of whole seconds plus a fraction of a microsecond
different to UTC(UNSO). In order for GPS receivers to provide to their users time according to UTC, the current
GPST to UTC(USNO) offset must be declared by the GNSS system. In addition, when the leap second insertion
event occurs and the offset increases, receivers must recognise it and be able to adjust their reported time
accordingly. To enable them to do this, a series of changes occur to the navigation message being broadcast
by the GNSS system. In this Application Note we will consider how GPS implements leap seconds. Other
GNSS systems (such as Galileo) implement them in a similar way. Refer to the relevant system’s SIS-ICD for
details on each specific implementation.
Normally, leap second events occur at midnight on 31st December or 30th June in a given year, however the
GPS SIS-ICD does not specify a particular date on which they may occur, so for the purpose of a receiver test,
we must assume it can happen at any date.
5.2. GPS leap second event implementation in the navigation message
The navigation data message as broadcast by the orbiting satellites is the mechanism used to inform
receivers of a leap second event. The following parameters are relevant to defining a change in the leap
second offset in the navigation data. These parameters are contained in sub frame 4, page 18 of the
navigation data.
a73
WNlsf – Week Number in which the leap second event will occur – Word 9, Bits 9 – 16.
a73
DN – Day Number on which the leap second Change will occur. (Sunday is Day 1) –
Word 9, Bits 17 – 24.
a73
ΔtLS – Current leap seconds offset. – Word 9, Bits 1 – 8
a73
ΔtLSF – Next leap second value (e.g. value at change). Word 10, Bits 1 – 8.
WNlsf and DN effectively define the time the leap second change will occur. For example, assume the current
date is 5th May 2008, this is a Monday, so DN will be 2, and WNlsf will be 454. The leap second change will
occur at the end of this day and will transition from the ΔtLS value to the ΔtLSF value.
The appendix in Section 9 gives the ICD-GPS-200 full definition of UTC
6. Simulating a leap second event
We will look at three methods of simulating a leap second event.
1. Navigation data modification.
2. Implementation using the SimGEN GUI.
3. Implementation using the User Defined Data (UDD) facility.
6.1. Navigation data modification
As previously mentioned, the parameters defining a leap second insertion event are contained in page 18 of
sub frame 4 in the GPS navigation data. SimGEN has a navigation data editor which allows you to make bit-
level modifications to any part of the navigation message, which can be added and removed at specified
times. The editor is similar in operation to the other editors within SimGEN. Figure 2 shows the navigation
data editor in SimGEN. Refer to reference 2 for further detail on the operation of this editor.
Simulating UTC leap second insertion events
Figure 2 SimGEN navigation data modification editor
6.1.1. Specifying WNlsf.
The GPS Week number WN is defined in the range 0 –1023. This is a 10 bit value, as specified by sub
frame 1, word 3, bits 1-10 of the GPS NAV Data Z-Count. For WNlsf, the week number is truncated to the
least significant 8 bits, the full week number being implied by the value of WN as given by the current
Z-count. (The difference between WN and WNlsf is always <128).
To specify a week number of 454 for WNlsf, you would first convert to binary to get 111000110.
Removing 1 MSB (to leave the required 8 bits) will give you the week number as 11000110.
(Note that some week numbers will require removal of 2 MSB’s)
GPS week numbers ‘roll-over’ to 1 when 1024 is reached. It is not possible to tell which is the current roll-
over period from WN.
6.1.2. Specifying of DN
Specification of the DN value is simple as it is defined as the day in the week that the leap second
change should occur at the end of, where 1 = Sunday. Convert the data from decimal into binary and fill
the preceding bits with zeros. For example: Day 2 = 10 in binary, so this should be entered in the Nav
Data (to fill the required 8 bits) as 00000010.
6.1.3. Specification of ΔtLS and ΔtLSF
Both ΔtLSF and ΔtLS are specified using 8 Bits. The range of these values is only limited by the field size.
However, as at Jan 2008 the number of leap seconds separating UTC and GPST is 14. The difference
between the ΔtLSF and ΔtLS must be only +/- 1 second. The leap second will never change by more than
1 second (and in practice, will only ever increase). As with the specification of the DN parameter, you
convert the leap second decimal value into binary, padding leading bits with 0, so 14 would be entered
as 00001110.
Simulating UTC leap second insertion events
116
Note: Although in the real world the difference between ΔtLSF and ΔtLS will only ever be 1 second,
SimGEN does not apply any restriction. Entering a larger value is entirely possible, but may cause
unpredictable effects on a receiver.
6.1.4. Example leap second insertion using navigation data modification
This example shows how to create a scenario which includes a leap second event insertion using the
navigation data modification method.
The scenario parameters will be as follows:
a73
Scenario Start Date = 5th May 2008. (this is a Monday = Day 2).
a73
Start Time = 23:40:00 (20 min before leap second insertion event will occur).
a73
ΔtLS (Initial Leap Second Value) = 14.
a73
ΔtLSF (Value Leap Second will change to) = 15.
a73
WNlsf (Week the change will occur) = 454 (Same as scenario start week).
a73
DN (day of week the change will occur at the end of) = 2 (Same as scenario start day).
First you need to set the scenario date, start time and duration in SimGEN. To do this, enter the
parameters as shown in Figure 3. Note that the Z Count, GPS Week number and TOWs are automatically
filled-in.
Figure 3 SimGEN date time and duration editor window
The next step is to edit the GPS constellation file and enter the relevant data into the Nav Data. So in the
example above we first need to convert the values of ΔtLSF, ΔtLS, WNlsf, DN into binary:-
ΔtLS = 14 Decimal = 00001110 Binary (8 Bits).
ΔtLSF = 15 Decimal = 00001111 Binary (8 Bits).
WNlsf = 454 decimal = 11000110 Binary (8 Bits).
DN = 2 decimal = 00000010 Binary (8 Bits).
Now make the nav data changes using the editor shown in Figure 2 by performing the following:
a73
Select the command type ‘Legacy NAV Data Mod’.
a73
Tick the ‘all’ tick-box next to SVID – this ensures that the changes will be transmitted in the nav
data by all satellites.
Simulating UTC leap second insertion events
117
a73
Enter the sub frame as 4.
a73
Enter the Page as 18.
a73
Enter the Word as 9.
a73
Enter the ΔtLS, WNlsf, and DN binary values (3 sets of 8 bits, previously defined above as
000011101100011000000010) beginning at bit 1.
a73
Enter the time that this change will be valid for, for example, the duration of the scenario
beginning at the start time of the scenario.
a73
Click the ‘b2leftIns Before’ button to insert the command.
a73
Using a new command, enter the data for ΔtLSF, by setting the bits to 00001111, starting at bit 1.
a73
Enter ‘-‘ for all the remaining bits 9 to 24.
a73
Enter the Word as 10.
a73
As with the previous command, tick the ‘All’ box for SVID, set the sub frame to 4, the Page to 18
and the start / stop times to the duration of the scenario.
a73
Click the ‘b2leftIns After’ button to insert the command after the one already in the list.
You should now have both commands in the command list as shown in Figure 4.
Figure 4 Modified navigation data
a73
Next, click ‘OK’ and name & save the file.
You have now set up the conditions to simulate a Leap Second event occurring at midnight on
5th May 2008.
6.1.5. Simulating a leap second insertion using GUI data entry
As mentioned previously, leap second insertions generally occur on the 31st December or 30th June in a
given year. The navigation data modification example shows how to simulate a leap second event that
can occur on any date – as this is, in theory, possible (however unlikely)
Simulating leap second events using the SimGEN GUI is much easier, but is limited to the 31st December
or 30th June dates.
118
Simulating UTC leap second insertion events
To set-up a leap second event using the GUI, perform the following:
a73
In the Scenario tree, under ‘Options’ tick the box ‘Leap Second at…’ (See Figure 5).
a73
Double-click the file to display the ‘Leap Second occurs at’ box (See Figure 5).
a73
Select either 31st December or 30th June, and enter the required year (See Figure 5).
a73
Click OK.
Figure 5 Applying a leap second in SimGEN
SimGEN now automatically modifies the navigation data and will apply the leap second change as
specified, when the scenario is run.
6.1.6. Simulating a leap second insertion using SimGEN’s User Defined Data
(UDD) facility
SimGEN’s User Defined Data facility allows the user to define some of the data normally defined in the
Signal Sources file, by means of user-supplied ASCII files. One such UDD file is a ‘Nav Data Modification’
file. In a similar way to that described in 6.1.4, the user-defined file overwrites the navigation data
normally generated by SimGEN.
This is achieved by specifying the sub frame, page and word to be changed in the Navigation Data,
together with the appropriate bits to be changed in this word. This can be applied to all or specified
satellites.
The Nav Data modification file is an ASCII file containing records (lines) with the following format:
Comment Record
These are records of up to 80 characters preceded by "!", use these to add comments (or a title) as
required. These records may be placed at any point in the file.
Week Number Record
This specifies the GPS week number to which the data is to be initially referenced. The format is:
WEEK: nnnn
nnnn is the week number, range 0 to 1023. Week number rollover will be implicit according to the start
time of the scenario.
The Week Number record only occurs once in each file, this is followed by a sequence of records which
119
Simulating UTC leap second insertion events
define the changes to be applied for all affected satellites from a specified time. Each set of data consists
of the following:
Time Record
Time of week from which the changes are to be applied, expressed as Z-count (i.e. number of 1.5 second
epochs into the week). The format is:
TOW: nnnnnn
nnnnnn is the time of week. This must be on a six-second epoch, range 0 to 403196.
The time record is followed by a number of sets of data for each satellite for which Nav Data amendment
is required. This comprises a single Satellite ID record and a variable number of Nav Data records which
allow a specified Nav Data word to be changed.
Satellite ID Record
The ID of the satellite for which the data changes are to be applied. The format is:
SVID: nn
nn is the satellite ID. If this is set to zero then the specified amendments apply to all satellites.
Range 0 to 32.
Nav Data Records
A series of records defining the changes required for the given satellite. The format is:
SF n1:P n2:W n3:B n4-n5: abcdef
n1 is the number of the subframe to be changed. (0 applies to all subframes).
n2 is the number of the page to be changed. (0 applies to all pages of the given subframe).
n3 is the number of the word to be changed. (0 applies to all words of the given subframe/page).
n4 is the first bit of GPS Nav Data word to be changed.
n5 Last bit of GPS Nav Data word to be changed. GPS bit range is from 1-24; the parity bits (25-30) may
not be edited and will be correctly defined by default.
abcdef is a hexadecimal character string defining bits to be used as bits 1-24 in GPS Nav Data word,
such that:
Each character represents four bits of the 24 bit editable range.
The most significant bit of "a" corresponds to bit 1 of the GPS Nav word.
The least significant bit of "f" corresponds to bit 24 of the GPS Nav word.
Only those bits within the specified range of n4-n5 are used.
Further Satellite ID and Nav Data records to be applied from the given TOW follow, as required, until the
next TOW record (if any) is accessed. Additional sets of data for later times then follow as needed.
Notes:
1) The Nav data changes are applied indefinitely until a new set of changes is defined for a given
satellite at a later time. All previous amendments for this satellite are then overwritten, so if no Nav
Data records follow the Satellite ID record the software will revert to generating the default Nav Data.
2) The changes defined in this way are to be applied before the Nav Data sub frames are passed to the
SAAS software (if applicable), so that further manipulation of this data may be performed at the
SAAS stage.
3) Blank lines in the file will be skipped.
120
Simulating UTC leap second insertion events
The UDD file appicable to the example we have been using would be as follows:
Once this file is defined, save the file and select it by ticking ‘Enable user-defined data under the GPS
Constellation File in the scenario tree, then when the sub-list appears, ticking the Nav data mod file and
selecting the file you have just created, as shown in Figure 6.
Figure 6 Enabling UDD in the scenario file tree
When the scenario is run, the data in the Nav data mod file will be applied accordingly.
121
Simulating UTC leap second insertion events
6.1.7. Simulating a leap second insertion using the UDD Global Nav-Data FIle
The Global Nav Data file allows the data for the Leap Second event to be entered directly. An example
generic Global Nav Data file for one SV is shown in Figure 7.
Figure 7 Example Global Nav Data File
As you can see, you can directly enter in the values of WNt, WNlsf, DN, Δtlsf, and ΔtLS and do not have to
perform binary or hex conversions on the parameters. However, the problem with using this method is
that you must also specify all of the other parameters within the file, for example, Ionospheric
characteristics, Satellite health, otherwise they will be overwritten with 0.
To enable the Global nav data file, tick the box for ‘Global nav data file’ in the scenario file tree.
When the scenario is run, the data in the Global nav data mod file will be applied accordingly.
A correctly functioning receiver, which is navigating from the simulator’s signal, should detect and apply
the leap second insertion. This may be observed by monitoring the receiver’s UTC time data output. The
time count will appear to stop for 1 second before continuing. For example, observing the seconds on a
receiver’s UTC time display may reveal the following 4-5-6-7-7-8-9, where 7 was the time at which the
leap second even occurred. It should be noted that a receiver might not actually implement the leap
second adjustment on the 00:00 midnight boundary. Some receivers make the change before this time.
The best way to check that the implementation has occurred is to log the receivers UTC time data to a file,
and analyse this file after the test has finished, rather than trying to physically observe the time count.
122
Simulating UTC leap second insertion events
7. Referenced Documents
1. IS-GPS-200D Navstar GPS Space Segment/Navigation User Interface Specification, Revision D,
7th Dec 2004
2. DGP00686AAA SimGEN Software User Manual (latest issue)
8. Further Information
Spirent’s Test Services Team is dedicated to providing you with information and test solutions to help you with
your testing needs, and to that end, we are actively producing Application Notes and Test Methodologies on a
wide variety of GNSS test subjects. Please visit www.spirent.com/positioning, or www.spirent.com and click the
Satellite Navigation link regularly to find the latest articles, or ask your Spirent Sales representative for more
information.
Spirent customers who have a current SimSUPPORT agreement can also benefit from an extended range of Test
Methodologies, which can be found by logging into the Support website:
www.positioningtechnology.co.uk/support
9. Appendix
Calculation of UTC as per ICD-GPS-200C
Page 18 of sub frame 4 includes: (1) the parameters needed to relate GPS time to UTC, and (2) notice to the user
regarding the scheduled future or recent past (relative to NAV message upload) value of the delta time due to
leap seconds (Δt
LSF
), together with the week number (WN
LSF
) and the day number (DN) at the end of which the
leap second becomes effective. "Day one" is the first day relative to the end/start of week and the WNLSF value
consists of eight bits which shall be a Modulo 256 binary representation of the GPS week number (see paragraph
6.2.4) to which the DN is referenced. The user must account for the truncated nature of this parameter as well as
truncation of WN, WN
t
, and WN
LSF
due to rollover of full week number (see paragraph 3.3.4(b)). The CS shall
manage these parameters such that the absolute value of the difference between the untruncated WN and WN
LSF
values shall not exceed 127.
Depending upon the relationship of the effectivity date to the user's current GPS time, the following three
different UTC/GPS-time relationships exist:
a. Whenever the effectivity time indicated by the WN
LSF
and the DN values is not in the past (relative to
the user's present time), and the user's present time does not fall in the time span which starts at DN + 3/4 and
ends at DN + 5/4, the UTC/GPS-time relationship is given by:
t
UTC
= (t
E
- Δt
UTC
) [Modulo 86400 seconds]
where t
UTC
is in seconds and Δt
UTC
= Δt
LS
+ A
0
+ A
1
(t
E
- t
ot
+ 604800 (WN - WN
t
)), seconds;
t
E
= GPS time as estimated by the user on the basis of correcting t
SV
for factors described in paragraph
20.3.3.3.3 as well as for ionospheric and selective availability (SA) (dither) effects;
Δt
LS
= delta time due to leap seconds;
A
0
and A
1
= constant and first order terms of polynomial;
t
ot
= reference time for UTC data (reference 20.3.4.5);
Simulating UTC leap second insertion events
123
W
N
= current week number (derived from subframe 1);
W
Nt
= UTC reference week number.
The estimated GPS time (t
E
) shall be in seconds relative to end/start of week. During the normal and short-term
extended operations, the reference time for UTC data, t
ot
, is some multiple of 212 seconds occurring
approximately 70 hours after the first valid transmission time for this UTC data set (reference 20.3.4.5). The
reference time for UTC data (t
ot
) shall be referenced to the start of that week whose number (WN
t
) is given in word
eight of page 18 in subframe 4. The WNt value consists of eight bits which shall be a Modulo 256 binary
representation of the GPS week number (see paragraph 6.2.4) to which the tot is referenced. The user must
account for the truncated nature of this parameter as well as truncation of WN, WN
t
, and WN
LSF
due to rollover of
full week number (see paragraph 3.3.4(b)). The CS shall manage these parameters such that the absolute value
of the difference between the un-truncated WN and WN
t
values shall not exceed 127.
Simulating UTC leap second insertion events
124
