GPS Database Issues (TP 2228E-30)

Safety Promotion & Education

One of the facts of current life is that old computers and new software that gobbles up gigabytes of disk space and memory do not mix very well. The same problem exists when large databases are crammed into early-generation GPS receivers that have limited memory space. Navigation databases are continually growing, and in some cases can exceed the storage capacity of certain legacy receivers. This can seriously affect the operation of GPS receivers, and in some instances, it already has. The following three examples show what can happen, usually at a most inconvenient time of the flight.

Spring 2003

In order to fit a new database into the Trimble receiver, the database provider inadvertently created a geographical region, extending from 40°N to 48°N and 65.5°W to 76.5°W, within which the receiver would cease to function, resulting in a loss of GPS guidance.

Summer 2005

Waypoints beginning with the letter “Z” were unintentionally omitted from the database. When one of these was part of an approach procedure, the receiver assigned a position of 0°N and 0°W to the missing waypoint, without any warning to the pilot. Once the issue was brought to the attention of the database provider, an acceptable database was promptly promulgated to the users.

Fall 2005

LPV (WAAS) [lateral precision, vertical guidance (wide area augmentation system)] approaches are now being coded and introduced into navigation databases. In one case, there were two area navigation (RNAV) approaches published to a single runway end—one lateral navigation (LNAV), the other LPV. To conserve memory, only the LPV procedure was coded, and this was the only approach offered. Unfortunately, the receiver had not been upgraded to WAAS, so the only approach that was available to the pilot was the one that he could not legally fly.

The relationship and compatibility of the avionics and its database is checked during initial certification; however, there is relatively little regulatory oversight of database updates. Pre-flight verification of all required procedures (and those that can be employed legally) for the flight is the only certain way to avoid being “trapped” by a database error during a critical stage of the flight. Pilots can minimize the risk of a database error during a critical stage of a flight by a pre-flight verification that all approaches that could conceivably be required are in the database, can be loaded successfully, and are correct. The correctness of the data may be checked by loading the approach and comparing the track and distance of each leg with the paper chart.

This may increase the time required to prepare for a flight, but if it prevents just one nasty surprise, it will be worth it.