Mauro Colombi, vice president of operations for Stonex, discusses the new S10 GNSS Receiver while at InterGeo 2014, held October 7-9 in Berlin. The S10 features a new generation of smart and open GPS, where a user can install custom applications directly on the receiver.
Tag: receiver design
-
Loctronix IDS Captures Real-World GPS Jamming Interference
A newly published white paper by Loctronix Corporation presents preliminary test results of its Interference Detection System (IDS), which included capturing two separate incidents of intentional interference caused by a sweep jammer device. On October 23, Loctronix will host a webinar, “Detecting GNSS Interference in the Wild,” based on the findings revealed in the white paper “Catching a Jammer.”
In recent tests, the IDS ran continuously for 24 hours monitoring for potential interference originating from traffic on a nearby highway, SR-522, passing through Woodinville, Washington. “In a single day, the IDS detected two separate instances of a sweep jammer moving along the highway,” noted Loctronix Founder and CEO Michael Mathews. “These discoveries were unexpected, given the relatively short monitoring period and the fact that SR-522 is not a heavy truck-route.”
“The two interference events were likely caused by sweep jammers installed within a vehicle’s interior. The intercepted signals exhibited significant variations in amplitude probably caused by the jammer antenna non-uniform radiation pattern as the jammer vehicle passed through the IDS antenna beam pattern,” Mathews added.
Intentional interference is designed to prevent a GPS receiver from acquiring and tracking signals. The use of jammers is in the U.S. is illegal; however, they can still be purchased for as little as $30. Thousands of GPS jammers are purportedly in use throughout Europe and several parties have been caught illegally jamming GPS in the U.S.
Loctronix developed the IDS to identify, characterize, and ultimately geolocate GPS interference. When interference is present, the system analyzes the interference for signal structure and notifies operators if the threat is significant.
The IDS is highly portable, simple to use, and cost-effective, Loctronix said. The system is based upon the Loctronix ASR-2300 software defined radio platform, making it readily configurable (from a single mobile detector to a multi-sensor network array) to monitor additional GNSS bands and, potentially, cellular bands.
Loctronix’ webinar, ”Detecting GNSS Interference in the Wild,” will be held October 23, 10-11 a.m. PDT.
In the video below, Michael B. Mathews, Ph.D., CEO and founder of Loctronix, tells GPS World about the IDS at the ION GNSS+ Conference, held September in Tampa, Florida.
-
EC, GSA Plan Workshop on GNSS Receiver Technology
On November 18, a Consultation Event will take place in Brussels on the subject of receiver technology. The event is being held to inform the stakeholders of the European GNSS receiver community about the format and timeline of funding opportunities for the period 2015-2020, and to gather input for the definition of R&D actions in the field of receiver technology.
The event is being organized by the European Commission’s Directorate-General Enterprise and Industry, in collaboration with European GNSS Agency (GSA).
The workshop will consist of one panel session, during which stakeholders from industry, SMEs, academia, and technology institutes will be asked to debate and recommend important lines of research in receiver technology.
Registration is now open on the Europa website. Interested participants are invited to fill in the registration form and to indicate which application area they are interested in and the fields of research that should be supported.
The workshop will be held at the Committee of the Regions, Jacques Delors building, rue Belliard 99-101, room JDE 53, Brussels.
-
Toward a Unified PNT — Part 1
Photo: peeterv/iStock/Getty Images Plus/Getty Images Complexity and Context: Key Challenges of Multisensor Positioning
By Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London
The next generation of navigation and positioning systems must provide greater accuracy and reliability in a range of challenging environments to meet the needs of a variety of mission-critical applications. No single navigation technology is robust enough to meet these requirements on its own, so a multisensor solution is required. Four key challenges must be met: complexity, context, ambiguity, and environmental data handling.
Although many new navigation and positioning methods have been developed in recent years to address GNSS shortcomings in terms of signal penetration and interference vulnerability, little has been done to bring them together into a robust, reliable, and cost-effective integrated system.
New positioning techniques investigated over the past 15 years include:Wi-Fi; ultra-wideband; phone signals; television and other signals of opportunity; Bluetooth; lasers, and dead reckoning; pedestrian dead reckoning (PDR) using step detection; pedestrian and activity-based map matching; magnetic anomaly matching; and GNSS shadow matching.
There have also been improvements to existing technologies: visual navigation, dead-reckoning algorithms, micro-electro-mechanical systems, inertial sensing with cold-atom technology, nuclear magnetic resonance gyros, distance-measuring equipment, Loran, Doppler with Iridium, multiple GNSS constellations, network assistance, and augmentation by commercial pseudolite systems.
In the next generation, a universal navigation system might be expected to provide position within 3 meters at any location with a very high reliability. No single positioning technology is capable of meeting the most demanding application requirements. Radio signals may or may not be subject to obstruction, attenuation, reflection, jamming, and/or interference. Known environmental features, such as signs, buildings, terrain height variation, and magnetic anomalies, may or may not be available for positioning. The system could be stationary, carried by a pedestrian, or on any type of land, sea, or air vehicle. Furthermore, for many applications, the environment and host behavior are subject to change. A multisensor solution is thus required.
A robust, reliable, and cost-effective integrated system must meet four key challenges:
Complexity. How to find the necessary expertise to integrate a diverse range of technologies, how to combine technologies from different organizations that wish to protect their intellectual property, how to incorporate new technologies and methods without having to redesign the whole system, and how to share development effort over a range of different applications.
Context. How to ensure that the navigation system configuration is optimized for the operating environment and host vehicle (or pedestrian) behavior when both are subject to change.
Ambiguity. How to handle multiple hypotheses, including measurements of non-unique environmental features, pattern-matching fixes where the measurements match the database at multiple locations, and uncertain signal properties, such as whether reception is direct or non-line-of-sight (NLOS).
Environmental Data Handling. How to gather, distribute, and store the information needed to identify signals and environmental features and define their points of origin or spatial variation.
Complexity
Achieving robust positioning in challenging environments potentially requires a large number of subsystems. For example, Figure 1 shows the possible components of a pedestrian navigation system using sensors found in a typical smartphone. Figure 2 shows possible components of a car navigation system using equipment already common on cars and other suitable low-cost sensors. Some technologies are common to the two platforms, while others differ.
Figure 1. Potential components of a pedestrian navigation system using smartphone sensors. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) 
Figure 2. Potential components of a car navigation system using commonly available equipment and other low-cost sensors. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Any multisensor navigation or positioning system needs integration algorithms to obtain the best overall position solution from the constituent subsystems. These algorithms must not only input and combine measurements from a wide range of subsystems, but also calibrate systematic errors in those subsystems. Designing the integration algorithms therefore requires expertise in all of the subsystems, which can be difficult to establish in a single organization. The more subsystems there are, the more of a problem this is.
The expert knowledge problem is compounded by the fact that different modules in an integrated navigation system are often supplied by different organizations, who may be reluctant to share necessary design information if this is considered to be intellectual property that must be protected. In a typical smartphone, one company supplies the GNSS chip, another supplies the Wi-Fi positioning service, a third organization supplies the mapping, the network operator provides the phone-signal positioning, a fifth company provides the inertial and magnetic sensors, and a sixth company produces the operating system. Because of lack of cooperation between these different organizations, useful information gets lost. For example, GNSS pseudo-range measurements are not normally available to application developers.
A further issue is reconfigurability. To minimize development costs, manufacturers share algorithms and software across different products, incorporating different subsystems. They also want to minimize the cost of adding new sensors to a product to improve performance. Similarly, researchers want to compare different combinations of subsystems. However, with a conventional system architecture, modifications must be made throughout the integration algorithm each time a subsystem is added, removed, or replaced. The more subsystems there are, the more complex this task becomes.
For a given application, different subsystems may also be used at different times. For example, a smartphone may use Wi-Fi positioning indoors and GNSS outdoors and may deploy different motion constraints and map matching algorithms, depending on whether the device is carried by a pedestrian or traveling in a car. Different integration algorithms for different configurations are more processor efficient, but also require more development effort. Conversely, an all-subsystem integration algorithm is quicker to develop, but can waste processing resources handling inactive subsystems.
Modular Integration. The solution to these problems is a modular integration architecture, consisting of a universal integration filter module and a set of configuration modules, one for each subsystem. The integration filter module would be designed by data fusion experts without the need for detailed knowledge of the subsystems. It would accept a number of generic measurement types, such as position fixes and pseudo-ranges, with associated metadata. The configuration modules would be developed by the subsystem suppliers and would convert the subsystem measurements into a format understood by the filter module and supply the metadata. They would also mediate the feedback of information from the integration filter to the subsystems. The metadata comprises the additional information required to integrate the measurements such as
- the measurement type and any coordinate frame(s) used.
- a sensor identification number (to distinguish measurements of the same type from different sensors).
- statistical properties of the random and systematic measurement errors.
- identification numbers and locations of transmitters and other landmarks.
A key advantage of this approach is that subsystems may be changed without the need to modify the integration filter. Provided the new subsystem is compatible, all that is needed is the corresponding configuration module.
Figure 3 shows an example of a modular integration architecture for a combination of conventional GNSS positioning, GNSS shadow matching, Wi-Fi positioning, and PDR. As well as providing measurements and associated statistical data to the integration filter module, the configuration modules feedback relevant information to the subsystems. Shadow matching works by comparing measured and predicted signal availability over a number of candidate positions, so requires a search area to be specified using other positioning technologies. PDR uses information from other sensors, where available, to calibrate the coefficients of its step length estimation model and correct for heading drift. Conventional GNSS positioning can also benefit from position and velocity aiding to support acquisition and tracking of weak signals in indoor and urban environments.
Figure 3. Modular integration of conventional GNSS, shadow matching, PDR, and Wi-Fi positioning for pedestrian navigation (different colors denote potentially different suppliers). (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) In principle, each subsystem configuration module could simply supply a position fix to the integration filter module with an associated error covariance. However, other forms of measurement generally give better results. For conventional GNSS positioning, the advantages of tightly coupled (range- domain) integration over loosely coupled (position-domain) are well known.
PDR is a dead-reckoning technique, so measures distance traveled rather than position. Consequently, providing measurements of position displacement and direction can avoid cumulative errors in the measurement stream.
GNSS shadow matching and some types of Wi-Fi positioning use the pattern-matching positioning method. This scores an array of candidate position solutions according to the match between the measured and predicted signal availability or signal strength. Although the output of these algorithms is in the position domain, a likelihood distribution can provide more information for the integration filter than a simple mean and covariance.
Other navigation and positioning techniques generate further types of measurement, including velocity, attitude, specific force, angular rate, range rate, and bearings and elevations of features. The types of measurement depend on the positioning method.
A universal integration filter must operate without prior knowledge of which measurements it must process and which states it must estimate. Consequently, it must reconfigure its measurement vector, state vector, and associated matrices according to the measurements available, using the metadata supplied by the configuration module. This capability is sometimes called “plug and play,” and a number of prototypes have been developed by different research groups.
The integration filter must be capable of implementing either error-state or total-state integration, depending on the measurements available. In error-state integration, one of the subsystems, such as inertial navigation, provides a reference navigation solution. The integration filter estimates corrections to that solution using the measurements from other subsystems. In total-state integration, the integration filter estimates the position and velocity directly, and an additional configuration module provides information on the host vehicle (or pedestrian) dynamics.
Modular integration algorithms could form part of a wider modular integrated navigation concept in which subsystem hardware and software is shared across a range of applications.
Issues to Resolve
A critical requirement for the successful implementation of modular integration is an open-standard interface for communication between the universal filter and configuration modules. This enables modules produced by different organizations to work together. To realize the full benefits of modular integration, in terms of interoperability and software re-use, there should be a single standard covering the consumer, professional, research, and military user communities and spanning all of the application domains air, sea, land, indoor, underwater, and so forth. A standard developed by one group in isolation is unlikely to meet the needs of the whole navigation and positioning community, while the development of multiple competing standards defeats the main purpose of modular integration.
This interface should be defined in terms of fundamental measurement types, such as position, velocity, and the ranges, bearings, and elevations of signals and features. However, there are many different coordinate systems that may be used and positioning may be in 2 or 3 dimensions, while ranging measurements may be true ranges or pseudoranges. Ranging and angular positioning measurements may be differenced across transmitters or landmarks, differenced across receivers or sensors, or double differenced across both.
A universal interface must support every measurement type that requires different processing by the filter module. However, it need not support formats that are easily convertible. Thus, there is no need to support both the north, east, down, and east, north, up conventions. There are two main approaches to defining the fundamental measurement types:
- A minimal number of very generic measurement types with metadata used to describe how these should be processed by the integration filter.
- A large number of more specific measurement types for which the processing methodology is already known.
For each measurement type, an error specification must be defined. For error sources assumed to be white, a standard deviation or power spectral density (PSD) is required. For correlated errors, such as biases, information on the time correlation is required alongside variances and covariance information. The interface standard should include every conceivable error source. Unused errors can simply be zeroed. The filter module should then use the error specification to determine which error sources to model and how.
Obtaining reliable navigation sensor error specifications can be difficult. Manufacturers often provide only limited information, while performance in the field can be different from that in the laboratory due to vibration and electromagnetic interference. For new positioning techniques, the error behavior may not be fully understood, while complex error behavior can be difficult to measure. Adaptive estimation techniques provide only a partial solution. Even where the error behavior is well known, it can be too complex to practically model within the estimation algorithm. This could represent a fifth challenge.
For subsystems used as the reference in an error-state integration filter, such as an inertial navigation system (INS), the errors will typically be correlated across the different components of the subsystem navigation solution, for example position, velocity, and attitude. Furthermore, to represent the error behavior within an integration algorithm, it is necessary to model the error properties of the underlying sensors, accelerometers and gyroscopes in the case of inertial navigation. Thus, it is likely that additional compound measurement types for reference system data will be needed.
For pseudorange measurements, an issue to consider is the synchronization of different transmitter and receiver clocks. Clocks in receivers for different types of signal, such as GNSS and Loran, may or may not be synchronized with each other. Also, the transmitter clocks are typically synchronized in groups. For example, the GPS satellite clocks are synchronized with each other, as are the GLONASS satellite clocks, but GLONASS is not currently synchronized with GPS. For optimal integration of pseudoranges from different sources, this information must be conveyed to the integration filter.
The interface standard for communication between the filter and configuration modules must also support feedback of information from the integration filter to the subsystems, via the configuration modules. The integrated position, velocity, and attitude solution, with its associated error covariance, is useful for aiding many different subsystems. Therefore, a generic standard for this should be defined. Conversely, the feedback to the subsystems of calibration parameters estimated by the integration algorithm is sensor specific, so should be incorporated in the definitions of the fundamental measurement types.
The user requirements, such as accuracy, integrity, continuity, solution availability, update rate, and power consumption, can vary greatly between applications. For example, accuracy is important for surveying, integrity for civil aviation, solution availability for many military applications, and power consumption for many consumer applications. This impacts the design of the whole navigation system. Different modules could be used for different applications. However, it is more efficient if the components adapt to different environments. Figure 4 shows how requirements information can be disseminated in a modular integrated navigation system.
Figure 4. Modular integration architecture incorporating requirements. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) An open-standard interface specification should be able to handle any conceivable navigation and positioning system. However, it is more efficient if the components adapt to different environments. Similarly, there will be differences in the error magnitudes that an integration filter can handle and in its capability to handle non-Gaussian error distributions. Variations in fault detection and integrity monitoring capability can also be expected. Consequently, there must be a capability specification for each filter module and a protocol for handling mismatches between the measurements and the filter module, and a means to certify that a filter module actually has the claimed capabilities. (Further discussion of modular integration may be found in our IEEE/ION PLANS 2014 paper, “The Four Key Challenges of Advanced Multisensor Navigation and Positioning,” and the Journal of Navigation paper, “The Complexity Problem in Future Multisensor Navigation and Positioning Systems: A Modular Solution.”)
Context
Context is the environment that a navigation system operates in and the behavior of its host vehicle or user. Examples include a pedestrian walking (behavior) in an urban street (environment), a car driving at highway speeds on an open road, and an airliner flying high above an ocean.
Context is critical to the operation of a navigation or positioning system. The environment affects the types of signals available. For example, GNSS reception is poor indoors while Wi-Fi is not widely available outside towns and cities. In underwater environments, most radio signals cannot propagate so acoustic signals are used instead. Processing techniques can also be context dependent. For example, in open environments, non-line-of-sight (NLOS) reception of GNSS signals or multipath interference may be detected using consistency checking techniques based on sequential elimination. However, in dense urban areas, more sophisticated algorithms are required and may be enhanced using 3D city models. GNSS shadow matching only works in outdoor urban environments.
Navigation using environmental feature matching is inherently context-dependent as different types of feature are available in different environments. Suitable algorithms, databases, and sensors must be selected. For example, terrain referenced navigation (TRN) uses radar or laser scanning in the air, sonar or echo sounding at sea, and barometric pressure on land. Map matching requires different approaches for cars, trains, and pedestrians. Similarly, algorithms and databases for image-based navigation depend on the types of feature available, which vary with the environment.
Behavioral context is also important and can contribute additional information to the navigation solution. For example, cars normally remain on the road, effectively removing one dimension from the position solution. Their wheels also impose constraints on the way they can move, reducing the number of inertial sensors required to measure their motion. Similarly, PDR using step detection depends inherently on the characteristics of human walking. Using PDR for vehicle navigation or vehicle motion constraints for pedestrian navigation will produce errors.
Host vehicle behavior is also important for tuning the dynamic model within a total-state navigation filter and for detecting faults through discrepancies between measured and expected behavior. Within a GNSS receiver, the behavior can be used to set tracking loop bandwidths and coherent correlator accumulation intervals, and to predict the temporal variation of multipath errors. The antenna placement on a vehicle or person can also affect performance.
Historically, context was implicit; a navigation system was designed to be used in a particular type of vehicle, handling its associated behavior and environments. However, many navigation systems now need to operate in a variety of different contexts. For example, a smartphone moves between indoor and outdoor environments and can be stationary, on a pedestrian, or in a vehicle. Similarly, a small surveillance drone may operate from above, amongst buildings, or even indoors. At the same time, most of the new positioning techniques developed to enable navigation in challenging environments, are context-dependent. To make use of these techniques in practical applications (as opposed to research demonstrators), it is necessary to know the context.
Context-Adaptive Navigation
The solution to the problem of using context-dependent navigation techniques in variable-context applications is context-adaptive navigation. As shown in Figure 5, the navigation system detects the current environmental and behavioral context and, in real time, reconfigures its algorithms accordingly. For example, different radio positioning signals and techniques may be selected, inertial sensor data may be processed in different ways, different map-matching algorithms may be selected, and the tuning of the integration algorithms may be varied.
Figure 5. A context-adaptive navigation system. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Previous work on context-adaptive navigation and positioning focused on individual subsystems and concerned either behavioral or environmental context, not both.
For example, there has been substantial research into classifying pedestrian motion using inertial sensors to enable PDR algorithms using step detection to estimate the distance travelled from the detected motion. The context information may also be used for non-navigation purposes.
Typically, orientation-independent signals are generated from the accelerometer and gyro outputs. Statistics such as the mean, standard deviation, root mean squared (RMS), inter-quartile range, mean absolute deviation, maximum−minimum, maximum magnitude, number of zero crossings, and number of mean crossings are then determined from a few seconds of data. Frequency-domain statistics may also be used. Finally, a pattern recognition algorithm is used to match these parameters to the stored characteristics of different combinations of activity types and sensor locations.
Detection of road-induced vibration using accelerometers has been used to determine whether or not a land vehicle is stationary, while a calibrated yaw-axis gyro can be used to determine when a vehicle is travelling in a straight line. Indoor and outdoor environments may be distinguished using GNSS carrier-power-to-noise-density ratio (C/N0 ) measurements. Wi-Fi signals might also be used for environmental context detection.
Context Detection Experiments
We have conducted a number of different context-detection experiments using GNSS, Wi-Fi, and accelerometers. Full details are presented in our ION GNSS+ 2013 paper, “Context Detection, Categorization and Connectivity for Advanced Adaptive Integrated Navigation,” and in our PLANS 2014 paper. Here, some highlights from the results are presented.
GNSS. GNSS data was collected at five locations inside and immediately outside UCL’s Grant Museum of Zoology; these are shown in Figure 6. C/N0 measurement data was collected from all GPS and GLONASS signals received by a Samsung Galaxy S3 Android smartphone. About 60 seconds of data was collected at each site. Figure 7 presents histograms of the C/N0 measurements and Table 1 lists the means and standard deviations.
Figure 6. Locations for the GNSS indoor/outdoor context detection experiment. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) 
Figure 7. GNSS C/N0 measurement distributions at sites inside and immediately outside UCL’s Grant Museum of Zoology. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) 
Table 1. Means and standard deviations of GNSS C/N0 measurements inside and outside UCL’s Grant Museum of Zoology. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) As expected, the average received C/N0 is lower indoors than outdoors and lower deep indoors than near the entrance. Furthermore, the standard deviation of the C/N0 measurements is larger outdoors than indoors and also larger near the entrance to the building than deep indoors. Thus, both the mean and the standard deviation of the measured C/N0 across all GNSS satellites tracked are useful both for detecting indoor and outdoor contexts and for distinguishing between different types of indoor environment.
Indoor/Outdoor Detection, Wi-Fi. Tests in and around several UCL buildings have shown no clear relationship between Wi-Fi SNRs and environmental context. However, as the environment changes, there is a rapid change in the Wi-Fi SNRs over a few epochs. For a user moving from inside to outside of a particular building, those signals which originate inside go from strong to weak, while many of those from neighboring buildings become stronger. Consequently, Wi-Fi signals could potentially be used to detect context changes instead of the absolute context. This is useful for improving the overall robustness of context determination.
To test this, Wi-Fi data was collected using a Samsung Galaxy S3 smartphone along a route with both indoor and outdoor sections and a context-change score calculated from the last six epochs of data at 1-second intervals.
Context-change score results are presented in Figure 8. The large blue blocks indicate when the user was outside and the smaller blue block shows when the user was in the building’s basement, a very different Wi-Fi environment. As can be seen, there are clear peaks in the “context change” score whenever the user moves between indoor and outdoor contexts.
However, there are also peaks when the user enters and leaves the basement, so the technique is sensitive to false positives and must be combined with other context detection techniques to be used reliably.
Figure 8. Context-change score computer from Wi-Fi SNR measurements. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Behavioral Detection, Accelerometers. The use of accelerometers to detect behavioral context is well established. However, by looking at the vibration spectra, more information can be extracted. For these experiments, specific force data was collected using an Xsens MTi-G IMU/GNSS device, the mean subtracted to remove most of the gravity, and a discrete Fourier transform obtained using the MATLAB function fft. Figures 9 and 10 respectively show the vibration spectra of the specific force magnitude for an IMU on a table and held by a stationary pedestrian. The table spectrum is approximately white, whereas the pedestrian data shows peaks between 6 and 10 Hz.
Figure 9. IMU spectra on a table. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) 
Figure 10. IMU spectra, stationary pedestrian. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Figures 11 and 12 respectively show the vibration spectra of a stationary Vauxhall Insignia car, and a stationary urban electric train. Here, the individual accelerometer spectra are shown. In each case, the x-axis was pointing forward, the y-axis to the right and the z-axis down. The car exhibits a lot of vibration at frequencies above 10 Hz due to its engine, whereas the dominant train vibration peak is around 1.5 Hz, with smaller peaks at 15 Hz, 25 Hz, 33 Hz, and 50 Hz, the mains power frequency. Thus, the two vehicles are very different from each other and also from the pedestrian. Figure 13 then shows the vibration spectrum of the car moving on a high-speed road. As might be expected, there is much more vibration when moving with broad peaks below 15 Hz due to road vibration and above 15 Hz due to engine vibration.
Figure 11. Specific force frequency spectrum of a stationary car. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) 
Figure 12. Specific force frequency spectrum of a stationary train. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) 
Figure 13. Specific force frequency spectrum of a car traveling on a high- speed road. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Finally, Figure 14 shows the vibration spectra on an escalator at an underground rail station. The IMU was in the trouser pocket of a pedestrian. Vibration at a range of frequencies below 30 Hz can be seen and it was observed that the resonant frequencies vary between individual escalators.
Figure 14. Specific force frequency spectrum on an escalator. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Issues to Resolve
Despite the work done with individual sensors, a multisensor integrated navigation system that adapts to both environmental and behavioral context remains at the concept stage. Realizing this in a practical system requires both effective context determination and a set of context categories standardized across the whole navigation and positioning community.
The first step in the standardization process is to establish a framework suitable for navigation and positioning. Each context category must map to a configuration of the navigation system; otherwise, it serves no purpose. Multiple categories may map to the same configuration as different navigation systems will respond to different context information. In an autonomous context-adaptive navigation system, the context categories must also be distinguishable from each other.
Figure 15 shows the relationships in a five-attribute framework, comprising environment class, environment type, behavior class, vehicle type, and activity type. The environmental and behavioral contexts are treated separately because they perform fundamentally different roles in navigation. Environmental context concerns the availability of signals and other features that may be used for determining position whereas behavioral context is concerned with motion.
Figure 15. Proposed attributes of a context category. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Context may be considered at different levels. Sometimes it is sufficient to consider broad classes such as indoor or aircraft. In other cases, more detail is needed, specifying the type of indoor environment or the type of aircraft. Therefore, a two-level categorization framework, comprising class and type is proposed. The behavioral context comprises the vehicle type and the activity undertaken by that vehicle. A common set of classes containing separate vehicle and activity types is thus proposed. For pedestrian navigation, different parts of the body move quite differently, so the sensor location on the body is analogous to the vehicle type.
The broad classes of environmental and behavioral context are relatively obvious. We therefore propose that the community adopts the classes in Table 2. Standardization at the type level requires further research to determine:
- which context categories a navigation system needs to distinguish between in order to optimally configure itself;
- which context categories may be distinguished reliably by context detection and determination algorithms.
Table 2. Proposed environment and behavior classes. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Effective Context Determination. The reliability of current context detection techniques is typically 90−99%, with some context categories easier to detect than others. For the purposes of controlling a navigation system, this is relatively poor. Furthermore, context detection research projects have typically considered a much smaller range of context categories than a practical context-adaptive navigation system would need. Generally, the more categories there are, the harder it is to distinguish between them.
To make context determination reliable enough for context- adaptive navigation to be practical, a new approach is needed. Firstly, the context should be detected using as much information as possible, maximizing both the range of sensors used and the number of parameters derived from each sensor.
Environmental context detection experiments have largely focused on GNSS and Wi-Fi signals. Other types of radio signal; environmental features detected using cameras, laser scanners, radar, or sonar; ambient light; sounds; odors; magnetic anomalies, and air pressure could all be used. Context may also be inferred by comparing the position solution with a map, provided both are sufficiently accurate.
Behavioral context detection experiments have generally used inertial sensors. As shown earlier, this could be taken further by analyzing different frequency bands and, where possible, separating the forward, transverse, and vertical components. Other motion sensing techniques, such as visual odometry and wheel-speed odometry could be used. Context information, such as vehicle type, can also be determined from the velocity, attitude, and acceleration solutions.
Considering every combination of environment type, vehicle type (or pedestrian sensor location), and activity type produces potentially tens of thousands of different context categories — too many to practically distinguish using context detection techniques alone. However, the number of context categories that must be considered may be reduced substantially by using association, scope, and connectivity information, making the determination process much more reliable.
Association is the connection between the different attributes of context. Certain activities are associated with certain vehicle types and certain behaviors are associated with certain environments; an airliner flies, while a train does not, and flying takes place in the air, not at the bottom of the sea.
For a particular application, the scope defines each context category to be required, unsupported, or forbidden. This enables forbidden context categories to be eliminated from the context determination process and required categories to be treated as more likely than unsupported categories.
Connectivity describes the relationship between context categories. If a direct transition between two categories can occur, they are connected. Otherwise, they are not. Thus, stationary vehicle behavior is connected to pedestrian behavior, whereas moving vehicle behavior is not because a vehicle must normally stop to enable a person to get in or out. Context connectivity is directly analogous to the road link connectivity used in map matching and a similar mathematical formulation may be used. In practice, it is best to represent the connectivity as continuously valued transition probabilities rather than in Boolean terms. This facilitates recovery from incorrect context determination and enables rare transitions between context categories to be represented.
Location-dependent connectivity takes the concept a stage further by considering that many transitions between context categories happen at specific places. For example, people normally board and leave trains at stations and fixed-wing aircraft typically require an airstrip to take off and land. Thus context transition probabilities may be modeled as functions of the position solution, provided the positioning and mapping error distributions are adequately modeled and the probability of transitions occurring at unusual locations is considered.
Finally, for maximum robustness, the whole context determination process should be probabilistic, not discrete. The system should maintain a list of possible context category hypotheses, each with an associated probability. Multiple context detection algorithms should be used, each based on different sensor information. The detection algorithms should also output multiple context category hypotheses with associated probabilities. The context determination algorithm should then produce a new list of context category hypotheses and their probabilities by combining:
- the previous list of hypotheses and their probabilities;
- the hypotheses and probabilities output by the context detection algorithms;
- context association, scope, and connectivity information.
Figure 16 illustrates the concept. When there is insufficient information to determine a clear context category, the list of context hypotheses and their probabilities will be output to the navigation algorithms. The handling of ambiguous information in navigation systems is discussed in Part 2.
Figure 16. Probabilistic context determination. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Context Adaptivity and Integration
The practical implementation of a complex multisensor navigation system for a multi-context application requires context-adaptive navigation to be incorporated into a modular multisensor integration architecture as described earlier. To enable different modules to adapt to changes in context, the architecture shown in Figure 4 should be extended to supply context information to the configuration modules, integration filter, and dynamic model from the system control module, alongside the user requirements. The configuration modules can then pass the context information onto the subsystems where necessary. Standardization of context categories and definitions across the navigation and positioning community is essential for this. Distribution of context information is useful even for single-context applications as it enables suppliers to provide modules that are optimized for multiple contexts.
The modular integration architecture must also support the context detection and determination process, allowing all subsystems to contribute. The configuration modules should therefore provide context detection information to a context determination module, as shown in Figure 17. The scope information should be supplied by the system control module.
Figure 17. Context-adaptive modular multisensor integration architecture. (Photo: Paul D. Groves, Lei Wang, Debbie Walter, Henry Martin, and Kimon Voutsis, University College London) Potential architectures for this are discussed in our PLANS 2014 paper.
Ambiguity and Environmental Data
Part 2 of this article, appearing in the November issue, explores the two remaining key challenges and forms conclusions and recommendations.
Paul Groves is a lecturer at University College London (UCL), where he leads a program of research into robust positioning and navigation. He is an author of more than 50 technical publications, including the book Principles of GNSS, Inertial and Multi-Sensor Integrated Navigation Systems, now in its second edition. He is a Fellow of the Royal Institute of Navigation and holds a doctorate in physics from the University of Oxford.
Lei Wang is a Ph.D. student at UCL. He received a bachelor’s degree in geodesy and geomatics from Wuhan University. He is interested in GNSS-based positioning techniques for urban canyons.
Debbie Walter is a Ph.D. student at UCL. She is interested in navigation techniques not reliant on GNSS, multi-sensor integration and robust navigation. She has an MSci from Imperial College London in physics and has worked as an IT software testing manager.
Henry Martin is a Ph.D. student at UCL. His project is concerned with improving navigation performance from a low-cost MEMS IMU. He is interested in inertial navigation, IMU error modelling, multi-sensor integration and calibration algorithms. He holds a master of mathematics degree from Trinity College at the University of Oxford and an MSc in advanced mechanical engineering from Cranfield University.
Kimon Voutsis is a Ph.D. student at UCL. He is interested in pedestrian routing models, human biomechanics, and positioning sensor performance under high accelerations, particularly IMUs and GNSS. He holds an MSc in geographic information science (UCL). His Ph.D. project investigates the effects of pedestrian motion on positioning.
All authors are members of UCL Engineering’s Space Geodesy and Navigation Laboratory (SGNL).
-
Multi-Constellation. Dual-Frequency. Single-Chip.
Fully Integrated NAPA Receiver Brings Mass-Market Potential
This integrated circuit supports simultaneous reception and processing of the GPS L1/L5, Galileo E1/E5a, and GLONASS G1 signals with 40 tracking channels. The dual-band analog RF front-end is integrated on the same mixed-signal chip as the baseband hardware, including an embedded processor to close the tracking loops: overall, a compact, low-power, and low-cost solution.
By Fabio Garzia, Stefan Köhler, Santiago Urquijo, Philipp Neumaier,Jörn Driesen, Sybille Haas, Thomas Leineweber, Tao Zhang, Sascha Krause, Frank Henkel,Alexander Rügamer, Matthias Overbeck, and Günther Rohmer
Multi-constellation multi-band global navigation satellite system (GNSS) receivers can efficiently exploit the advantages derived from the modernization of existing GNSS constellations, such as GPS and GLONASS, as well as from the launch of new ones like Galileo and BeiDou. Utilizing multiple systems can significantly improve the availability of a navigation solution in urban canyons and heavily shadowed areas. Increased satellite availability also guarantees higher measurement redundancy and improved reliability. Moreover, the excellent inherent noise and multipath mitigation capabilities of the new and modernized wideband signals in the L5/E5a band, combined with the ionosphere error mitigation given by frequency diversity, significantly improves the accuracy in both measurement and position domains.
Still, most commercial fully-integrated single-chip mass market GNSS receivers use only a single-frequency band for their positioning, velocity, time (PVT) solution: either GPS L1 C/A or Galileo E1 and GLONASS G1. For example, the Teseo chips are single-chip solutions that support multiple constellations but only on one frequency band. This approach reduces design costs and enables the lowest consumption of power, but neglects the advantages of wideband signal processing – which offers increased robustness thanks to two simultaneous frequency band receptions and the capability of mitigating the ionosphere error.
Another approach for realizing multi-constellation multi-frequency solutions is to combine different chips for the analog front-end and the digital baseband. One fully integrated single-chip analog multi-band front-end for the simultaneous reception of GPS L1/L5, Galileo E1/E5, and GLONASS has been presented. However, this chip included only the front-end and requires an additional, separate digital-baseband solution.
The purpose of the NAPA project (NAvigation chip for Pedestrian navigation and higher precision Applications) is to close this gap by providing a fully integrated, compact, low-power, and low-cost solution in which the analog and digital parts of the GNSS receiver are integrated together on the same chip. The NAPA receiver offers all the advantages of multi-constellation reception with additional dual-frequency support.
The NAPA chip features a monolithic, single mixed-signal chip implementation of a multi-system, multi-band analog front-end and the related digital baseband core, including an embedded processor. The NAPA chip can be used as a stand-alone GNSS sensor, because no additional components are required to obtain a PVT solution. The ASIC was implemented in a low-power technology and adopts some ad-hoc low-power architectural features. In regard to costs, an ASIC solution is more convenient than FPGA, provided the non-recurring engineering costs (NRE) are amortized by the amount of chips manufactured and sold. The NAPA chip supports multi-system (GPS, Galileo, and GLONASS) and multi-band (GPS/Galileo L1/E1, L5/E5a, GLONASS G1) processing. Figure 1 shows the frequency band being selected for receiving and processing in the NAPA chip. With two fully deployed GNSS — GPS and GLONASS — NAPA chips can already be used in many commercial applications. Thanks to the spectral overlay of the GPS L1/L5 and Galileo E1/E5a signals, the chip is also ready for Galileo. The frequency selection features both the narrow-band legacy signals L1/G1, which can be used for fast acquisition. For highest tracking accuracy, the wideband GPS L5 and Galileo E5a BPSK(10) modulated signals can be utilized.
Figure 1. GNSS signals received and processed by the NAPA chip. The higher accuracy is obtained primarily by the attenuation of the ionospheric error. The ionosphere is a dispersing media that can introduce a bias error between 1 and 20 m. Forming a linear combination of two independent frequency-band measurements, the ionospheric bias can be measured and almost completely removed. In addition, Precise Point Positioning and Wide/Narrow-laning combinations are possible, thanks to the second received frequency band. The first allows for the combination of precise satellite positions and clocks with multi-frequency measurements, providing cm/dm solutions. The second adopts fast ambiguity solutions for carrier-phase positioning and cycle-slip detection.
In this article, we present the NAPA chip in detail. We describe the architecture of the analog front-end and its digital counterpart and the innovative features of each. Then we provide details about chip implementation, manufacturing, and test setup. Finally, we present the first verification results and draw conclusions.
Architecture Overview
The NAPA chip architecture, depicted in Figure 2, is composed of two separate blocks integrated on the same silicon die: the analog core provides the functionality of a two-frequency radio-frequency (RF) front-end, whereas the digital part implements the main GNSS processing tasks, including the correlator channels and an embedded processor, and takes care of the RF front-end control. The interface between the two blocks is completely digital and provides synchronizers to ensure a valid clock domain crossing (CDC).
Figure 2. Overall NAPA architecture with emphasis on the digital core blocks. Analog Front-End. The analog RF front-end supports the simultaneous reception of GPS L5 / Galileo E5a and GPS L1 / Galileo E1 / GLONASS G1 signals as well as modes where only one reception path is activated.
Both passive and active GNSS antennas are supported, thanks to integrated low noise amplifiers (LNA). There are two separate signal reception paths for the two frequency bands. The L1/E1/G1 path is characterized by a quasi-zero-IF conversion that mixes the middle frequency between L1/E1 and G1 to zero frequency. The L1/E1 reception bandwidth is up to 14 MHz so as to incorporate the MBOC modulations of Galileo E1 and future GPS L1C signals. A programmable automatic gain control (AGC) controls the complex analog baseband signals before they are digitized with a 4-bit dual-channel analog digital converter (ADC).
The second reception path receives an L5/E5a signal with up to 20 MHz bandwidth for the BPSK(10) modulated signals. This path uses a low-IF architecture. The signal is down-converted to an intermediate frequency (IF) of 15.345 MHz. The image frequency is suppressed by a polyphase filter. The real-valued analog signal is controlled by an AGC and converted to the digital domain using a single 4-bit ADC. A common phase locked loop (PLL) is used with specific L1/E1/G1 and L5/E5a dividers to generate the mixers’ local oscillator (LO) frequencies. The PLL loop filter is integrated on-chip to minimize external elements. Moreover, automatic filter and voltage-controlled oscillator (VCO) calibrations are included to mitigate process tolerances. The PLL can handle input clock frequencies between 10 and 80 MHz with a recommended clock frequency of 36.115 MHz.
An SPI core was implemented on the front-end part to facilitate control of the different front-end features. This means it is possible to tune the PLL, to switch off a complete front-end path if the second frequency band is not used and to activate different on-chip calibration procedures.
The frequency plan of the front-end is depicted in Figure 3. Due to the quasi zero-IF architecture, the complex L1/E1 baseband signal is located on an IF of -13.64 MHz and the GLONASS G1 frequency division multiple access (FDMA) signals on an IF of +12.94 MHz, with respect to the GLONASS G1 center frequency of 1602 MHz. The real-valued L5/E5a signals are provided by the second ADC and located on an IF of 15.345 MHz.
Figure 3. RF front-end frequency plan. The ADC samples are generated with a frequency of 74.4871875 MHz for both the single channel L5, as well as for the dual-channel L1/E1/G1 ADCs. The ADC clock is also directly connected to the baseband digital core and is used as the main clock for the GNSS hardware modules. The embedded processor in the digital core receives a second clock, which is twice as fast as the GNSS hardware one.
Digital Baseband SoC. The baseband is characterized by a system-on-chip (SoC) architecture based on a SPARC-compatible 32-bit LEON2 microprocessor running at approximately 150 MHz. The GNSS functionality, including acquisition and tracking, are implemented using dedicated hardware modules.
The processor’s primary functions are to correctly configure the RF front-end and control the different parts of the receiver. In particular, it triggers acquisition, initializes, and starts the tracking channels with the signals detected during acquisition and takes care of closing the frequency/phase/delay locked loops (FLL/PLL/DLL) used for signal tracking. The tracking loops have strict real-time constraints; communication between the channels and the processor features a high-speed infrastructure.
Structurally, the processor is connected to a hierarchical on-chip Advanced Microcontroller Bus Architecture (AMBA) composed of a high-performance bus (AHB) and a peripheral bus (APB). The AHB provides a direct connection between the processor, the real-time GNSS modules, and the system memory, a monolithic 1 MByte block that hosts the main program at run-time. Different programs can be loaded if needed by using the external SD-card interface.
In addition to the processor, there are four additional AHB masters: the bootloader, the SD-card controller, the real-time GNSS modules, and the on-chip processor debugger. The bootloader is in charge of the bus control at system start-up. The SD-card controller has integrated direct-memory access (DMA) capabilities to move data between the SD card and the system memory. The real-time GNSS modules can write the tracking results directly to the system memory. Finally, the integrated processor debugger allows real-time debugging and is used mainly in the verification phase. The APB provides a connection to generic peripherals, and control and status interface of the GNSS modules without real-time constraints, as well as the control and status interface of the RF front-end. Since the GNSS modules operate in a separate clock domain that runs at half the frequency of the processor domain, some synchronization logic is necessary to ensure correct CDC.
The adoption of an SoC architecture provides higher flexibility than conventional static hardware solutions. In addition to typical GNSS applications, the user can also implement some signal monitoring and processing algorithms in software. The eCos-embedded operating system is provided to ease software development.
Generic Peripherals. The digital core is equipped with several peripherals that enable the communication with the outside world. The two separate universal asynchronous receiver/transmitter (UART) interfaces can run at 115.2 kbps. A dedicated serial peripheral interface (SPI) master is also provided with a maximum of 10-MHz clock frequency. For example, these interfaces can be used to provide NMEA data to some external display device or raw data (pseudoranges, code phases) in order to calculate a PVT solution. It is also possible to directly access the measurements generated from the correlator hardware and to control the tracking NCOs, which means users can choose their own algorithms for the loop closure. A possible application is the realization of vector-delay tracking using the NAPA ASIC and an external processor.
The SD-card interface facilitates the loading and storage of large amounts of data, for example, memory codes and almanacs. The possibility of making signal snapshots periodically and saving them to an SD card for later analysis has also been foreseen. This could be useful in special applications in which the receiver hardware is not accessible to the user all of the time.
In addition, 10 general-purpose I/O pins (GPIO) are provided. They can be controlled via software and can provide a very basic interface (for example, to connect to external LEDs or switches).
Acquisition Module. The acquisition module adopts a parallel code phase search in the Fourier domain by using a 16-k Samples Fast Fourier Transform (FFT) core. The adopted algorithm is known as parallel code-phase search.
The L1/E1/G1 signals coming from the front-end are first filtered and then sent to the acquisition module to allow a fast detection of the satellites in the L1/E1/G1 bands with their respective code delays and Doppler frequencies. The acquisition of GLONASS G1 FDMA signals is possible thanks to a software-configurable hardware mixer that can be set with the different G1 carrier frequencies. No direct hardware acquisition is supported for the L5/E5a band signals. The tracking of L5/E5a band signals is possible by performing a hand-over from L1/E1 band or a Tong search using the tracking channels.
The acquisition process is performed iteratively over all the possible satellites and over a set of Doppler values. These values are obtained by dividing the complete range of possible Doppler variations into bins. The smaller these bins are, the more accurate the acquisition result, but the more time is required to complete the entire process.
The acquisition has an additional layer of configurability because of the adoption of coherent and incoherent accumulations. These accumulations are supported in hardware but are completely software-controlled. This provides another possibility for achieving higher accuracy, but at the cost of a larger execution time due to an increase in the amount of accumulations.
To speed up acquisition, we introduced a dedicated logic based on a novel patented algorithm. With this algorithm, we are able to detect the Doppler of the L1/E1 satellites present in the signal with an accuracy of 2 Hz. By performing this Doppler search step before the actual acquisition, we are able to generate a list with Doppler values that can be used instead of the bins. This gives more accurate results thanks to the algorithm’s inherent accuracy (see Figure 4) and allows a reduction in the acquisition time since the amount of Doppler values are usually smaller than the bins. Another advantage of this algorithm is the possibility to detect the transition to an indoor context (such as where there is a lack of satellite signals) by simply looking at the Doppler list, without performing any acquisition.
Figure 4. Comparison between standard and Doppler-list based acquisition of an L1 signal. A single iteration step for the acquisition of a GPS L1 signal requires no more than 1 ms for each accumulated epoch. To achieve a good compromise between accuracy and speed, we typically use four epochs of incoherent accumulation, which means approximately 4 ms execution time. For Galileo L1 with four incoherent accumulations, an iteration step takes approximately 16 ms. This time has to be multiplied by the number of satellites and bins to estimate the execution time of the complete process.
Integrated Acquisition Memories. The acquisition module is characterized by dedicated memory blocks used for the fast FFT processing. It also provides the possibility to use these on-chip memories to store a snapshot of the incoming signals. In particular, we can store up to 81,920 samples of raw data for the complex L1 and real L5 IF signals for further analysis or processing, even off-chip. This enables sophisticated spoofing detection methods, for example, as well as interferer detection and characterization methods. Spoofing detection can be implemented by monitoring the 2D-acquisition search space. Interferer detection and characterization can employ short-time Fourier transforms (STFT) on the snapshot.
Using the chip as a simple snapshot receiver without having to use the on-chip dedicated GNSS hardware is also a possibilty. For this purpose, the integrated peripherals like UART and SPI ports are provided as interfaces.
Tracking Module. The 40 versatile tracking channels can be mapped to any combination of GPS, Galileo, and GLONASS signals on the two reception bands. One possible combination would be to track 10 GPS and 10 Galileo satellites simultaneously on both L1/E1 and L5/E5a bands. Alternatively, the user can include GLONASS signals by using fewer GPS / Galileo combinations. The assignment of these tracking channels to the actual GNSS signals can be changed at run-time in order to adapt to different reception situations or to assist the selected signal processing methods.
Each channel is characterized by a five-tap correlator. For the BPSK modulated signals without side peaks, such as GPS L1/L5, Galileo E5a, and GLONASS G1, we use only three values (early, late, and prompt). For Galileo E1 BOC(1,1) signals, five values are foreseen (very early and very late in addition to the previous), so that false peak lock conditions can be detected and a bump-jumping algorithm can be applied. The switch between these modes can be done at run-time and determines the amount of correlation values to be exchanged between correlators and processor.
Low-Power Features. The GNSS modules operate in their own clock domain. This clock domain is divided in clock-gated regions. There is a common region for the bus interfaces, one region for the acquisition, and one for each tracking channel. This allows a fine-grain shut-down of the GNSS modules that are not currently in use. For example, the acquisition can be deactivated when there are enough signals in tracking or the unused tracking channels can be disabled. This allows a reduced power consumption for the idle modules. This activation/deactivation procedure is controlled through a set of registers connected to the APB and is performed via software.
External Front-End Interface. To allow for more flexibility, we provided an additional RF front-end interface. The interface is also depicted in Figure 3. This interface features one 2-bit complex and an additional 2-bit real input, as well as a clock input. The user can decide to directly connect the digital baseband core to an external RF front-end with compatible sampling rate parameters, and exclude the on-chip RF front-end. This makes it possible to use the NAPA chip for validating other RF front-end devices, or it can be adapted to special customer needs.
Boot-Up Sequence. The SoC includes a hard-coded bootloader that is in charge of the bus control at start-up. In this phase, the processor is switched off. The bootloader loads a 24-kByte program from the SD-card to the system memory and starts the processor. In this phase, the processor runs with the external oscillator clock. Having performed the RF front-end initialization, the processor can switch to the front-end PLL generated processor clock that runs at approximately 150 MHz. This switch is completely transparent to the processor. Then the actual main GNSS receiver program is loaded into the system memory and executed.
The NAPA Chip
The NAPA chip has been manufactured in a low-power 1.2 V 65 nm TSMC technology. The 4.5 mm x 5.0 mm chip die was mounted in a QFN68 package; first test samples are available. The core requires a 1.2 V power supply, the pads 1.8 V. Figure 5 shows a picture of the die and its interconnections. The two parts, the analog core and the digital baseband, are clearly distinguishable. The chip is currently in the verification phase.
Figure 5. NAPA chip. Within the project, the development and testing of the NAPA design was carried out on basically two platforms. During the hardware development phase, the baseband core has been prototyped on a FPGA device and tested using a special file-player setup, as explained in the following section. Having taped out the chip and received the first samples from the foundry, a test board has been developed in order to verify NAPA chip functionality.
FPGA Test Setup. In the development phase, the NAPA baseband core has been implemented on a Xilinx Virtex6 FPGA device. A Xilinx ML605 development board has been used for the test setup. The main limitation of the testing in this phase was the lack of an analog RF front-end prototype. In order to make early testing of GNSS functionality possible, we adopted a file player developed by Fraunhofer IIS in a previous project. This file player uses a desktop PC to reproduce a digital signal data-stream stored in a binary file on the PC. The stream is sent through a dedicated interface to a commercial digital acquisition board. This board receives a clock synchronized with the baseband core’s clock in the FPGA and delivers the signals directly to the FPGA pins. The complete setup is depicted in Figure 6. The setup in use can be seen on the left part of the opening figure.
Figure 6. FPGA test setup. Test Board. In the verification phase, which is currently ongoing, the first unpackaged test chip dies have been glued directly to the test PCB and bonded on board without any housing. After receiving the packaged chips, the QFN68 could be regularly soldered on the PCB. A block diagram of the board is depicted in Figure 7. The board hosts the typical switch buttons and LEDs for quick control and status detection as well as some specific interfaces. The clock can be provided through a dedicated SMA clock connector as well as a discrete oscillator. Two sub-miniature push-on (SMP) connectors are also provided for separate the L1 and L5 antenna inputs. The two UART ports, the debugger UART, and the SPI master port are connected using a FTDI chip. This chip allows the simultaneous connection of these ports to a desktop PC’s USB port. A parallel connector is provided to interface external front-end ADC signals and clock. The GPIOs are accessible through the same connector. A dedicated socket is added for a mini-SD card.
Figure 7. Block diagram of NAPA test board. Preliminary Results
The chip on the test board was first tested using the same file player of the FPGA setup. This way, we could evaluate the correct functionality of the digital baseband core without the need to activate and configure the on-chip front-end. After the successful tests, we focused on the on-chip front-end configuration, and we used the antenna connectors to provide valid GNSS signals. We tested the chip using three different configurations: a GNSS signal simulator, a static roof antenna, and a small active patch antenna.
In the three configurations, we successfully acquired GPS L1 and Galileo E1 signals. We were also able to perform tracking on GPS L1 and L5I, as well as Galileo E1b and E5aI. Figure 8 shows the spectrum of a snapshot of L1 and L5 paths made using the on-chip dedicated snapshot hardware and sent through the UART port with a dedicated binary protocol for offline processing. For this special test, we used an arbitrary waveform generator to provide noiseless Galileo and GLONASS signals in the L1 and L5 frequency bands, supported by the NAPA chip. After performing a FFT of the two snapshots, we can clearly see these signals. In the L1 plot, the E1b signal is present in the negative frequency range with the two peaks typical of the BOC(1,1) modulation. The FDMA GLONASS G1 is in the positive frequency range with its trapezoidal characteristic. It is also possible to see a side lobe of the E1a BOCcos(15,2.5) in the proximity of the zero frequency. In the L5 plot, we can see the main peak of BPSK E5a signal on the right and its mirrored image on the left, due to the fact that L5 signal path is real.
Figure 8. Spectrum of L1 and L5 band showing a Galileo E1 and E5a signal. Acknowledgment
This project has been funded by the Bundesministerium für Bildung und Forschung (BMBF) (German Federal Ministry of Education and Research), which is gratefully acknowledged.
-
Assured PNT for Our Future: PTA
Actions Necessary to Reduce Vulnerability and Ensure Availability
By Brad Parkinson
(From the 25th Anniversary GNSS History Special Supplement)Introduction
Brad Parkinson About 40 years ago, we had a vision for positioning, navigation, and timing (PNT). That vision was more than successful, and became known as GPS. In some respects we have been almost too successful: PNT is frequently taken for granted. PNT, in the form of GPS, has become a powerful worldwide enabler for productivity and for safety. Estimated yearly value runs to many tens of billions of dollars.
For several years, I have been concerned about comments that denigrate GPS because the signal strength is relatively weak. The speakers have gone on to say it can be completely replaced with inertial or other techniques. Recently, comments by government officials further energized me to look at the full picture.
What can we do to reduce the vulnerability and ensure that the expectations of the users are going to be met? I summarize my solution as the PTA program and will elaborate in this article. At a top level, the term PTA means: Protect, Toughen, and Augment GPS to assure PNT. Note I say PNT, not GPS. The central issue is assuring access of PNT to the user, not the source of the information. I strongly believe that PTA is both achievable and absolutely necessary. Protecting PNT is particularly important to Europeans as they are just about to launch their fledgling Galileo system.
Speeches and travel only reach a limited number. When GPS World invited me to write a piece for the magazine’s 25th anniversary issue, it seemed an ideal opportunity to expand knowledge of the PTA program. The following is an edited form of a talk I have given a number of times, most recently at the European Navigation Conference in Rotterdam in April 2014.
GNSS initiatives and the GNSS community are growing rapidly, and certainly we are very enthusiastic about the progress of Galileo. But some places in the U.S. community are saying, “Well, this GPS band is underutilized; devoting all that bandwidth to a single system is not prudent.”
I beg to differ with that view. If you look at the separate signals in the L1 band around the world, by the year 2023 they will grow to be well more than 400 individual signals. Those signals service over 2 billion users, from emergency service providers to precision agriculture to crustal monitoring and many, many more. I have an entirely separate talk on “GPS for Humanity,” but that is not our subject today.
Calling the GPS frequency band “underutilized” simply points out ignorance, even among our supporters. For example, we say PNT to emphasize that GNSS provides four dimensions. Certainly, timing is the forgotten fourth dimension of GPS, and even our politician friends rarely understand the importance of this aspect. Yet we know that highly accurate timing, supplied by GPS, is absolutely critical for power distribution, for telecommunications, and for the financial sector.
It is instructive to summarize the penetration of the PNT “Stealth Utility” into the fabric of our society.
Market Size. Overall, GPS has more than 2 billion users worldwide. This represents a very diverse user group; we providers are continually seeing new and innovative ways to use GPS.
Figure 1, for which I am indebted to Frank van Diggelen, gives an estimate of the number of receivers currently fielded. Notice the number of military receivers: less than half a million. The gray bar depicts the industrial uses such as survey and machine control, which come in at about 4.5 million; these tend to be extremely high enhancers of industrial productivity.
Figure 1. GNSS market size, 2012. We have to change the chart scale to depict bigger market segments. For example, recreation, automotive, and computing are shown on the lower half of the chart. In fact, mobile phones will still not fit on the chart. Attesting to the size of the estimated mobile phone base: one company alone will produce more than 900 million GPS-equipped smartphones this year. The pie diagram shows the dominance of mobile devices, but much higher productivity gains come from high-precision devices whose impact is very disproportionate to numbers of receivers.
We asked some economists, just what is all this worth? They looked at a subset of all the industries and concluded that GPS has a positive net effect to the tune of at least $32 billion annually. They had an expanded study that suggested about $90 billion annually. So, for those who question the value of GPS, the answer is that the net yearly returns to our national investment are more than 1000 percent. (Note: National investment is about $3 billion annually.)
To ensure these enormous economic benefits of PNT, there are two fundamental needs, and we providers must assure that they are met. The first and most important need is availability.
Availability. When we say availability, it is defined in a certain way; it means that PNT is available at the application-specified accuracy. We usually measure that accuracy at the 90th percentile: only 10 percent of the time can that error be exceeded.
Integrity. The second user need is the required integrity. That means that when the user expects a specific accuracy, the system is not lying to him. Integrity assurance is very much a focus of both the International Civil Aviation Organization (ICAO) and, in the United States, the Federal Aviation Administration (FAA). In many cases they require that PNT errors not exceed specified bounds more than once in 10 billion measurements (1 x 10-7). This integrity level requires so many samples, it is virtually impossible to verify experimentally; we have not had that many airplane landings, but it can be calculated. The metric we use is how many minutes GPS is not available — unavailability — at the specified accuracy and integrity. That is more easily understood than availability that aproaches 99.9XXX percent. The usual goal is that unavailability be zero.
We have an independent assessment of how well we are doing: FAA’s Wide Area Augmentation System (WAAS). They put out a report card with a lot of numbers. GPS clearly deserves a grade of A+.
And it will get better. The U.S. government’s PNT Advisory Board, which I co-chair, recently advocated that the full navigation message be added at the new civil frequencies, the L2C and L5C signals. The Air Force has now complied, thanks to strong support from General Willie Shelton. This makes two more civil signals fully available. They currently expect 2.9 meter ranging accuracy, but by the end of the year the Air Force operators expect the same full accuracy as the rest of the signals, on the order of 0.5 meter of ranging error.
This is an outstanding picture.
So What’s the Problem? A statement made by a high-level U.S. government official in my presence exemplifies the problem: “GPS is much too vulnerable. We must replace it with new inertials and chip-scale atomic clocks.”
I found this statement appalling. Unfortunately, it was a meeting where you don’t normally speak up, and I didn’t. Nonetheless, to me, that was totally wrong.
GPS indeed has a very weak signal, and it depends on having clear line-of-sight to four satellites. But in my opinion, a much better statement is what I call the PTA solution. Our goal should be to:
- Protect the system and the signal.
- Toughen the receiver and the system.
- Augment GPS as needed to ensure users’ PNT requirements are met.
The focus is ensuring positioning, navigation, and timing (PNT), not merely ensuring GPS.
Fundamental Prerequisites for PNT
The first prerequisite for GPS-based PNT is a receivable, clear, and truthful (truthful implies full integrity) ranging signal. There are five main challenges to this.
Too-powerful authorized signalsnearby. This aspect snuck up on our community. The FCC authorizers were about to license a powerful signal in the frequency band adjacent to GPS, drowning out any hope of receiving the GPS signal. This can be called the authorized jammer. All PNT providers must be very vigilant about this; we have seen ignorant elements of the government poised to do great harm with well-intended but destructive actions, without knowledge of the unintended consequences.
Natural Interference. This interference, the cause of delays and attenuation, is reasonably well understood, and the subject of much research, dating back to when we first defined GPS. Random events such as solar flares can potentially cause great harm.
Inadvertent Natural or Manmade Jamming. A nearby device that creates spurious, destructive emissions can be a serious problem for GPS receivers. This class tends to be manageable by well-designed receivers.
Collateral Interference. An example is a person who wants to evade tracking but is inadvertently jamming nearby GNSS receivers in addition to his own local receiver.
Deliberate Jamming or Spoofing. This is perhaps the major concern for developers and users. I will discuss this further later.
There is a second major prerequisite: satellite geometry. The user who cannot see enough of the sky is called “sky-impaired.” There are two possible underlying problems:
- The satellite constellation has “brown-out” because of failures or inadequate numbers; or
- The user is operating in a mountainous or urban area with high, local shading angles.
Overcoming sky-impairment requires a denser constellation, or use of multiple GNSS.
Protect, Toughen, Augment
What can we — as developers, operators, and manufacturers — do to overcome the PNT availability challenges for our users? My solution is PTA. The good news is that quite a few of the actions I recommend are underway — in fact, many of GPS World’s readers are active participants.
I am going to examine these three PTA principles, expand on them a bit, and hopefully explain a few things that help focus on a broad solution.
Protect the System and the Signal
This can be organized into seven actions: three PreActions and four ReActions. PreActions are before there is serious interference, and ReActions obviously come after interference is occurring.
First, the PreActions.
Protect the Spectrum. The chart in Figure 2 represents the frequency plan for the L1 band, and displays some of the sources of the 400 signals I referenced earlier. The blue star, GPS L1 C/ A, is the only fully operational and reliable signal in the world right now. The red star is the U.S. GPS military signal. You can see it has important power lobes close to the band edge. The black star is M-code, the new military signal of the United States.
Figure 2. Frequency plan for the L1 band. The Galileo power curve, which is pale green, has very significant nodes close to the band edge. Of course, the Galileo PRS (the magenta star) is right on the band edge. The imperative for these wider bandwidths is that they produce sharper correlation edges and consequently produce greater measurement precision. This leads to greater accuracy, and greater usefulness and utility for many PNT users.
Reallocation of radio bands adjacent to GNSS poses a significant threat. The band edge of the proposed high-power communication signal (sometimes called broadband) appears as the black vertical line. It is obviously very close to the edges of many of the colored PNT signals. Tests conclusively demonstrated unacceptable levels of interference with L1 C/A.
Consider the proposed, high-powered terrestrial signal one quarter-mile from a GPS receiver. This produces a power ratio of 5 billion (broadband) to one (GPS). To visualize that power ratio, consider Niagara Falls, which produces about a billion watts. Compared to that, GPS power is a tablespoon of water dropped from five feet, once per second (about 0.2 watts). This is the power ratio that was almost authorized with 40,000 ground-based transmitters in the U.S. At a city block away, the effect is 10 times worse.
To quantify interference effects, some initial tests were run and measured broadband effects used for analysis. Cell-tower locations near Las Vegas, Nevada, approximated the broadband transmitter locations. The nearby airport, McCarran Field, has three RNAV (GPS) approaches. As expected, GPS users on the ground would be significantly jammed, but the effect on aircraft would be nine times worse than the impact on ground receivers. This is due to altitude (line of sight), geometry, and the sensitivity of aircraft receivers.
The 12 broadband transmitters around McCarran Field would jam all of the RNAV GPS approaches to all three runways. Signals of this type would effectively shut down or severely limit operations at the airport.
Signals in the GPS band will increase in the next decade as the newer GNSS become operational. The proposed, adjacent broadband is even more incompatible with these newer signals since they will be closer in frequency. Note that the whole approach was rejected, solely on the basis of L1/CA. It was not even tested against the other, more susceptible, modern signals. The worst would have been yet to come, had they been authorized to broadcast in the adjacent band.
Adjacent bands can continue to broadcast non-GNSS signals originating in space because the power levels will be comparable with the PNT spectrum. But we must be very vigilant to stop any high-power terrestrial signals from being allowed. They would become, effectively, authorized jammers. There should be no spectrum reallocation to ground transmitters until technology has been thoroughly demonstrated to solve any problems, (particularly for the high-precision users) and there is enough time to re-equip the users.
Europeans should have two other important frequency authorization concerns. First, there is a legal barrier within the United States to using Galileo signals. They have not been formally authorized. I think it is a bureaucratic glitch, but it is something we in the United States have to solve; we do want to use all GNSS signals. Stay tuned!
There is another concern. A group at the Electronic Communications Committee, European Commission, recommends allowing pseudolites in the L1 GNSS band. As an experienced user of pseudolites for aircraft landing and some other applications, I believe this is a very risky idea; pseudolites can be very useful, but frequencies should be found elsewhere to avoid unexpected interference.
Stiff Legal Penalties for Interference. The second PreAction is to enact stiff legal penalties for GPS jamming, both in terms of jail time and fines. The goal is to deter the ubiquitous $33 GPS jammer that one can buy on the Internet.
On the U.S. FCC website, the agency lists the penalties for having a GPS jammer. Forfeitures range up to $16,000, and they might even put you in jail. The Australians take a much stronger view: up to five years imprisonment or $850,000 in some cases. Some people are alarmed by these heavy penalties and call them brutal. However, they are not always imposed, and if jamming and spoofing is intentional, especially where the landing of airplanes is concerned and lives are at stake, I think a strong deterrent is warranted.
Stop Jammer Manufacturing, Sales. The third pre-action is to prevent proliferation by shutting down manufacturing and web sales of jammers. What is the status?
The FCC website states that manufacturers should comply with the law: stop marketing these devices in the United States and stop selling and shipping to addresses in the United States. The loophole is you apparently can manufacture these devices if you sell them outside the U.S. Now, I have a little difficulty with this. I have pointed this out to the DHS and others; hopefully, stronger action will be taken.
The FCC told me in an open meeting a few months ago that they were shutting down the websites where these devices are sold. But about three weeks ago, I went online and immediately found a website that sells nine different devices to jam GPS and cellphone devices. Indeed, there were jammers, all very affordable, for jamming just about everything. More recently, the FCC assessed a multi-million dollar penalty against such a jammer manufacturer. We will see if this actually happens. I hope they accelerate these efforts.
Now for the ReActions.
Detect Jamming. To stop jamming, the first step is to know when it is occurring. There are a variety of ways to do this. Some devices or concepts are already on the table: for example, a Chronos CTL3510 GPS Jammer Detector, an Exelis Signal Sentry Jammer Detector, and the J911 cell phone detection and reporting of jamming, an example from NavSys.
The idea behind the NavSys J911 is that all GPS-equipped smartphones have the capability to detect jamming. This does not pinpoint jammer location, but alerts authorities to the problem. Phone location can be reported to a central database for the next two actions.
Pinpoint Jammer Location. Techniques range from directional antennas to time-difference-of-arrival using Fast Fourier Transforms. The latter was demonstrated for the FAA at Stanford more than 10 years ago: location pinpointed within five meters. Cell towers could implement such techniques, since they have accurate time and could run correlations. There are already commercial GPS jamming locators: something called a JLOC (NaySys Jammer Locator). The British are using similar techniques for jammer detection on some of their freeways.
Eliminate Jammer. Having pinpointed the jammer, the next step is to physically eliminate it. What is the status? At Newark Airport there is an FAA, ground-based GPS augmentation system antenna right next to the turnpike. They are part of a blind landing system. In early 2010, there was an infamous jammer interfering with the FAA GPS receiver. It took three months to locate the offending truck driver and shut down the jammer. The good news is that, more recently, in the same general location, they located a similar moving jammer within 24 hours after the interference started. However, these are very special locations. Recent studies have suggested that interference sources are much more widespread. Note: Only certain enforcement personnel are authorized to seize the jammer and arrest its operator.
Prosecute. Having located the offender, the law should then be applied to prosecute. Leeway should be applied, commensurate with the circumstances. In this New Jersey case, the authorities say the perpetrator is liable for a forfeiture of $31,875.
Toughen Receivers
There are at least five well-known ways to toughen receivers, thereby increasing jam resistance:
- Increased satellite signal spreading (such as L1C, L5) allowing greater processing gain;
- Integration with inertial navigation components;
- Digital beam-steering or null-steering antennas;
- Increased satellite power such as L5 (a difficult and fairly expensive technique);
- Local antenna shading, for example, the top of an airplane, which is shaded from the jammer.
These improvements cascade and are cumulative, but a remaining issue is to make such techniques more affordable.
To illustrate these anti-jamming techniques, consider the effective area of a 1-kW jammer located on the Capitol building in Washington, D.C. A basic high-quality GPS receiver, within a line-of-sight range of 20 miles, will stop providing PNT. Simply using the newest L1C spread-spectrum GPS signal reduces the jamming area by about two thirds, allowing operation to about 10 miles from the Capitol. Adding inertial aiding allows PNT to within three miles, and adding digital beam-forming antennas and using aircraft natural shading brings the effective radius to about 0.1 mile, about the size of the capital building.
The point is toughening the PNT receiver with the technologies mentioned is an extremely effective strategy. It would require over 60,000 jammers to cover the same area as the original non-toughened GNSS receiver.
Some techniques are very affordable today, while others, such as digital beam-forming antennas, remain too expensive for the ordinary user. In addition, there is a potential U.S. problem of export restrictions. Unfortunately, many of these existing restrictions have simply incentivized non-U.S. development of equivalent capabilities.
Augment
The last element of the PTA construct is to augment or substitute PNT sources. We are all aware of the coming revolution in multiple PNT sources from new GNSS. An all-GNSS receiver diversifies the frequencies and the signals, thereby reducing vulnerability to interference. It also improves availability for the sky-impaired user because of densification of satellites sources. Using satellites from multiple constellations can significantly improve availability, provided integrity requirements are met.
With these additional GNSS constellations, there are three major levels of cooperation:
- Compatible: no mutal interference;
- Interoperable: working to allow common time and geodesy system;
- Interchangeable: using accurately calibrated biases and offset. Any four SVs will suffice.
The major issue again is probably integrity, because to ensure economic value, availability requires known integrity. As far as the U.S. FAA and ICAO are concerned, for precision aircraft operations the integrity value should be that the system be “out of spec” less than once in 1 billion times. To be productive they also would like zero minutes of unavailability. That may seem extreme, but commercial aviation and public safety demand it. Regarding integrity, some new GNSS are clearly making faster progress than others.
It is useful to further examine the densifying opportunity of additional GNSS. The chart in Figure 3 shows how densification can impact the user. The number of satellites (SVs) available in the sky (assumed optimal distribution) is shown. The colors refer to whether 0, 1, or 2 SVs are out of commission for maintenance or repositioning (typical maximum is 1 for GPS). The measure of effectiveness is minutes of outage per day. Consider a shading angle of 60 degrees, representing a user near a rugged mountain slope area or a city. With the nominal 24 SV GPS constellation (the GPS specification is 24 despite the U.S. having 31 active SVs), the outages, due to geometry alone, are six to ten hours. Improvement with additional satellites is dramatic and quite non-linear. With 33 satellites (about a 37% increase in density) outages are zero minutes per day to 33 minutes if one satellite is out for maintenance (reduction by a factor of over 10!). Of course, SVs could be from different GNSS constellations if they are truly interchangeable and have the required integrity. The clear message is that about 33 SVs are needed to cover reasonably high elevation angles.
Figure 3. How densification of additional GNSS can affect the user. Integrity Monitoring. Currently, the U.S. GPS control segment continuously monitors GPS satellites. If a fault is found, they set the satellite inoperative until the problem is resolved, which may take many minutes. This alarm time is not fast enough for precision aircraft landing and approach (the requirement is six seconds to alarm). For these rapid integrity alarms, the United States relies on the FAA’s WAAS, and Europe uses EGNOS to monitor the basic GPS L1 C/A signal. Soon, the EGNOS message will include Galileo integrity alerts. Unfortunately, the United States does not yet have a plan for reciprocal WAAS monitoring of Galileo signals. In fact, formal approval to even use these signals has not yet been granted by the U.S. FCC.
Self Integrity (RAIM). If an all-GNSS receiver has more than six satellites in view, the user can use the Receiver Autonomous Integrity Monitoring (RAIM) technique. This allows the user to cross-check each measurement against others to find erroneous satellites and guard against spoofing. Take the recent GLONASS situation. With a good RAIM PNT receiver, the user could quickly isolate the large errors from the combined set of GPS/GLONASS measurements. In fact, some deployed receivers did just that. If all GNSS are totally interchangeable, it will be enormously helpful to implement RAIM.
The recent, prolonged GLONASS outage saddened us all because it reduced the credibility of all GNSSs. We hope the Russians will be forthcoming in announcing what happened and the corrections that are being made; hopefully, it won’t happen again.
Fortunately, there is a third independent, real-time tracking network of 200+ sites, known as the Global Differential System (GDGPS). Although NASA administers GDGPS, local-country scientists maintain and operate individual sites in near real time. GPS is monitored down to centimeter precision.
A central issue for GDGPS is whether the integrity monitor capability itself has integrity. Because of redundancy and independence, a form of inverse RAIM, hereby named System Autonomous Integrity Monitoring (SAIM), can be used. Figure 4 depicts the number of independent looks or ranging measurements to a single satellite over various points on the Earth. You can see in the dark areas the value is 60, and even in the relatively unmonitored areas around South America, the redundancy is 20. At a typical spot, perhaps off Spain, it depicts 50-fold redundancy. By cross-checking the dozens of GDGPS measurements for each satellite, a strong integrity cross-check can be created. The GDGPS plan is to also monitor Galileo as it becomes operational. Thus, GDGPS has excellent prospects to provide real-time integrity assessments for all users and all operational constellations. We need plans to connect all users to these potential integrity alarms.
Figure 4. The number of independent looks or ranging measurements to a single satellite over various points on the Earth. There are three classes of ground-based augmentations:
Pseudolites. Ground augmentations could also include pseudolites broadcasting GPS-like signals for additional ranging. While somewhat helpful, this technique cannot cover large areas and can act as a strong interference source if the signal is in any GNSS frequency band. For this reason, in my opinion, pseudolites should never be authorized in GNSS frequencies.
Distance-Measuring Equipment. Modernized DME, planned as a GPS supplement by the U.S. FAA, is very valuable for the airborne users. Most ground users derive no benefit from DME because they do not have line of sight to the widely scattered transmitters. Ohio University’s Frank van Gras is working for the FAA on a DME plan should GPS not be available. It involves moving from the so-called legacy DME to the enhanced DME to ensure continuous aviation operations.
eLoran. eLoran, covering expandable local regions, uses a powerful signal at an entirely different frequency. It is two-dimensional, but in calibrated areas differential (eDLoran) is perhaps as accurate as 10 meters for harbor areas and similar purposes.
I chaired a study of eLoran for the FAA in 2006. Initially skeptical, the study members finally concluded (unanimously) that eLoran:
- meets the needs of all identified critical applications: 10–20 meter navigation accuracy for harbor entrance; 0.3 mile required navigation performance (RNP 0.3); stratum 1 frequency precision and 50-ns time accuracy.
- is a modern system: new infrastructure, solid state transmitters, state-of-the-art time and frequency equipment, uninterruptible power supplies; new operating concepts, time of transmission, all-in-view signals, message channel with differential corrections, integrity; new digital user equipment, processes eLoran and GPS signals interchangeably, compact H-field antennas eliminate p-static.
- is affordable: Less than $143M to fully complete eLoran, avoid costs of decommissioning existing Loran-C infrastructure; operations and maintenance currently $37M/year, reduced with eLoran-enabled automation.
And our group concluded it was the most prudent and cost-effective general augmentation or backup to GPS.
The National PNT Advisory Board also unanimously recommended that we deploy eLoran. The departments of Transportation and Homeland Security supported it; then, after a change of administrations, in a budget crunch, it was defunded, and the dismantling of existing Loran C stations began. Congress now may be taking action, and the recent GLONASS outages should give an impetus to that.
Who Will Implement PTA?
To my knowledge, many elements are currently being pursued, some by GPS World readers. But I can identify no entity that has the authority, the knowledge, the breadth, and the resources to create a single, well-focused program. This reminds me of a fable from Aesop regarding ants. When no leadership emerges, the ants have to band together to solve the problem. Yes, I am suggesting that we are the ants and we all must contribute to the solution, as well as seeking governmental agencies to step up to the responsibility.
In that regard I have a “to do” list. We must:
- Protect PNT.
- Vigorously defend the spectrum.
- Work with lawmakers to increase legal penalties for PNT interference.
- Work with manufacturers and law enforcement to improve timeliness and accuracy of interference identification (crowd-sourcing, every cell phone a detector).
- Field jammer location equipment.
- Toughen PNT.
- Develop industry (ICAO/RTCA/RTCM) standards for deep inertial integration and directional antennas.
- Develop vector receivers (all GNSS).
- Continue to implement ARAIM and inertial for integrity (+WAAS/EGNOS).
- Encourage users to move to rugged receivers.
- Augment PNT.
- Expand integrity notifications to include GDGPS.
- Develop RTCA standards for seamless DME and GPS/GNSS.
- Implement eLoran and develop RTCM standards for seamless use.
- Develop an international process for integrity certification of all GNSS (GLONASS, Galileo, and BeiDou).
In conclusion, the rumors of the death of GPS, in my opinion, are greatly exaggerated. Let’s not throw out the baby with the bath water. Instead let’s accelerate and expand PTA to Protect our band, and Toughen our receivers, and Augment GPS to ensure that PNT is available for all users now and in the future.
In the words of American poet Robert Frost,
The woods are lovely, dark and deep,
But we have promises to keep,
And miles to go before we sleep,
And miles to go before we sleep.
Thank you.
BRAD PARKINSON has been the Edward C. Wells Endowed Chair (emeritus) at Stanford University, where he is a recalled professor of aeronautics and astronautics.
He co-founded the well-known Stanford GPS Laboratory and led the development of many innovative uses of GPS, including blind aircraft landing, precision farm tractors, and the prototype of the FAA’s WAAS. He also directed development and was a co-PI for the successful test of Einstein known as Gravity Probe-B sponsored by NASA. He worked in various executive or board capacities at Trimble Navigation, Intermetrics, Rockwell International, and The Aerospace Corporation.
As an Air Force colonel, from 1972 to 1978, he was the chief architect and first director of the NAVSTAR GPS development program, retiring from the service after orbiting the first GPS satellites and proving GPS capabilities. He is a fellow of five professional societies and recipient of dozens of awards, including:sharing the 2003 Draper Prize with Ivan A. Getting for leading the development of the Global Positioning System.
-
Canadian Science Minister Announces Grant to Langley’s UNB Lab
Professor Langley (fourth from left) discusses the UNB geodesy program with Canadian Science Minister Ed Holder (third from left.) The Canadian Minister of State for science and technology, Ed Holder, visited the University of New Brunswick on July 28 to announce the awarding by the Natural Sciences and Engineering Council of $2.4 million to 28 UNB researchers.
He was joined by Keith Ashfield, member of Parliament for Fredericton, where UNB is based, and Craig Leonard, the New Brunswick Minister of Energy and Mines.
A highlight of the visit was a tour of the Department of Geodesy and Geomatics Engineering to see the work of Prof. Richard Langley and his students. Langley received $170,000 in Natural Sciences and Engineering Research Council (NSERC) funding in the competition. The funding will support the work of his group in improving augmented multi-constellation satellite-based precise positioning in a wide range of environments. Langley is GPS World’s Innovation editor, a post he has held since the magazine’s inception.
Canadian Science Minister Ed Holder looks at GPS World magazine, which has featured Innovation columns edited by Richard Langley for more than two decades. Although GPS was the first widely available satellite navigation system, it has now been joined by the Russian GLONASS system, and will soon be accompanied by the European Galileo system, the Chinese BeiDou system, and the Japanese QZSS — all of which have test satellites now in orbit. There are interesting problems to be solved in gaining maximum benefits from this plethora of GNSS for precise positioning and navigation, and Langley and his team will address a number of them.
The team is also involved in the analysis of data from the GPS-based instrument on the Canadian CASSIOPE scientific satellite launched at the end of September 2013. The instrument, which precisely determines the position of the satellite and provides information on the state of the Earth’s ionosphere, was designed at UNB.
The NSERC Discovery Grants Program is an integral component of the government’s efforts to develop, attract and retain the world’s most talented researchers at Canadian universities. The program funds discovery research in a multitude of scientific and engineering disciplines, which builds a broad base of research capacity across the country.
Professor Langley gave the following presentation at the NSERC Discovery Grants Scholarships Rollout Announcement at UNB on July 28:
-
M3 Systems Announces Simulator Based on Vector Signal Transceiver
M3 Systems is now offering the StellaNGC multi-constellation GNSS simulator based on the National Instruments (NI) vector signal transceiver.
The simulator is designed for the testing of satellite navigation receivers for GPS, GLONASS, Galileo, and EGNOS/WAAS. It is designed to improve performance, scalability, and versatility, and reduce cost over existing navigation test solutions.
GNSS is the predominant technology today for navigation and outdoor positioning. However, given the weakness of GNSS signals, receiver performance is often affected by interference from the local environment and propagation channel conditions. Understanding the effects of this interference is of particular importance not only for existing GNSS signals but also for future signals that will appear with the deployment of new constellations such as Galileo.
To properly characterize receiver performance under varying conditions, the StellaGNC multi-constellation GNSS simulator provides signal generation, signal recording and replay, interference generation, signal and data processing, and complete analysis tools. The StellaNGC simulator is based on the NI vector signal transceiver in PXI for improved performance and full simulation capabilities. For record and playback only, a scaled-down version is also available based on the NI USRP (Universal Software Radio Peripheral). Both options were developed with NI LabVIEW and benefit from the performance and flexibility of the NI RF platform.
The simulator provides a scalable solution that allows easy signal additions through software upgrades, multi-frequency, processing extensions with the addition of FPGAs with NI FlexRIO, and an HDD extension for storage increase. Because the simulator is based on the open PXI standard, the hardware investment can also be extended to other applications, such as simulation, record and playback, or payload simulation.
-
How to Survive a Total Constellation Outage
Yesterday we posted news of an 11-hour downtime for the full GLONASS constellation, due to an upload of bad ephemerides. Coincidentally, during that 11-hour period, the mass-market chip company Broadcom was conducting multi-constellation receiver tests in Asia. Frank van Diggelen, Broadcom’s chief GNSS scientist and vice president says, “We have definitive data to show how a multi-constellation receiver survives such an outage.”
Here are the pictures, and the story they tell.
Test data coincident with the GLONASS ephemeris disruption of April 1 and 2 showing conclusively how a GPS/GLONASS/QZSS/BEIDOU receiver survives the complete disruption of one of the constellations.
On April 2 at 1:00 a.m. Moscow time, bad ephemeris was uploaded to all satellites (see chart at the bottom of this story).
There are two receivers shown here, from two different manufacturers, both in smartphones. The yellow dots are for a GPS/GLONASS receiver; the blue dots are from the Broadcom 47531 receiver which tracks GPS/GLONASS/QZSS/BeiDou signals simultaneously. The 47531 receiver includes logic to use redundant measurements to check the validity of all measurements. It successfully identified and removed the bad GLONASS ephemeris 100 percent of the time, as can be seen by the continuity and accuracy of the positions.
Here is the satellite outage chart from yesterday’s story. All GLONASS satellites were restored to healthy state after the 11-hour interruption.
Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning. -
Innovation: Ground-Based Augmentation
Combining Galileo with GPS and GLONASS
By Mirko Stanisak, Mark Bitter, and Thomas Feuerle
INNOVATION INSIGHTS by Richard Langley GPS = SAFER FLIGHT. While reviewing material for an article celebrating the 25th anniversary of the launch in February 1989 of the first Block II or operational GPS satellite, I was yet again annoyed by many articles on the Web stating that GPS only became available for civil use after the launch of this satellite. Some sources get closer to the truth when they say that GPS was opened for civil use in 1983, following the shoot-down of the Korean Airlines Flight 007. In fact, GPS was designed to serve the needs of both the military and civil communities from the outset. A government memo from April 1973 clearly states: “Civil user needs should be considered in the design of the spaceborne equipment.”
One of the first demonstrations of the use of GPS for aircraft navigation occurred in July 1983, when a Sabreliner business jet was flown in stages from Cedar Rapids, Iowa, to the Paris Air Show, flying only when a sufficient number of the experimental or Block I satellites were in view. The first standalone GPS receivers certified for aviation use (with Receiver Autonomous Integrity Monitoring or RAIM) became available by the mid-1990s. But already the Federal Aviation Administration had been looking into the development of a system to provide higher accuracies and better integrity than that afforded by standalone receivers. In 1994, the FAA announced the development of the Wide Area Augmentation System, its brand of a system generically known as satellite-based augmentation. Geostationary satellites transmit corrections and integrity information to GPS receivers, permitting GPS use for en route navigation all the way down to traditional Category I approach and landing. CAT I approaches can be flown down to a decision height of 61 meters (200 feet). WAAS was declared operational on July 10, 2003, but enhancements to the system continue. Japan, Europe, and India also have operational SBAS based on GPS.
Ground-based GPS augmentation was first developed for maritime applications with the U.S. Coast Guard’s low-frequency system coming on line in the mid-1990s. Also in the mid-1990s, the FAA began the development of the Local Area Augmentation System, generically known as a ground-based augmentation system (GBAS), to provide aircraft with approach and landing capabilities from CAT I down through CAT II (30-meter or 100-foot decision height) and CAT III (no decision height but certain visual range minima) using a VHF datalink. Initial CAT I systems are being operated at Bremen, Germany, and at Newark Liberty International Airport and Houston George Bush Intercontinental Airport.
While a GPS-based GBAS will definitely offer improved navigation services for aircraft, might these services be even better if the systems were to use satellites from other constellations besides GPS? In this month’s column, we look at a straw-man concept for modifying the GBAS protocols to accommodate multiple constellations and the results of preliminary tests using GPS, GLONASS, and Galileo simultaneously.
“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. Write to him at lang @ unb.ca.
Ever since the declaration of Full Operational Capability (FOC) of the U.S. Global Positioning System in April 1995, GPS has dominated satellite navigation, especially in aviation applications. By contrast, the Russian GLONASS system cannot be used in western aviation because no approval guidelines exist for GLONASS equipment. Thus GPS has been the de-facto standard in aviation for years.
However, within the last few years, major changes have evolved in the field of GNSS, providing a wide variety of useable satellite navigation systems. The European Union launched its Galileo project, which will provide global multi-frequency services in the near future. China is upgrading its BeiDou system (formerly called Compass) to provide global coverage with more medium-Earth-orbit (MEO) satellites. The operators of GPS and GLONASS have started modernization programs that will enable multi-frequency operations in the future, too. Therefore, a large number of usable satellites and signals from multiple systems will soon be available.
In aviation, almost all phases of flight can be assisted by satellite navigation systems nowadays. The most challenging phase of flight with respect to accuracy, continuity, availability, and integrity is the approach and landing phase. The Ground Based Augmentation System (see FIGURE 1; courtesy of the European Organization for Civil Aviation Equipment) allows precision approaches to be performed using satellite navigation. It uses a VHF data link to broadcast differential GNSS corrections, integrity information, and approach definitions to approaching aircraft. These aircraft combine the differential corrections with their own GNSS measurements, calculate a GBAS-corrected position solution, and determine path deviations based on the selected approach.
FIGURE 1. GBAS principle. (Source: EUROCAE WG 28, ED-114) From a technical perspective, GBAS can use either GPS or GLONASS for differential corrections. For this, the International Civil Aviation Organization (ICAO) Standards and Recommended Practices (SARPs) include GPS and GLONASS side by side. On the other hand, some standardization documents (for example, those from RTCA) are limited to GPS only, effectively excluding GLONASS from being used in the western world. Nevertheless, Russian GBAS systems provide differential corrections for GPS and GLONASS, and are expected to be certified in Russia in the near future. Additional GNSS such as Galileo or BeiDou are not yet included within these documents, as these systems are not approved for aviation use themselves. This article will focus on how a multi-constellation GBAS with GPS, GLONASS, and Galileo could work.
GBAS installations can provide multiple services for different kinds of operation, based on GNSS L1 corrections only. On the one hand, the differentially corrected positioning service (DCPS) is intended to be a generic service for high accuracy positioning. On the other hand, two different GBAS approach services have been defined. GBAS Approach Service Type C (GAST-C) allows Category I (CAT I) procedures and is already in operation. GAST-D is still under development and will enable precision approaches and landings down to CAT II/III minima once certified. To mitigate all possible hazards, GAST-D will require some additional broadcast messages.
VHF Data Broadcast
The VHF Data Broadcast (VDB) is used to communicate binary GBAS messages to approaching aircraft. It operates in the VHF band (108.025 – 117.975 MHz) and uses time-division multiple access (TDMA) to allow the operation of multiple GBAS ground stations on a single frequency. As shown in FIGURE 2, VDB uses UTC time to have a common time frame. Two frames are transmitted each second, lasting 0.5 seconds each. Within each frame, eight slots with durations of 62.5 milliseconds can be used for transmission. Binary application data is encoded using a differentially encoded eight-phase-shift-keying modulation (D8PSK) and a symbol rate of 10,500 symbols per second. With three bits transmitted per symbol, up to 31,500 bits per second can be transmitted. Each slot can contain up to 222 bytes of binary application data. Usually, only a subset of slots is allocated to a particular ground facility. This way, multiple GBAS ground facilities can share a common VDB frequency.
FIGURE 2. VDB timing structure. (Source: RTCA SC-159, DO-246D) Within each slot, multiple VDB messages can be transmitted as application data. The coding of information in VDB messages is defined in the RTCA’s GNSS-Based Precision Approach Local Area Augmentation System (LAAS) Signal-in-Space Interface Control Document (ICD) and depends on the VDB message type. (LAAS is the U.S. GBAS.) Currently, message types (MT) 1, 2, 3, 4 and 11 are defined. Figure 2 is derived from this document.
Message Type 1 – MT1. Within VDB Message Type 1, differential corrections based on 100-second smoothing are transmitted. These corrections are required by all GBAS approach services (GAST-C and GAST-D). Aside from the differential corrections, additional information for the first broadcast satellite is transmitted. This includes an ephemeris cyclic redundancy check (CRC), mitigating the effects of wrongly received GNSS navigation data, and the Issue of Data (IOD) flag, indicating the time of applicability for the ephemeris data to be used. To transmit this information for all satellites, the satellite for which differential corrections are transmitted first has to be alternated continuously.
Each MT1 message can contain up to 18 pseudorange- and range-rate corrections for individual satellites. Nevertheless, it is possible to link two consecutive MT1 messages using the Additional Message Flag (AMF). The value of this parameter indicates whether this is a single message (0), or the first (1) or second (3) part of a linked MT1 message. Up to 36 differential corrections can be transmitted using two consecutive VDB time slots with 18 corrections each.
All MT1 measurement blocks must be transmitted at least once per frame. The maximum transmission rate is once per slot for all measurement blocks.
Message Type 2 – MT2. VDB Message Type 2 contains station and integrity parameters such as the coordinates of the reference point to which all differential corrections refer. MT2 messages can include (next to a “core” MT2 message) multiple Additional Data Blocks (ADBs) to transmit information required for different GBAS services. At the moment, the Additional Data Blocks 1, 3, and 4 are defined.
ADB1 contains the maximum distance to the reference point at which the corrections may be used (Dmax) as well as parameters to calculate the remaining risk of incorrect GNSS ephemeris data (Kmd,e). Within ADB3, additional information required for GAST-D is transmitted. ADB4 implements the VDB authentication feature. If this ADB is broadcast by a ground facility, MT2 messages must be transmitted first and contain additional indications about which VDB slots are allocated to the ground facility.
MT2 messages must be transmitted at least each 20th frame, but may be repeated up to once per frame.
Message Type 3 – MT3. The VDB Message Type 3 is a fill message, which is only used in conjunction with the GBAS authentication feature (MT2, ADB4). Among other things, this feature requires a minimum slot occupancy of at least 95 percent. Thus, MT3 messages are broadcast only by ground facilities that support the authentication feature and are completely ignored by airborne GBAS receivers.
Message Type 4 – MT4. With VDB Message Type 4, approach information can be broadcast to approaching aircraft. A pilot can select a specific approach by simply tuning to a given channel number.
Currently, GBAS only uses Instrument Landing System look-alike straight-in approaches called Final Approach Segments (FAS). Each FAS represents one approach. This way, a single GBAS ground facility can provide multiple approaches for all runways of an airport. All approaches must be broadcast at least once per 20 consecutive frames.
Message Type 11 – MT11. The VDB Message Type 11 provides differential corrections in a way very similar to MT1 messages. The main difference is that MT11 corrections are based on 30-second smoothing, which is required for GAST-D service. As for MT1, all MT11 measurement blocks must be transmitted at least once per frame.
Enhancements for GBAS with Galileo
At the moment, the GBAS standardization documents include information on GPS, GLONASS, and SBAS ranging sources. No information on Galileo or other constellations has been added yet. Thus, to include Galileo for GBAS, some Galileo-specific experimental additions to the standards are necessary. These proposed modifications have been made in such a way as to keep as close to the other system standards as possible to preserve consistency. This way, hardly any new functionality is added, but additional satellites can be used. The additional Galileo signals (E5a, E5b, E6) are not used at the moment; however, they might be highly beneficial for multi-frequency applications in the future.
All modifications presented here are purely experimental and will most probably not be exactly the same as those in future standards documents. Nevertheless, they provide a way to test Galileo together with GPS and GLONASS for GBAS on an experimental basis.
Ranging Source ID. The Ranging Source ID uniquely addresses a single satellite. It is used in MT1 and MT11 to transmit the differential corrections and other information for each ranging source. In ICAO Annex 10, Standards and Recommended Practices, the Ranging Source ID is defined for GPS, GLONASS, and SBAS only. To provide Galileo corrections as well, an experimental mapping for Galileo satellites was added; see TABLE 1.
TABLE 1. GBAS Ranging Source IDs. In this way, up to 36 Galileo satellites can be addressed.
Navigation Data. Galileo provides two different sets of navigation data. The I/NAV data corresponds to the Safety-of-Life (SoL) service and is broadcast on E1 and E5b. The F/NAV data corresponds to the Open Service (OS) and is broadcast on E5a. In order to remain as close as possible to the legacy navigation systems, we selected the I/NAV navigation data for use, as it is broadcast on the E1 frequency and can thus be received with an L1-only GNSS receiver.
The navigation data is primarily used in VDB MT1. For the first transmitted correction in this message, the ephemeris set that shall be used in the aircraft is identified via the Issue of Data (IOD) field. To be consistent with the GPS ephemeris, we used Galileo’s IODnav parameter.
Together with the identification of the navigation data, a CRC parameter is transmitted in MT1 for the first satellite within the differential corrections. This parameter ensures that the receiver as well as the ground facility use identical navigation data for all calculations. The CRC algorithm uses the raw navigation data to generate a distinct CRC value.
For GPS and GLONASS, two ephemeris masks are defined. These masks ensure that only information relevant for GBAS processing are covered by the CRC. For Galileo, a similar mask had to be designed.
Additional Data Blocks in MT2. Within VDB MT2, station parameters and integrity information are transmitted. Some parameters for the over-bounding of possible ephemeris errors are specific to each satellite navigation system.
To extend MT2 to Galileo, parameters for the DCPS, GAST-C, and GAST-D must be added for Galileo. For downward compatibility, these parameters cannot be included in the existing Additional Data Blocks beside the existing parameters. Thus, a new Additional Data Block (ADB5) was defined on an experimental basis. This Additional Data Block is dedicated to Galileo and is structured as shown in TABLE 2. The coding of all values corresponds to the coding of the parameters for the existing systems.
TABLE 2. Additional Data Block 5 in Message Type 2 for Galileo parameters. Optimized VDB Transmission Scheme
Having available a large number of ranging sources for differential corrections, the VHF VDB is a bottleneck for the transmission of this data. To demonstrate this, we first consider the number of visible satellites that there will be in the future. This leads to construction rules for an optimal VDB transmission scheme, which allows transmitting the maximum number of differential corrections.
Number of Satellites Available. To demonstrate the number of differential corrections enabled by the different systems in the future, we computed the number of visible satellites over a day for a stationary GNSS receiver in Braunschweig, Germany. Even though only four Galileo satellites were in orbit at that time, up to 26 different satellites (GPS, GLONASS, and Galileo) were in view simultaneously. Keeping in mind the preliminary Galileo constellation, it is obvious that more than 30 satellites will be available simultaneously in the future — considering only GPS, GLONASS, and Galileo. Adding BeiDou satellites for GBAS would further boost these numbers.
The broadcast of such a large number of differential corrections is limited by the capacity of the VDB and thus by the number of slots assigned to a GBAS ground facility. The number of assigned slots for a facility should be limited as far as possible to be able to use the same frequency for other GBAS ground facilities. Thus, the available capacity must be used as effectively as possible.
Number of Bytes Required. Each VDB message is framed by a message block header (6 bytes) and the message block CRC (4 bytes).
The length of each message depends on the message type and the amount of information to be transmitted. The resulting length for a message of each type is given in TABLE 3.
TABLE 3. Size of different VDB message types (including message block header and CRC). Variable length message types are dependent on the number of corrections, N. VDB Constraints. A GBAS ground facility must transmit the VDB data following some constraints. These are:
- MT2 messages (including all Additional Data Blocks required) must be transmitted at least each 20th frame (that is, every 10 seconds).
- If authentication is required, each MT2 message must be transmitted in the first slot assigned to the GBAS ground facility.
- All differential corrections (both MT1 and MT11) must be transmitted at least once in each frame. However, it is possible to split the differential corrections into two adjacent slots using the Additional Message Flags in MT1 and MT11 messages.
- Within each MT1 message, the ephemeris decorrelation parameter (Peph), the Issue of Data (IOD), and the ephemeris CRC is transmitted for the first satellite in the message. Thus, the first satellite must be alternated in order to broadcast the ephemeris information for all satellites.
- Approach definitions are transmitted in MT4 messages. All MT4 messages must be transmitted within at least each 20th slot.
Based on these constraints, a VDB encoding scheme has been developed, which allows us to fulfill all the requirements listed above while optimizing the number of differential corrections that can be transmitted. Even though it is optimized for GAST-D-like services (including authentication parameters, MT11 messages, and experimental Galileo extensions), it can be used for legacy GAST-C systems, too.
Rules for Optimal VDB Transmission. To fulfill the requirement for the MT2 message to be transmitted first, a complete MT2 message must be transmitted each 20th frame at the beginning of the first slot assigned. If no MT2 message has to be transmitted, an MT4 message is transmitted instead. Thus, all messages are arranged in proper order by three simple rules:
- MT2 (each 20th frame) or MT4 (otherwise)
- MT11 (all corrections; can be split into two messages)
- MT1 (all corrections; can be split into two messages).
Additionally, two more rules must be fulfilled. On the one hand, if supporting the authentication feature, each slot in which the ground facility may transmit VDB data must be filled to at least 95 percent. For this, MT3 null messages may be used to ensure that each slot is filled sufficiently. On the other hand, an additional rule for MT1 messages is necessary if more than three slots are assigned to the GBAS ground facility. In this case, to maximize the number of differential corrections the MT1 messages may be transmitted in the last two assigned slots only. This rule is necessary because the Additional Message Flag is limited to two slots for differential corrections.
Using this transmission scheme, the number of differential corrections is maximized while fulfilling the minimum requirements on the VDB data. Even in case of the maximum number of differential corrections, MT4 approach definitions can still be broadcast. However, in this case, the number of transmittable FAS segments is limited to 19. If more approaches (or different approach types such as Terminal Area Paths (TAPs)) have to be transmitted, the VDB generation scheme must be adapted.
Number of Transmittable Corrections. Using the optimized transmission scheme explained earlier, the number of transmittable corrections can be calculated easily for different numbers of assigned slots for GAST-C as well as for GAST-D services (see TABLE 4).
TABLE 4. Number of differential corrections that can be broadcast. The exact distribution of VDB messages for the maximum number of differential corrections (18) is shown in FIGURE 3 for an MT1/MT11 configuration and two assigned slots.
FIGURE 3. VDB messages for two slots and 18 satellites (MT1 and MT11). Experimental Realization of Multi-Constellation GBAS
The experimental GBAS multi-constellation extensions described earlier have been implemented in software for further testing. As these enhancements are purely experimental and might change in the future, we have ensured that these definitions can be changed easily.
Navigation Software. The Institute of Flight Guidance at Technische Universität Braunschweig has been developing an experimental navigation framework for many years. This software, called TriPos, can handle and combine different navigation technologies. TriPos can be used for simulations, post-processing of recorded data, and even for live (online) processing. It is written in C++ and supports various platforms.
The navigation framework can be extended easily. Originally, only GPS was supported within the software, but support for GLONASS and Galileo as well as augmentation systems like SBAS and GBAS were added over the past few years. Additionally, the software handles GNSS data of multiple frequencies internally and can thus be used for multi-constellation and multi-frequency applications. TriPos includes decoders for the binary protocols of most GNSS receivers currently available.
For GBAS research, two components can be simulated using the software. On the one hand, the Ground Facility simulation calculates the differential corrections and provides simulated VDB data. On the other hand, the GBAS receiver simulation emulates the behavior of an airborne GBAS receiver and uses VDB data and GNSS measurements to calculate a GBAS solution. Both simulations can use either recorded data in post-processing or live data for online-processing. This allows complete simulation of GBAS.
Multi-Constellation GBAS Ground Facility Simulation. The GBAS ground facility simulation uses raw binary data from multiple stationary GNSS receivers to calculate binary VDB data. The simulation can be freely configured to process either live or pre-recorded GNSS data. Even though it features all algorithms required by the standards, it does not contain additional monitor algorithms at the moment.
Nevertheless, it can provide a valid VDB signal-in-space (SIS), which can be used by GBAS receivers and simulation tools (such as Eurocontrol’s PEGASUS tool). The ground facility simulation supports legacy GBAS CAT-I (GAST-C) as well as GAST-D (including all additional VDB information required) using GPS and GLONASS. Support for Galileo has been added according to the experimental definitions described earlier. In addition to FAS data blocks, the ground facility simulation is also capable of providing curved approaches using TAP data blocks.
Multi-Constellation Airborne GBAS Receiver Simulation. The GBAS receiver simulation has been used for various GBAS-related projects. It supports GAST-C as well as GAST-D and can be configured flexibly to use GPS, GLONASS, and/or Galileo (using the experimental enhancements as described earlier). For GAST-D, all airborne monitoring algorithms required are present. Thus, the aircraft-specific parameters (for example for the airborne geometry screening) can be configured together with the other parameters.
Flight Trials
The practicability of the multi-constellation GBAS approach has been tested in flight trials. To ensure that all four Galileo satellites were in view and capable of providing valid data during our trials, an orbit prediction tool and the Notice Advisory to Galileo Users (NAGU) service of the European GNSS Service Center (GSC) were used prior to the flight.
The data processing configuration is shown in FIGURE 4 and includes the GBAS simulation components explained earlier. All processing is done in real time while recording all data for later post processing.
FIGURE 4. Schematic data processing for the flight experiments (ground components in orange, airborne components in blue). Ground Processing. On the ground, two Septentrio AsteRx3 GNSS receivers connected to two roof-top antennas were used. The GNSS receivers were connected to the GBAS ground facility simulation via a network and provided binary GPS, GLONASS, and Galileo raw measurements with an update rate of 2 Hz as well as navigation data. Using this data, the ground facility simulation generated binary VDB data. The GBAS ground facility simulation was configured to generate multi-constellation GAST-D VDB data for a three-slot configuration. All required messages (MT1, MT2 including all required ADBs, MT3, MT4 and MT11) were generated and sent to the telemetry facility via the network.
Telemetry. Official VHF data broadcasts operate in a frequency band between 108 and 118 MHz, which is reserved for authorized aviation applications. However, for our experimental system, an alternative data link was used. The Institute of Flight Guidance operates a full-duplex telemetry system to share data between ground and aircraft. Even though the operating frequencies are different, the telemetry system allows the generated binary VDB data to be transmitted to research aircraft. The airborne telemetry receiver outputs data as if it were a VDB receiver to allow us to switch between a real VDB receiver and the telemetry receiver easily.
Research Aircraft. The Institute of Flight Guidance operates the research aircraft of the Technische Universität Braunschweig. The Dornier Do 128-6 with the call sign D-IBUF (see FIGURE 5) is a twin-engine turboprop aircraft without a pressurized cabin and has been used multiple times for GBAS-related research over the years.
FIGURE 5. Research aircraft D-IBUF (Dornier Do 128-6). The research aircraft allows us to flexibly integrate experimental equipment for specific flight trials. For the multi-constellation GBAS flights, a JAVAD Delta GNSS receiver (capable of multiple constellations and frequencies), a telemetry receiver, and an experimental cockpit display were installed temporarily.
Airborne Processing. The online GBAS receiver simulator uses GNSS data from the JAVAD Delta GNSS receiver together with the VDB data received via telemetry. The receiver was configured to output raw GPS, GLONASS, and Galileo measurements with an update rate of 10 Hz. The simulator was configured to use this data to calculate a multi-constellation GAST-D solution. Based on the selected approach definition, the resulting information (deviations, distance to threshold, and so on) was displayed in the cockpit using an experimental cockpit display.
Results. The flight test was conducted in the evening of November 6, 2013 (16:52 – 17:58 UTC), at Research Airport Braunschweig (EDVE). We performed five approaches with a 10 nautical mile final segment. The flight path as calculated by the GBAS receiver subsystem is shown in FIGURE 6.
FIGURE 6. Flight trial trajectory. (Map data © OpenStreetMap contributors) FIGURE 7 shows the number of satellites used for the GBAS receiver simulation, and distinguishes between the different satellite navigation systems used. Up to 22 satellites have been used simultaneously for GBAS processing, including up to 10 GPS satellites, eight GLONASS satellites, and four Galileo satellites.
FIGURE 7. Number of satellites used by the multi-constellation GBAS receiver simulation. Even though no certified GBAS equipment was used for the flight trials, FIGURE 8 shows the resulting vertical and lateral protection levels (VPL and LPL) of the online multi-constellation GBAS receiver simulation. Both values fluctuate due to the differences between 100- and 30-second smoothing position solutions, which have to be added to the protection levels for GAST-D. Nevertheless, both sets of values remain clearly below the corresponding Alert Limits (FAS Lateral Alarm Limit (FASLAL): 40 meters, FAS Vertical Alarm Limit (FASVAL): 10 meters). A valid GAST-D service was achieved continuously.
FIGURE 8. Vertical and lateral protection levels (VPL and LPL). FIGURE 9 shows a vertical integrity diagram, commonly known as a Stanford plot, for the integrity of the multi-constellation GBAS simulation. This plot shows the Vertical Protection Level (VPL) as determined by the GBAS receiver simulation against the actual Vertical Position Error (VPE). The Vertical Position Error is a direct measure for the Vertical Navigation System Error (V-NSE). This has been determined using a precise point positioning reference trajectory. Both values are normalized by the current VAL as these values change during the approaches. During the flight, the GBAS online processing ran at a rate of 10 Hz, resulting in 43,670 GAST-D epochs and an availability of 100 percent.
FIGURE 9. Normalized vertical Stanford plot of flight trials (GAST-D using GPS, GLONASS, and Galileo). Color scale indicates number of occurrences. Of course, these results must not be misinterpreted as a multi-constellation GBAS performance assessment. The ground facility simulation was highly experimental and lacked any kind of long-term analysis. Even the GNSS antennas used do not meet formal requirements. However, aside from a quantitative judgment, these results show the practicability of this multi-constellation GBAS approach on an experimental basis.
Conclusion and Outlook
In this article, experimental extensions to GBAS have been developed to support GPS, GLONASS, and Galileo simultaneously. Based on these extensions, an optimized VDB transmission scheme has been created. In this way, the number of transmittable differential corrections could be maximized. Using flight trials, the multi-constellation GBAS concept has successfully been verified. The experimental airborne GBAS subsystem was able to calculate a valid GBAS solution including GPS, GLONASS, and Galileo satellites continuously.
It has been shown that multi-constellation GBAS is possible from a purely technical perspective. On the other hand, neither operational nor approval aspects for satellite navigation systems other than GPS have been addressed yet. Additionally, further testing would be necessary to ensure the compatibility with legacy GPS-only GBAS equipment. However, in theory, all modifications for Galileo are backward compatible. Nevertheless, it has to be assured that certified GBAS multi-mode receivers only use the GPS part of the VDB data and are not disturbed by additional VDB messages or additional ranging sources, for example. The required tests are planned for the future.
The operational benefit of multi-constellation GBAS systems cannot be foreseen yet. A certification for this will take several years and could only be addressed by the GBAS community after the completion of the GAST-D certification. Most probably, the use of GNSS signals on multiple frequencies could provide a highly improved GBAS service and will allow much more operational benefit. Many of the satellite navigation systems have already introduced additional frequencies, including signals in the protected L5 aviation band. The use of multiple frequencies for satellite navigation in aviation can remove most ionospheric errors effectively and mitigate a major source of uncertainty. Thus, multi-constellation GBAS can just be seen as a preliminary step on the way towards multi-frequency GBAS. The concepts and infrastructure described in this article will serve as a basis for more research in this area.
Acknowledgments
Most of our work on multi-constellation GBAS was done within the research project “Bürgernahes Flugzeug,” which was established in 2009 and is partly funded by the German federal state of Lower Saxony. This is gratefully acknowledged by the authors. Additionally, the authors would like to thank all colleagues involved for constructive discussions and their support. This article is based on the paper “Mulitple Satellite Navigation for the Ground Based Augmentation System” presented at ITM 2014, The Institute of Navigation 2014 International Technical Meeting, held in San Diego, California, January 27-29, 2014.
MIRKO STANISAK is a research assistant at the Institute of Flight Guidance (IFF) at the Technische Universität (TU) Braunschweig in Germany. He received his diploma in mechanical engineering (Dipl.-Ing.) in 2009 from TU Braunschweig.
MARK BITTER holds a Dipl.-Ing. in mechanical engineering from TU Braunschweig and has been employed as a research engineer at TU Braunschweig IFF since 2003.
THOMAS FEUERLE received his Dipl.-Ing. in mechanical engineering in 1997 from TU Braunschweig. He joined the TU Braunschweig IFF in May 1997. Since 2005, he has been the leader of the Air Traffic Management Team at the IFF. In April 2010, he completed his Ph.D. dissertation at TU Braunschweig.
FURTHER READING
• Authors’ Conference Paper
“Multiple Satellite Navigation Systems for the Ground Based Augmentation System,” by M. Stanisak, M. Bitter, and T. Feuerle in Proceedings of ITM 2014, the 2014 International Technical Meeting of The Institute of Navigation, San Diego, California, January 27–29, 2014, pp. 254–264.
• Standards Documents
Aeronautical Communications, Vol. 1, Radio Navigation Aids, Annex 10 to the Convention on International Civil Aviation, International Standards and Recommended Practices, International Civil Aviation Organization, Montreal, Draft Version, May 2010.
GNSS-Based Precision Approach Local Area Augmentation System (LAAS) Signal-In Space Interface Control Document (ICD), DO-246D, RTCA Special Committee 159, Global Positioning Systems, RTCA Inc. Washington, D.C., December 2008.
Minimum Operational Performance Standards for GPS Local Area Augmentation System Airborne Equipment, DO-253C, RTCA Special Committee 159, Global Positioning Systems, RTCA Inc. Washington, D.C., December 2008.
Minimum Operational Performance Specification for Global Navigation Satellite Ground Based Augmentation System Ground Equipment to Support Category I Operations, ED-114, EUROCAE Working Group 28 on Global Navigation Satellite System, European Organisation for Civil Aviation Equipment, Malakoff, France, September 2003.
• GBAS Research and Development
“Conception, Implementation and Validation of a GAST-D Capable Airborne Receiver Simulation” by M. Stanisak, R. Schork, M. Kujawska, T. Feuerle, and P. Hecker in Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 250–257.
“Making the Case for GBAS: Experimental Aircraft Approaches in Germany,” by U. Bestmann, P.M. Schachtebeck, T. Feuerle, and P. Hecker in Inside GNSS, Vol. 1, No. 7, October 2006, pp. 42–45.
“Initial GBAS Experiences in Europe” by A. Lipp, A. Quiles, M. Reche, W. Dunkel, and S. Grand-Perret in Proceedings of ION GNSS 2005, the 18th International Technical Meeting of the Satellite Division of The Institute of Navigation, Long Beach, California, September 13–16, 2005, pp. 2911–2922.
• GPS Use in Aviation
“Aircraft Landings: The GPS Approach,” by G. Dewar in GPS World, Vol. 10, No. 6, June 1999, pp. 68–74.
“GPS in Civil Aviation” by K.D. McDonald in GPS World, Vol. 2, No. 8, September 1991, pp. 52–59.
-
A Mass-Market Galileo Receiver
Its Algorithms and Performance
The authors test three mass-market design drivers on a chip developed expressly for a new role as a combined GPS and Galileo consumer receiver: the time-to-first-fix for different C/N0, for hot, warm, and cold start, and for different constellation combinations; sensitivity in harsh environments, exploiting a simulated land mobile satellite multipath channel and different user dynamics; and power consumption strategies, particularly duty-cycle tracking.
By Nicola Linty, Paolo Crosta, Philip G. Mattos, and Fabio Pisoni
The two main GNSS receiver market segments, professional high-precision receivers and mass-market/consumer receivers, have very different structure, objectives, features, architecture, and cost. Mass-market receivers are produced in very high volume — hundreds of millions for smartphones and tablets — and sold at a limited price, and in-car GNSS systems represent a market of tens of millions of units per year. The reason for these exploding markets can be found not only in the improvements in electronics and integration, but also in the increasing availability of new GNSS signals. In coming years, with Galileo, QZSS, BeiDou, GPS-L1C, and GLONASS-CDMA all on the way, the silicon manufacturer must continue the path towards the fully flexible multi-constellation mass-market receiver.
Mass-market receivers feature particular signal processing techniques, different from the acquisition and tracking techniques of standard GNSS receivers, in order to comply with mobile and consumer devices’ resources and requirements. However, a limited documentation is present in the open literature concerning consumer devices’ algorithms and techniques; besides a few papers, all the know-how is protected by patents, held by the main manufacturers, and mainly focused on the GPS L1 C/A signal. We investigate and prove the feasibility of such techniques by semi-analytical and Monte Carlo simulations, outlining the estimators sensitivity and accuracy, and by tests on real Galileo IOV signals.
To understand, analyze, and test this class of algorithms, we implemented a fully software GNSS receiver, running on a personal computer. It can process hardware- and software-simulated GPS L1 C/A and Galileo E1BC signals, as well as real signals, down-converted at intermediate frequency (IF), digitalized and stored in memory by a front-end/bit grabber; it can also output standard receiver parameters: code delay, Doppler frequency, carrier-to-noise power density ratio (C/N0), phase, and navigation message. The software receiver is fully configurable, extremely flexible, and represents an important tool to assess performance and accuracy of selected techniques in different circumstances.
Code-Delay Estimation
The code-delay estimation is performed in the software receiver by a parallel correlation unit, giving as output a multi-correlation with a certain chip spacing. This approach presents some advantages, mostly the fact that the number of correlation values that can be provided is thousands of times greater, compared to a standard receiver channel. Use of multiple correlators increases multipath-rejection capabilities, essential features in mass-market receivers, especially for positioning in urban scenarios. The multi-correlation output is exploited to compute the received signal code delay with an open-loop strategy and then to compute the pseudorange.
In the simulations performed, the multi-correlation has a resolution of 1/10 of a chip, which is equivalent to 30 meters for the signals in question; to increase the estimate accuracy, Whittaker-Shannon interpolation is performed on the equally spaced points of the correlation function belonging to the correlation peak.
The code-delay estimate accuracy is reported in Figures 1 and 2. The results are obtained with Monte Carlo simulations on simulated GNSS signals, with sampling frequency equal to 16.3676 MHz. In particular, a GPS L1 C/A signal is considered, affected by constant Doppler frequency equal to zero for the observation period, to avoid the effect of dynamics. The figures show the standard deviation of the code estimation error, that is, the difference between the estimated code delay and the true one, expressed in meters (pseudorange error standard deviation) for different values of C/N0. To evaluate the quality of the results, the theoretical delay locked loop (DLL) tracking jitter is plotted for comparison, as
where Bn is the code loop noise bandwidth, Rc is the chipping rate, Bfe is the single sided front-end bandwidth, Tc is the coherent integration time, and c is the speed of light.
In the two figures, the red curve shows the theoretical tracking jitter for a DLL, which can be considered as term of comparison for code-delay estimation. To correlate the results, a E-L spacing equal to D = 0.2 chip is chosen, and the code-delay error values of the software receiver simulation are filtered with a moving average filter. By averaging 0.5 seconds of data (for example, L = 31 values spaced 16 milliseconds), an equivalent closed-loop bandwidth of about 1 Hz can be obtained:
In particular, in Figure 1, a coherent integration time equal to 1 millisecond (ms) and 16 non-coherent sums are considered, while in Figure 2 a coherent integration time equal to 4 ms and 16 non-coherent sums, spanning a total time T=64 ms, are considered. In both cases, the software receiver results are extremely good for high C/N0. The code-delay error estimate is slightly higher than its equivalent in the DLL formulation. The open-loop estimation error notably increases in the first case below 40 dB-Hz due to strong outliers, whose probability of occurrence depends on the C/N0. In fact, this effect is smoothed in the second case, where the coherent integration time is four times larger, thus improving the signal-to-noise ratio.
Figure 1. Comparison between code delays estimation accuracy, Tc=1 ms , T=16 ms, B=1 Hz, D=0.2 chip. 
Figure 2. Comparison between code delays estimation accuracy, Tc=4 ms, T=64 ms, B=1 Hz, D=0.2 chip. Nevertheless, the comparison between open loop multi-correlation approach and closed loop DLL is difficult and approximate, because the parameters involved are different and the results are only qualitative.
Doppler Frequency Estimation
In the particular case of the software receiver developed here, the residual Doppler frequency affecting the GNSS signal is estimated by means of a maximum likelihood estimator (MLE) on a snapshot of samples, exploiting open-loop strategy. In fact, despite the higher standard deviation of the frequency error (jitter), open-loop processing offers improved tracking sensitivity, higher tracking robustness against fading and interference, and better stability when increasing the coherent integration time. In addition, the open-loop approach does not require the design of loop filters, avoiding problems with loop stability. A certain number of successive correlator values, computed in the multiple correlations block, are combined in a fast Fourier transform (FFT) and interpolated.
Figure 3 shows the root mean square error (RMSE) of the frequency estimate versus signal
C/N0, obtained collecting 16 coherent accumulations of 4 ms of a Galileo E1B signal, then computing a 16 points FFT spanning a time interval of 64 ms, and finally refining the result with an interpolation technique. Three different curves are shown, corresponding respectively to:- the RMSE derived from simulations, carried out with GNSS data simulated with the N-FUELS signal generator;
- a semi-analytical estimation, exploiting the same algorithm;
- the Cramer-Rao lower bound (CRLB) for frequency estimation, shown as
where fs is the sampling frequency.
Figure 3. Doppler frequency estimate RMSE versus C/N0 in super-high resolution with T=64 ms, comparison between theoretical and simulated results. A well-known drawback is the so-called threshold effect. Below a certain C/N0, the frequency estimate computed with MLE suffers from an error, and the RMSE increases with respect to the CRLB.
Mass-Market Design Drivers
Once we have analyzed the features of some mass-market algorithms with a software receiver, we can move toward the performance of a real mass-market device, to compare results and confirm improvements brought by the new Galileo signals, so far mainly known from a theoretical point of view.
A recent survey identified three main drivers in the design of a mass-market receiver, coming directly from user needs, and solvable in different ways.
Time-to-first-fix (TTFF) corresponds to how fast a position, velocity, and time (PVT) solution is available after the receiver is powered on, that is, the time that a receiver takes to acquire and track a minimum of four satellites, and to obtain the necessary information from the demodulated navigation data bits or from other sources.
Capability in hostile environments, for example while crossing an urban canyon or when hiking in a forest, is measured in terms of sensitivity. It can be verified by decreasing the received signal strength and/or adding multipath models.
Power consumption of the device. GNSS chipset is in general very demanding and can produce a not-negligible battery drain.
We analyzed these three drivers with a commercial mass-market receiver and with the software receiver.
Open-Sky TTFF Analysis
TTFF depends on the architecture of the receiver, for example the number of correlators or the acquisition strategy, on the availability of assistance data, such as rough receiver position and time or space vehicles’ (SV) ephemeris data, and on the broadcast navigation message structure. Some receivers, like the one used here for testing, embed an acquisition engine that can be activated on request and assures a low acquisition time; moreover, they implement ephemeris extension. In contrast, other consumer receiver manufacturers exploit a baseband-configurable processing unit, similar to the one implemented in the software receiver, with thousands of parallel correlators generating a multi-correlator output with configurable spacing, depending on the accuracy required. By selecting an appropriate number of correlators, depending on the available assistance data and on the accuracy required, the TTFF consequently varies.
We assessed the performance of the receiver under test for different C/N0, for hot, warm, and cold start, and for different constellation combinations, exploiting hardware-simulated GNSS data. Good results are achieved, especially when introducing Galileo signals.
Figure 4 reports the hot-start TTFF for different C/N0 values in the range 25–53 dB-Hz, computed using the receiver. The receiver, connected to a signal generator, is configured in dual-constellation mode (GPS and Galileo) and carries out 40 TTFF trials, with a random delay between 15 and 45 seconds. In a standard additive white Gaussian noise (AWGN) channel and in hot-start conditions, the results mainly depend on the acquisition strategy and on the receiver availability of correlators and acquisition engines. In an ideal case with open-sky conditions and variable C/N0, the introduction of a second constellation only slightly improves the TTFF performance; this result cannot be generalized since it mainly depends on the acquisition threshold of the receiver, which can change using signals of different constellations. In real-world conditions, the situation can vary.
Figure 4. Hot start TTFF for Galileo+GPS configuration versus C/N0 using the test receiver. Cold Start. Secondly, we analyze TTFF differences due to the different structure of GPS and Galileo navigation messages. The I/NAV message of the Galileo E1 signal and the data broadcast by GPS L1 C/A signals contain data related to satellite clock, ephemeris, and GNSS time: parameters relevant to the position fix since they describe the position of the satellite in its orbit, its clock error, and the transmission time of the received message.
Table 1 shows some results in the particular case of cold start, with an ideal open-sky AWGN scenario. The TTFF is significantly lower when using Galileo satellites: while the mean TTFF when tracking only GPS satellites is equal to about 31.9 seconds (s), it decreases to 24.7 s when considering only Galileo satellites, and to 22.5 s in the case of dual constellation. Similarly, the minimum and maximum TTFF values are lower when tracking Galileo satellites. The 95 percent probability values confirm the theoretical expectations. Again, in the ideal case with open-sky conditions, the results with two constellations are quite similar to the performance of the signal with faster TTFF. However, in non-ideal conditions, use of multiple constellations represents a big advantage and underlines the importance of developing at least dual-constellation mass-market receivers.
Table 1. Comparison between TTFF (in seconds) in cold start for different constellation combinations. Furthermore, it is interesting to analyze in more detail the case of a GPS and Galileo joint solution. GPS and Galileo system times are not synchronized, but differ by a small quantity, denoted as the GPS-Galileo Time Offset (GGTO). When computing a PVT solution with mixed signals, three solutions are possible: to estimate it as a fifth unknown, to read it from the navigation message, or to use pre-computed value. In the first case it is not necessary to rely on the information contained in the navigation message, eventually reducing the TTFF. However, five satellites are required to solve the five unknowns, and this is not always the case in urban scenarios or harsh environments, as will be proved below. On the contrary, in the second case, it is necessary to obtain the GGTO information from the navigation message, and since it appears only once every 30 seconds, in the worst case it is necessary to correctly demodulate 30 seconds of data. Both approaches show benefits and disadvantages, depending on the environment. The receiver under test exploits the second solution: in this case, it is possible to see an increase in the average TTFF when using a combination of GPS and Galileo, due to the demodulation of more sub-frames of the broadcast message.
Sensitivity: Performance in Harsh Environments
Harsh environment is the general term used to describe those scenarios in which open sky and ideal propagation conditions are not fulfilled. It can include urban canyons, where the presence of high buildings limits the SV visibility and introduces multipath; denied environments, where unintentional interference may create errors in the processing; or sites where shadowing of line-of-sight (LoS) path is present, for example due to trees, buildings, and tunnels. In these situations it is necessary to pay particular attention to the signal-processing stage; performance is in general reduced up to the case in which the receiver is not able to compute a fix.
A first attempt to model such an environment has been introduced in the 3GPP standard together with the definition of A-GNSS minimum performance requirements for user equipment supporting other A-GNSSs than GPS L1 C/A, or multiple A-GNSSs which may or may not include GPS L1 C/A. The standard test cases support up to three different constellations; in dual-constellation case it foresees three satellites in view for each constellation with a horizontal dilution of precision (HDOP) ranging from 1.4 to 2.1.
To perform TTFF and sensitivity tests applying the 3GPP standard test case, we configured a GNSS simulator scenario with the following characteristics, starting from the nominal constellation:
- Six SVs: three GPS (with PRN 6,7, 21) and three Galileo (with code number 4, 11, 23);
- HDOP in the range 1.4 – 2.1;
- nominal power as per corresponding SIS-ICD;
- user motion, with a heading direction towards 90° azimuth, at a constant speed of 5 kilometers/hour (km/h).
In addition to limiting the number of satellites, we introduced a narrowband multipath model. The multi-SV two-states land mobile satellite (LMS) model simulator generated fading time series representative of an urban environment. The model includes two states:
- a good state, corresponding to LOS condition or light shadowing;
- a bad state, corresponding to heavy shadowing/blockage.
Within each state, a Loo-distributed fading signal is assumed. It includes a slow fading component (lognormal fading) corresponding to varying shadowing conditions of the direct signal, and a fast fading component due to multipath effects. In particular, the last version of the two-state LMS simulator is able to generate different but correlated fading for each single SV, according to its elevation and azimuth angle with respect to the user position: the angular separation within satellites is crucial, since it affects the correlation of the received signals. This approach is based on a master–slave concept, where the state transitions of several slave satellites are modeled according to their correlation with one master satellite, while neglecting the correlation between the slave satellites. The nuisances generated are then imported in the simulator scenario, to timely control phase and amplitude of each simulator channel. Using this LMS scenario, the receiver’s performance in harsh environments has been then verified with acquisition (TTFF) and tracking tests.
The TTFF was estimated with about 50 tests, in hot, warm, and cold start, first using both GPS and Galileo satellites, and then using only one constellation. In the second case only the 2D fix is considered, since, according to the scenario described, at maximum three satellites are in view. Table 2 reports the results for the dual-constellation case: in hot start the average TTFF is about 8 s, and it increases to 36 s and 105 s respectively for the warm and cold cases. Clearly the results are much worse than in the case reported earlier of full open-sky AWGN conditions. In this scenario only six satellites are available at maximum; moreover, the presence of multipath and fading affects the results, and they exhibit a larger variance, because of the varying conditions of the scenario.
Table 2. TTFF (in seconds) exploiting GPS and Galileo constellations in harsh environments. Table 3 shows similar results, but for the GPS-only case. In this case the receiver was configured to track only GPS satellites. The mean TTFF increases both in the hot and in the warm case, whereas in cold start it is not possible compute a 2D fix with only three satellites; the ambiguity of the solution cannot be solved if an approximate position solution is not available. It may seem unfair to compare a scenario with three satellites and one with six satellites. However, it can be assumed that this is representative of what happens in limited-visibility conditions, where a second constellation theoretically doubles the number of satellites in view.
Table 3. TTFF (in seconds) exploiting only GPS constellations in harsh environments. The results confirm the benefits of dual-constellation mass-market receivers in harsh environments where the number of satellites in view can be very low. Making use of the full constellation of Galileo satellites will allow mass-market receivers to substantially increase performances in these scenarios.
Tracking.We carried out a 30-minute tracking test with both the receiver and the software receiver model. Both were able to acquire the six satellites and to track them, even with some losses of lock (LoLs) due to fading and multipath reflections. Figure 5 shows the number of satellites in tracking state in the receiver at every second, while Figure 6 shows the HDOP as computed by the receiver. When all six satellites are in tracking state, the HDOP lies in the range 1.4 – 2.1, as defined in the simulation scenario; on the contrary, as expected, in correspondence with a LoL it increases.
Figure 6. HDOP computed by the test receiver in the Multi-SV LMS simulation. Figure 7 compares the signal power generated by the simulator and the power estimated by the receiver, in the case of GPS PRN 7 and Galileo code number 23. This proves the tracking capability of the receiver also for high sensitivity. To deal with low-power signals, the integration time is extended both for GPS and for Galileo, using the pilot tracking mode in the latter case.
Figure 7. C/N0 estimate computed by the receiver in harsh environments and compared with the signal power. Figures 8 and 9 show respectively the position and the velocity solution. In the first case latitude, longitude, and altitude are plotted, while in the second case the receiver speed estimate in km/h is reported.
Figure 8. Test receiver position solution in LMS scenario. 
Figure 9. Test receiver velocity solution in LMS scenario. In this framework it is possible to evaluate the advantages and disadvantages of using the broadcast GGTO when computing a mixed GPS and Galileo position. When the LMS channel conditions are good, all six SVs in view are in tracking state, as shown in Figure 5. However, when the fading becomes important, the number is reduced to only two satellites. If the receiver is designed to extract the GGTO from the navigation message, then a PVT solution is possible also when only four satellites are in tracking state, that is for 90 percent of the time in this specific case. On the contrary, if the GGTO has to be estimated, one more satellite is required, and this condition is satisfied only 57 percent of the time, strongly reducing the probability of having a fix. Nevertheless, estimating the GGTO requires the correct demodulation of the navigation message, and this is possible only if the signal is good enough for a sufficient time.
Figure 5. Number of satellites tracked by the test receiver in the Multi-SV LMS simulation. Power-Saving Architectures
The final driver for mass-market receivers design is represented by power consumption. Particularly for chips suited for portable devices running on batteries, power drain represents one of the most important design criteria. To reduce at maximum the power consumption, chip manufacturers have adopted various solutions. Most are based on the concept that, contrarily to a classic GNSS receiver, a mass-market receiver is not required to constantly compute a PVT solution. In fact, most of the time, GNSS chipsets for consumer devices are only required to keep updated information on approximate time and position and to download clock corrections and ephemeris data with a proper time rate, depending on the navigation message type and the adopted extended ephemeris algorithm. Then, when asked, the receiver can quickly provide a position fix. By reducing the computational load of the device during waiting mode, power consumption is reduced proportionally.
To better understand advantages and disadvantages of power saving techniques, some of them have been studied and analyzed in detail. In particular, the algorithm implemented in the software receiver model is based on two different receiver states: an active state, in which all receiver parts are activated, as in a standard receiver, and a sleep state, where the receiver is not operating at all. In the sleep state, the GNSS RF module, GNSS baseband, and digital signal processor core are all switched off. By similarity to a square wave, these types of tracking algorithms are also called duty-cycle (DC) algorithms. Exploiting the software approach’s flexibility, we can test the effect of two important design parameters:
- sleep period length;
- minimum active period length.
Their setting is not trivial and depends on the channel conditions, on the signal strength, on the number of satellites in view, on the user dynamics, and finally on the required accuracy.
In the software receiver simulations performed, the active mode length is fixed to 64 ms: the receiver collects 16 correlation values with coherent integration time equal to 4 ms, to perform frequency estimation as described above. Then it switches to sleep state for 936 ms, until a real-time clock (RTC) wake-up initiates the next full-power state. In this way a fix is available at the rate of 1 s, as summarized in Figure 10. However, there are some situations where the receiver may stay in full-power mode, for example during the initialization phase, to collect important data from the navigation message, such as the ephemeris, and to perform RTC calibration.
Figure 10. Duty cycle tracking pattern in the software receiver simulations. There are benefits of using this approach coupled to Galileo signals: the main impact is the usage of the pilot codes. Indeed, a longer integration time allows reducing the active period length, which most impacts the total power consumption, being usually performed at higher repetition rate.
Some simulations were carried out to assess the performance of DC algorithms in the software receiver. While in hardware implementations the direct benefit is the power computation, in a software implementation it is not possible to see such an improvement. The reduced power demand is translated into a shorter processing time for each single-processing channel. The DC approach can facilitate the implementation of a real-time or quasi-real-time software receiver.
The main drawback of using techniques based on DC tracking is the decrease of the rate of observables and PVT solution. However, this depends on the application; for some, a solution every second is more than enough.
Real-Signal Results
On March 12, 2013, for the first time the four Galileo IOV satellites were broadcasting a valid navigation message at the same time. From 9:02 CET, all the satellites were visible at ESTEC premises, and the first position fix of latitude, longitude, and altitude took place at the TEC Navigation Laboratory at ESTEC (ESA) in Noordwijk, the Netherlands. At the same time, we were able to acquire, track, and compute one of the first Galileo-only mobile navigation solutions, using the receiver under test. Thanks to its small size and portability, it was installed on a mobile test platform, embedded in ESA’s Telecommunications and Navigation Testbed vehicle. Using a network connection, we could follow, from the Navigation Lab, the real-time position of the van moving around ESTEC.
Figure 11 shows the van’s track, obtained by post processing NMEA data stored by the receiver evaluation board. The accuracy achieved in these tests met all the theoretical expectations, taking into account the limited infrastructure deployed so far. In addition, the results obtained with the receiver have to be considered preliminary, since its firmware supporting Galileo was in an initial test phase (for example, absence of a proper ionospheric model, E1B-only tracking).
Figure 11. Galileo-only mobile fix, computed on March 12, 2013. Conclusions
Analysis of a receiver’s test results confirms the theoretical benefits of Galileo OS signals concerning TTFF and sensitivity. Future work will include the evolution of the software receiver model and a detailed analysis of power-saving tracking capabilities, with a comparison of duty-cycle tracking techniques in open loop and in closed loop.
Acknowledgments
This article reflects solely the authors’ views and by no means represents official European Space Agency or Galileo views. The article is based on a paper first presented at ION GNSS+ 2013. Research and test campaigns related to this work took place in the framework of the ESA Education PRESTIGE programme, thanks to the facilities provided by the ESA TEC-ETN section. The LMS multipath channel model was developed in the frame of the MiLADY project, funded by the ARTES5.1 Programme of the ESA Telecommunications and Integrated Applications Directorate.
Manufacturers
The tests described here used the STMicroelectronics Teseo II receiver chipset and a Spirent signal simulator.
Nicola Linty is a Ph.D. student in electronics and telecommunications at Politecnico di Torino. In 2013 he held an internship at the European Space Research and Technology Centre of ESA.
Paolo Crosta is a radio navigation system engineer at the ESA TEC Directorate where he provides support to the EGNOS and Galileo programs. He received a MSc degree in telecommunications engineering from the University of Pisa.
Philip G. Mattos received an external Ph.D. on his GPS work from Bristol University. He leads the STMicroelectronics team on L1C and BeiDou implementation, and the creation of totally generic hardware that can handle even future unknown systems.
Fabio Pisoni has been with the GNSS System Team at STMicroelectronics since 2009. He received a master’s degree in electronics from Politecnico di Milano, Italy.
-
Recording and Replay for Multiple Constellations and Frequency Bands
The design and verification of a new class of portable wideband record-and-playback system considers the relative merits and limitations of both simulator and record/replay approaches. The authors also discuss the benefits of the different test approaches to the development and characterization of various GNSS receiver types.
By Steve Hickling and Tony Haddrell
As new GNSS systems become available, and users take receivers to ever more challenging environments, the need for repetitive and repeatable testing during development grows ever stronger. Simulators have traditionally demonstrated performance and repeatability in the laboratory environment, and this approach remains the only option for planned signals not yet broadcast from space. However, this approach is becoming more complex as the number of GNSS signals and their reception environments increase.
Another way of testing receivers is through field trials. This allows investigation of conditions difficult to simulate, such as multiple reflections and interferers. These environments, however, are time-varying, and thus not repeatable in the true sense. Therefore, proper comparisons can only be made by assessing all competing receivers in the same trial, and any performance anomalies seen cannot necessarily be tracked down by returning to the same location at some point in the future. Furthermore, developers would like to see for themselves any such anomalies and try to understand and correct them, but it is not always desirable or practical (and certainly not economical) to put development engineers in locations scattered all over the globe.
To tackle this problem, GNSS signal record-and-replay capability is gaining acceptance as a practical tool for recording a signal environment at a single point in time and replaying at will. In real terms this means a device must receive the radio signals from the GNSS satellites, reduce them to a form suitable for storage, and then recreate signals from the stored data in a manner that makes them look completely real to any receiver under test or development.
Some receiver manufacturers developed their own capability to do this. Early devices were of necessity restricted in the signals they could handle and store, limited both by budget and available technologies. The basic problems are the amount of data to be stored in real time and the ability to recover it in real time. Even the GPS L1-only low bandwidth C/A code requires at least 2 Mbytes per single second of recording, or more than 100 Mbytes per minute.
Fortunately, with digital storage technology advances, we can now make use of higher storage capacities (1 TByte of storage is readily available at reasonable cost) and also higher write/read bandwidths (100 MBytes per second is realistic). All we need is some hardware and a processor that can handle the data rates.
Once we have our wanted signals reduced to some form of digital representation, we can simply store and retrieve them at will, handling the recordings as simple, if somewhat large, data files. This allows file distribution between equipments, and a split between making the recording in the field and replaying it in the laboratory. In fact, many manufacturers have dedicated field recording teams who send the files back to the engineers interested in the signal environments.
Replaying the signals is in some ways similar to generating simulated signals. In both cases, the starting point is digital data, on the one hand recorded in the field, on the other hand calculated by mathematical algorithms using the scenario specified in the simulator. In both cases the signal is created by generating radio frequency (RF) carriers and modulating them according to the GNSS signal formats.
Contrast of Two Approaches. None of the characteristics of the record/replay device replace the functionality of the simulator; in fact, both are valid tools for development and testing. For instance, it is not possible with a record/replay device to manipulate individual satellite signals, nor to introduce specific errors in the radio signals. Equally, it is not really possible with a simulator to recreate a particular physical environment made up of many reflected signals, jammers, manmade noise, and moving scenery. With a simulator, the user has control over the power of the received satellite signal, whereas in the recorder the entire signal-to-noise ratio observed at the point of reception has been recorded, and the user can only control the amplitude of the entire noise plus signal.
Permanent Signal Monitoring
One other aspect of raw signal recording lies outside the receiver testing topic, but is of interest for GNSS signal monitoring. It uses the ability to record GNSS signals all of the time, in this case from a good signal environment, and then to retain any time spans where an anomaly in the signals has been detected by a monitor receiver. This is comparable to recording security CCTV pictures, where we expect nearly all of the resulting files to be redundant, but can retain the interesting bits to replay over and over for further analysis. For example, if it is known that a given timing receiver installation suffers periodic loss of lock, it is possible to make a recording using the loss of lock to signpost the interesting region in much the same way as a reverse trigger on an oscilloscope.
Limitations and Compromises
The sheer function of recording GNSS signals off-air has some built-in limitations. First, the signal recorded represents only a snapshot of the environment, although numerous recordings can be made at, say, busy and quiet times, day and night, etc. This is really a reversal of the “non repeatability” aspect of measuring performance in a particular location. In the recording sense, we only get repeatability, with no guarantee that the scenario captured represents worst case conditions. Thus, going back to the location in the future may or may not provide similar results.
In addition to this, there are some signal processing aspects that limit the fidelity of the replayed signals. The first is that any recorder must have an external GNSS antenna and a GNSS receiver front-end built in, and this combination will receive both the satellite signals and thermal noise. The level of the noise is much higher than that of the signals if we don’t do any correlation related processing, and the receiver will contribute some more noise of its own (the noise figure of the system). The second aspect is that in downconverting the radio signals to a usable frequency for sampling and storage, the recorder must use some frequency reference of its own, which will contribute some frequency uncertainty and some phase noise (or jitter on the frequency). The final aspect is the digitization of the downconverted signal to get it into a suitable form for manipulation and storage. Since we are essentially sampling noise here (with the GNSS signal buried in it) we need to look at fidelity in reproduction of the noise during playback, and the effect of any signal (a jammer or interferer) that is above the amplitude of the noise. In analyzing this last aspect, we may include the effect of any automatic gain control (AGC) used to present the correct amplitude signal to the analog to digital (A2D) converter.
A New Simulation Requirement
We wanted to create a much more comprehensive and flexible device than hitherto available, going part way towards the much more general (and expensive) instrumentation recorders that are currently the only alternative.
The requirement is for a flexible, self-contained device that can be easily carried or transported for recording purposes, so having an internal battery and built-in control functionality, and simultaneously a device that fits neatly into a networked and externally controlled laboratory environment.
The first approach was to cover all of the possible GNSS frequency bands, although as more are added with time, we realized that this needed to be moderated somewhat. So the product covers L1, L2, L5 and their derivatives for the differing GNSS systems GPS, GLONASS, Galileo, and BeiDou, and also the Inmarsat commercial band to cover the proprietary augmentation signals used by many high-accuracy receivers (see Figure 1, red outlines).
FIGURE 1. Frequency bands, outlined in red, supported by the new record-and-replay device. The next decision was what bandwidths to allow at each frequency, and how much of this bandwidth could be covered at once. The limitations here are driven by the data storage requirements of the signals being recorded, and the speed that they can be written to disk. The resulting solution allows bandwidths (BW) of up to 30 MHz at each frequency, and any three such bandwidths to be recorded at once. Physically, this is implemented with three channels with the ability to record any of the available frequencies or bandwidths. The user has, therefore, flexibility to set up recording for his particular needs, which may be just L1 covering BeiDou, GPS, Galileo, and GLONASS, or an L1,L2,L5, combination for a survey type application.
Of course, there are always requests for more capability, and we envisaged early on the ability to stack two devices to give six channels of 30-MHz BW for recording, say, GPS/Galileo and GLONASS at L1, GPS and GLONASS at L2, Galileo/GPS at L5, and an Inmarsat data carrier. See later for how this is achieved.
The whole product has to fit in a portable box with enough battery power for more than one-hour field campaigns, and also be capable of running from mains or vehicle power. The associated antenna needs to cover all of the frequency bands. Figure 2 shows the end result in its standalone configuration.
Figure 2. Portable solution for recording. One additional requirement was placed upon the design, and that is the ability to record and replay non-GNSS data simultaneously with the GNSS signals, and reproduce them, if desired, in synchronism with the replayed signals. This allows time ticks, events, assistance data, sensor data, or even video to be stored and replayed along with the raw signals.
Architecture and Implementation
The new record-and-replay device uses a fast computer running the Linux operating system as its control center and storage/retrieval engine. Dedicated hardware is used to format or recover the raw data, and this has access directly to the computer bus to minimize the delays in writing or reading the mass storage, which in this case is a solid state hard drive (SSD). The overall architecture is shown in Figure 3.
Figure 3. Concept-level architecture. The signal recording capability hinges around the RF planning, which has the task of supplying the necessary flexibility without adding more than minimal signal degradation.
For the RF functionality, the device contains a broadband front end and a three-channel RF amplifier (L1, Imarsat, and L2/L5), filtering the signal down to reasonable bandwidths for later downconversion. Three independent channels of downconversion to baseband I and Q analog signals have access to any of the RF channels and are based upon satellite TV technology architectures. The downconverters have baseband filters that can be commanded to a desired bandwidth by the control processor. This allows the use of narrower bandwidths where possible, allowing more recording time for a lower sampling rate. The baseband signals are sampled at 10 MHz or 30 MHz, paying attention to the Nyquist requirements for pre-digitisation filtering. Two bits for each of the I and Q signals are utilized for packing into the recorded file format. Figure 4 shows the arrangement.
Figure 4 . The RF architecture. At this stage any additional synchronous data to be recorded, such as truth or assitance data, is inserted into the bit stream, and the data from all the channels in use is combined in a pre-determined format. Dedicated hardware is used for this, and large data buffers are provided to alleviate bottlenecks in sending data to the disks. Each file has an associated definition in a header, and contains synchronization data to allow the device to set up the replay path and recover the data bits in order to reproduce whatever combination was recorded. Note that resulting data files are given the same extension, regardless of content. Data files can be very big (at maximum bandwidth we record about 2.7 Gbytes per minute) and may be difficult to handle once recorded. To assist with this, the device has a second, removable SSD on board, allowing recorded files to be simply popped out of the caddy and shared with another device, or even mailed or couriered. The RF path for the replay consists again of three independent channels, able to generate any of the supported frequencies and modulate upon them the original signals recovered from the stored file. Once again, dedicated hardware and large buffers are needed to unpack the files and send the RF data to the correct channels or to the synchronous data outputs in the case of recorded digital data, as determined by the file header.
The data representing the recorded RF is converted back to analog form and filtered before being applied to modulators which regenerate the original channelized signals. Each channel has a programmable attenuator to “level” the amplitude, and the three channels are then combined together before passing through a common attenuator to provide user control over the replayed carrier to noise ratio (C/N0). Figure 5 shows the upconverter arrangement.
Figure 5. An upconverter channel. All frequencies created within the device need to be traceable to a common reference. In addition, this reference needs to be at least as good as the reference in any receiver to be tested, since both its offset from true frequency and its rates of change will be superimposed on the replayed data. Many commercial-grade GNSS receivers (such as those used in mobile phone) are specifically designed to cope with poor oscillators, for instance a low-grade temperature controlled crystal oscillator (TCXO), whereas more professional receivers may expect a couple of orders of magnitude better performance. We decided, therefore, to include an ovenized oscillator (OCXO) for use both in record and playback modes. One challenge presented by this decision is that the oven is necessarily thirsty for power, and therefore a bigger battery is needed than would otherwise be the case.
The OCXO used is a 10.23-MHz component, thus allowing direct generation of the wanted GNSS frequencies using integer ratios and avoiding as much phase noise as possible in the various RF channels. A dedicated phase locked loop (PLL) generates a reference for output to other devices, and a 10-MHz input connector is provided to lock the OCXO to an external reference. These capabilities are utilized when combining two such devices, since we must have the same frequency reference in each. Apart from locking the two oscillators together, this configuration also needs time synchronization between the sampling in both devices, and this is achieved via an additional cable connected between the accessory connectors. Once time and frequency synchronized, the devices behave as a single six-channel unit, using external RF splitter/combiners for the RF connections.
Design Challenges
RF Total Bandwidth. The GNSS bands covered by the device range from the L5 band to the GLONASS L1 band, a total range of 480 MHz allowing for signal bandwidths. Table 1 shows the relevant bands.
Whilst the RF front end must be wide open to this range, assuming the use of a single RF input port, it is obviously necessary to provide bandwidth narrowing by filtering as soon as possible, to exclude jammers or carriers using the space between the GNSS bands, and to avoid the sheer noise power overwhelming the RF circuits. Examination of the supported GNSS services shows them essentially packed into two clusters of frequencies, which provide a convenient way of filtering down the RF input into two RF “channels.” This gets the total bandwidth down to about 180 MHz. Figure 1, the opening graphic for this article, shows the groupings. Beidou B3 and Galileo E6 are currently out of scope for this product, but will be supported in a later version.
The Inmarsat-supported signals are assigned their own RF path, since their structure is data modulated carriers, usually with low SNR. Elsewhere in the Inmarsat band there are more powerful carriers supporting comms traffic, which can “grab” the AGC and therefore cause loss of SNR during the digitization process. Hence this band is processed though its own RF path, maintaining as low a bandwidth as possible consistent with the frequency allocations of the various (proprietary) GNSS augmentation data carriers.
Tradeoffs. Throughput of the recording or replay paths is the performance limitation of the current architecture. Thus a lot of discussions and simulations concerning possible bandwidth, sampling rates, and bit depth tradeoffs was undertaken at the outset of the design. In addition, we needed to decide whether to sample signals at an IF frequency or at baseband. Trials were conducted to determine the real rates of disk access, which are different to the often quoted write and read speeds of computer interfaces.
The results of the trials and simulation led us to adopt a maximum average data rate to/from the storage system of 50 Mbytes/second, this being shown to be available over a period of many hours. Actually, at this rate we fill up a 1-Tbyte disk in about five hours.
To service the GNSS signal bandwidths of interest, again there are two groups of signals. This time we are looking at either the commercial signals (“open service signals” in some systems’ parlance) used by consumer-type receivers, which are relatively narrow band, and the military, high-accuracy, or resilient signals of interest to surveying and precision applications. Therefore, we offer two sampling rates, approximately 10 and 30 MHz, to avoid building large files where more than half of the bandwidth was of no interest to the user.
Next, we have to look at bit resolution. Given that we have generally a noise-like signal with Gaussian characteristics, if we were looking at digitizing at an intermediate frequency (IF), it can be shown that a 2-bit analog-to-digital converter (A2D) would be sufficient to keep the digitization losses to less than 1dB. Obviously, the fewer number of bits we need to store the better, commensurate with achieving the performance targets.
Frequency planning for all of the possible frequencies and bandwidths of interest is a complex task. The requirement here was to downconvert each signal of interest to a low IF suitable for digitizing, whilst having control of the bandwidth to eliminate unwanted signals and fulfill the Nyquist criterion. In addition, we wanted each channel to be isolated from the others even when the replay path involving the generation of the IF carriers was considered.
We therefore decided to downconvert to baseband for each channel, to avoid cross-contamination via the various IFs that would have to be generated for replay. In other words, we adopted an IF of zero Hz. This in turn means that the final bandwidth-determining filters are at baseband, and can readily be controlled by software means rather than having to switch RF paths. By downconverting into quadrature baseband channels, all stored signals are at the same (zero) IF, and crosstalk and imaging during upconversion is avoided.
Thus the A2D architecture of 2 bits in the inphase (I) and 2 bits in the quadrature (Q) arms of the downconverted signal was adopted. Doing the calculation in terms of stored data, we see that we can operate three channels inside our target storage bandwidth, with a margin left for other features such as storing video at the same time.
- For 30M samples per second (SPS), each channel has 4 bits or 0.5 bytes
- Therefore, for three channels the storage bandwidth is 0.5 * 3 * 30 MSPS, or 45 Mbytes/s
To keep the optimum A2D characteristics, the AGC is designed to adjust the signal amplitude at the converter to give a Gaussian response to the four states determined by the two bits in each arm. The AGC operates independently in each channel. Figure 6 shows the final architecture for the device in block diagram form.
Figure 6. Final architecture. Real-Time Data Handling. Storage and retrieval of the digitized signals is carried out by dedicated hardware connected to the RF downconverter, the playback upconverter, and the main computer that “owns” the storage media. Large buffers allow the storage media to lag (record) and lead (playback) the real-time signals in time, and to take short breaks for housekeeping functions. Data is packed into a binary file according to a pre-determined sequence, which in turn is set by the number of channels and bandwidths in use. A file header is generated which contains all of the information necessary for reconstructing the data streams for replay. A synchronization sequence is added at the start of the file to allow recovery of the correct bits for each channel and each baseband quadrature arm, and to the correct timeslots for each component. Destroying the correct time reproduction is the most likely issue to cause faulty replay in any record/replay device. GNSS receivers don’t like discontinuous or slewing time!
This approach also allows the insertion of external digital data into the file. Providing the data processing hardware is aware of the individual bits into which this data is placed, digital data recorded at the same time as the raw signals may be regenerated synchronously during replay. Thus any data that is applied to a receiver in a real time trial can be available for the same trial any time after the event. Two streams of synchronous data can be recorded per channel potentially making six serial data streams per chassis available.
User Interfaces
A final challenge presents itself in the case of user interfaces. Although the operational options of the device are quite complex, there is a requirement to be able to capture field data with just the equipment itself and any necessary antenna setup. Consequently, the product has a display and control keys implemented on the front panel, allowing the user comprehensive access to the internal functions using a menu system and scrolling displays. Alternatively, for operation in a lab environment, a network connected user interface is specified, and this requirement is supported by a webserver running on the main processor in the device. Thus, simply opening a web browser and connecting to the device’s IP address allows full functional control.
In addition, connecting a mouse, keyboard, and monitor to the device allows access to the main processor, allowing the running of scripts thus providing full control of replays and receiver functions for running continuous tests in an automated laboratory environment. Using this approach, receiver modifications can be tested over many scenarios and locations many times each, to provide statistically relevant results, without taking up operator time. Remote monitoring is possible using the webserver.
Performance Testing
A range of tests and trials have been carried out to verify that the product meets its specifications, and to measure the performance in a number of real life scenarios.
Repeatability, Degradation, Attenuation. The first and most obvious thing to explore is the effect of the record and playback on signal-to-noise ratio. Since the RF circuits add some noise to the signal recorded, we would expect some degradation to take place here. Also, during replay, the receiver under test adds more noise, depending on its noise figure, although this should be the same as would be added when using “live” signals. Many receivers adjust for their noise figure when reporting C/N0 numbers (C/N0 is a signal to noise measurement normalized to a 1-Hz bandwidth and is the standard reported measurement for most GNSS receivers). However, by replaying back the recorded signal and noise at a higher level than would have been received in “live” conditions, we can eliminate almost all of the degradation. In live versus replayed tests for individual satellites using a JAVAD receiver, which allows us to test all of the supported bands and constellations, we found that replay is possible within ±1 dB of the original live signals. Replayed signals were about 10 dB above the original recorded level to achieve this, effectively swamping the receiver’s noise contribution.
An interesting aspect of controlling the C/N0 this way is the ability to attenuate the replayed signal and, therefore, increase the contribution of the test receiver’s noise figure. Thus, although the recorded C/N0 hasn’t changed, we can attenuate the replay level and use the receiver to add noise.
This process is not linear, and we obviously have to remove nearly all of the 10-dB excess to get started. The device keeps a table of attenuation vs C/N0 reduction, allowing the user to simply dial up the required C/N0 loss. Since this depends on the receiver noise figure, effects may differ slightly from receiver to receiver. Usefully the table is user definable allowing tailoring to a specific receiver.
Losses from Phase Noise, Other Factors. This category of degradation is more difficult to quantify, since the effects are on tracking and therefore range and phase measurement rather than signal to noise ratio. One way of looking at this is, therefore, to establish the positioning performance during live and replayed sessions, and measure the differences. This has some complexity, though, since putting the same signals into a receiver multiple times yields differing performance each time, meaning that we have to use some statistical analysis. Of course this isn’t possible on live signals, and is one reason why repeatable replayed signals are so important in developing GNSS receivers. Another aspect is the fact that some of the effects are differential among frequency bands (filter delays, for instance) and across bands as well (group delay) and also occur in the receiver under test, which will have been calibrated to mitigate its own contribution.
Figure 7 shows a comparison of static positioning for live and replayed signals using only GPS L1 and a 10-MHz sampling rate with an ST-Ericsson receiver, whilst Figure 8 is from a JAVAD receiver using all possible signals in live mode and GPS L1/L2 and GLONASS L1 in replay. In both cases the degradation is within 1 meter always, and much less than this when statistically analyzed.
Figure 7. Static position GPS L1 comparison: live left, replayed right. 
Figure 8. GPS L1/ L2 with GLONASS L1 comparison. Another opportunity to measure the effects is to run a zero baseline phase solution, whereby the receiver is used as the “base station” when receiving live signals which are simultaneously recorded. During replay, the same receiver is used as the “rover” with RTK corrections coming from the previously captured live session. In this setup, therefore, we are really only measuring differences in the replayed and live signals, and the usual measurement limitations of the receiver.
Figure 9 shows the results of one such test, with the pseudorange and carrier phase residuals plotted. This was carried out using two devices in master/slave mode recording GPS L1, L2, L5, and GLONASS L1, L2. As can be seen, the residuals are within “normal” expectations and are measured as 0.42 m RMS for the pseudorange and 1mm RMS for the carrier phase.
Figure 9. Residuals from zero baseline replay. Drive Test
One of the most common uses for the recorder is to capture the signals at a particular time in a chosen “difficult” environment, A number of representative trials were carried out and we were able to demonstrate consistent results and repeatability. In some cases, the replayed signals yield better performance than live ones, which of course is possible given the differing receiver responses per signal run.
Also, the more times a receivers sees the same time span, the more ephemeris and iono data it can build up, especially true of built up areas where data acquisition is difficult. Figure 10 shows a small section of the City of Coventry in the UK, where the green trace is the “live” plot and the replayed one is in orange. Much of this route is under roads or buildings.
Figure 10. Live and replayed drive around in Coventry. Dynamic Range and Fidelity
When jamming signals are introduced, the dynamic range comes into play. The earlier discussion of the 2-bit I and 2-bit Q architecture is tested here as the performance of the AGC and A2D is critical in maintaining the fidelity of the GNSS signals in a jamming environment. Note that we are not addressing deliberate jamming here, any “controlled” jammers can be added with an RF mixer at replay. Instead, we are concerned with the everyday jamming environment encountered just about everywhere electronic equipment is deployed.
A test was carried out to determine the dynamic range of record/playback paths. A simulator was used as a GPS L1 signals source, and progressively larger jamming signal added via an RF power combiner. The resultant C/N0 in a test receiver was plotted using the live signals which were recorded at the same time. A subsequent replay of those signals was then plotted on top of the original C/N0s. The result is in Figure 11.
Figure 11. Results of the increasing jammer test. As can be seen, with low jammer powers the real-time and replayed C/N0s track very closely. The ST-Ericsson receiver we used has some signal processing mitigation built in, and so only shows slow degradation as the jammer power is increased. In the real-time run, it was able to track satellites with the J/S ratio greater than 44 dB (and therefore >25 dB above the noise)
On the replayed line, we see the dynamic range limitations start to dominate the replayed signal when the J/S reaches about 30 dB, or 11 dB above the noise, which aligns well with the theoretical analysis of the digitization strategy. This range is sufficient for most environments encountered in real tests.
In Use and Additional Capabilities
With so much flexibility we find that users have a diverse range of applications for the device. These range from multi-constellation usage at L1 only, allowing BeiDou, Galileo, GLONASS, and GPS to be captured, to full six-channel recordings using GPS, GLONASS, and Galileo at L1, L2, and L5 along with an Inmarsat-based assistance channel. For the first time in this class of device, recording of the “military” bandwidth signals is possible. User feedback has been favorable, especially since the unit opens up new capabilities for receiver development and testing.
A small margin of recording bandwidth has been put to use with the ability to record video alongside the raw GNSS signals, and to replay it simultaneously. This allows developers not only to see the performance of their receiver in difficult signal environments, but also to gain a visual idea of the physical environment. Figure 12 shows a receiver control panel along with video pictures of the recorded environment.
Figure 12. GPS L1 and video synchronized replay Conclusion
Early user feedback has validated the concept behind the device. Although the device will cover additional GNSS constellations and bands as they become operational, for the present the technology is stretched about as far as it can be consistent with the development of a timely and cost effective device. We will continue to address the compromises in the search for more performance, no doubt pushed by user demands.
Acknowledgment
The authors thank their colleagues at Integrated Navigation Systems and Spirent UK for support and access to design and user information.
Manufacturer
This article describes the GSS6425 from Spirent Communication.
Steve Hickling obtained his joint physics and electronics degree from the University of Birmingham. He is responsible for Spirent’s GNSS test solutions as lead product manager in the positioning business.
Tony Haddrell obtained his degree in physics at Imperial College, London, and is technical director at integrated Navigation Systems. He is a consultant to GNSS companies and a visiting lecturer at Nottingham University.
