Foreflight flight plan with procedure import to Garmin GPS

[Larry Erdman]

I have recently upgraded my 1981 Cessna R172K with a Garmin GPS 175. I'm able to stream simple flight plans from the GPS to Foreflight without a problem. But, if I add an approach and then try to stream it, it gets imported with an error regardless of the direction. i.e. KPAN VPGCF VPGCG KKNB imports fine from FF to GPS but if I add a standard FAA approach such as the RNAV (GPS) RWY 01 with an in IAF of DEDKE in FF and then try to send it to the GPS, it doesn't recognize the procedure. And, if I simply add the same FAA approach (RNAV (GPS) RWY 01 with an in IAF of DEDKE) in the GPS and send it to FF, it imports with an error as well.

Any help? I have a request into Garmin who shows no issue with Garmin Pilot & Garmin GPS and is looking for someone internal who has FF to test the issue I'm experiencing.

 

[Jon Wilder]

Traffic and weather stream in real time. Flight plans do not. You're just sending your point to point flight plan to the navigator unit.

The approach has to be selected directly on the navigator. Once you select it on the navigator, load approach, then activate, Foreflight should pick up the change and ask if you want to load the new plan from the panel (assuming you have the "Auto-Receive Panel Flight Plans" option in Foreflight selected).

 

[Larry Erdman]

Actually, the procedures should transfer both ways. Here is what Foreflight has told me …

Jason here. Thank you for flying with Foreflight. What you are experiencing is a known issue with some Garmin equipment that is using Garmin nav data instead of Jeppesen nav data. There are discrepancies between the two data sets on some procedures that can cause the errors you are seeing. ForeFlight uses the Jeppesen navigation data. We do not have a good workaround to offer at this time.

Regards,
Jason P.

 

[robin ardoin]

I encounter the same behavior but I don't mind. I prefer to choose the approach directly on the navigator so, under 'live fire', I can hit a button or two to accommodate any last minute changes. When I select the approach directly on the navigator, I am not relying on a BT connection nor worrying about any corruption of the data transfer at a time that I need to focus on flying the plane.

 

[midlifeflyer]

I encounter the same behavior but I don't mind. I prefer to choose the approach directly on the navigator so, under 'live fire', I can hit a button or two to accommodate any last minute changes. When I select the approach directly on the navigator, I am not relying on a BT connection nor worrying about any corruption of the data transfer at a time that I need to focus on flying the plane.

I've done it both ways but I also prefer to load approaches on the panel FMS (mostly out of habit). But I don't really see the problem you describe. When it works properly, it's not being loaded as a series of waypoints - which would be improper - but as a package telling the FMS to load the approach with whatever transition selected.

In terms of "live fire," for me, initial briefing and loading an approach is a process that takes place in a low workload environment, pretty much as soon as I know what approach to expect. The very latest is when ATC advises which approach to expect in the case of a towered airport with multiple runways. Otherwise, it won't be later than when I can hear the current ATIS or AWOS, and it may be as early as on the ground before departure. Can't get much lower workload than that!

And it's not all or nothing. Once the approach is in the FMS, nothing prevents you from changing it there. Regardless of how or when loaded, any last minute changes are in the FMS. Going back to an EFB to change from a published transition to an activated intermediate segment, remove or bypass a procedure turn when cleared straight in, or insert a HILO because there's someone ahead of me on an approach, just seems extremely inefficient.

 

[Jon Wilder]

Actually, the procedures should transfer both ways. Here is what Foreflight has told me …

Jason here. Thank you for flying with Foreflight. What you are experiencing is a known issue with some Garmin equipment that is using Garmin nav data instead of Jeppesen nav data. There are discrepancies between the two data sets on some procedures that can cause the errors you are seeing. ForeFlight uses the Jeppesen navigation data. We do not have a good workaround to offer at this time.

Regards,
Jason P.

So I guess the solution would be to cancel your flyGarmin database subscription and use Jepp as your database provider.

 

