Spirent’s simulation systems have changed significantly from their technology beginnings, which can be traced back to World War II radars. The company and its technology have evolved to keep pace with today’s growing population of GNSS constellations and to meet the challenges that receiver manufacturers and users encounter in an ever-complex integrated GNSS environment.
In the early days of GPS when there were only enough satellites for a fix at odd times of the day or night, these nighttime expeditions were the only form of testing that we could get our hands on. Then as the constellation grew, we were delighted when eventually you could do open sky testing whenever you needed. It never even occurred to us that more exhaustive, more complex testing would become essential as time progressed.
If you walked into any GNSS manufacturer’s testing facility nowadays, the ubiquitous test rack at the heart of most test validation systems might well include a Spirent simulator of some vintage. I recall when we were bringing up receivers in engineering, one of our concerns was how the heck could we afford another one of these beasts for the guys down in production? After we already broke the bank when we managed to convince management that we couldn’t live without a Spirent, we were wondering who we’d push to the front of the line to tell the boss that we had to buy yet another one for the guys on the production line. At one time before a cut-down single channel box became available, we shared our simulator with production who operated the system remotely and a coax run provided RF onto the production floor. We still did open sky testing in R&D, but the complex validation scenarios would have been impossible for the team without our Spirent simulation system.
Recently I got to wondering where Spirent had come from and how come they had become one of the leading players in GNSS simulation. I did recall that they were UK based, that there were a number of name changes and that at one stage they also had receiver capability. So I got talking with John Pottle who’s always been my marketing window into Spirent, and Peter Boulton who’s been my principle technical contact. I was interested in Spirent’s background, their engineering capability, how they got where they are now and where they plan to go in the future.
Its not surprising that Spirent’s roots go way back in England to the period of the second world war. England developed radar as an early warning system that helped win the air combat Battle of Britain. Following the extensive blitz bombing of London, the UK government subsequently re-located the radar technology team well out of harm’s way to the distant and more secure southern tip of England, and that technology team formed the core of a high-tech group based in Paignton, Devon which eventually evolved to focus on GNSS simulation.
Southern England – Paignton base for Spirent.
It’s a nice area to live in, with fewer people, smaller towns and a very pleasant climate. So the technology guys and their families hung around and the government facility became Standard Telephones (STC) and Cables Defence Systems. Focusing in those days on travelling wave guides, cathode ray tubes, and radar amplifiers and the like, this business grew to include solid-state amplifiers, satellite communications and repeaters for fiber-optic networks. This all needed test equipment and a test division grew up to service STC’s technology groups.
As GPS came on line, the UK Government Royal Aircraft Establishment (RAE) needed GPS simulation capability to verify GPS system performance, and STC came up with a test system equipped with 6 dual-frequency satellite signal sources with additional jamming sources and a range of military data interfaces. The computer operating system was VMS running on a Digital Microvax2 platform, the software was written in DEC Fortran and the DOS-like user interface had textual menus with a graphics terminal for X-Y plots. Just like we had racks of equipment for the original single channel GPS receivers, GPS simulation systems started in the same way.
RAE GPS Simulation System 1987.
In parallel STC was also working on a contract to develop a military GPS receiver, and several of the GPS ASICS used in that receiver found their way into the simulator. Simultaneously, the RAE contract was extended to include provision of full SA-A/S capability, which was delivered in 1988. This classified system was used to formally evaluate the Rockwell-Collins 3A receiver SA-A/S implementation – at the time this test system was the only one available capable of emulating all the features of SA-A/S.
As it became clear in1988 that GPS would have a wider commercial market, STC began to invest in simulation systems for commercial receiver manufacturers.
STR2740 Simulator 1989.
STR2760 Simulator 1991.
With dual frequency and up to 10 satellite channels, the STR2740 was still quite large as it was based on the floor standing Microvax2. Porting the software to a desktop VMS workstation gave us the more familiar STR2760 that was first displayed at the ION-GPS-1991 convention in Albuquerque. This initial unit was actually purchased from the ION display show floor and STC had to hustle to quickly make more!
Then ownership passed to Northern Telecom in Canada, who was initially interested in STC’s fibre-optic communications technology and products. After a few years, Northern Telecom changed its name to Nortel – so then we all started talking about ‘Nortel simulators’. The next phase of internal development re-tuned the technology and the resulting 1997 STR4760 simulator boasted double the channel capacity and enabled the inclusion of GLONASS and SBAS capability.
STR4760 Simulator 1997.
In the same timeframe, development of a Controlled Radiation Pattern Antenna (CRPA) was underway in Paignton, but this didn’t quite fit with a business focus on testing, so the CRPA line was sold to Cossor, which was subsequently merged with Raytheon — and the well-known GAS-1 mil-spec CRPA was the outcome. The GPS receiver technology went along with the CRPA to Cossor and ultimately on to Raytheon.
In 1997 the Nortel name also disappeared as Bowthorpe in UK became the new owners and the group became known as ‘Global Simulation Systems’ and we then had “GSS” simulators for a period, but by 2000 the parent company changed its name to Spirent, and that name seems to have stuck.
When SA was switched off in 2000, the potential for commercial GPS became apparent to the Spirent team and this fired up investment in a brand new range of products for the commercial GPS L1 C/A code marketplace – units can often be found in use for single channel production testing, whilst other multi-channel simulators are in use for commercial, pre-production, R&D and verification.
Full L2C, L5 and M-code GPS modernisation was introduced in 2004 while retaining essential systems and scenarios backward compatibility. Spirent’s approach has been to endeavour to get to market early with new signal capability for early adopters.
Support for all Galileo signals and services arrived in 2006 and the GSS8000 series in 2008 added a wide range of additional signal generation capabilities as well as GLONASS L1/L2 and QZSS.
GSS8000 Series Simulator 2008.
SimGEN has been the Microsoft Windows user interface provided by Spirent since around 2002.
SimGEN interfaces to external receivers, and enables external vehicle trajectory input via various interfaces. High speed remote control is also possible and logging/displaying/plotting is also available for report generation and results analysis.
So today, Spirent has accumulated a significant range of simulation capabilities:
Galileo RF constellation simulators for all frequencies & services
GPS L1 C/A and P/Y, L2C, L5, M-Code, M-Noise, L1C
GPS SBAS (MSAS, WAAS, EGNOS, Gagan)
GLONASS L1/L2
QZSS L1 C/A, SAIF, L1c, L2c and L5 signals
R&D systems for the IRNSS regional system program
Automotive sensor simulation
SimGEN emulation of Aircraft Landing Augmentation System (GBAS)
SimINERTIAL adds stimulation of test Inputs for several types of inertial sensors.
Equipment for both GNSS manufacturing and field testing
With around 25 in-house engineers and a number of outside consultants, the technical team is not huge. But with 27 years of accumulated experience in GNSS simulation, and a large ‘vault’ of key technologies, Spirent is well positioned for the challenges that the world’s multiple, evolving GNSS constellations are presenting to manufacturers.
So what’s next for the Spirent simulator business? Well the Chinese COMPASS constellation is coming on fast, so even though there is still no complete, usable public ICD available, Spirent has adopted the same approach used when release of the Galileo ICD was restricted by ESA – Spirent supplies a COMPASS simulator which has the ‘real’ modulation and frequencies, but the customer inputs the navigation messages.
Spirent is also getting some traction from users who want simulation systems to model specific applications – like car motion sensors to simulate the inputs of in-vehicle navigation system, or full ground segment monitoring and fully integrated message generation for GBAS aircraft landing systems or simulation designed for testing of integrated GPS/Inertial systems.
The days of relying on GNSS alone for navigation and positioning may be fast disappearing, so its likely that things will get even more complex. While there may be some significant questions, such as which combination of GNSS frequencies/signals/constellations to choose from to optimise performance for a particular application, the focus for developers is getting much broader than GNSS or even multi-GNSS alone. Or you could say that the problem has shifted from proving GPS receiver performance alone, to proving, and improving systems and applications performance to meet increasingly demanding end-user needs.
For example, in defence applications where integrity and resilience are key focus areas, inertial navigation is used to complement GNSS, and adaptive antenna technology helps to overcome intentional interference threats. In commercial markets, getting good accuracy everywhere has led to hybrid approaches that include cellular and Wi-Fi positioning and augmentation from MEMS inertial sensors.
Spirent’s product road maps appear to reflect this shift in customer needs. This year we should expect to see Spirent GNSS/inertial test capability for commercial inertial sensors, and also manufacturing and functional testing of consumer devices that include not only GNSS but also Wi-Fi, Bluetooth and other emerging technologies such as near-field communications (NFC) contactless technologies.
So a varied range of GNSS simulation capabilities which match up to the challenges which users face in the real world — and with over 800 simulations systems supplied world-wide, Spirent is surely setting the pace for the evolving GNSS & systems simulation marketplace.
By Alison Brown, Jarrett Redd, and Mark-Anthony Hutton
GNSS signal simulators can be expensive and beyond the limited budgets of many researchers. In this month’s column, we look at one company’s approach to providing GNSS signal simulation at a low cost — one that virtually any researcher can afford.
INNOVATION INSIGHTS by Richard Langley
WHY DO WE SIMULATE REALITY in mathematics, science, engineering, and other pursuits — even in our recreational activities? Well, we do it for a variety of reasons. In mathematics and science, we try to comprehend reality, which is complicated and variable and often has some degree of randomness. We build mathematical models of physical, chemical, or biological processes to better understand them or to predict a particular outcome given some initial conditions. The model may contain a stochastic component to reflect a degree of uncertainty associated with the processes. Weather forecasting is a prime example. Typically, the models are run on a computer where the model parameters and initial conditions can be readily adjusted and the varying outcomes analyzed.
Simulations of reality are often used in teaching where students can more easily grasp the behavior of complicated systems whether they be in the natural sciences or in economics or the social sciences. In medical education, simulated human patients are used initially because it is safer than having students operate on real patients. Similarly, flight simulators are used for the training of pilots because it is cheaper and safer than using real aircraft and a wide variety of “what if” scenarios can be experienced.
Simulation is used for a range of engineering activities to see how an existing system behaves under different conditions because it is faster or cheaper than performing tests in the “real world.” It can also be used to estimate how a proposed new system might behave before it becomes a reality — looking at traffic flow in road networks, for example.
We also use simulation for recreation, whether it is playing with the latest computer game or improving our swing with a golf simulator. And simulation is a mainstay of the movie industry.
But getting back to engineering and the main interest of this magazine, simulation is a useful technique in the design and operation of equipment used with global navigation satellite systems. With a radio frequency simulator, we can mimic the radio signals generated by the satellites. These devices allow us to define scenarios, including receiver trajectories, and to replay them while varying the operating parameters of the receiver. Some simulators allow us to record live signals and then to play them back under different assumed conditions.
However, such GNSS signal simulators can be expensive and beyond the limited budgets of many researchers. In this month’s column, we look at one company’s approach to providing GNSS signal simulation at a low cost — one that virtually any researcher can afford.
As the noted French sociologist and philosopher, Jean Baudrillard, pessimistically once said: “We live in a world where there is more and more information, and less and less meaning.” In the field of GNSS engineering, at least, simulation is helping to stem the tide and give us a better understanding of reality.
“Innovation” features discussions about advances in GPS technology, its applications, and the fundamentals of GPS positioning. The column is coordinated by Richard Langley, Department of Geodesy and Geomatics Engineering, University of New Brunswick. To contact him with topic ideas, email him at lang @ unb.ca.
Embedded GPS receivers have become commonplace with the proliferation of GPS navigation systems into all but the least expensive vehicle and cell-phone lines. As more manufacturers embed low-cost GPS receivers into their products, the need for low-cost GPS signal simulators has also grown. Controlled virtual testing is vital in ensuring the expected system performance.
Many GPS signal generators are available that are designed specifically for high-volume production test applications for devices that use commercial GPS/SBAS, GLONASS, and Galileo receivers. Often the cost of these high-end simulators is beyond the reach of small companies or universities. In response to this need, we have developed our low-cost, software-defined radio (SDR)-based GPS Signal Architect Test Set to address a broad range of research, academic, industrial, and defense applications. The system is designed to be flexible, scalable, and most importantly, inexpensive.
Our test set leverages the capabilities of the Universal Software Radio Peripheral (USRP) radio and our GPS Signal Simulation Toolbox to provide users with a GPS signal generation capability at a much lower cost than currently available on the market. The combination of the GPS signal simulation software coupled with the record and playback capability of the USRP makes for an extremely low-cost, yet highly flexible, GPS signal simulation capability.
FIGURE 1 shows the GPS signal simulator hardware. It is designed for use with commercial software-defined radios and is based on our GPS Signal Simulation Toolbox.
FIGURE 1. GPS signal simulator hardware.
Toolbox. The Toolbox is a complete set of GPS signal simulation, test, and analysis tools. This Matlab-based signal simulation toolbox simulates the effect of the signal degradation on a conventional commercial GPS receiver, including the effect of the ionospheric activity on the code and carrier tracking loops such as losing lock or cycle slipping. The Toolbox’s geographic tools facilitate the transformation of data between the various coordinate systems commonly used in GPS research, including latitude-longitude-altitude; WGS 84 Earth-centered, Earth-fixed (ECEF); north-east-down; and body-fixed reference frames. It also provides tools to read GPS almanacs and ephemerides and compute ECEF and line-of-sight vectors to GPS satellites as a function of user position and time. The receiver design and analysis tools model different receiver architectures and simulate different error scenarios by providing tracking and navigation algorithms, including phase lock loops and delay lock loops.
The user-configurable options allow the operator to define virtually all aspects of a GPS signal environment, including the GPS spreading code(s), navigation message, and interference scenarios. Such flexibility is particularly useful in simulating GPS jamming environments, where time, resources, and repeatability are generally scarce.
Because these tools are linked directly to Matlab, it is relatively simple to define and implement new signal components as they become available. Of primary interest are the GPS modernization codes as well as those of other global navigation satellite systems (GNSS). Also of interest are new and exotic categories of jammers, including frequency-modulated, amplitude-modulated, phase-modulated, and frequency-swept jammers.
An early version of the toolbox was reviewed in a previous Innovation column (see Further Reading).
Configuration. In the configuration shown in Figure 1, the signal control unit (SCU) is used to control the radio for record and playback operation. The USRP includes a 10-MHz frequency standard as well as an input for an external reference clock. The GPS Signal Architect software can produce custom GPS scenario data files, which can use the USRP to produce a GPS signal at RF.
This article provides a review of how the signal simulator uses the USRP family of radios as low-cost RF record and playback devices using the Signal Architect files. In addition, the hardware design and supported signals are described and test results are presented showing the USRP providing simulated GPS signals to conventional GPS user equipment.
Radio Hardware
The USRP radio family provides an inexpensive development platform for software-defined radios. The USRP can also be used to record and play back the GPS signal in a static or mobile environment. The system operator can then reproduce the signal on the bench either from a simulated profile or from a previously recorded test environment. An advantage of the USRP is that it supports a wideband transceiver front-end that can accommodate the full 20 MHz of the GPS signal band and can be tuned to operate at any of the GPS signal frequencies (L1 at 1575.42 MHz, L2 at 1227.60 MHz, or L5 at 1176.45 MHz). This allows record and playback of both the civil and military GPS codes.
While the GPS Signal Architect tools can be easily adapted for use with any commercial SDR, the USRP family was chosen because of its reasonable price, quality construction, and extensive support by the GNU Radio project.
USRPs are SDRs, which can, in principle, transmit or receive signals on any frequency under software control. Typically, USRPs connect to a host computer through a high-speed USB or gigabit Ethernet link, which the host-based software uses to control the USRP hardware and to transmit or receive data. Some USRP models also integrate the general functionality of a host computer with an embedded processor that allows the USRP to operate in a standalone fashion. The USRP hardware is controlled through a hardware driver, which supports Linux, MacOS, and Windows platforms. A framework running on the host computer then accesses the USRP through the driver. Several frameworks, including GNU Radio (a free software toolkit for learning about, building, and deploying SDR systems developed under the GNU Project — “GNU” is a recursive acronym that stands for “GNU’s Not Unix”), LabView, Matlab, and Simulink, use the driver. The driver’s functionality can also be accessed directly with an application programming interface (API), which provides native support for C++. Any other language that can import C++ functions can also use the driver. This is accomplished in Python through the Simplified Wrapper and Interface Generator, for example. The API allows users to develop their own custom frameworks, as we did with our SCU.
Of the available USRP radios, the N210 was chosen because it has the highest sample rate, greatest flexibility, and largest capacity for modification (see FIGURE 2).
FIGURE 2. Univeral Software Radio Peripheral.
The USRP provides an interface between high-speed analog to digital converters, high-speed digital to analog converters, and an Ethernet interface, as previously mentioned. Daughterboards available for the USRP provide an interface from the baseband signals present at the data converters to the GPS frequency bands and vice versa.
A daughterboard (or daughtercard or piggyback board) is a circuit board meant to be an extension or “daughter” of a motherboard. The USRP uses interchangeable daughterboards, plugging into the main board, to serve as the RF front end. Several classes of daughterboard modules exist: receivers, transmitters, and transceivers. Transmitter daughterboard modules can modulate an output signal to a higher frequency; receiver daughterboard modules can acquire an RF signal and convert it to baseband; and transceiver daughterboard modules combine the functionality of a both a transmitter and receiver.
For this project, a WBX (wide bandwidth) transceiver daughterboard was installed in the USRP. The tunable range of the WBX (50 MHz to 2.2 GHz) covers all the current GNSS frequencies. An RF pre-filter is used to band-limit the GNSS signals to the sample rate selected for use in the SCU to avoid spectral folding from the N210 40-MHz channel bandwidth. For example, a 2-MHz filter centered at L1 is optimal based on the Nyquist sampling frequency of 2 MHz of both the in-phase and quadrature (I/Q) components of the signal. If sampling at 20 MHz, then a 20-MHz pre-filter should be used.
Signal Control Unit
The SCU includes a Linux single-board computer with software developed to run under the GNU Radio Companion (an open-source graphical tool for creating signal flow graphs and generating flow-graph source code using the GNU Radio libraries) and management of the GNU SDR for RF record and playback under control of the GPS Signal Architect software through an Ethernet connection. This enables the user to tap into the excellent USRP community support for his or her project and benefit from the close relationship between the GNU Radio project and the USRP manufacturer. The Ethernet connection is also used to download and upload recorded or simulated signal files from the Signal Architect signal simulation software.
Signal Simulation Software
The GPS Signal Architect hardware and software provides users with a Matlab-based GPS signal generation capability. If our Matlab GPS Toolbox is provided, the Signal Architect GPS simulation can be run under the Matlab environment. For the non-Matlab user, the Signal Architect software is bundled as a stand-alone executable. The signal simulation flow is depicted in FIGURE 3.
FIGURE 3. Signal Architect simulation flow. (Click to enlarge.)
GUI. Using a simple, intuitive graphical user interface (GUI), the user specifies a trajectory and a complete set of simulation parameters to create an I/Q data file (see FIGURE 4). The user specifies a trajectory either from an NMEA file (most GPS receivers use the National Marine Electronics Association 0183 interface standard for logging positions and other data) or a KML file from Google Earth (Google’s Keyhole Markup Language has become a standard for describing geographically referenced features), and an almanac file used to define GPS satellites to be simulated. The user defines the mask angle for the satellite selection and the noise figure to be simulated. The Signal Architect software then generates a simulated digital storage file, including the selected pseudorandom noise codes (C/A and/or the unencrypted military P or M′ codes).
FIGURE 4. Signal Architect graphical user interface. (Click to enlarge.)TABLE 1. Signal simulator system specifications.
Scenarios. The Signal Architect software also ships with preloaded scenario files that the user can run right out of the box into the SCU using the USRP. The Signal Architect software supports computers with multi-core processors and will automatically configure itself to run on all available processors. The Signal Architect software will generate either static or dynamic simulation profiles. The Signal Architect GUI allows the operator to easily modify a wide range of scenario variables from the pre-set defaults. Complete scenarios are easily shared between signal simulation systems, supporting collaborative testing between similar projects and reducing the amount of time spent developing test tools.
The signal data file can then be used for subsequent analysis within Matlab using the Matlab GPS Toolbox, or can be provided to the SCU and USRP to create a GPS signal suitable for playback into a GPS receiver. If the Matlab GPS Toolbox is available, the user has complete flexibility to manipulate the signal at various stages of generation or post-generation to simulate GPS anomalies. Without the toolbox, the user is restricted to using only the standard error modeling provided by the compiled Signal Architect code.
Simulation Test Results
To demonstrate the high fidelity of our Signal Architect signal record and playback capability, a series of stationary GPS simulations were run. In these tests, the USRP was used to record and play back GPS C/A-code signals at the L1 band (1575.42 MHz). The SCU and USRP were connected to a rooftop-mounted GPS L1 antenna. The GPS signal was split between a commercial GPS receiver and the USRP to allow the operator to monitor the GPS receiver while the USRP was recording the GPS signal.
In record mode, the I/Q data is written from the USRP to a file on the SCU. In playback mode, the data is read from the file by the USRP to generate the RF signal. The RF signals are output to the GPS receiver through an external variable attenuator. The attenuator allows the operator to adjust the signal power into the GPS receiver as different lengths of antenna cable are added or as the signal is split to other GPS receivers.
To demonstrate the GPS Signal Architect Test Set performance, representative data was collected in a series of two laboratory tests. The first test demonstrates the system performance as a record and playback GPS signal simulator. The second test results demonstrate the system performance when using the Signal Architect software to generate custom GPS scenario files for playback into the GPS receiver.
In the first test, the GPS simulator hardware was configured as shown in FIGURE 5. The GPS receiver and USRP were connected to a commercially available antenna. The antenna was positioned at a known location with a clear view of the GPS constellation. The signal from the GPS antenna was split between the GPS receiver and the USRP so that the data could be logged by the receiver software at the same time as it was being recorded by the SCU.
FIGURE 5. GPS Signal Simulator record and playback GPS simulation.
The simulated satellite constellation is shown in FIGURE 6. Seven GPS satellites are in view.
FIGURE 6. Simulated satellite constellation.
The 2-D position error from the simulated signal is shown in FIGURE 7. The errors are representative of the accuracies achievable using GPS C/A-code pseudoranges.
FIGURE 7. North-east (2-D) position error.
We can examine the performance of our test set by looking at plots of the measurements of carrier-to-noise-density ratio (C/N0) from the GPS receiver for both the live sky data and for the recorded signal when played into the GPS receiver by the Signal Simulator for three of the GPS receiver channels (see FIGURE 8). The C/N0 data collected from the GPS antenna is shown in blue, while the C/N0 from the USRP is shown in green.
FIGURE 8. C/N0 record and playback vs. live sky collection.
As we can see, the C/N0 was 1–2 dB lower in playback mode when compared to the data collected from the GPS antenna. The signal loss is due to the 1-bit sampling of the incoming GPS signal by the Signal Architect software. One-bit and 2-bit quantization are used in many commercial GPS receivers. The rule of thumb states that 1-bit quantization degrades the signal-to-noise ratio by 1.96 dB, and 2-bit quantization degrades the signal-to-noise by 0.55 dB. These results show that 1-bit I/Q sampling is sufficient for reproducing GPS L1 C/A-code signals with the USRP.
In the second test, the Signal Architect software was used to generate a 10-minute static GPS C/A-code L1 scenario file. The SCU used the USRP to generate the GPS signal.
Shown in FIGURE 9 are the number of satellites the GPS receiver was able to track. When using the GPS Signal Architect Test Set to play back the scenario file, the GPS receiver was able to track all the simulated satellites in the file. The time necessary for the GPS receiver to acquire and track the satellites is consistent with the performance one would expect from the GPS receiver when connected to an external antenna.
FIGURE 10 shows the C/N0 measurements from the GPS receiver for three of the receiver channels. There were nine satellites in this static scenario file. The C/N0 for all the satellites is stable for the duration of the scenario playback.
FIGURE 9. Number of satellites tracked (digital signal file playback mode).FIGURE 10. C/N0 (digital signal file playback mode).
Another Hardware/Software Option
We have also worked with the manufacturer of the LabSat hardware signal simulator to include some of the software functionality of our USRP system.
The LabSat GNSS simulator (see FIGURE 11) can be used to record live navigation satellite RF data streamed onto a hard drive. This can then be played back as an RF signal. When integrated with the SatGen software, simulated digitized RF data can be generated and played back into the LabSat simulator in place of the recorded, digitized GNSS RF signals.
FIGURE 11. LabSat GNSS simulator.
The core of the SatGen software is our Signal Architect software component, which has been adapted to run on the LabSat platform to allow simulation of the multiple GNSS satellite signals.
Hardware. The latest version of the LabSat hardware design (LabSat 2) enables the record and playback of GPS and GLONASS synchronized RF data streams (see FIGURE 12). When recording the GPS or GLONASS signals, the RF L1 channels (1575.42 MHz for GPS and 1602.0 MHz for GLONASS) are down-converted to a 0-Hz intermediate frequency. The signals are sampled (2 bit I and Q) at 16.368 MHz to capture the full GLONASS set of frequency channels. The GPS and GLONASS data is then interleaved into a 4-bit data stream and recorded in an internal buffer as a binary file. A high-speed USB link then transmits the data to a PC before streaming onto the PC hard disk. For playback, the PC streams the stored binary data to the LabSat via the USB link. The recorded digital GPS and GLONASS signals are up-converted onto the GPS and GLONASS RF channels and played back into the receiver under test. A digital attenuator on the output can adjust the RF output level.
FIGURE 12. LabSat GNSS simulator hardware design.
Using the LabSat record and playback mode, all of the real-world effects on the GNSS signals are recorded, including multipath effects, drop-outs, and atmospheric effects, allowing repeatable tests to be performed on GNSS receivers under a variety of real-world conditions, such as operating in urban canyons. This is ideal for debugging fault conditions on GNSS equipment and software. For more extensive simulations in different environments, the LabSat SatGen software can be used to generate simulated scenarios at any time or place or for a dynamic environment.
SatGen Scenario Simulation. SatGen is a software package that allows users to define trajectories for use in generating simulated data files for playback into LabSat. A user-defined trajectory file can be used to create a LabSat-simulated scenario for a route anywhere in the world. Routes can be generated directly from NMEA files imported directly into SatGen from a GPS datalogger or from user-defined routes generated using Google Earth.
SatGen users can use Google Earth to define a route by creating a path using its “Add Path” tool. The user can use as many or as few waypoints as the user wants, and can edit routes by moving, adding, or removing waypoints. The path is saved as a standard Google Earth KML file, which is imported into SatGen, which then fills in and smoothes the trajectory between the waypoints. The user can also define velocity profiles, or SatGen can provide these automatically. SatGen creates an NMEA file that is used to generate a binary I/Q simulated signal file for replay on the LabSat hardware.
Signal Architect Simulation. The core of the SatGen software is GNSS Signal Architect, an upgraded version of our GPS Signal Architect, which provides the capability to simulate multiple GPS signals and also different GNSS signals.
Signal Architect imports the NMEA trajectory either from a prerecorded file or from one generated using SatGen, and uses this file to generate a GNSS-simulated scenario. The user specifies the input GPS satellite constellation through a Yuma-format almanac file and the GLONASS constellation through a GLONASS almanac file in “.agl” or RINEX format. These files are then used to generate the simulated pseudorange, Doppler, and carrier phase for the GPS and GLONASS satellites in view of the simulated GNSS receivers above a specified mask angle. This simulated range data is then used to generate the digitized I/Q signals for the GPS and GLONASS satellites. Users who have access to our GNSS Signal Simulation Toolbox (an upgrade of our GPS toolbox) will have the added ability to modify the GNSS signal strength and add additional high-resolution error models to the simulated signals including multipath or GNSS signal error characteristics. The resulting I/Q simulated data file for the GPS plus GLONASS constellation is then recorded in a data file, which can be loaded into the LabSat hardware for playback into a receiver under test.
Test results using the LabSat and SatGen combination have demonstrated that highly accurate navigation solutions can be obtained with a variety of playback modes.
Conclusion
The combination of our GPS Signal Architect software with either the SCU and USRP or LabSat has proven to be an ideal low-cost GPS signal simulation tool with the capability of simulating or recording the complete GPS signal spectrum, including both the civil and the military codes for playback. The initial release of the GPS Signal Architect Test Set supports L1 operation and C/A- and P-code and M′ signal simulation or C/A- and P(Y)-code and M′ record and playback, while both GPS and GLONASS signal generation and playback is available with LabSat.
Our team of GPS and RF experts is continually developing and updating the system to provide additional functionality. Future releases of our test set will include support for multi-frequency SDR hardware and the capability to simulate other civil and military GPS signals, and also those of other global navigation satellite systems. To reflect this capability, we have branded the latest version of our simulation system, the GNSS Signal Architect Test Set.
Acknowledgments
The authors acknowledge the support of Ettus Research LLC in the development of the technology associated with the USRP system, as well as Racelogic Ltd. for collaboration on the LabSat GNSS simulator. USRP is a registered trademark of National Instruments Corp.
The article is based primarily on the papers “GPS Signal Simulation Using Open Source GPS Receiver Platform” presented at the Virginia Tech Symposium on Wireless Personal Communication in June 2011 and “SatGen GNSS Signal Simulation Software” presented at ION GNSS 2011 in Portland, Oregon, in September 2011.
Manufacturers
The GNSS Signal Architect Test Set was developed by Navsys Corp. The USRP used for the test set is the Ettus Research LLC model USRP N210. The LabSat 2 GNSS Simulator and associated SatGen software is produced by Racelogic Ltd. The GPS equipment used in our tests was a Novatel DL-4 plus receiver and a GPS-702GG antenna.
Alison Brown is the president and chief executive officer of Navsys Corp., Colorado Springs, Colorado, which she founded in 1986. Brown has a Ph.D. in mechanics, aerospace, and nuclear engineering from UCLA, an M.S. in aeronautics and astronautics from MIT, and an M.A. and B.A. in engineering from Cambridge University. She is a fellow of the Institute of Navigation and an honorary fellow of Sidney Sussex College, Cambridge.
Jarrett Redd is a senior systems engineer with Navsys Corp. working on hardware, firmware, and embedded systems development for signal acquisition, processing, and transmission. He holds an M.S. and B.S. in computer engineering from Texas A&M University.
Mark-Anthony Hutton is a software engineer with Navsys Corp. working on GNSS signal simulation tools and the GPS Jammer Detection and Location System. He holds a B.S. in computer science from the University of Colorado at Colorado Springs.
FURTHER READING
• Authors’ Proceedings Papers
“SatGen GNSS Signal Simulation Software” by A. K. Brown, M.-A. Hutton, M. Quigley, and M. Sampson in Proceedings of ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 19–23, 2011, pp. 2031–2034.
“GPS M’-Code and P-Code Signal Simulation Using an Open Source Radio Platform” by A. Brown and B. Johnson in Proceedings of ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 19–23, 2011, pp. 1494–1498.
“Modeling and Simulation of GPS Using Software Signal Generation and Digital Signal Reconstruction” by A. Brown, N. Gerein, and K. Taylor in Proceedings of the 2000 National Technical Meeting of The Institute of Navigation, Anaheim, California, January 26–28, 2000, pp. 646–652.
“GPS Simulation” by M. B. May in GPS World, Vol. 5, No. 10, October 1994, pp. 51–56.
• Matlab Simulation Toolboxes
“GPS MATLAB Toolbox Review” by A.K. Tetewsky and A. Soltz in GPS World, Vol. 9, No. 10, October 1998, pp. 50–56.
• NMEA 0183
NMEA 0183, The Standard for Interfacing Marine Electronic Devices, Ver. 4.00, published by the National Marine Electronics Association, Severna Park, Maryland, November 2008.
CAST Navigation of Tewksbury, Massachusetts introduced its SGX GPS Satellite Simulator. With its compact size — 7 × 11× 3 inches — and weighing in at just over 4 pounds, the SGX is CAST’s newest and smallest fully capable simulator to date.
The new SGX replaces the CAST-SIMCOM Simulator which was a 17-inch, 50-pound simulator. The SGX lightweight portability operates on AC or battery power, features 16 channels of L1 C/A and P codes, and is extremely accurate and repeatable, according to the company.
Features include touch screen, individual satellite power control, and start and stop scenarios with a touch of a button.
The CAST-SGX is portable, affordable, lightweight and utilizes CAST long standing proven technology.
CAST has been in the GPS simulation and support business for more than 25 years, designing, developing, manufacturing, and integrating innovative GPS/INS simulators and associated equipment for government, military, prime vendor, and consumer markets.
Testing GNSS Receivers with Record and Playback Techniques
By David A. Hall
Is there a way to perform repeatable tests on GNSS receivers using real signals? This month’s column looks at how to use an RF vector signal analyzer to digitize and record live signals, and then play them back to a GNSS receiver with an RF vector signal generator.
INNOVATION INSIGHTS by Richard Langley
AS A PROFESSOR, I’m quite familiar with testing — of students, that is. It’s how we check their performance — how well they have mastered the course material. Outside academia, testing is also quite common. We have to pass a driving test before we can get a license. We might have to pass a physical fitness test before starting a job. And manufacturers have to test or stress their products to make sure they are fit for purpose. As David Ogilvy, the father of advertising once quipped, “Never stop testing, and your advertising will never stop improving.” But it’s not just manufacturers who should test products. Consumers, or their representatives, should test products on offer — not only to corroborate (or dispute) manufacturers’ claims but also to compare one manufacturer’s product against another. There’s a whole slew of magazines, television programs, and web resources devoted to testing and comparing everything from laundry detergent to automobiles. And GNSS receivers are no exception.
When we conduct tests, we are usually trying to get answers to certain questions — just like those posed to students on their exams. In testing GNSS receivers, what are some appropriate questions? When a receiver is turned on, how long does it take until the position of the receiver is determined? When a weak signal area is encountered, can the receiver still determine its position? If the signal is interrupted and then restored, how long does it take for the receiver to recover and resume calculating its position? And what is the position accuracy under different situations?
While we can certainly hook up an antenna to a receiver to get answers to these questions in a certain environment on a certain day at a certain time with certain signals, the scenario cannot be repeated — not exactly. If we tweak a receiver operating parameter, for example, we don’t know for certain whether any observed change is due to the tweaking or a change in the scenario. We could use a radio-frequency (RF) simulator — a device for mimicking the radio signals generated by the satellites. This would allow us to define scenarios, including receiver trajectories, and to replay them as many times as necessary while varying the operating parameters of the receiver. Or we could modify the scenario from run to run. Such test scenarios could include those difficult to carry out with live signals such as determining how a receiver would perform in low Earth orbit. While extremely useful, these are tests with simulated signals.
Is there a way to perform repeatable tests on GNSS receivers using real signals? In this month’s column, we learn how to use an RF vector signal analyzer to digitize and record live signals, and then play them back to a GNSS receiver with an RF vector signal generator — a procedure we can repeat as often as we like.
While GNSS simulators have long provided the de facto technique for testing GPS receivers, radio frequency (RF) record and playback has emerged as an innovative method to introduce real-world impairments to GNSS receivers. In this article, we will provide a hands-on tutorial on how to test a navigation device using the record and playback technique.
The premise of RF record and playback is to capture GNSS signals off the air with a vector signal analyzer (VSA) and then replay them to a receiver with an RF vector signal generator (VSG). With recorded GNSS signals, one is able to introduce a signal that contains natural impairments — instead of an ideal signal — to the GNSS receiver. As a result, one can observe how a receiver will behave in a real-world environment where interference, multipath fading, and other impairments are present.
A VSA combines traditional superheterodyne radio receiver technology with high-speed analog-to-digital converters and digital signal processors to perform a variety of measurements on complex modulated signals. It is widely used in the telecommunications industry as a test instrument. Digitized signals can be recorded for future analysis. A VSG reverses the process, taking a digital representation of a complex waveform and, using digital-to-analog converters, generating an appropriately modulated RF signal.
Recording GPS or GLONASS signals off the air can be done in a fairly straightforward manner. An RF recording system combines appropriate antennas, amplifiers, and an RF signal recorder (usually a VSA) to capture many hours of continuous RF signal. In such a system, the basic components include the RF front end, the RF signal-acquisition device, and high-volume storage media. A block diagram of a typical recording system is shown in Figure 1.
Figure 1. GPS receivers implement cascaded low-noise amplifiers. The RF signal acquisition block includes analog-to- digital conversion (ADC) and digital down conversion (DDC) to select the data of interest.
In the figure, the RF front end is designed to condition the GNSS signal in such a way that it can be captured — with maximum dynamic range — by the recording device. The recording device digitizes a given signal bandwidth, and then stores in-phase and quadrature (IQ) waveforms to disk.
In general, RF recording devices are designed to tune to a broad range of frequencies and can thereby record many different types of signals. Thus, selecting the signal to record is as simple as setting the center frequency and bandwidth of the recording device. For example, to record the GPS C/A-code L1 signal, the center frequency should be set to 1575.42 MHz. Because each satellite generates the same carrier frequency, one can capture C/A-code signals from all satellites simply by capturing all signals within a 2.046 MHz (twice the code chipping rate) band around the carrier frequency.
By contrast, recording GLONASS signals requires slightly different settings. Because the GLONASS constellation uses frequency division multiplexing, every satellite generates the same code, but each pair of antipodal satellites transmits at a unique center frequency. Thus, recording L1 signal information for the entire GLONASS constellation requires a recorder to capture signals that range from 1598.0625 MHz (channel -7) to 1605.375 MHz (channel 6). In order to capture the entire bandwidth of each satellite, a recorder is actually required to capture 1.022 MHz of signal for each carrier (again, twice the code chipping rate). Therefore, the total recording bandwidth is actually 1597.5515 MHz to 1605.886 MHz, a span of 10.3345 MHz. On the RF signal analyzer, one can record GLONASS signals simply by setting the center frequency to 1601.71875 MHz, and the bandwidth to ≥ 10.3345 MHz.
Modern RF signal recorders are capable of recording both GPS and GLONASS C/A-code signals on a single wideband recording channel. For example, one of our RF signal analyzers is capable of recording up to 50 MHz of signal bandwidth. With this instrument, one can simultaneously record both GPS and GLONASS by setting the center frequency to 1590.1415 MHz and the bandwidth to ≥ 31.489 MHz. However, while RF recording systems can be used to capture a wide range of GNSS signals including GPS L1/L2/L5, GLONASS L1/L2, Galileo, and others, this article focuses primarily on the GPS C/A-code signal.
Setting up the RF Front End
The trickiest aspect of recording GPS signals is the selection and configuration of the appropriate antenna and low noise amplifier (LNA). When connecting a typical off-the-shelf GPS passive patch antenna to a signal analyzer, the peak power in the GPS L1 band ranges from -120 to -110 dBm. Because the power level of GPS signals is small, significant amplification is required to ensure that the VSA can capture the full dynamic range of the signal.
The simplest method to amplify an off-the-air GPS signal so that it can be captured by an RF signal recorder is the combination of an active GPS antenna and one or more external LNAs. Note that many professional GPS antennas offer the best performance because they combine high element gain with an LNA and even pre-selection filtering, which improves the dynamic range of the RF recorder.
With the RF front end appropriately configured, one can verify system performance using a simple spectrum analyzer demonstration panel. The demo panel allows one to visualize the RF spectrum in the GPS L1 band. If all is set up correctly, the C/A-code GPS signal should be visually present on the display. Figure 2 illustrates a screenshot of the spectrum on a virtual spectrum analyzer display.
Note that visualizing the GPS signal in the frequency domain with an RF signal recorder (or spectrum analyzer) requires careful attention to settings such as resolution bandwidth and averaging. Because the signal-to-noise ratio (SNR) of the GPS signal is so small, the settings shown in Figure 2 require a narrow resolution bandwidth (10 Hz) and significant averaging (20 averages per measurement record, so a 20-second interval for 1 Hz data). With these settings applied, one can easily visualize a modulated signal above the noise floor with approximately 1 MHz of bandwidth and centered at 1575.42 MHz. This signal is the GPS C/A-code. In Figure 2, the reference level of the signal analyzer was set to -50 dBm to reduce the noise floor of the instrument to the lowest possible level. Note that setting the signal analyzer’s reference level provides a simple mechanism to adjust the front-end attenuation or amplification. In general, RF signal analyzers provide the greatest dynamic range when the reference level of the instrument matches closely with the average power of the signal connected to the front end. In this case, setting the reference level of our signal analyzer to -50 dBm removes all front-end attenuation, giving the analyzer a more optimal noise figure for signal recording.
Figure 2. GPS is visible in the spectrum only if a narrow resolution bandwidth is used. This spectrum was obtained with a center frequency of 1575.42 MHz, a frequency span of 4 MHz, a resolution bandwidth of 10 Hz, root-mean-square averaging with 20 averages, and a reference level of 250 dBm.
Hardware Connections
With the reference level appropriately set, it is important to properly configure the RF front end of the recording device. As previously mentioned, one can achieve the best RF recording results by using an active GPS antenna. The active antenna used in our experiment utilized a built-in LNA to provide up to 30 dB of gain with a 1.5 dB noise figure. (Recall that the noise figure is the difference in dB between the noise output of a device and the noise output of an “ideal” device with the same gain and bandwidth when it is connected to sources at the standard noise temperature — usually 290 K.) However, the LNA must be powered by supplying a DC bias to the RF connection. While there are several methods to supply the DC bias, we will look at two of the easiest methods.
Method 1: Active Antenna Powered by GPS Receiver. The first method to power an active antenna is with a bias tee or DC power injector. Using this three-port component, a DC voltage (3.3 V in this case) is fed to its DC port, which applies the appropriate DC offset to the active antenna connected to the RF-in port while blocking it on the RF-out port. The device gets its name from the fact that the three ports are often arranged in the shape of a “T.” Note that the precise DC voltage one should apply depends on the DC power requirements of the active antenna. A diagram illustrating the connections is shown in Figure 3.
Observe in Figure 3 that one can use off-the-shelf hardware such as a programmable DC power supply to supply the DC bias signal. Also, one can use a generic off-the-shelf bias tee as long as it has bandwidth up to 1.58 GHz.
Figure 3. This set-up shows the use of a DC bias tee to power an active GPS antenna.
Method 2: Active GPS Antenna Powered by Receiver. A second method of powering the active GPS antenna is with the receiver itself. Most off-the-shelf GPS receivers use a single port to power and receive signals from an active GPS antenna, and this port is already biased with an appropriate DC voltage. Combining an active GPS receiver, a power splitter, and a DC blocker, one can power an active LNA and simply record essentially the same signal as that observed by the GPS receiver. A diagram of the appropriate connections is shown in Figure 4. Some splitters incorporate a DC block on all but one of the output ports.
As Figure 4 illustrates, the DC bias from the GPS receiver is used to power the LNA. This method is particularly useful for drive tests because one can observe the receiver’s characteristics, such as velocity and dilution of precision, while recording.
Figure 4. With a DC blocker, one can record and analyze the same GPS signals being tracked by a GPS receiver.
Selecting the Right LNA
Recording GPS signals with generic RF signal recorders is possible largely because external LNAs can be used to reduce the effective noise floor of the receiver. Today, one can find off-the-shelf spectrum analyzers with noise figures ranging from 15 dB to 20 dB. One of our analyzers, for example, has a 15 dB noise figure while applying up to 60 dB of gain. By applying external amplification to the front of an RF signal analyzer, however, one can substantially reduce the noise figure of the RF recording system.
To calculate the total noise that will be added to the recorded GPS signal, one must calculate the noise figure for the entire RF front end. As a matter of principle, the noise figure of the entire system is always dominated by the first amplifier in the system. Thus, careful selection of the first and second stage LNAs is crucial for a successful signal recording.
We can calculate the noise figure of the RF recording system by using the Friis formula for noise figure, named for engineer Harald Friis, a Danish-American radio engineer who worked at Bell Telephone Laboratories. To use this formula, first convert the gain and noise figure of each component to its linear equivalent; the latter is called the “noise factor.” For cascaded systems such as our RF recording system, the Friis formula provides us with the noise factor of the entire system:
(1)
Note that both noise factor (nf) and gain (g) are shown in lowercase to distinguish them as linear measures rather than logarithmic measures. The conversion from linear to logarithmic gain and noise figure (and vice v
ersa) is shown in the following equations:
An active GPS antenna using a built-in LNA typically provides 30 dB of gain while introducing a noise figure that is typically on the order of 1.5 dB. The second part of the recording instrumentation provides 30 dB of additional gain as well. Though its noise figure is higher (5 dB), the second amplifier actually introduces very little noise into the system. As an academic exercise, one can use the Friis formula to calculate the noise factor for the entire RF front end of the recording instrumentation. Gain and noise figure values are shown in Table 1.
Table 1. Noise figures and factors of the first two components of the RF front end.
According to the calculations above, one can determine the overall noise factor for the receiver:
(6)
To convert noise factor into a noise figure (in dB), apply Equation 2, which yields the following results:
(7)
As Equation 7 illustrates, the noise figure of the first LNA (1.5 dB) dominates the noise figure of the entire RF recording system. Thus, with the VSA configured such that the noise floor of the instrument is less than that of the input stimulus, one’s recording introduces only 1.507 dB of noise to the off-the-air signal.
Saving Data to Disk
Each GNSS produces slightly varying requirements for an RF recorder’s signal bandwidth and center frequency. For the GPS C/A-codes, the essential requirement is to record 2.046 MHz of RF bandwidth at a center frequency of 1575.42 MHz.
In the tests described here, we set the IQ sample rate of our RF recorder at 5 megasamples per second (Ms/s). Since each 16-bit I and Q sample is 32 bits (or 4 bytes each), the actual recording data rate is 20 megabytes per second (MB/s) to ensure the entire bandwidth was captured. Capturing more than 4 MHz of bandwidth is sufficient to record the 2.046 MHz C/A-code signals.
Because one can achieve data rates of 20 MB/s or more with standard PXI controller hard drives (PXI is the open, PC-based platform for test, measurement, and control), one does not need to use an external redundant array of independent disks (RAID) volume to stream GPS signals to disk when using a PXI recording system. In general, data rates exceeding 20 MB/s require the use of an external RAID volume. External RAID systems are capable of storing more than 600 MB/s of data and can be used to support wide bandwidth channels or even multi-channel recording applications. For example, the recording system shown in Figure 5 uses an external RAID volume for high-speed signal recording. This system combines PXI RF signal generators and analyzers with external amplifiers and filter banks for a ready-to-use GNSS record and playback solution.
Figure 5. Two-channel record and playback system from Averna.
In our tests, we decided to use a 320 GB USB drive for better portability. With a disk speed of 5400 revolutions per minute, we were able to benchmark it ahead of time and observed that we were able to achieve read and write speeds exceeding 25 MB/s. Thus, we were easily able to use this disk drive and still record IQ samples at 5 MS/s (20 MB/s) when recording off-the-air signals. With the existing hard-drive setup, we could record more than 4 hours of continuous IQ signal. Note that capturing longer recordings simply requires a larger hard disk. By using a 2 terabyte RAID volume (the largest addressable disk size in the Windows XP operating system), we can extend our recording time to 25 hours. With this setup, we could also reduce the IQ sample rate to 2.5 MS/s (still sufficient to capture the GPS C/A-code signals) and extend the recording time to 50 hours.
Receiver Performance
Once the off-the-air signal of a GNSS band is recorded to disk, it can be re-generated and fed to a receiver using an RF signal generator. With an RF signal generator that is able to reproduce the real-world GNSS signal, engineers are able to test a wide range of receiver characteristics. Because recorded signals contain a rich set of channel impairments such as ionosphere distortion and interference from other transmitters, design engineers often use recorded signals to prototype the baseband processing algorithms on a GNSS receiver.
In our case, we used a VSG directly connected to a GPS evaluation board. In the experiments described below, the receiver’s latitude, longitude, and velocity were tracked over time. Data was read from the receiver using a serial port, which read NMEA 0183 sentences at a rate of one per second. NMEA 0183 is a standard protocol developed by the National Marine Electronics Association for communications between marine electronic devices. NMEA 0183 has been adopted by virtually all GPS receiver manufacturers. In our LabVIEW graphical development environment, one can parse all sentences to return satellite and position-fix information.
For practical testing purposes, GPS dilution of precision and active satellites (GSA), GPS satellites in view (GSV), course over ground and ground speed (VTG), and GPS fix data (GGA) sentences are the most useful. More specifically, one can use information from the GSA sentence to determine whether the receiver has achieved a position fix and is used in time-to-first-fix measurements. When performing sensitivity measurements in this example, the GSV sentence was used to return carrier-to-noise-density ratios (C/N0) for each satellite being tracked. In addition, the VTG sentence allows us to observe the velocity of the receiver. Finally, the GGA sentence provides the receiver’s precise position by returning latitude and longitude information. See the references in Further Reading for in-depth information on the NMEA 0183 protocol.
Using the receiver’s reported latitude and longitude information, we are able to test its ability to report a repeatable position when the recorded signal is played back to the receiver. In this experiment, we tracked the receiver position over 10 minutes. For the best results, the command interface of the receiver should be tightly synchronized with the start trigger of the RF signal generator. The results in Figure 6 show that the RF vector signal generator in this experiment was synchronized with the GPS receiver by using the data line of the serial communications (COM) port (RxD, pin 2) as a start trigger. Using this synchronization method, the vector signal generator and GPS receiver were synchronized to within one clock cycle of the VSG’s arbitrary waveform generator (100 MS/s). Thus, the maximum skew should be limited to 10 microseconds. Given our receiver’s maximum velocity of 15 meters per second (our maximum speed on the drive test), we can determine that the maximum error induced by clock offset of the signal generator is 10 microseconds x 15 meters per second, or 0.15 millimeters.
Using the configuration described above, one is able to report the receiver’s latitude and longitude over time, as shown in Figure 6.
Figure 6A. Receiver latitude over a four-minute span.Figure 6B. Receiver longitude over a four-minute span.
As the data from Figure 6 illustrate, a recorded test-drive signal reports static, position, and velocity information. In addition, one can observe that this information is relatively repeatable from one trial to the next, as evidenced by the difficulty in graphically observing each individual trace. To better characterize the deviation between each trace, one can also compute the standard deviation between each sample in the waveforms. Figure 7 illustrates the standard deviation between each of the 10 trials, calculated for every one-second interval, versus time.
Figure 7. Standard deviation of both latitude and longitude over time.
When observing the horizontal standard deviation, it is interesting to note that the standard deviation appears to rapidly increase at time = 120 seconds. To investigate this phenomenon further, we can plot the total horizontal standard deviation against the receiver’s velocity and a proxy for C/N0. In this case, we simply averaged the C/N0 values for the four highest satellites reported by the receiver. Since four satellites are required to achieve a three-dimensional position fix, our assumption was that position accuracy would closely correlate with the signal strength of these important satellite signals.
One simple method to evaluate the horizontal repeatability of the receiver position versus time is to calculate the standard deviation on a per-sample basis of each recorded latitude and longitude (in degrees). Once the standard deviation is measured in degrees, we can roughly convert this to meters with the following equation:
Note that Equation 8 represents a highly simplified error calculation method, which assumes that the Earth is a perfect sphere. For a more precise calculation of repeatability, the geodesic formula (which presumes that the Earth is ellipsoidal) should be used. In our simple experiment, the goal is merely to correlate repeatability with other factors that we can measure from the receiver. Figure 8 illustrates the standard deviation of horizontal position repeatability over 10 trials and at one-second time intervals.
Figure 8. Correlation of position accuracy and C/N0.
As one can observe in Figure 8, the peak horizontal error (measured by standard deviation) occurring at time = 120 seconds is directly correlated with satellite C/N0 and not correlated with receiver velocity. At this sample, the standard deviation is nearly 2 meters while it is less than 1 meter during most other times. Concurrently, the top four C/N0 averages drop from nearly 45 dB-Hz to 41 dB-Hz.
The exercise above illustrates not only the effect of C/N0 on position accuracy but also the types of analysis that one can conduct using recorded GPS data. For this experiment, the drive recording of the GPS signal was conducted in Huizhou, China (a city north of Shenzhen), but the actual receiver was tested at a later date in Austin, Texas.
Conclusion
In this article, we’ve illustrated how to use commercially available off-the-shelf products to record GPS signals with an RF recorder, and then play the signal back to a receiver. As the results illustrate, recorded GPS signals can be used to measure a wide range of receiver characteristics. Not only can receiver designers use these test techniques to better prototype a receiver baseband processor, but also to measure system-level performance such as position repeatability.
Manufacturers
The tests discussed in this article used a National Instruments PXIe-5663E, 6.6 GHz, RF signal analyzer; a National Instruments PXI-5690, 100 kHz to 3 GHz, two-channel programmable amplifier and attenuator; a National Instruments PXIe-5672, 2.7 GHz, RF vector signal generator with quadrature digital upconversion; a 320 GB USB Passport hard drive from Western Digital Corp.; a National Instruments PXI-4110 programmable, triple-output, precision DC power supply; and a ZX85-12G-S+ bias tee manufactured by Mini-Circuits. The article also mentioned the RP-3200 2-channel record and playback system manufactured by Averna, which incorporates National Instruments modules.
David Hall is an RF product manager for National Instruments. He holds a bachelor’s of science with honors in computer engineering from Pennsylvania State University.
FURTHER READING
More on GNSS Receiver Record and Playback Testing
GPS Receiver Testing, tutorial published by National Instruments, Austin, Texas.
Friis Formula and Receiver Performance
RF System Design of Transceivers for Wireless Communications by Q. Gu, published by Springer, New York, 2005.
Global Positioning System: Signals, Measurements, and Performance, 2nd edition, by P. Misra and P. Enge, published by Ganga-Jamuna Press, Lincoln, Massachusetts, 2006.
“Measuring GPS Receiver Performance: A New Approach” by S. Gourevitch in GPS World, Vol. 7, No. 10, October 1997, pp. 56-62.
“GPS Receiver System Noise” by R.B. Langley in GPS World, Vol. 8, No. 6, June 1997, pp. 40–45.
Global Positioning System: Theory and Applications, Vol. I, edited by B.W. Parkinson and J.J. Spliker Jr., published by the American Institute of Aeronautics and Astronautics, Inc., Washington, D.C., 1996.
GNSS Receiver Testing Using Simulators
“Testing Multi-GNSS Equipment: Systems, Simulators, and the Production Pyramid” by I. Petrovski, B. Townsend, and T. Ebinuma in Inside GNSS, Vol. 5, No. 5, July/August 2010, pp. 52–61.
“GPS Simulation” by M.B. May in GPS World, Vol. 5, No. 10, October 1994, pp. 51–56.
GNSS Receiver Testing Using Software
“GPS MATLAB Toolbox Review” by A.K. Tetewsky and A. Soltz in GPS World, Vol. 9, No. 10, October 1998, pp. 50–56.
GNSS L1 Signal Descriptions
Navstar GPS Space Segment / Navigation User Interfaces, Interface Specification, IS-GPS-200 Revision E, prepared by Science Applications International Corporation, El Segundo, California, for Global Positioning System Wing, June 2010.
Global Navigation Satellite System GLONASS, Interface Control Document, Navigational Radio Signal in Bands L1, L2 (Edition 5.1), prepared by Russian Institute of Space Device Engineering, Moscow, 2008.
NMEA 0183
NMEA 0183, The Standard for Interfacing Marine Electronic Devices, Ver. 4.00, published by the National Marine Electronics Association, Severna Park, Maryland, November 2008.
“NMEA 0183: A GPS Receiver Interface Standard” by R.B. Langley in GPS World, Vol. 6, No. 7, July 1995, pp. 54–57.
