One of the routes I fly frequently is from my home base in Santa Fe, NM, to the San Francisco Bay Area. Now, the Bay Area isn’t known to be particularly inexpensive for anything, but if you shop around you can find not-completely-unreasonable fuel prices. Most times when I’m going that way, my destination is Bryon, CA, C83, because it consistently has the lowest fuel prices in the area.
In fact, my trips to the Bay Area are frequent and consistent enough that I’ve got a stored route: KSAF-PUMPS-KITTN-KATTS-ECA-C83. And, that’s where the trouble began on my latest trip.
What We Normally Do
For common routes I load the stored route in my EFB, check NOTAMs, brief the weather, check the winds and predicted flight time, then file. I do all that the night before. The morning of the flight, I’ll check weather and NOTAMS again and head to the airport.
At the airport, I’ll pull the airplane out of the hangar, preflight, and hop in. Once inside I get the ATIS and clearance before starting the engines. That morning Tower was still closed—I’m a morning person—so in good VMC, I planned to launch VFR and pick up my clearance in the air from Center. With the engines running, I uploaded the flight plan from Pilot. That’s where the first sign of trouble popped up; my Garmin GTN 650 didn’t like the flight plan from my Garmin Pilot EFB. It was fine last time. What the…
I was already late and in a bit of a hurry. The GTN balked at something to do with the last couple legs, so I just deleted them, leaving KATTS direct C83. Once out of the pattern and on my way, I called Center. There I got the second sign of trouble.
As I’d done many times before, I called. “Good morning, Albuquerque, Twin Cessna three-four-zero November, off Santa Fe. Like to pick up my clearance to Charlie eighty-three.”
“Twin Cessna three-four-zero November, Albuquerque Center. Good morning. Squawk four-five-three-one.”
“Four-five-three-one. Twin Cessna three-four-zero November.”
“Twin Cessna four-zero November, verify full call sign, departure and destination.”
“This isn’t good,” I thought, as I repeated, “November three-four-zero November, departed Santa Fe. Destination, Charlie eighty-three, Byron, California.”
“Sorry. I don’t have your flight plan.” I s’pose it could have been worse. There might have been an overcast restricting my climb below the rising terrain, but fortunately the weather was severe clear, so I continued my climb, putting a VFR 16,500 in the altitude preselector.
Center checked again and still didn’t find the flight plan. Fortunately, they were slow and the controller took pity on me and offered to enter my pop-up flight plan. “Cleared to C83 via direct.”
Yeah, that’s not gonna work either. “Center, there’s special use airspace out there that they never let me go through, so could I add a few en-route fixes?” The controller took pity again and accepted my requested routing fix by fix. I determined that the problem had something to do with the Manteca VOR (ECA) that I’d used since I got my instrument rating out there in the late 90s. So I left ECA off my requested route.
“Cleared as requested. Climb and maintain flight level two-zero-zero.” And, we’re off and running.
What Happened
This isn’t a story specifically about Pilot; it’s more a story about data. This sort of thing could happen elsewhere.
You should know by now that the FAA is dropping VORs left and right. As you’ve probably already guessed, Manteca is one of the VORs that was decommissioned. After getting my clearance sorted out, I looked on the charts at my stored flight plan. Pilot had dutifully placed ECA on the route, but Manteca was nowhere to be found on the charts themselves.
I concluded that Manteca had been decommissioned. However, the nav data provider(s) hadn’t yet removed it from the underlying data. Noting that I’m an editor of a prominent aviation publication, I figured I’d better dig into this further. Perhaps there’s an article here…
Who Provides Your Data?
I started my investigation with a call to Garmin Pilot support. They confirmed that, indeed, ECA wasn’t on the charts, but, yes, it was in the underlying nav data. They took that report, presumably to send it to the database team to fix.
Then, I reached out to my contacts at Garmin and essentially got a confirmation of what I’d already strongly suspected: All data is not created equal.
We pilots are essentially a cheap bunch. Few places illustrate this better than our huge demand for low- or no-cost databases. To meet this demand, Garmin and all the rest source and aggregate no- or low-royalty data to compile the databases found in the lower-cost versions of the non-certified applications, like my basic Garmin Pilot. Some of these sources are better than others at scrubbing the datasets every 28 days, so it is quite possible that a decommissioned VOR could remain in the EFB data set for some time after it should have been removed.
In Garmin’s case, the U.S. data properly removed ECA, but the world data overlay hadn’t. It happens, so they maintain a “blacklist” and apply it to their processing of the composite EFB database. When I reached out to my Garmin contact, because of my call to support, the ECA VOR will be removed from Garmin’s non-certified databases in the next update cycle. (Meanwhile, my inquiry has caused them to modify their process to prevent this problem. I’m told that new process is in place.)
The data used in EFBs might or might not be the same data used in your certified, panel-mount navigators. Those navigators require a fully DO-200A certified navigation database. These are commonly sourced from Jeppesen, but in recent years Garmin has been optionally providing their own. Regardless of the vendor, though, the validation required of the database with every 28-day update requires extensive manual and automated processes that are responsible for a large portion of what we label as the high cost of this data.
As an alternative, some EFB vendors (including Garmin) offer alternative data packages at a price premium. (ForeFlight and FlyQ say they only use DO-200A—soon 200B—data from the start and ECA wasn’t there. Hilton Software’s WingX didn’t respond to my inquiry and ECA remains in their data.)
I also discovered that the issue might lie in the size of your data. If you use U.S. data only, it most often comes from the FAA, so is likely correct. However, with world-wide data, multiple sources might be stitched together, potentially introducing errors like this.
Lesson Learned
I’ll note here that the deleted-fix issue can pop up in different ways. Say your data is perfect, but a fix in your stored route was since deleted. Presumably the system will catch that, but you’ll still have a mismatch. Worse, of course, is if the deleted fix lingers in your nav data.
I’m not going to switch to different data. Instead, I’ve decided to validate the routes myself by newly creating each route using current charts. I’ve realized that although tedious, this will re-familiarize me with the route, perhaps seeing something I’d otherwise miss. So, no more stored routes for me.
It’s worth pointing out that with the FAA accelerating the rate of VOR decommissioning, this is more and more likely to occur. If it does, hopefully you’ll find it at home or at least in good VMC.
Frank Bowlin now recreates each route for each flight. This way he validates the fixes and re-familiarizes himself with the route. Nonetheless, he also whines for better data and lower prices.
Similar problems exist with the EFB redition of TFRs.
Every flight planning package I’ve looked at has a caveat in their meta data that, boild down fro the legalese, reads something like this: “no warrantees expressed or implied”. Often the only way to tell if the EFB rendering is correct is to look at the actial TFR NOTAM, and make your last pre-flight step prior to shutting & latching the cockpit door a voice call to FSS.
Does Garmin Pilot offer ‘flight plan received’ and ‘expected route’ emails like Foreflight does? If so, I think that would have headed off this problem before you were airborne.