Testing Multi-GNSS Equipment

For the complete story, including figures, graphs, and images, please download the PDF of the article, above.

Testing procedures comprise an important element in the development, manufacturing, and integration of GNSS devices. Essentially, everybody involved in GNSS will be involved in or affected by testing at one time or another.

For the complete story, including figures, graphs, and images, please download the PDF of the article, above.

Testing procedures comprise an important element in the development, manufacturing, and integration of GNSS devices. Essentially, everybody involved in GNSS will be involved in or affected by testing at one time or another.

Naturally, when we talk about test procedures, we think of an engineer or scientist developing or validating a new GNSS device. But even a consumer who walks out of a shop with a new GNSS unit can be viewed as being involved in a test. He or she switches on the unit and sees if it works. That is the test.

A conference attendant browsing at an exhibition approaches a booth and asks the exhibitor for a demonstration of his GNSS device. The exhibitor is performing a test.

Up until now, most common tests have been tailored for GPS, but the need to consider multi-GNSS testing is becoming more and more important. The next three GLONASS satellites are planned to be launched in August. This launch should complete the GLONASS constellation, and Russia’s GNSS will have reached its full operational capability. Europe’s Galileo and China’s Compass/Beidou-2 are on the horizon. Consequently, market demand is increasing for equipment that supports multiple GNSS technologies.

How does the involvement of a second or third GNSS affect testing procedures? In other words, how are multi-GNSS tests different from GPS-only tests, and are they necessary? Can GPS testing procedures and test equipment still suffice for multi-GNSS testing?

This article, the first of two parts, will look at the professional test procedures that appear throughout a GNSS receiver’s life cycle. The second part will look at various simulator designs, specification requirements for various tests involving multiple GNSSes, and whether a specific simulator design is suitable for a particular test.

As we will see, not only do the tests for individual specification parameters vary, but even the definitions of those parameter can differ.

Why Use Simulators?
Quite often live signals from the satellites are used for testing GNSS devices. However, this approach has limitations due to the difficulty in anticipating and controlling the manifestation of the signals as well as the inability to repeat the signal environment. For these reasons, in many situations the preferred tool for GNSS device testing is a GNSS simulator.

In the activities described in this article, we used a simulation system that provides up to 36 channels of combined GPS, GLONASS, and Galileo L1 with the option to enable one, two, or three constellations. We also used a single-channel simulator that can generate a single, combined GPS/SBAS, GLONASS, and Galileo signal to enable testing of GPS only or multi-GNSS devices in a production environment.

A multi-channel simulator provides a system-level environment incorporating multiple parameters into the simulated scenario. Single-channel simulators allow the optimization of the receiver’s tracking and acquisition loops, rather than whole system. The latter type allows more control over specific parameters such as a Doppler profile. In contrast, a multi-channel simulator incorporates such variables as satellite motion, vehicle dynamics, and clock parameters and generally cannot be configured to fit a specific profile.

Simulators provide a universal, high-level capability to cover the necessary tests from design to manufacturing of GNSS equipment. Moreover, their use allows us to exclude most of the other testing equipment that might otherwise be necessary.

As our primary test subject device, we used a software real-time receiver developed by the first author, which enabled us to conduct most of the tests and, at the same time, obtain the extensive visualization and flexibility needed for research purposes. The software receiver operates on a personal computer with a range of performance capabilities depending on the PC processor. Figure 1 (above, right) shows a test-bench setup in our office.

Receiver Life Cycle
Within this article we look at the professional test applications throughout a receiver life cycle. For our purposes, then, we can describe the receiver life cycle as passing through the following stages:
1)     research and development in which new algorithms and solutions emerge
2)    design and validation where specific receiver designs are created and compared with a benchmark design or given specification
3)     hierarchical element production, which encompasses the sequential production of chip, module, OEM, and user device, with each sub-stage requiring particular tests of the device’s input and output
4)     consumer testing and certification
5)     repair and maintenance.

We will consider here only the tests that are specific to GNSS and omit those of a more general nature for consumer electronic products, such as tests for electromagnetic compatibility (EMC), space applications, such as tests for radiation tolerance, and so on.

The issues of test generalization and standardization become more pressing as GLONASS expands from use only in high-end geodetic applications to adoption by mass markets such as fleet tracking and cellular phones.

Meanwhile, Galileo and Compass are expected to come on-line very soon. The Galileo R&D and design stages are already well under way.

This situation leads us to address the question: Do GLONASS, Galileo, Compass, and a modernized GPS require any modifications in our test procedures and /or perceptions? The authors believe that they do.

Going forward, the need for these modifications arises first from the fact that these systems are different from today’s GPS, where most of our experience lies, and secondly from the multi-system nature of the devices that will be tested. Therefore, our tests perceptions should account for variations in different GNSSes and for the use of GNSSes in combination — not as a sum of separate systems, but as an integrated system.

Let us look at these stages in detail.

Receiver Design Concepts and Their Effect on Test Procedures
Before delving more deeply into test procedures and strategies, we should review the basic functions within a GNSS receiver …

Channel tracking produces code phase, carrier phase, Doppler and signal-to-noise-ratio (SNR) measurements. The navigation message decoding function deciphers the satellite signal’s data content. PVT (position, velocity, time) represents the calculation of those values for the receiver. The user interface communicates with the receiver operator by means of anything from a serial data stream to a full map display. All these components should be tested.

. . .