[midlifeflyer]

So I guess the solution would be to cancel your flyGarmin database subscription and use Jepp as your database provider.

Or load approaches in the FMS.

 

[Jon Wilder]

Or load approaches in the FMS.

I meant if he was dead set on having the procedure import feature work.

 

[Larry Erdman]

So I guess the solution would be to cancel your flyGarmin database subscription and use Jepp as your database provider.

I asked ForeFlight that and this was the response.

Larry,

There are some procedures that are affected by the differences between Garmin Navdata and Jeppesen Navdata, but the specific one you identified should not be one of them. We tried that route and procedure in our Lab using a GNX375, also at the same software version 3.22 and using Garmin Navdata, and it transferred without error. I also tried it on my GTN750Xi I have installed in my Bonanza where I use Garmin Navdata, and it worked as well, in both directions.

I do believe you will find using Jeppesen Navdata will work better in some instances with ForeFlight, because ForeFlight uses Jeppesen Navdata. However, this does not explain why the procedure you were having difficulty with did not work.

 

[John Collins]

There was a Garmin bug which I believe has since been resolved that had the following characteristic. If an approach procedure had an IAF that was also connected to a feeder route, only the fix on the feeder route would be accepted when a send to panel was used. IOW, in your case, a send to panel of [KACIR RNAV (GPS) RWY 1] [KKNB] would work, but [DEDKE RNAV (GPS) RWY 1] [KKNB] would fail. DEDKE is an IAF and KACIR is a fix for a feeder route that connects to DEDKE. If one loaded the approach on the panel selecting DEDKE and downloaded it to FF, it would transfer as KACIR and not as DEDKE, in spite of the panel device clearly having DEDKE selected. This bug existed in the GNS530W until it was fixed in the final software update version 5.40. The same bug existed in early GTN systems, but was fixed sooner than the GNS530W. It is remotely possible that the software bug exists in other devices and this can be easily tested. If the bug exists in your GPS175, it would accept a transfer if the approach was joined at KACIR and fail if it was joined at DEDKE. Note that I reported the bug to Garmin on the GNS530W, which is what I had installed at the time.

 

[Larry Erdman]

There was a Garmin bug which I believe has since been resolved that had the following characteristic. If an approach procedure had an IAF that was also connected to a feeder route, only the fix on the feeder route would be accepted when a send to panel was used. IOW, in your case, a send to panel of [KACIR RNAV (GPS) RWY 1] [KKNB] would work, but [DEDKE RNAV (GPS) RWY 1] [KKNB] would fail. DEDKE is an IAF and KACIR is a fix for a feeder route that connects to DEDKE. If one loaded the approach on the panel selecting DEDKE and downloaded it to FF, it would transfer as KACIR and not as DEDKE, in spite of the panel device clearly having DEDKE selected. This bug existed in the GNS530W until it was fixed in the final software update version 5.40. The same bug existed in early GTN systems, but was fixed sooner than the GNS530W. It is remotely possible that the software bug exists in other devices and this can be easily tested. If the bug exists in your GPS175, it would accept a transfer if the approach was joined at KACIR and fail if it was joined at DEDKE. Note that I reported the bug to Garmin on the GNS530W, which is what I had installed at the time.

John, I think I've heard of that before but I don't think this is the issue. FF team said they are able to recreate my import/export using the supplied procedure without a problem using a GNX375 and GTN750Xi (see below) so I don't know if this is specific to a GPS175 or my specific system/database. I tried the import again using different IAFs and even RVs but no luck.

There are some procedures that are affected by the differences between Garmin Navdata and Jeppesen Navdata, but the specific one you identified should not be one of them. We tried that route and procedure in our Lab using a GNX375, also at the same software version 3.22 and using Garmin Navdata, and it transferred without error. I also tried it on my GTN750Xi I have installed in my Bonanza where I use Garmin Navdata, and it worked as well, in both directions.