Testing GNSS receiver systems in real-world conditions is limited by unpredictability, legal restrictions, and the inability to replicate scenarios. CAST Navigation addresses this challenge with advanced simulation technology that creates controlled, repeatable satellite signal environments.
When testing a GNSS, comprehensive testing usually isn’t possible when relying on live satellite signals, according to CAST Navigation. In a live environment, engineers can’t determine the exact cause of errors, which can slow development and increase risk, so it’s impossible to establish controlled conditions suitable for experimentation and isolate specific variables without using a controlled signal environment.
A valid experiment requires repetition of identical scenarios because it enables engineers to validate assumptions, debug faults and compare performance. Without this consistent verification, it’s impossible to put confidence in a satellite system, CAST Navigation said.
Also, certain GNSS conditions can’t be put into practice in the real world for testing purposes. For example, spoofing or jamming satellite signals is usually illegal because such activities could cause interference or harm in other systems. Also, environmental effects like atmospheric interference or terrain obstruction can’t be easily configured or isolated in a live testing scenario.
Improving reliable testing
A controlled simulation environment that can generate repeatable GNSS conditions enables engineers to conduct reliable testing and validation. CAST Navigationprovides such a highly realistic and reliable simulated satellite signal environment, enabling organizations to conduct rigorous testing of guidance systems and positioning technologies. By creating artificial signals that can be precisely repeated as many times as necessary, engineers can get the data they need without the difficulties and restrictions of operating in a real-world environment.
Multi-constellation frequencies available
At the core of this technology from CAST Navigation is the ability to generate multi-constellation GNSS signals across multiple frequencies, such as GPS, GLONASS and BeiDou. These systems are highly adaptable to all kinds of experimental conditions. They support simultaneous simulation of multiple satellite systems at once, allowing engineers to account for variables like terrestrial movement and space-based trajectories.
Using advanced motion modeling, engineers can use CAST’s system to simulate position, orientation and complex motion patterns in real time. But CAST Navigation technology isn’t just modeling satellite movement. It’s also modeling the environment the satellites are operating in, with variables such as atmospheric interference (such as ionospheric delay) fully integrated into the testing environment.
Engineers can test their production systems in both ideal and adverse environments, such as one where satellite signals are being jammed. This makes CAST Navigation systems suitable for both military and commercial applications, particularly when engineers are trying to design resilient and flexible GNSS systems.
BroadSim Wavefront Simulator at work. (Image: Talen-X)
Talen-X has added the BroadSim Wavefront Simulator to its software-defined platform.
The BroadSim Wavefront further extends the capabilities achieved by BroadSim Anechoic, incorporating support for controlled radiation pattern antenna (CRPA) and multi-element receiver testing.
BroadSim, powered by Skydel SDX, has brought new innovations to the forefront each year to meet the growing needs of Talen-X’s customers, and the new wavefront simulator is the latest advancement.
Its features include:
Phase-coherent simulation
Real-time automated phase calibration
Scalable from 4 to 16 elements
Advanced jamming and spoofing scenarios.
Talen-X engineers are approaching delivery of an operational demonstration unit, as well.
BroadSense Nano
The BroadSense Nano GPS jamming sensor is the newest addition to Talen-X’s BroadSense product line. It has the smallest size, weight and power of any BroadSense product.
The video below features shows a prototype of the Nano, as well as information about its features and a demonstration of the unit reacting to various jamming waveforms in real time.
Skydel SDX Release 17.1 adds a fine level of control on signal multipath to the software-defined GNSS simulator.
SDX 17.1 introduces a powerful multipath simulation option, enabling users to create less-than-ideal signal propagation conditions for GNSS testing. Multipath echoes can be added and fined-tuned for each satellite, per signal. Control is possible via four fundamental attributes: pseudorange offset, power loss, Doppler shift and carrier-phase offset.
It’s now convenient to create simplified test conditions otherwise impossible to achieve with the live sky. The new options are fully controllable through the SDX application program interface (API), and can be modified on the fly while the simulation is running.Release 17.1 also adds L2C navigation message modification. Besides the usual conditions such as start and stop time and PRN number, users can specify the message type, and the message content to match.
Because the CNAV message is 300 bits long and not subdivided in words like the NAV message, managing the modifications as a per-bit fashion would be tedious. The interface solves this by letting you add modifications for portions of the message — and lets users add as many as they need.
Software-defined radios (SDR) can take a few seconds to initialize when starting the simulation. To improve software synchronization performance, Skydel has added an armed state. Upon clicking the arm button (or issuing the command through the API), the armed state prepares all hardware. When the start command is later received, the delay to emit the GNSS signals is minimal.
Other updates have also been made. See the release notes for the full list. As always, existing licensees benefit from an immediate upgrade.
Among the next items on SDX’s development agenda is the release of advanced jamming capabilities through an innovative integration with the GNSS simulator.
By Thorsten Lück, Günter Heinrichs, IFEN GmbH, and Achim Hornbostel, German Aerospace Center
This article discusses the GALANT adaptively steered antenna array and receiver and demonstrates the test scenarios generated with the GNSS simulator. Exemplary results of different static and dynamic test scenarios are presented, demonstrating the attitude determination capabilities as well as the interference detection and mitigation capabilities.
The vulnerability of GNSS to radio frequency interference and spoofing has become more and more of a concern for navigation applications requiring a high level of accuracy and reliability, for example, safety of life applications in aviation, railway, and maritime environments.In addition to pure power jamming with continuous wave (CW), noise or chirp signals, cases of intentional or unintentional spoofing with wrong GNSS signals have also been reported.
Hardware simulations with GNSS constellation signal generators enable the investigation of the impact of radio interference and spoofing on GNSS receivers in a systematic, parameterized and repeatable way. The behavior of different receivers and receiver algorithms for detection and mitigation can be analyzed in dependence on interference power, distance of spoofers, and other parameters. This article gives examples of realistic and advanced simulation scenarios, set up for simulation of several user antennas simultaneously.
The professional-grade high-end satellite navigation testing and R&D device used here is powerful, easy to use, and fully capable of multi-constellation / multi-frequency GNSS simulations for safety-of-life, spatial and professional applications. It provides all L-band frequencies for GPS, GLONASS, Galileo, BeiDou, QZSS, SBAS and beyond in one box simultaneously. It avoids the extra complexity and cost of using additional signal generators or intricate architectures involving several hardware boxes, and offers full control of scenario generation. A multi-RF capable version provides up to four independent RF outputs and a master RF output that combines the RF signal of each of the up to four individual RF outputs.
Each individual RF output is connected to one or more “Merlin” modules (the core signal generator module for one single carrier) allowing simulation of up to 12 satellites per module. Because of the flexible design of the Merlin module, each one can be configured to any of the supported L-band frequencies.
As one chassis supports up to nine individual Merlin modules, different Multi-RF combinations are feasible:
two RF outputs with up to four modules each
three RF outputs with up to three modules each
four RF outputs with up to two modules each.
With these configurations, the user can simulate different static or dynamic receivers or even one receiver with multiple antennas, covering such challenging scenarios as ground networks, formation flying or use of beam-forming antennas.
As the user is free to assign each individual module to a dedicated simulated antenna, the user could also employ up to nine modules to simulate nine different carrier signals for one single antenna using the master RF output, thus simulating the complete frequency spectrum for all current available GNSS systems in one single simulation.
All modules are calibrated to garantee a carrier phase coherency of better than ±0.5°. Figure 1 shows the output at the RF master of two modules assigned to the same carrier but with a phase offset of 180°.
Figure 1. Carrier-phase alignment of the high-end simulator with six modules compared to the first module.
Theoretically, the resulting signal should be zero because of the destructive interference. In practice, a small residual signal remains because of component tolerance, small amplitude differences and other influences. Nevertheless the best cancellation can be seen at this point. The phase accuracy can now simply be estimated from the measured power level of the residual signal:
(1)
(2)
with
This means that the sum of two sine waves with the same frequency gives another sine wave. It has again the same frequency, but a phase offset and its amplitude is changed by the factor A. The factor A does affect the power level. If φ is 180° then A is 0, which means complete cancellation.
So A shows the power of the resulting signal relative to the single sine wave. It can also be transformed to dB:
(3)
Figure 2 shows the carrier suppression as a function of carrier phase offset with a pole at 180ϒ.
Figure 2. Carrier suppresion as a function of phase delay.
The factory calibration aligns the modules to a maximum of 0.5ϒ misalignment. The measured suppresion therefore shall be better than 41.18 dBc. In practice, the residual signal is also caused by other influences, so that the actual phase alignment can be expected to be much better.
With four RF outputs, the received signal of a four element antenna can be configured very easily. Figure 3 shows the dialog to configure a four-element antenna with the geometry shown in Figure 4. Note that the antenna elements are configured in the body-fixed system with the x-axis to front and the y-axis to the right (inline with a north-east-down, NED, system when facing to north), while the geometry shown in Figure 4 follows an east-north-up (ENU) convention.
Figure 3. Configuration of individual antennas per receiver.
Figure 4. Geometry of the GALANT four-element phased-array antenna (view from top).
The following sections give an overview of multi-antenna systems and discuss results from a measurement campaign of the German Aerospace Center (DLR) utilizing the simulator and the DLR GALileo ANTenna array (GALANT) four-element multi-antenna receiver.
Multi-Antenna Receivers
Multi-antenna receivers utilize an antenna array with a number of antenna elements. The signals of each antenna element are mixed down and converted from analog to digital for baseband processing. In the baseband, the signals received by the different antenna elements are multiplied with complex weighting factors and summed. The weighting factors are chosen in such a way that the received signals from each antenna element cancel out into the direction of the interferers (nulling) and additionally, for advanced digital beamforming, such that the gain is increased into the direction of the satellites by forming of individual beams to each satellite. Because all these methods work with carrier phases, it is important that in the simulation setup, the signals contain the correct carrier phases at the RF-outputs of the simulator corresponding to the user satellite and user-interferer geometry, and the position and attitude of the simulated array antenna.
Figure 5 presents the geometry of a rectangular antenna array with 2×2 elements and a signal s(t) impinging from direction (ϕ, θ).
Figure 5. Parallel wavefront impinging on a rectangular array with 2×2 elements.
The spacings of the elements dx, dy are typically half a wavelength, but can also be less. The range difference for antenna element i relative to the reference element in the center of the coordinate system depends on the incident direction (ϕ, θ) and the position (m=0,1, n=0,1) of the element within the array:
(4)
The corresponding carrier phase shift is:
(5)
For CRPA and adaptive beam forming applications, the differential code delays may be neglected if they are small compared to the code chip length. However, it is essential that the carrier phase differences are precisely simulated, because they contain the information about the incident direction of the signal and are the basis for the array processing in the receiver. For instance, the receiver can estimate the directions of arrival of the incident signals from these carrier phase differences.
Now we consider a 2×2 array antenna. It can be simulated with the simulator with four RF outputs, where each output corresponds to one antenna element. In the simulator control software, a user with four antennas is set up, where the position of each antenna element is defined as an antenna position offset relative to the user position. In this approach, both differential code and carrier delays due to the simulated array geometry are taken into account, because the code and carrier pseudoranges are computed by the simulator for the position of each antenna element. However, the RF hardware channels of the receiver front-end may have differential delays against each other, which may even vary with time. If the direction of the satellites and interferers shall be estimated correctly by the receiver algorithms, a calibration signal is required to measure and compensate these differential hardware delays.
For the real antenna system, a binary phase-shift keying (BPSK) signal with zero delay for each antenna channel is generated by the array receiver and fed into the antenna calibration port. For the simulation, this calibration signal must also be generated by the constellation simulator.
In a simple way, a satellite in the zenith of the user antenna can be simulated, which has the same distance and delay to all antenna elements. Unfortunately, this simple solution includes some limitations to the simulated position and attitude of the user, because the user position must be at the Equator (if a “real” satellite is simulated in form of a geostationary satellite) and the antenna must not be tilted.
With a small customization of the simulator software, these limitations could be overcome. Figure 6 shows how to set up the generation of a reference signal. This reference signal can either be simulated as a transmitter directly above the user position, which follows the user position and thus allows also simulations offside the Equator, or simulated as a zero-range signal on all RF outputs, neglecting any geometry, which is the preferred method. The latter one is more or less identical to the reference/calibration signal generated by the receiver itself.
Figure 6. Configuration of a modulated reference signal.
The power level of this signal is held constant and is not affected by any propagation delay or attenuation simulated by the control center.
Attitude Determination
According to Figure 5, the phase difference measured between antenna elements is a function of the direction of arrival (DoA). Thus, the DoAs of the incident signals can be estimated from the phase differences. In the GALANT receiver, the DoAs are estimated by an EPSPRIT algorithm after correlation of the signals. Compared with the (known) positions of the GNSS satellites, this allows the estimation of the antenna array attitude. Figure 7 shows the sky-plot of simulated satellites as seen at receiver location (simulated on the right; reconstructed by the receiver from the decoded almanac in the middle and the DoA on the left). By comparison of the estimated DoAs of all satellites and the skyplot from the almanac, the attitude of the antenna is estimated (left). In addition, the attitude angles simulated by the simulator is given (right).
Figure 7. Simulating and estimating attitude with a multi-element antenna.
Simulation of Interference
It is possible to simulate some simple types of interference. Possible interference scenarios are:
Wideband Noise. By increasing the power of a single satellite of the same or another GNSS constellation, a wideband pseudo-noise signal can be generated. Using a geostationary satellite also enables simulating an interference source at low elevations and constant position. Use of power-level files also allow generation of scenarios with intermittent interference (switching on and off the interference) with switching rates up to 5 Hz.
CW or Multi-Carrier IF. By disabling the spreading code and navigation message, a CW signal can be generated. The simulator also allows configuration of subcarrier modulations. Without spreading code (or to be precise with a spreading code of constant zero) the generated signal will consist of two carriers symmetrically around the original signal carrier (for example, configuring a BOC(1,1) signal will create two CW signals at 1.57542 GHz ± 1.023 MHz, thus producing “ideal” interferer for the Galileo E1 OS signal.)
Depending on the number of Merlin modules per RF output, interference to signal ratios up to 80 dB could be realized, limited by a dynamic range of 40 dB within one module and additional 40 dB range between two modules. However, the maximum power level of one individual signal is currently limited to -90 dBm. If only one channel per module is used, the maximum power level of this single signal can be increased by another 18 dB (for example, by using one module solely for interference generation and another module for GNSS simulation).
Figure 8 shows the simulated geometry for an interference scenario based on wideband noise generated by a geostationary satellite, producing –90 dBm signal power at the receiver front end. The interference source is very near to the direction of PRN 22 with a jammer power of –90 dBm, resulting in a jammer to signal ratio of J/S = 25 dB.
Figure 8. Geometry for the wideband noise interference scenario.
Figure 9 shows the two-dimensional antenna pattern as a result of the beam-forming before and after switching on the interferer. The mitigation algorithm tries to minimize gain into the direction of the interferer. As this also decreases gain into the direction of the intended satellite, the C/N0 drops by approximately 10 dB for PRN 22, because its main beam is shifted away from the interference direction. For satellites in other directions, the decrease in C/N0 is less: compare Figure9with Figure 10. However, the receiver still keeps tracking the satellite. After switching of beamforming, the signal is lost.
Figure 9. Beamforming for PRN 22 (light green line in lower plot) to mitigate for interference.
Figure 10. Tracking is lost after switching off beamforming for individual channels (light blue, purple) and all channels (at the end of the plot).
Simulation of Spoofing
The simulation of a spoofing signal requires twice the resources as the real-world scenario, as every “real” LoS-signal must also be generated for the spoofing source. A simulation of an intentional spoofer who aims to spoof a dedicated position in this context is, however, very similiar to the simulation of a repeater ([un-]intentional interferer) device:
The repeater (re-)transmits the RF signal received at its receiver position. A receiver tracking this signal will generate the position of the repeater location but will observe an additional local clock error defined by the processing time within the repeater and the travel time between repeater and receiver position. A correct simulation for a multi-antenna receiver therefore has to superpose the code and carrier range as observed at the repeater location (considering geometric range between the transmit antenna of the repeater and the individual antenna elements) with the code and carrier ranges at the receiver location.
Instead of the location of the repeater P2, however, any intended location Px could be used to simulate an intelligent spoofer attack (Figure 11).
The simulator can generate such scenarios by configuring the position of the (re-)transmitting antenna and the intended position (for example, the position of the repeater). By calculating the difference between the real receiver position and the position of the transmitting antenna, the additional delay and free-space loss can be taken into account. The user may also configure the gain of the transmit antenna and the processing time within the repeater. Currently, this setup does only support one “user” antenna to be simulated. However, this feature combined with multi-antenna support will enable the simulator to simulate repeater or intelligent spoofer attacks in the future (Figure 12). To distinguish the “real” signal from the “repeated” signal, the “repeated” signal could be tagged as a multipath signal. This approach would allow simulation of the complete environment of “real” and “repeated” GNSS signals in one single simulator.
Figure 11. Geometry of repeater/spoofer and GNSS receiver.
Figure 12. Simulator’s capability to simulate a repeater.
Manufacturers
The simulator producing the results described here is the NavX-NCS from IFEN GmbH. The simulator is valuable laboratory equipment for testing not only standard or high-end single-antenna GNSS receivers, but also offers additional benefit for multi-antenna GNSS receivers like the DLR GALANT controlled reception pattern antenna system.
The GNSS constellation simulator offers up to four phase-coherent RF outputs, allowing the simulation of four antenna elements with two carrier frequencies, each utilizing one single chassis being 19 inch wide and 2 HU high.
Simulation of intentional and unintentional interference is a possible feature of the simulator and allows receiver designers and algorithm developers to test and enhance their applications in the presence of interference to identify, locate and mitigate for interference sources.
Thorsten Lück studied electrical engineering at the universities in Stuttgart and Bochum. He received a Ph.D. (Dr.- Ing.) from the University of the Federal Armed Forces in Munich in 2007 on INS/GNSS integration for rail applications. Since 2003, he has worked for IFEN GmbH, where he started as head of R&D embedded systems in the receiver technology division. In 2012 he changed from receiver development to simulator technologies as product manager of IFEN’s professional GNSS simulator series NavX-NCS and head of the navigation products department.
Günter Heinrichs is the head of the Customer Applications Department and business development at IFEN GmbH, Poing, Germany.He received a Dipl.-Ing. degree in communications engineering in 1988, a Dipl.- Ing. degree in data processing engineering and a Dr.-Ing. degree in electrical engineering in 1991 and 1995, respectively. In 1996 he joined the satellite navigation department of MAN Technologie AG in Augsburg, Germany, where he was responsible for system architectures and design, digital signals, and data processing of satellite navigation receiver systems. From 1999 to April 2002 he served as head and R&D manager of MAN Technologie’s satellite navigation department.
Achim Hornbostel joined the German Aerospace Center (DLR) in 1989 after he received his engineer diploma in electrical engineering from the University of Hannover in the same year. Since 2000, he has been a staff member of the Institute of Communications and Navigation at DLR. He was involved in several projects for remote sensing, satellite communications and satellite navigation.In 1995 he received his Ph.D. in electrical engineering from the University of Hannover.His main activities are in receiver development, interference mitigation and signal propagation.
Spectracom has begun a program to develop robust application-specific testing solutions. The program fills what the company calls a technology and expertise gap in providing customers in a variety of industries the tools to perform more comprehensive qualification of their mission-critical systems. Examples of these industries include:
interference detection and mitigation (IDM) verification;
assisted-GNSS (A-GPS) validation,
hardware-in-the-loop (HIL) testing for automotive applications;
high-dynamic platform simulations for aerospace and defense (UAVs, UASs); and
precision agriculture/surveying testing via RTK/differential measurements.
“Our full featured platform of multi-GNSS simulation capabilities combine flexible hardware and user oriented software to deliver the functionality and user interfaces necessary for today’s demanding test scenarios,” said Spectracom CTO, John Fischer. “We understand, however, that even the most powerful tools often need something more to reduce complexity, increase productivity and ensure consistent, reliable results. Toward these ends we are excited to bring our extensive applications knowledge directly to our customers to design and deliver custom configurations and test systems that are unique to their applications.”
Today’s PNT applications combine data from a variety of receivers, sensors and other sources. Spectracom is designing its solutions to integrate simulated GNSS RF with all other data sources in the test system for true “hardware-in-the-loop” verification, the company said.
For instance, Spectracom’s new assisted-GNSS (A-GNSS) feature is designed to integrate with 3GPP/LTE testers to send “assistance data” directly to the device under test. The company takes a similar approach to testing RTK-enabled receivers with user-settable virtual base-station parameters.
“Spectracom’s value is to partner with our customers to ensure they have the ability to easily use GNSS simulation as part of a comprehensive PNT testing solution,” said Rohit Braggs, Director of Marketing and Strategy. “More testing in the lab enables faster time to market, at a reduced cost and increased reliability. We are asking developers of the most demanding PNT applications to put us to the test.”
By Sarang Thombre, Jussi Raasakka, Tommi Paakki, Francescantonio Della Rosa, Mikko Valkama, Laura Ruotsalainen, Heidi Kuusniemi, and Jari Nurmi
INNOVATION INSIGHTS by Richard Langley
WE HAVE A CAT. My wife and I do, that is. One with a voracious appetite. She likes to be fed on demand, even at the most inopportune times. Like three o’clock in the morning. No, it doesn’t help to close the bedroom door. Her squeaking (yes, some cats squeak) still wakes us up. I was designated as the one to get up in the night to feed her. Sometimes twice. Each night, every night. That got tiresome (literally) very quickly. Automation came to the rescue. We now have a microprocessor-controlled cat feeder, which rotates food compartments into the feeding position at pre-programmed times. Just fill up one or two of the compartments with “crunchies” before retiring, set the activation time to 3:00 a.m., say, and no more middle-of-the-night squeaking interrupting blissful sleep.
This is just one example of how automation — machines replacing (or supplementing) human activity to perform repetitive, difficult, undesirable, or even humanly-impossible tasks — can affect (and benefit) our everyday lives.
As noted on Wikipedia, two common types of automation are ones that involve feedback control, which is usually continuous and involves making measurements using one or more sensors and computing adjustments to keep the measured variables within a set range, and those that involve sequence control, in which a programmed sequence of discrete operations is performed, often based on system logic. An aircraft autopilot is an example of the former while our cat-feeding machine is an example of the latter. Some systems, such as Earth-orbiting satellites, can involve both types.
Automation applications range from the (now) mundane (such as point-and-shoot cameras, smart phones, home control, and factory assembly lines) to the (now) exotic (such as robots to assist the elderly and the infirm and robots to explore space). Laboratories have also benefited from increasing automation, making rapid clinical and analytical testing, for example, possible.
The testing of GNSS receivers can also benefit from automation. This work typically requires the active participation of humans to initiate, control, monitor, and terminate test cases. These manual operations are often inefficient and inaccurate, rendering the test results unreliable. Furthermore, accessing the internal signals of a receiver at different stages of processing is necessary to pinpoint the exact location of any anomalies. Using traditional black-box testing techniques, it is only possible to test the final outputs of a receiver. In this month’s column, we take a look at an automated test bench for analyzing the overall performance of multi-frequency, multi-constellation GNSS receivers. The system includes a data-capture tool to extract internal process information and controlling software, called the Automated Performance Evaluation Tool or AutoPET, which is able to communicate between all modules of the system for hands-free, one-button-click testing of GNSS receivers. Would my cat appreciate the benefit? Likely not, but GNSS engineers and scientists certainly will.
“Innovation” is a regular feature that discusses advances in GPS technology and its applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas.
The prototype GNSS receiver developed at the Department of Electronics and Communications Engineering of Tampere University of Technology (TUT), called TUTGNSS, is now in the performance-testing phase. TUTGNSS is a GPS L1/L5 + Galileo E1/E5a dual-frequency dual-constellation receiver jointly developed by TUT and its international partners under two European Union Framework Programme research grants.
During the manual testing of the receiver, it was noticed that the results were often contaminated with errors due to imprecise time-keeping and inconsistent test environments.
It was also strenuous and time consuming to perform repetitive tests over multiple iterations, with decreasing personnel efficiency as the number of iterations increased. The aforementioned problems led to the results being deemed unreliable and unrepeatable. There was thus a need to innovate and automate the testing process and environment. In addition, there was also the need to study the signals as they flowed through the internal signal processing chain, so that the exact location of anomalies could be detected.
Currently, few solutions are available in the commercial and academic domains, which can perform end-to-end fully automated, yet customizable testing of GNSS receivers. A couple of commercial testing tools were recently unveiled, which claim to perform similar automated testing of GNSS receivers. However, these are not fully customizable by the end-user, having the limitation that they can be used only with their parent company’s proprietary signal simulators. Other commercial automated testing tools are available nowadays. However, they are targeted towards electronic systems other than GNSS receivers. It was due to these reasons that we decided to implement an in-house solution. Consequently, we devised the Automated Performance Evaluation Tool (AutoPET), along with a data capture tool.
AutoPET is implemented completely in software (Qt, with C++) and communicates with the receiver under test (RUT) via RS-232 and a National Marine Electronics Association (NMEA) protocol and with a commercial GNSS signal simulator via an RS-232 link. It handles the GNSS test cases with user-defined iterations and other system settings. AutoPET has already been used for making test runs on the TUTGNSS receiver with positive results. It is possible to initiate the overall testing of the receiver with a single button-click and the results are stored in the computer without any human intervention. Test scenarios currently included in the tool’s library are: time-to-first-fix (TTFF), position accuracy, acquisition sensitivity, tracking sensitivity, and reacquisition time. By changing the scenarios in this library, the tool can be used with different simulator models. Another innovative aspect of AutoPET is that it uses multi-threading to perform the receiver testing. Multiple software processing threads are necessary to keep track of the receiver operations and simulator feeds simultaneously, so that an appropriate interrupt can be generated when the receiver has performed the desired operation. This feature is explained in further detail later on.
Data Capture Tool (dCAP) is a hybrid (software-controlled hardware) entity capable of extracting the user-defined internal process data from the different modules (acquisition, tracking, bit decoding, and so on) of the GNSS RUT and stores it in a computer via a 100-Mbps Ethernet link. The dCAP hardware is independent of the receiver module (although implemented on the same softcore) and operates through minimal interference with the receiver operation. This data can then be post-processed to monitor and record the behavior of the receiver and to investigate any anomalies in its intermediate stages. An experimental version of dCAP has already been used to monitor the carrier-to-noise-density ratio (C/N0), carrier Doppler, and code delay from the internal tracking channels, and the raw GNSS signals in I/Q format entering the baseband processing unit (BPU) of the TUTGNSS receiver from its radio front end.
The benefits of AutoPET over state-of-art approaches are that it is portable (software platform independent), easy to use, suitable for testing most receivers using a variety of simulators (provided each of them can communicate with the outside world using some form of communication protocol), and its operational parameters are easy to modify through an external configuration file. dCAP is designed specifically for the TUTGNSS receiver; however, it can be easily replicated for most experimental embedded system receivers. Once implemented, dCAP offers a clear view of the internal operation of the receiver by accessing intermediate signals between the input and output terminals. The speed and size of data capture are limited only by the type of Ethernet connection and the size of the internal and external memories. Additional details of AutoPET and dCAP are provided in the next two sections of this article, while the third section describes the application of these tools in testing the GPS L1 operation of the TUTGNSS receiver.
Automated Performance Evaluation Tool
AutoPET is a software program developed using the Qt platform and the C++ language, which communicates between the GNSS receiver, signal simulator, and its associated computer through a remote PC that houses AutoPET. The set-up is shown in FIGURE 1. This figure also denotes the different communication protocols used between the different modules.
FIGURE 1. Block schematic of the AutoPET assembly.
At the center is the GNSS receiver, which accepts RF signals from the GNSS signal simulator. These signals represent signals from the sky in accordance with the scenario loaded in the simulator, and therefore represent unidirectional communication. On the other hand, the receiver communicates with the remote PC housing AutoPET using the NMEA-0183 protocol. This is bidirectional communication, as the receiver continuously updates its status via NMEA messages to AutoPET and, in turn, AutoPET sends a response/control command to the receiver. The receiver sends the $GPGGA NMEA message every second, and through reading this message, AutoPET can determine the current status (acquisition, tracking, position fix, and so on) of the receiver.
The TUTGNSS receiver has the capability to perform a cold start to initiate the next test iteration when commanded by AutoPET. For this purpose, we have designed a simple custom message string, which can be identified by the TUTGNSS receiver as a cold-start command. In response, the receiver sends a custom NMEA message, $GPTXT, which identifies that it has successfully performed a cold start. Performing a cold start involves erasing all a priori navigation-related information from the receiver memory. This includes erasing the ephemeris, almanac, and timing information, and ensuring that all satellite tracking is lost.
AutoPET communicates with the GNSS signal simulator through its controlling computer, called the Sim-PC (which runs the control software for the simulator). This communication is bidirectional using a 100-Mbps Ethernet link. The AutoPET library holds the scenario files, through which it remotely controls the simulator. In turn, the Sim-PC returns responses or error messages in the form of Extensible Markup Language (XML) strings to the AutoPET. The communication between the Sim-PC and the simulator is through its proprietary protocols.
AutoPET makes extensive use of multi-threading. The receiver, AutoPET, and the simulator function autonomously of each other and hence are independently controlled using their own processing threads running in parallel. Examples of some processing threads are:
Thread 1 – monitors the receiver operation through the received NMEA messages. This thread is responsible for identifying, for example, if the receiver achieves a position fix or if it performs a successful cold start.
Thread 2 – monitors the simulator through the received XML error messages and response messages from the Sim-PC. It is responsible for identifying, for example, if the simulator scenario is successfully set up or if the satellite signals are turned on and off when demanded by the test case.
Thread 3 – monitors the internal operation of AutoPET itself to check, for example, if a timer has expired or if the user performs any operation on the GUI during the progress of a test.
Each thread generates an internal software interrupt within AutoPET based on which future course of action has to be dynamically determined.
Later in the article, the application of AutoPET for single-frequency, single-constellation operation and testing of the TUTGNSS receiver is described. However, it can just as easily be applied for more complex, multi-frequency, multi-constellation testing. The scenarios are stored in the library of AutoPET, and they can be easily updated without requiring any changes in the tool itself. On the other hand, the receiver operation needs to be updated to perform position fixes with multiple signals and constellations. If the receiver allows updating of its operation mode using software commands, as is the case in TUTGNSS, these commands can also be included within AutoPET.
In the case of TUTGNSS, two configuration settings control the mode of operation and the manner in which it has to be turned on (cold, warm, or hot start) via a 32-bit control word. Table 1 describes the various options and the digital control word bits corresponding to each option. There are eight possible modes of operation that would require three bits to be uniquely represented. However, we have assigned five bits, to accommodate any planned future increase in operating modes. Similarly, there are three ways to turn on the TUTGNSS receiver, and they can be uniquely represented by two bits. Therefore, out of the 32 available bits, only seven bits are currently utilized. The rest of the bits are in reserve for future use. The mode selection bits are in least significant bit positions of the control word. For example, if the receiver should perform a position fix after a warm start using GPS L1 and Galileo E1 signals, the 32 bit control word would be 00000000_0000000_00000000_00100010. Using this control word at the beginning of every test, AutoPET can be used for a simple single constellation or more advanced multi-constellation testing of the receiver.
TABLE 1. Control words for multi-frequency, multi-constellation testing of TUTGNSS.
Data Capture Tool
The overall set up of dCAP is shown in FIGURE 2. The TUTGNSS receiver consists of the radio front end and the BPU implemented on an Altera Stratix-II development board. This board consists of the NIOS-II softcore embedded processor controlled by the MicroC operating system within a field-programmable gate array (FPGA) board. The hardware is programmed using VHSIC Hardware Description Language (VHDL) and consists of the system entity and a few peripheral entities, such as a phase-locked loop (PLL), which are not shown in the figure for sake of simplicity. The system entity consists of (among others) two software-controlled hardware entities, one for the TUTGNSS receiver BPU and the other for the dCAP server, called CPU-0 and CPU-1 respectively. The Control-PC is responsible for the overall programming of the FPGA board through a USB link. It also holds a Qt-based user interface acting as the dCAP client implementation.
FIGURE 2. Overall block schematic of the dCAP assembly.
The dCAP client (in the Control-PC) establishes an Ethernet connection with the dCAP server (on the FPGA) and requests a user-specified internal data sample. As an example, let us assume the user requests raw I/Q samples input to the TUTGNSS BPU from the radio front end. The dCAP server software communicates with the TUTGNSS software, which in turn allows the dCAP server hardware access to the requested data from the appropriate region of the TUTGNSS hardware, similar to how a signal across a resistor on a dense printed circuit board is viewed by placing oscilloscope probes across it. The only limitation with dCAP is that the user has to predict, in advance, which internal data parameters are of interest and create access points within the correct hardware entities. The dCAP server hardware will connect to the respective access point when demanded by the client.
This data snapshot is first buffered in the local shared memory entity on the FPGA board due to the requirements of speed, size, and time synchronization. The dCAP server software is responsible for transferring this data from the internal memory to the Control-PC through the Ethernet link. The data is stored on the Control-PC hard drive in the form of a *.bin file. Therefore, the size of each data-packet that can be accessed at a time is limited by the size of the FPGA memory entity, while the total data size is limited only by the size of the hard drive of the Control-PC. The speed of data capture is restricted by the maximum speed of the Ethernet link between the dCAP client and server.
In FIGURE 3, the internal operation of the dCAP server is illustrated, assuming that we would like to access the raw samples from the radio front end. The first block that the samples enter inside the TUTGNSS BPU is the baseband converter unit (BCU). This is where the dCAP hardware probes listen in on the signal samples. Through these probes, the signals are diverted to the first-in-first-out (FIFO) data collector on the dCAP server (CPU-1) in addition to their usual route through the further baseband processing blocks of the receiver. After the FIFO collector, the data undergoes clock arbitration, time synchronization, and master-slave synchronization, before being buffered into the on-chip Synchronous Dynamic Random Access Memory (SDRAM), where it waits until the dCAP server transfers it through the Ethernet-based local network to the requesting dCAP client within the Control-PC. In the case where different internal data has to be monitored, the probes simply reorient to the correct access point within the correct hardware entity (for example, to monitor the signal C/N0, the probes access the tracking loops).
FIGURE 3. Block schematic of an example of the dCAP internal operation.
TUTGNSS Receiver Performance Testing
During the GPS L1 performance testing of the TUTGNSS receiver, the reference receiver position in the simulator was set randomly. Ionosphere and troposphere errors were turned off in the simulator. On average, 100 iterations were performed for each test, and the total duration to complete all tests was two weeks. dCAP was used in monitoring the tracking channels and extracting information such as the C/N0, carrier Doppler, and code-delay estimates for the satellites being tracked. Access to these parameters enabled testing the acquisition and tracking sensitivity of the TUTGNSS receiver, thus confirming the results of the tests performed using AutoPET.
Acquisition Sensitivity. Acquisition sensitivity for the TUTGNSS receiver was measured to be -141.5 dBm via AutoPET and -141 dBm via dCAP. Each coherent integration interval was 4 milliseconds, and 256 such intervals were integrated non-coherently. Using AutoPET, 100 acquisition iterations were performed at every power level, and the average number of satellites acquired was recorded. It was observed that no satellites were acquired at -142 dBm. The acquisition sensitivity test using dCAP involved extracting the carrier Doppler and code-delay estimates. A successful acquisition was assumed only if the code-delay estimate error was less than ±1 chip (300 meters) and the carrier Doppler estimate error was less than ±150 Hz. Based on these criteria, 96.72% of acquisitions were found to be successful when the satellite power was maintained at -141 dBm in the simulator as shown in the histograms in FIGURES 4 and 5.
FIGURE 4. Code-delay estimate within ±1 chip (300 meters).
FIGURE 5. Carrier Doppler estimate within ±150 Hz.
Tracking Sensitivity. Tracking sensitivity for the TUTGNSS receiver was measured to be -151 dBm via both tools, assuming a coherent integration interval of 20 milliseconds. Using AutoPET, 100 tracking iterations were performed at every power level and the average number of satellites tracked was recorded. Using dCAP, this test was performed by selecting one satellite and observing how the receiver C/N0 tracked this satellite during high and low signal power conditions. Twenty tracking iterations of 90 seconds each were performed for a particular satellite. In each iteration, the satellite power in the simulator was maintained at the nominal condition of -130 dBm (equivalent to 38 dB C/N0 in the receiver) for the first 30 seconds. Subsequently, the power of the satellite was dropped to -151 dBm (equivalent to 17 dB C/N0 in the receiver).
As visible in Figure 6, the receiver was able to continue tracking the satellite at -51 dBm in 19 out of the 20 iterations. In the case where tracking was lost, the C/N0 can be seen to diverge rapidly to 0. To make sure that in the rest of the 19 cases the receiver was really tracking the satellite at low power, the power of the satellite was increased again after an additional 30 seconds. In each of the 19 cases, the receiver successfully continued to track the satellite.
FIGURE 6. Tracking C/N0 in one tracking channel using dCAP.
3D Position Accuracy and TTFF. Computation of the position fix was performed using a least-squares algorithm without any filtering. Using only AutoPET, 100 position fix iterations were performed and the average 3D error in meters was computed. Within the same test case, the time for achieving a position fix was also recorded. The initial (0–30 seconds) position fix estimates are not very accurate. This is because only the first four acquired satellites are used for the position computation. As more satellites are acquired and tracked, their inclusion into the computation gradually improves the position accuracy to within 1 meter. The average TTFF was computed to 60.59 seconds.
Validity of C/N0 Estimator. FIGURE 7 presents a comparison of C/N0 measurements between the TUTGNSS receiver (extracted using dCAP) and a commercial receiver. The input power from the simulator was varied between -130 dBm and -151 dBm with steps of around 2 dB for 10 seconds each. The C/N0 readings from the two receivers were measured at each power level and plotted on the same scale. The reference power level represents the C/N0 readings of a hypothetical (ideal) receiver with zero radio front-end losses. As the figure shows, on average there is close conformance between the estimated values of C/N0 in the two receivers. The difference between the two receivers and the reference is approximately 5 dB, which includes radio front-end noise and other losses. The TUTGNSS receiver displays lower C/N0 estimation peak-to-peak inconsistency than the commercial receiver.
FIGURE 7. C/N0 measurement using dCAP: Comparison between TUTGNSS, a commercial, and a hypothetical receiver.
Other Uses of dCAP. During initial prototype validation, we noticed that satellite tracking was inconsistent even under high C/N0 conditions. dCAP was used to extract detailed baseband tracking information that helped to identify the source of the problem: signal anomalies due to insufficient clock buffering on an experimental RF front end, as shown in FIGURE 8. Such anomalies would have been impossible to detect with traditional black-box testing practices. Once the problem was rectified, dCAP was used once again to monitor the RF front-end signals and performance of the baseband tracking loops, where FIGURES 9 and 10 show a marked improvement in the receiver signal processing and satellite tracking performance.
FIGURE 8. Signal anomaly in the Q-branch signal due to insufficient clock buffering in the experimental RF front end: detected using dCAP.
FIGURE 9. Code Doppler extracted from one tracking loop.
FIGURE 10. Carrier Doppler extracted from one tracking loop using dCAP.
Conclusion
In this article, we have demonstrated the results of the TUTGNSS prototype receiver testing using AutoPET and dCAP. Results were presented, analyzed, and conclusions drawn for the GPS L1 performance of the receiver. Furthermore, the procedures can be easily replicated through software modifications for testing more advanced multi-frequency, multi-constellation modes of the receiver.
Added to the benefits of automation in terms of improved accuracy and personnel efficiency, the proposed AutoPET is a cost-effective solution to anyone working on GNSS receiver technology to understand its most important performance parameters. This tool is portable (software platform-independent), easy to install, and easy to execute on any computer with the basic scientific software. From an academic point of view, dCAP is useful for teaching the spectral characteristics of GNSS signals at every stage from deep inside the receiver to researchers or university students in laboratory exercises. Together, these tools have assisted in the complete characterization of the TUTGNSS receiver at TUT, and can be easily adapted, enhanced, and applied to other research-based receivers as well. In other words, the proposed research has an academic as well as practical appeal.
Acknowledgments
This research work received support from the Tampere Doctoral Programme in Information Science and Engineering (TISE), Nokia Foundation, and the Ulla Tuominen Foundation. It has also been partially supported by the Academy of Finland (under the projects: 251138 “Digitally-Enhanced RF for Cognitive Radio Devices”, and 256175 “Cognitive Approaches for Location in Mobile Environments”). We wish to gratefully acknowledge each of these institutions. This article is based on the paper “Automated Test-bench Infrastructure for GNSS Receivers – Case Study of the TUTGNSS Receiver” presented at the 26th International Technical Meeting of the Satellite Division of The Institute of Navigation held in Nashville, Tennessee, September 16–20, 2013.
Manufacturers
The tests described in this article used a Spirent Federal Systems STR4500 multi-channel GPS/SBAS simulator and a u-blox AG EVK-5P GNSS receiver evaluation kit with a LEA-5P receiver module.
SARANG THOMBRE is a GNSS research scientist in the Department of Navigation and Positioning at the Finnish Geodetic Institute (FGI), Helsinki.
JUSSI RAASAKKA is a GNSS R&D scientist at Honeywell International s.r.o. in the Czech Republic.
TOMMI PAAKKI is a teaching assistant and a doctoral student at the Department of Electronics and Communications Engineering, Tampere University of Technology (TUT).
FRANCESCANTONIO DELLA ROSA is the project manager of the Multitechnology Positioning Professionals (MULTI-POS) Marie Curie Initial Training Network and a research scientist at TUT.
MIKKO VALKAMA is a full professor and the head of the Department of Communications Engineering at TUT.
LAURA RUOTSALAINEN is the deputy head of the Department of Navigation and Positioning and aspecialist research scientist at FGI.
HEIDI KUUSNIEMI is a professor and the acting head of the Department of Navigation and Positioning at FGI.
JARI NURMI is a professor in the Department of Electronics and Communications Engineering at TUT.
FURTHER READING
• Authors’ Conference Paper
“Automated Test-bench Infrastructure for GNSS Receivers – Case Study of the TUTGNSS Receiver” by S. Thombre, J. Raasakka, T. Paakki, F. Della Rosa, M. Valkama, and J. Nurmi in Proceedings of ION GNSS+ 2013, the 26th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 16–20, 2013, pp. 1919–1930.
• TUTGNSS
“TUTGNSS – University Based Hardware/Software GNSS Receiver for Research Purposes” by T. Paakki, J. Raasakka, F. Della Rosa, H. Hurskainen, and J. Nurmi, in Proceedings of Ubiquitous Positioning Indoor Navigation and Location Based Service (UPINLBS), 2010, Helsinki, Finland, October 14–15, 2010, doi: 10.1109/UPINLBS.2010.5654337.
“Software-based GNSS Signal Simulators: Past, Present and Possible Future” by S. Thombre, E.S. Lohan, J. Raquet, H. Hurskainen, and J. Nurmi, in Proceedings of ENC GNSS 2010, the European Navigation Conference 2010, Braunschweig, Germany, October 19–21, 2010.
NMEA 0183, The Standard for Interfacing Marine Electronic Devices, Ver. 4.10, published by the National Marine Electronics Association, Severna Park, Maryland, June 2012.
Emerging GNSS applications in automobiles support regulation, security, safety, and financial transactions, as well as navigation, guidance, traffic information, and entertainment. The GNSS sub-systems and onboard applications must demonstrate robustness under a range of environments and varying threats. A dedicated automotive GNSS test center enables engineers to design their own GNSS test scenarios including urban canyons, tunnels, and jamming sources at a controlled test site.
By Mark Dumville, William Roberts, Dave Lowe, Ben Wales, NSL, Phil Pettitt, Steven Warner, and Catherine Ferris, innovITS
Satellite navigation is a core component within most intelligent transport systems (ITS) applications. However, the performance of GNSS-based systems deteriorates when the direct signals from the satellites are blocked, reflected, and when they are subjected to interference. As a result, the ability to simulate signal blockage via urban canyons and tunnels, and signal interference via jamming and spoofing, has grown fundamental in testing applications.
The UK Center of Excellence for ITS (innovITS), in association with MIRA, Transport Research Laboratory (TRL), and Advantage West Midlands, has constructed Advance, a futuristic automotive research and development, and test and approvals center. It provides a safe, comprehensive, and fully controllable purpose-built road environment, which enables clients to test, validate and demonstrate ITS. The extensive track layout, configurable to represent virtually any urban environment, enables the precise specification of road conditions and access to infrastructure for the development of ITS innovations without the usual constraints of excessive set up costs and development time.
As such, innovITS Advance has the requirement to provide cityscape GNSS reception conditions to its clients; a decidedly nontrivial requirement as the test track has been built in an open sky, green-field environment (Figure 1).
Figure 1. innovITS Advance test circuit (right) and the environment it represents (left).
NSL, a GNSS applications and development company, was commissioned by innovITS to develop Skyclone in response to this need. The Skyclone tool is located between the raw GNSS signals and the in-vehicle system. As the vehicle travels around the Advance track, Skyclone modifies the GNSS signals to simulate their reception characteristics had they been received in a city environment and/or under a jamming attack. Skyclone combines the best parts of real signals, simulated scenarios, and record-and-replay capabilities, all in one box. It provides an advanced GNSS signal-processing tool for automotive testing, and has been specifically developed to be operated and understood by automotive testing engineers rather than GNSS experts.
Skyclone Concept
Simulating and recreating the signal-reception environment is achieved through a mix of software and hardware approaches. Figure 2 illustrates the basic Skyclone concept, in which the following operations are performed.
In the office, the automotive engineer designs a test scenario representative of a real-world test route, using a 3D modelling tool to select building types, and add tunnels/underpasses, and jammer sources. The test scenario is saved onto an SD card for upload onto the Skyclone system.
The 3D model in Skyclone contains all of the required information to condition the received GNSS signals to appear to have been received in the 3D environment.
The Skyclone system is installed in a test vehicle that receives the open-air GNSS signals while it is driven around the Advance track circuit.
The open-air GNSS signals are also received at a mobile GNSS reference receiver, based on commercial off-the-shelf GNSS technology, on the test vehicle. It determines the accurate location of the vehicle using RTK GNSS. The RTK base station is located on the test site.
The vehicle’s location is used to access the 3D model to extract the local reception conditions (surrounding building obstructions, tunnels attenuations, jamming, and interference sources) associated with the test scenario.
Skyclone applies satellite masking, attenuation, and interference models to condition/manipulate raw GNSS signals received at a second software receiver in the onboard system. The software receiver removes any signals that would have been obstructed by buildings and other structures, and adds attenuation and delays to the remaining signals to represent real-world reception conditions. Furthermore, the receiver can apply variable interference and/or jamming signatures to the GNSS signals.
The conditioned signals are then transmitted to the onbaord unit (OBU) under test either via direct antenna cable, or through the air under an antenna hood (acting as an anechoic chamber on top of the test vehicle). Finally, the GNSS signals produced by Skyclone are processed by the OBU, producing a position fix to be fed into the application software.
Figure 2. Skyclone system concept.
The Skyclone output is a commercial OBU application that has been tested using only those GNSS signals that the OBU receiver would have had available if it was operating in a real-world replica environment to that which was simulated within the Skyclone test scenario.
Skyclone Architecture
The Skyclone system architecture (Figure 3) consists of five principal subsystems.
Office Subsystem Denial Scenario Manager. This software has been designed to allow users to readily design a cityscape for use within the Skyclone system. The software allows the users to select different building heights and styles, add GNSS jamming and interference, and select different road areas to be treated as tunnels.
Figure 3. Baseline Skyclone system architecture.
City Buildings. The Advance test site and surrounding area have been divided into 14 separate zones, each of which can be assigned a different city model. Ten of the zones fall inside of the test road circuit and four are external to the test site. Each zone is color-coded for ease of identification (Figure 4).
Figure 4. Skyclone city zones.
The Skyclone system uses the city models to determine GNSS signal blockage and multipath for all positions on the innovITS Advance test site. The following city models, ordered in decreasing building height and density, can be assigned to all zones: high rise, city, semi urban, residential, and parkland.
Interference and Jamming. GNSS jamming and interference can be applied to the received GNSS signals. Jamming is set by specifying a jamming origin, power, and radius. The power is described by the percentage of denied GNSS signal at the jamming origin and can be set in increments of 20 percent. The denied signal then decreases linearly to the jammer perimeter, outside of which there is no denial.
The user can select the location, radius, and strength of the jammer, can select multiple jammers, and can drag and drop the jammers around the site.
Tunnels. Tunnels can be applied to the cityscape to completely deny GNSS signals on sections of road. The user is able to allocate “tunnels” to a pre-defined series of roads within the test site. The effect of a tunnel is to completely mask the sky from all satellites.
Visualization. The visualization display interface (Figure 5) provides a graphical representation of the scenario under development, including track layout, buildings, locations, and effects of interference/jammers and tunnels. Interface/jammer locations are shown as hemispherical objects located and sized according to user definition. Tunnels appear as half-cylinder pipes covering selected roads.
Figure 5. 3D visualisation display.
Reference Subsystem
The reference subsystem obtains the precise location of the test vehicle within the test site. The reference location is used to extract relevant vehicle-location data, which is used to condition the GNSS signals.
The reference subsystem is based on a commercial off-the-shelf real-time kinematic GPS RTK system, capable of computing an accurate trajectory of the vehicle to approximately 10 centimeters. This position fix is used to compute the local environmental parameters that need to be applied to the raw GNSS signals to simulate the city scenario.
A dedicated RTK GNSS static reference system (and UHF communications links) is provided within the Skyclone system. RTK vehicle positions of the vehicles are also communicated to the 4G mesh network on the Advance test site for tracking operational progress from the control center.
Vehicle Subsystem
The vehicle subsystem acquires the GNSS signals, removes those that would be blocked due to the city environment (buildings/tunnels), conditions remaining signals, applies interference/jammer models, and re-transmits resulting the GNSS signals for use by the OBU subsystem.
The solution is based on the use of software GNSS receiver technology developed at NSL. In simple terms, the process involves capturing and digitizing the raw GNSS signals with a hardware RF front end. Figure 6 shows the system architecture, and Figure 7 shows the equipment in the innovITS demonstration vehicle.
Figure 6. Skyclone hardware architecture.
The digitized signals are then processed in NSL’s software receiver running on a standard commercial PC motherboard. The software receiver includes routines for signal acquisition and tracking, data demodulation and position determination.
In the Skyclone system, the raw GNSS signals are captured and digitized using the NSL stereo software receiver. The software receiver determines which signals are to be removed (denied), which signals require conditioning, and which signals can pass through unaffected. The subsystem does this through accurate knowledge of the vehicle’s location (from the reference subsystem), knowledge of the environment (from the office subsystem), and knowledge of the satellite locations (from the vehicle subsystem itself).
The Skyclone vehicle subsystem applies various filters and produces a digital output stream. This stream is converted to analog and upconverted to GNSS L1 frequency, and is sent to the transmitter module located on the same board.
The Skyclone transmitter module feeds the analog RF signal to the OBU subsystem within the confines of a shielded GPS hood, which is attached to the vehicle on a roof rack. An alternative to the hood is to integrate directly with the cable of the OBU antenna or through the use of an external antenna port into the OBU. The vehicle subsystem performs these tasks in near real-time allowing the OBU to continue to incorporate non-GNSS navigation sensors if applicable.
Onboard Unit Subsystem
The OBU subsystem, typically a third-party device to be tested, could be a nomadic device or an OEM fitted device, or a smartphone. It typically includes a GNSS receiver, an interface, and a software application. Examples include:
Navigation system
Intelligent speed adaptation system
eCall
Stolen-vehicle recovery system
Telematics (fleet management) unit
Road-user charging onboard unit
Pay-as-you-drive black-box
Vehicle-control applications
Cooperative active safety applications
Vehicle-to-vehicle and vehicle-to-infrastructure systems.
Tools Subsystem Signal Monitor
The Skyclone Monitor tool provides a continuous monitoring service of GNSS performance at the test site during tests, monitoring the L1 frequency and analyzing the RF singal received at the reference antenna. The tool generates a performance report to provide evidence of the open-sky GNSS conditions. This is necessary in the event of poor GNSS performance that may affect the outcome of the automotive tests. The Skyclone Monitor (Figure 8) is also used to detect any spurious leaked signals which will highlight the need to check the vehicle subsystem. If any spurious signals are detected, the Skyclone system is shut down so as to avoid an impact on other GNSS users at the test site. A visualization tool (Visor) is used for post-test analysis displaying the OBU-determined position alongside the RTK position within the 3D environment.
Figure 8. GNSS signal and positioning monitor.
Figure 9. 3D model of city.
Performance
Commissioning of the Skyclone system produced the following initial results. A test vehicle was installed with the Skyclone and RTK equipment and associated antennas.. The antennas were linked to the Skyclone system which was installed in the vehicle and powered from a 12V invertor connected to the car power supply. The output from the RTK GPS reference system was logged alongside the output of a commercial third-party GNSS receiver (acting as the OBU) interfaced to the Skyclone system. Skyclone was tested under three scenarios to provide an initial indication of behavior: city, tunnel, and jammer.
The three test cenarios were generated using the GNSS Denial Scenario Manager tool and the resulting models stored on three SD cards. The SD cards were separately installed in the Skyclone system within the vehicle before driving around the test site.
City Test. The city scenario consisted of setting all of the internal zones to “city” and setting the external zones to “high-rise.”
Figure 10A represents the points as provided by the RTK GPS reference system installed on the test vehicle. Figure 10B includes the positions generated by the COTS GPS OBU receiver after being injected with the Skyclone output. The effect of including the city scenario model is immediately apparent. The effects of the satellite masking and multipath model generate noise within the position tracks.
Figure 10A. City scenario: no Skyclone.
Figure 10B. City scenario: withSkyclone.
Tunnel Test. The tunnel scenario consists of setting all zones to open sky. A tunnel is then inserted along the central carriageway (Figure 11). A viewer location (depicted by the red line) has been located inside the tunnel, hence the satellite masking plot in the bottom right of Figure 11 is pure red, indicating complete masking of satellite coverage. The output of the tunnel scenario is presented in Figure 12. Inclusion of the tunnel model has resulted in the removal of all satellite signals in the area of track where the tunnel was located in the city model. The color shading represents signal-to-noise ratio (SNR), an indication of those instances where the output of the test OBU receiver has generated a position fix with zero (black) signal strength, hence the output was a prediction. Thus confirming the tunnel scenario is working correctly.
Figure 11. 3D model of tunnel.
Figure 12. Results.
Jammer Test. The jammer test considered the placement of a single jammer at a road intersection (Figure 13). Two tests were performed, covering low-power jammer and a high-power jammer. Figure 14A shows results from the low-power jammer. The color shading relates to the SNR as received within the NMEA output from the OBU, which continued to provide an output regardless of the jammer. However, the shading indicates that the jammer had an impact on signal reception.
Figure 13. Jammer scenario.
Figure 14A. Jammer test results: low power interference.
Figure 14B. Jammer test results: high-power interference.
In contrast the results of the high-power jammer (Figure 14B) show the effect of a jammer on the OBU output. The jammer denies access to GNSS signals and generates the desired result in denying GNSS signals to the OBU. Furthermore, the results exhibit features that the team witnessed during real GNSS jamming trials, most notably the wavering patterns that are output from GNSS receivers after they have regained tracking following jamming, before their internal filtering stabilizes to nominal behaviors.
The Future
The Advance test site is now available for commercial testing of GNSS based applications. Current activity involves integrating real-world GNSS jammer signatures into the Skyclone design tool and the inclusion of other GNSS threats and vulnerabilities.
Skyclone offers the potential to operate with a range of platforms other than automotive. Unmanned aerial systems platforms are under investigation. NSL is examining the integration of Skyclone features within both GNSS simulators as well as an add-on to record-and-replay tools. This would enable trajectories to be captured in open-sky conditions and then replayed within urban environments.
Having access to GNSS signal-denial capability has an immediate commercial interest within the automotive sector for testing applications without the need to invest in extensive field trials. Other domains can now benefit from such developments. The technology has been developed and validated and is available for other applications and user communities.
By Axel van den Berg, Tom Willems, Graham Pye, and Wim de Wilde, Septentrio Satellite Navigation, Richard Morgan-Owen, Juan de Mateo, Simone Scarafia, and Martin Hollreiser, European Space Agency
A fully stand-alone, multi-frequency, multi-constellation receiver unit, the TUR-N can autonomously generate measurements, determine its position, and compute the Galileo safety-of-life integrity.
Development of a reference Galileo Test User Receiver (TUR) for the verification of the Galileo in-orbit validation (IOV) constellation, and as a demonstrator for multi-constellation applications, has culminated in the availability of the first units for experimentation and testing. The TUR-N covers a wide range of receiver configurations to demonstrate the future Galileo-only and GPS/Galileo combined services:
Galileo single- and dual-frequency Open Services (OS)
Galileo single- and dual-frequency safety-of-life services (SoL), including the full Galileo navigation warning algorithms
Galileo Commercial Service (CS), including tracking and decoding of the encrypted E6BC signal
GPS/SBAS/Galileo single- and dual- frequency multi-constellation positioning
Galileo single- and dual-frequency differential positioning.
Galileo triple-frequency RTK.
In parallel, a similar test user receiver is specifically developed to cover the Public Regulated service (TUR-P). Without the PRS components and firmware installed, the TUR-N is completely unclassified.
Main Receiver Unit
The TUR-N receiver is a fully stand-alone, multi-frequency, multi-constellation receiver unit. It can autonomously generate measurements, determine its position, and compute Galileo safety-of-life integrity, which is output in real time and/or stored internally in a compact proprietary binary data format.
The receiver configuration is fully flexible via a command line interface or using the dedicated graphical user interface (GUI) for monitoring and control. With the MCA GUI it is also possible to monitor the receiver operation (see Figure 1), to present various real-time visualizations of tracking, PVT and integrity performances, and off-line analysis and reprocessing functionalities. Figure 2 gives an example of the correlation peak plot for an E5 AltBOC signal.
FIGURE 1. TUR-N control screen.
FIGURE 2. E5 AltBOC correlation peak.
A predefined set of configurations that map onto the different configurations as prescribed by the Test User Segment Requirements (TUSREQ) document is provided by the receiver.
The unit can be included within a local network to provide remote access for control, monitoring, and/or logging, and supports up to eight parallel TCP/IP connections; or, a direct connection can be made via one of the serial ports.
Receiver Architecture
The main receiver unit consists of three separate boards housed in a standard compact PCI 19-inch rack. See Figure 3 for a high-level architectural overview.
FIGURE 3. Receiver architecture.
A dedicated analog front-end board has been developed to meet the stringent interference requirements. This board contains five RF chains for the L1, E6, E5a/L5, E5b, and E5 signals. Via a switch the E5 signal is either passed through separate filter paths for E5a and E5b or via one wide-band filter for the full E5 signal. The front-end board supports two internal frequency references (OCXO or TCXO) for digital signal processing (DSP).
The DSP board hosts three tracker boards derived from a commercial dual-frequency product family. These boards contain two tracking cores, each with a dedicated fast-acquisition unit (FAU), 13 generic dual-code channels, and a 13-channel hardware Viterbi decoder. One tracking core interacts with an AES unit to decrypt the E6 Commercial Service carrier; it has a throughput of 149 Mbps.
Each FAU combines a matched filter with a fast Fourier transform (FFT) and can verify up to 8 million code-frequency hypotheses per second. Each of the six tracker cores can be connected with one of the three or four incoming IF streams. To simplify operational use of the receiver, two channel-mapping files have been defined to configure the receiver either for a 5-frequency 13-channel Galileo receiver, or for a dual-frequency 26-channel Galileo/GPS/SBAS receiver. Figure 4 shows all five Galileo signal types being tracked for nine visible satellites at the same time.
FIGURE 4. C/N0 plot with nine satellites and all five Galileo signal types: L1BC (green), E6BC (blue), E5a (red), E5b (yellow), and E5 Altboc (purple).
The receiver is controlled using a COTS CPU board that also hosts the main positioning and integrity algorithms. The processing power and available memory of this CPU board is significantly higher than what is normally available in commercial receivers. Consequently there is no problem in supporting the large Nequick model used for single-frequency ionosphere correction, and achieving the 10-Hz update rate and low latency requirements when running the computationally intensive Galileo integrity algorithms. For commercial receivers that are normally optimized for size and power consumption, these might prove more challenging.
The TUR project included development of three types of Galileo antennas:
a triple-band (L1, E6, E5) high-end antenna for fixed base station applications including a choke ring;
a triple-band (L1, E6, E5) reference antenna for rover applications;
a dual-band (L1, E5b) aeronautic antenna for SOL applications
Figure 5 shows an overview of the main interfaces and functional blocks of the receiver, together with its antenna and a host computer to run the MCA software either remotely or locally connected.
FIGURE 5. TUR-N with antenna and host computer.
Receiver Verification
Currently, the TUR-N is undergoing an extensive testing program. In order to fully qualify the receiver to act as a reference for the validation of the Galileo system, some challenges have to be overcome. The first challenge that is encountered is that the performance verification baseline is mainly defined in terms of global system performance. The translation of these global requirements derived from the Galileo system requirements (such as global availability, accuracy, integrity and continuity, time-to-first/precise-fix) into testable parameters for a receiver (for example, signal acquisition time, C/N0 versus elevation, and so on) is not trivial. System performances must be fulfilled in the worst user location (WUL), defined in terms of dynamics, interference, and multipath environment geometry, and SV-user geometry over the Galileo global service area.
A second challenge is the fact that in the absence of an operational Galileo constellation, all validation tests need to be done in a completely simulated environment. First, it is difficult to assess exactly the level of reality that is necessary for the various models of the navigation data quality, the satellite behaviour, the atmospheric propagation effects, and the local environmental effects. But the main challenge is that not only the receiver that is being verified, also the simulator and its configuration are an integral part of the verification. It is thus an early experience of two independent implementations of the Galileo signal-in-space ICD being tested together. At the beginning of the campaign, there was no previously demonstrated or accepted test reference.
Only the combined efforts of the various receiver developments benchmarked against the same simulators together with pre-launch compatibility tests with the actual satellite payload and finally IOV and FOC field test campaigns will ultimately validate the complete system, including the Galileo ground and space segments together with a limited set of predefined user segment configurations. (Previously some confidence was gained with GIOVE-A/B experimental satellites and a breadboard adapted version of TUR-N). The TUR-N was the first IOV-compatible receiver to be tested successfully for RF compatibility with the Galileo engineering model satellite payload.
Key Performances
Receiver requirements, including performance, are defined in the TUSREQ document.
Antenna and Interference. A key TUSREQ requirement focuses on receiver robustness against interference. It has proven quite a challenge to meet the prescribed interference mask for all user configurations and antenna types while keeping many other design parameters such as gain, noise figure, and physical size in balance. For properly testing against the out-of-band interference requirements, it also proved necessary to carefully filter out increased noise levels created by the interference signal generator.
Table 2 gives an overview of the measured values for the most relevant Antenna Front End (AFE) parameters for the three antenna types. Note: Asymmetry in the AFE is defined as the variation of the gain around the centre frequency in the passband. This specification is necessary to preserve the correlation peak shape, mainly of the PRS signals.
The gain for all antenna front ends and frequencies is around 32 dB. Figures 6 and 7 give an example of the measured E5 RHCP radiating element gain and axial ratio against theta (the angle of incidence with respect to zenith) for the high-end antenna-radiating element. Thus, elevation from horizontal is 90-theta.
FIGURE 6. High-end antenna E5 RHCP gain.
FIGURE 7. High-end antenna E5 axial ratio.
UERE Performance. As part of the test campaign, TUR performance has been measured for user equivalent range error (UERE) components due to thermal noise and multipath.
TUSREQ specifies the error budget as a function of elevation, defined in tables at the following elevations: 5, 10, 15, 20, 30, 40, 50, 60, 90 degrees. The elevation dependence of tracking noise is immediately linked to the antenna gain pattern; the antenna-radiating element gain profiles were measured on the actual hardware and loaded to the Radio Frequency Constellation Simulator (RFCS), one file per frequency and per antenna scenario. The RFCS signal was passed through the real antenna RF front end to the TUR. As a result, through the configuration of RFCS, real environmental conditions (in terms of C/N0) were emulated in factory.
The thermal noise component of the UERE budget was measured without multipath being applied, and interference was allowed for by reducing the C/N0 by 3 dB from nominal. Separately, the multipath noise contribution was determined based on TUSREQ environments, using RFCS to simulate the multipath (the multipath model configuration was adapted to RFCS simulator multipath modeling capabilities in compliance with TUSREQ). To account for the fact that multipath is mostly experienced on the lower elevation satellites, results are provided with scaling factors applied for elevation (“weighted”), and without scaling factors (“unweighted”). In addition, following TUSREQ requirements, a carrier smoothing filter was applied with 10 seconds convergence time.
Figure 8 shows the C/N0 profile from the reference antenna with nominal power reduced by 3 dB. Figure 9 shows single-carrier thermal noise performance without multipath, whereas Figure 10 shows thermal noise with multipath. Each of these figures includes performance for five different carriers: L1BC, E6BC, E5a, E5b, and E5 AltBOC, and the whole set is repeated for dual-frequency combinations (Figure 11 and Figure 12).
FIGURE 8. Reference antenna, power nominal-3 dB, C/N0 profile.
FIGURE 9. Reference antenna, power nominal-3 dB, thermal noise only, single frequency.
FIGURE 10. Reference antenna, power nominal-3 dB, thermal noise with multipath, single frequency.
FIGURE 12. Reference antenna, power nominal-3 dB, thermal noise with multipath, dual frequency.
The plots show that the thermal noise component requirements are easily met, whereas there is some limited non-compliance on noise+multipath (with weighted multipath) at low elevations. The tracking noise UERE requirements on E6BC are lower than for E5a, due to assumption of larger bandwidth at E6BC (40MHz versus 20MHz). Figures 9 and 10 refer to UERE tables 2 and 9 of TUSREQ. The relevant UERE requirement for this article is TUSREQ table 2 (satellite-only configuration). TUSREQ table 9 is for a differential configuration that is not relevant here.
UERRE Performance. The complete single-frequency range-rate error budget as specified in TUSREQ was measured with the RFCS, using a model of the reference antenna. The result in Figure 13 shows compliance.
FIGURE 13. UERRE measurements.
FIGURE 14. L1 GPS CA versus E5 AltBOC position accuracy (early test result).
Position Accuracy. One of the objectives of the TUR-N is to demonstrate position accuracy. In Figure 14 an example horizontal scatter plot of a few minutes of data shows a clear distinction between the performances of two different single-frequency PVT solutions: GPS L1CA in purple and E5AltBOC in blue. The red marker is the true position, and the grid lines are separated at 0.5 meters. The picture clearly shows how the new E5AltBOC signal produces a much smoother position solution than the well-known GPS L1CA code. However, these early results are from constellation simulator tests without the full TUSREQ worst-case conditions applied.
FIGURE 14. L1 GPS CA versus E5 AltBOC position accuracy (early test result).
The defined TUSREQ user environments, the basis for all relevant simulations and tests, are detailed in Table 3. In particular, the rural pedestrian multipath environment appears to be very stringent and a performance driver.
This was already identified at an early stage during simulations of the total expected UERE and position accuracy performance compliance with regard to TUSREQ, summarized in Table 4, and is now confirmed with the initial verification tests in Figure 10. UERE (simulated) total includes all other expected errors (ionosphere, troposphere, ODTS/BGD error, and so on) in addition to the thermal noise and multipath, whereas the previous UERE plots were only for selected UERE components. The PVT performance in the table is based on service volume (SV) simulations.
The non-compliances on position accuracy that were predicted by simulations are mainly in the rural pedestrian environment. According to the early simulations:
E5a and E5b were expected to have 43-meter vertical accuracy (instead of 35-meter required).
L1/E5a and L1/E5b dual-frequency configurations were expected to have 5-meter horizontal, 12-meter vertical accuracy (4 and 8 required).
These predictions appear pessimistic related to the first position accuracy results shown in Table 5. On single frequency, the error is dominated by ionospheric delay uncertainty. These results are based on measurements using the RFCS and modeling the user environment; however, the simulation of a real receiver cannot be directly compared to service-volume simulation results, as a good balance between realism and worst-case conditions needs to be found. Further optimization is needed on the RFCS scenarios and on position accuracy pass/fail criteria to account for DOP variations and the inability to simulate worst environmental conditions continuously.
Further confirmations on Galileo UERE and position accuracy performances are expected after the site verifications (with RFCS) are completed, and following IOV and FOC field-test campaigns.
Acquisition. Figure 15 gives an example of different signal-acquisition times that can be achieved with the TUR-N after the receiver boot process has been completed. Normally, E5 frequencies lock within 3 seconds, and four satellites are locked within 10 seconds for all frequencies. This is based on an unaided (or free) search using a FAU in single-frequency configurations, in initial development test without full TUSREQ constraints.
FIGURE 15. Unaided acquisition performance.
When a signal is only temporarily lost due to masking, and the acquisition process is still aided (as opposed to free search), the re-acquisition time is about 1 second, depending on the signal strength and dynamics of the receiver. When the PVT solution is lost, the aiding process will time out and return to free search to be robust also for sudden user dynamics.
More complete and detailed time-to-first-fix (TTFF) and time-to-precise-fix (TTPF), following TUSREQ definitions, have also been measured.
In cold start the receiver has no prior knowledge of its position or the navigation data, whereas in warm start it already has a valid ephemeris in memory (more details on start conditions are available in TUSREQ). Table 6 shows that the acquisition performances measured are all compliant to TUSREQ except for warm start in E5a single frequency and in the integrity configurations. However, when the navigation/integrity message recovery time is taken off the measurement (as now agreed for updated TUSREQ due to message limitations), these performances also become compliant.
Specific examples of statistics gathered are shown in figures 16–21, these examples being for dual-frequency (E5b+L1) with integrity configuration. The outliers, being infrequent results with high acquisition times, are still compliant with the maximum TTFF/TTPF requirements, but are anyway under further investigation.
FIGURE 16. TTFF cold-start performance, dual frequency with integrity E5b+L1.
FIGURE 17. TTFF cold-start distribution, dual frequency with integrity E5b+L1.
FIGURE 18. TTPF cold-start performance, dual frequency with integrity E5b+L1.
FIGURE 19. TTPF cold-start distribution, dual frequency with integrity E5b+L1.
FIGURE 20. TTFF warm-start performance, dual frequency with integrity E5b+L1.
FIGURE 21. TTFF warm-start distribution, dual frequency with integrity E5b+L1,
Integrity Algorithms. The Galileo SoL service is based on a fairly complex processing algorithm that determines not only the probability of hazardous misleading information (PHMI) based on the current set of satellites used in the PVT computation (HPCA), but also takes into consideration the PHMI that is achieved when one of the satellites used in the current epoch of the PVT computation is unexpectedly lost within the following 15 seconds. PHMI is computed according to alarm limits that are configurable for different application/service levels. These integrity algorithms have been closely integrated into the PVT processing routines, due to commonality between most processing steps.
Current test results of the navigation warning algorithm (NWA) indicate that less than 10 milliseconds of processing time is required for a full cycle of the integrity algorithms (HPCA+CSPA) on the TUR-N internal CPU board. Latency of the availability of the integrity alert information in the output of the receiver after it was transmitted by the satellite has been determined to be below 400 milliseconds. At a worst-case data output rate of 10 Hz this can only be measured in multiples of 100 millisecond periods. The total includes 100 milliseconds of travel time of the signal in space and an estimated 250 milliseconds of internal latency for data-handling steps as demodulation, authentication, and internal communication to make the data available to the integrity processing.
Conclusions
The TUR-N is a fully flexible receiver that can verify many aspects of the Galileo system, or as a demonstrator for Galileo/GPS/SBAS combined operation. It has a similar user interface to commercial receivers and the flexibility to accommodate Galileo system requirements evolutions as foreseen in the FOC phase without major design changes.
The receiver performance is in general compliant with the requirements. For the important safety-of-life configuration, major performance requirements are satisfied in terms of acquisition time and position accuracy.
The receiver prototype is currently operational and undergoing its final verification and qualification, following early confirmations of compatibility with the RFCS and with the Galileo satellite payload.