R&D Design
The R&D stage covers two distinctive sub-areas: basic, which includes fundamental tests requiring a valid reference signal, reference truth data, and repeatability; and advanced, which simulates (with repeatability) situations that are seldom possible or impossible to achieve under the normal circumstances, and also activities that facilitate niche, high-end applications.

. . .

Coordinate Systems & Error Models
At this stage the benefit of multi-GNSS for testing is rather clear. One needs to ensure that a receiver can properly integrate multi-GNSS coordinate systems (including various associated time frames) and error budget models.

As we discussed earlier, the various GNSS systems’ coordinate frames seem to be fairly well integrated already, and nothing is required in this sense for a standard receiver. The time frames however are unlikely to be coordinated well enough, not only because they differ, but they are also calculated in a different way — either as an assembly of clocks or a master clock.

Another issue to consider for multi-GNSS design and testing is the underlying error models. An ionospheric model is of particular importance. For example, GPS uses the Klobuchar model, and Galileo uses the NeQuick model.

. . .

Some Common Tests
We will look at some common tests here, because it all starts at the R&D stage. Most of these tests are also required in further stages, but regardless of the results obtained during R&D, they are not going to be any better later in the development process. Probably the only exception is power consumption.

A TTFF test is required to define this parameter under various receiver start-up modes. Normally those are specified as “Hot,” “Warm,” and “Cold” starts. The definitions of start-up modes, however, are not standardized and depend on the technology implemented in the specific receiver. Sometimes they are defined by the information content available in a receiver, but other times they are understood in terms of a period of receiver inactivity.

In our case, we were particularly interested in our software receiver’s BGPS instant positioning testing. We are measuring TTFF under the conditions when the receiver has a set of predicted ephemeris and time with accuracy of one or a few seconds.

. . .

Development and Validation
Validation tests may actually be required at each design/development stage as proof of a job well done. They may include any or all imaginable tests, depending on the stage and specification.

Some parameters are not normally in a specification of a standard receiver, but rather apply to a receiver’s front end. We mention them here because, as far as receiver testing is concerned, they should be checked as part of component validation tests. These parameters may include the local oscillator’s phase noise limits, required noise figure, second- and third-order intermodulation, filtering characteristics, and so forth.

One example of the validation tests comes in the chip development cycle. Because the chip development requires a large amount of initial investment and it is impossible to change the design once completed, more elaborate performance validation tests are required using an FPGA prototype.

. . .

A Production Pyramid
We now should look at the production stage of receiver development. For mass-production devices (and actually for some high-end equipment as well), this may include the manufacturing of a multi-GNSS chip. Such chips are produced in volume and go to various modules manufactures.

In turn, the modules, being produced in lesser volume by more manufacturers, pass along to the OEM manufacturers. The hierarchy pyramid keeps narrowing as the complexity of the receiver form factor increases and eventually reach a system integrator and then the end users as a finished product.

. . .

Why Not a Ring-Up Test?
From a practical point of view, it would be most convenient just to “ring up” the circuits with a sine wave to test them. Unfortunately, many potential problems can go undetected with that approach. In fact, ring-up tests cannot even properly ensure that antenna connections are sound.

Some technical issues, such as those related to soldering, wiring, soldering material, impedance mismatch, and so forth, can cause extra signal losses. Such losses in RF may go undetected with ring-up tests but still cause severe degradation in receiver parameters or even equipment failure.

. . .

Multi-GNSS Test Specifics
A very important question for the designing of the final product test is: Will GPS-only testing serve for multi-GNSS devices?

First of all, a multi-GNSS receiver would also require a final test that included the specifics of each GNSS. Could a proper GPS-only test ensure a proper operation of GLONASS or Galileo components? The answer to that is no. The hardware components for each system may significantly differ starting from the RF part.

. . .

Consumer Testing and Certification
End-user products of today and tomorrow not only combine various GNSSes, but their manufacturers also aim to market them in many countries worldwide, because applications are now global and truly international. So, when multi-GNSS equipment comes to a local market, the issue of local certification may become crucial for success there.

Of course, various special niche markets, such as those for safety-of-life applications, and associated professional services also generally require certification — for example, a pre-flight test of an airborne receiver in an aircraft hangar using retransmitted GNSS signals or simulator.

Certification is and will be even more important for the equipment that must be endorsed for federally controlled applications, such as aviation, public fleet management, and E911 type of services for mobile phone users.

Both the multi-GNSS products and the equipment used to test them must be certified. Standard certification equipment includes:

• multi-channel high end simulator such as we used in our tests
• geodetic reference point
• multi-GNSS high-end reference receiver
• timing receiver.

Conclusion
Adjustments to test procedures at all stages are required when testing multi-GNSS equipment. The article has examined the some of the differences among GNSS systems that require separate test procedures and how simulators can facilitate this process.

We have also discussed the various phases of equipment manufacturing and the need for testing at various levels of the production pyramid. In the next article we will look at various simulator designs, specification requirements for different types of equipment tests, and whether a specific simulator design is suitable for a particular test.

For the complete story, including figures, graphs, and images, please download the PDF of the article, above.

Acknowledgement
The first author would like to thank Andrew Addy, Asia Pacific director of sales for Spirent Positioning products, for his assistance in designing the BGPS dynamic test described in this article, and for introducing the author to a fascinating field of GNSS simulation in 1998 during user seminars. The first author also would like to acknowledge Dr. Richard Langley, Department of Geodesy and Geomatics Engineering at the University of New Brunswick, for introducing a “cool start” name for the type of start used in BGPS.