Co-Authored by Willy Negrete, InHand Director of Quality Assurance/Test 

Portable devices that incorporate a Global Positioning System (GPS) have become a mainstay feature in most modern, handheld devices. While GPSs are a great feature, they can be tough to design-in to devices and they are equally as tough to test in a cost-effective and robust way.

Problems with Testing GPS

GPS is a weak signal under strict control from the FCC, creating a challenge for the original design-in as well as test. The signal will seldom appreciably propagate into a structure without direct line of sight (LOS) to the sky. Further, powering up a GPS device from a “cold start” to a satellite lock can typically take between 1.5 to 3.5 minutes or more even with a good unobstructed signal and fast-locking electronics. From a production test standpoint, these two traits directly contradict traditional robust, economical production test, where manufacturing facilities are typically contained within large buildings with steel walls/roofs with total test time goals of under one minute/device.

Because end-to-end GPS testing can be difficult to implement, many location-based products are manufactured without complete testing and something less than the Holy Grail (satellite lock) of testing is typically implemented. Since it is fairly easy to communicate with the GPS chipset independent of the radio frequency (RF) signal, some manufacturers may just test this link, but not actually receive or verify the satellite feed. Unfortunately, while this tests a basic element of the functionality, it does not test the most crucial: end-to-end verification of valid location and timing data through the antenna.

A further testing challenge is that this is typically the area where there will be a GPS failure, as the antenna is usually located at the board edge and is relatively heavy and exposed compared to the rest of the electronics. For products without an integrated antenna, this may be sufficient to cover the vast majority of assembly/manufacturing problems, but for products with an internal antenna, such an approach leaves a significant element of the operation untested. When doing final packaging, it can be fairly easy to jar the antenna and break this sensitive RF feed, meaning a problem isn’t found until fielded.

To ensure it is not the customer who discovers the problem, testing the GPS NMEA data stream through the antenna of a packaged device is necessary. So the question is, what is the best way to do this in a production environment?


One solution is to use a GPS repeater or re-radiator to rebroadcast the satellite-based signal into the manufacturing building. The typical use case for such devices are airplane hangers (or similar large structures) requiring a real GPS signal for location or time-base information, but are blocked directly from the satellites. In this use case, a technician may test out the navigation system (crucial to the aircraft’s operation) without having to leave the hangar.

For the purposes of a production use case for a GPS-based product, however, using such a device can solve the problem of getting the signal to the production floor, but does not rid it of variable data, as the satellite data changes moment-by-moment. Further, this means that you need to go through a cold restart process for acquisition to verify lock and this process can take up to 3.5 minutes, depending on satellite number, location, and LOS access. The roof access at most contract manufacturers (CMs) is obscured in some directions, so piping down a signal in some satellite configurations, would reduce the number of satellites the device could see and increase lock time. Further, as the situation is dynamic, it is a more complex determination to compare apples-to-apples reception at any arbitrary time of day. This is especially true when trying to implement automated test and provide consistent thresholds and/or criteria to establish for pass/fail purposes. Such a solution is a good next step, but re-radiators suffer from the shortfalls summarized above.

GPS Simulator
The best way to get a repeatable, consistent broadcast of known information, content, and power over specific channels is through a GPS simulator. Use of a GPS simulator allows creating a simple analysis routine to determine if there are any issues with the connection. Virtually all GPS simulators employ remote and programmable control and operation over common interfaces (Ethernet, USB, etc.), so these fit well with automated testing. Most simulators also offer common drivers/API’s, so Labiew, C#, etc., can be used for automation control. The feature set on GPS simulators varies, and the price can range from $5k to $50k+; but for the purpose of production testing, the lowest-end products work well. There is no need to set up profiles, time-base precision, satellite lock, etc., as production floor testing is designed to simply validate the hardware and assembly (defects in material and workmanship). This can be done in a very clean and rapid fashion using a simulator.

Most GPS assembly failures occur in the RF feed path, so a simulator can test for this by generating a pre-designated signal with known location/timing information and signal strength. This allows for a very fast verification/test time. Signal strength and time-to-lock could be easily added to the PASS criteria so any anomalous feeds could be picked up in the case of marginal performance. It is also the best way to incorporate testing of other GNSS signals, such as GLONASS.

A valid production test environment does not require real data, but does require consistent data. A simulator provides this, and also adds an element of test portability. Once divorced from the need to acquire actual satellite signals, use of a simulator allows the production test to be moved within a facility – or to a different facility with relative ease.

Pros aside, use of a simulator does have its own challenges apart from the investment in the equipment. For example, broadcasting on the GNSS frequencies are some of the most protected spectrum on the planet, so doing so requires licensing and official permission from the FCC. Fortunately, this process not particularly onerous (although it can take several weeks). Filing a form is required, including specifics, such as the general layout and use case, plus you’ll need to prove (analytically is acceptable) that the RF signal generated will not cause interference outside of the facility. Licenses (whose thresholds are strictly maintained) are good for two years and are renewable, so maintenance is easy.

Then, once the instrumentation and licensing is in place, the final step is the writing the application code and automating the test. A test infrastructure will have to be designed to look for and use the simulated data in the proper way, to maximize throughput and provide the best production solution.

In our test case, the GPS testing consists of a multithreading C# application interfacing with several UUTs simultaneously. The test application communicates to the GPS Signal Simulator (single channel GPS signal simulator) via Ethernet to configure the GPS simulator output to a known RF power level. The application retrieves and parses the NMEA messages from each serial port on each UUT in order to obtained the SNR value (Signal to Noise Ratio). This parameter in the NMEA standard is often referred to as signal strength. This value is an indirect but more useful value that raw signal strength. It can range from 0 to 99 and has units of dB according to the NMEA standard. The range of working values in a given gps will usually show a difference of between the lowest and highest values. This SNR parameter is obtained by parsing the NMEA interpreted sentence $GPGSV. An example of this sentence is:


By.reading this value the test application validates if the SNR value is in the predefined good SNR range and generates PASS/FAIL result. This test methodology help us to find assembly/manufacturing issues in the RF path (broken lines, missing components, missing cables).