In this case, things weren’t exactly as they seemed, and a little more detail is required, and it brought up a very interesting question. What if your GPS data is not depicting correctly.
If you look at the first picture to the right, you can see a track (from a screen shot I took on my iPad with my charting software) that shows us approaching the KBTL Class D airspace ring. On a practical test, I will always stop an applicant from “getting us in trouble” and doing something such as breaking airspace. You can see our track on the screen shot was taking us very close to the KBTL airport.
In this case, we were navigating visually (not using the GPS to get to a point west of KBTL that is used as a common entry point to the airspace (a gate – high density training environment) and staying a little further north than we normally might to avoid some rain showers that were in the area. As we approached the area, I got a bit more sensitive to the proximity to the airspace as the applicant visually navigated using a chart and referenced the ground. I did the same, but also had my charting application running and shot this screen shot as we got closer to the airport.
At this point, I started to reference the DME indications in the panel relative to the KBTL airport. As most pilots will remember, a Class D airport typically has airspace that extends to 4.4 nautical miles from the center of the airport. So, when we saw the DME drop from 4.7, to 4.5, and then to 3.9, we had a problem. Especially because we had not communicated with the tower yet.
Now, I will admit the applicant was not monitoring the DME point, they were referencing the ground points on the chart. In most cases, I would never have let the DME get below the 4.4 before issuing the notice of disapproval and stopping the applicant from entering the airspace without communicating with the tower. But in this case, some things were not quite adding up.
You can see, if you look closely, that the DME indication on the panel (and I have blown up piece of it below here, indicates that the aircraft was 3.9 miles from the KBTL airport (there was a previous point also listed as a destination in the FMS from when we started the practical testing as the point from the applicant’s cross country.
The problem is that when the DME was reading 3.9 miles, my application on my iPad was showing a different ships position on the sectional. And what we saw on that actually matched what was below us on the ground (back to that pilotage and dead reckoning stuff). You can see the ships position in the image to the right at the time in the lower left of the image.
Now, the applicant did come pretty close to the KBTL airspace without communicating on their way to the gate they were using to approach the airport, but they didn’t break it so there really was nothing there to issue a disapproval based on (although we did have a discussion about how close to airspace is prudent to travel without communication in the debrief). But it did bring up an issue.
Was the GPS accurate?
We continued and eventually got an indication on the DME that we were 0.0 DME from the KBTL airport as you can see in the image below (the DME is in the upper left if you aren’t familiar with this page depiction). Unfortunately, the 0.0 DME from KBTL didn’t happen to be over the airport. Uh, oh.
As you can see from the map, the ships position on the IFD in the aircraft showed us about 8 miles to the west of KBTL (and that matched what we saw outside the window on the ground).
We continued to monitor (play with the system) to see what else we could come up with on why the performance issue was happening. I tried another waypoint, the Battle Creek VOR (which is out of service, but the GPS point is still designated in the system). The system indicated that we were 18 miles from the BTL VOR to the east. Hmmm…this definitely wasn’t the case either. The BTL VOR and the KBTL airport are co-located.
I reloaded a “direct-to” the KBTL airport and it said we were 0.0 from the airport. As we flew visually toward the airport the DME counted up to 2.3 then back down to 0.0 by the time we got to the airport. I thought maybe the system had corrected. But then when we executed the first landing and then take back off, the DME never left 0.0 as we flew a traffic pattern. Another hmmmm….
So, the aircraft got downed for maintenance at the end of the flight.
Now, the discussion point this drove is that what the data depicted is not matching what is actually happening. And a more scary question, what if you are IFR and can’t cross-check what it is depicting with what you see on the ground. I can imagine how dangerous having a system depict a position roughly 8 miles away from where it actually is could be. Fatal comes to mind.
While some of you may recognize the particular avionics system that is depicted, I would like to avoid any discussion of a particular manufacturer of avionics systems. Instead, I think we need to have a discussion about what we can do to cross-check our GPS based data systems to ensure we are accurately seeing information for our intended route(s) of flight.
If we are IFR, visual checking of the points is not an option. If the ship’s position on the map is not matching what we are seeing on a CDI or on depicted DME data, what do we do? In this case, the aircraft had dual ADHRS and GPS systems, but no faults were being indicated for any mis-compare of data.
I don’t really have a great answer yet. Obviously, there will be a discussion with this manufacturer about this particular instance, but on the broader sense, if we think there is a problem, our options become limited.
One option might be to query ATC for radar position verification if you can identify that a problem exists.
As we have transitioned from a primarily analog set of instruments in our aircraft to digital devices that are software driven, like any other software (think our computers), they may experience software glitches that make them perform incorrectly. There are software updates that are released and should be applied. Things like this glitch are the reason that it is important to make sure as aircraft owners that we apply any software updates. However, every update also introduces the potential for new errors in any updates also, so it is prudent to watch carefully how all systems are performing.
I guess another option is always the iPad or a portable GPS device. Although I hate to start thinking my non-approved IFR instrument, the iPad, is my primary backup device for on-board aircraft equipment.
I would enjoy knowing what find as the cause of this problem.
As would I!….I will definitely let you know if I get more info Jack.
Pingback: Ok, so the GPS Was Doing What it was “Supposed” to Do, Just Not What I “Would Want” it To Do |