ForeFlight NavLog is kicking out wrong leg times

woodchucker

Pattern Altitude
Joined
Sep 20, 2014
Messages
1,840
Display Name

Display name:
woodchucker
Kind of strange thing here. I've got TAS set at 105, and the NavLog is performing calculations as if the GS is 85, with calm winds aloft being reported in NavLog.

Now, when I go to the airport and look at winds aloft, they are being given as 8 kts out of the north, which would add a tailwind for a trip to the south, therefore adding to the GS, not subtracting.

What am I missing here? Feel free to call me an idiot if I'm missing something fundamentally important. I'm at work right now and my brain is a bit frazzled.

Note: I also used the ruler tool in the Map screen for the same leg, and it does calculate the leg time correctly (I'm not sure if they incorporate current winds in that though).
 
Why don't you post the route so we can enter it for comparison.
 
Drop a line to foreflight support.
 
The leg I'm specifically looking at is KBTF --> VPPTM. Altitude is 10500.

I don't want to go to ForeFlight unless it's an actual problem on their end, and not a malfunction on my end.

One other thing, I have the ETD set at 12:30 pm local tomorrow.
 
No, because other legs have the same error. So far as I know, foreflight does not incorporate climb and descent portfolios.
 
I've had it do that a few times ETA all out of whack.it usually happens when I modify a route in-route. Had to close out the flight and reenter it before it would start calculating correctly.
 
There is most definitely some weirdness going on there. It doesn't like 10,500'. It calculates a 16 minute leg, winds aloft calm. If I reverse the route, it calculates (correctly) a 14 minute leg and says "route too short for 10,500."
 
I've had it do that a few times ETA all out of whack.it usually happens when I modify a route in-route. Had to close out the flight and reenter it before it would start calculating correctly.

I'll try that when I get home.
 
flying over area 51? ;);)
 
Woodchucker,

Go to More->Aircraft and tap the little circled i next to the airplane that is checked as the default. Scroll down to the Climb Performance and Cruise Performance sections. What is listed there?
 
This. Give them a chance to explain it. Let us know.

Yep, I'm fixing to do that.

The odd discrepancies occur on the beginning and ending legs.

Outbound: KBTF --> VPPTM 19 minutes
Inbound: VPPTM --> KBTF 14 minutes

Inbound: CDC --> KSGU 28 minutes
Outbound: KSGU --> CDC 35 minutes

Both trips are 2 hrs 26 minutes TT.

Do you guys think that ForeFlight actually is throwing in fudge factors for TOC?
 
Woodchucker,

Go to More->Aircraft and tap the little circled i next to the airplane that is checked as the default. Scroll down to the Climb Performance and Cruise Performance sections. What is listed there?

Oh, totally forgot about that. I left the climb and descent information blank, cruise is 105 (when going downhill with the wind behind me and the sails up).

Do you think that has any effect on how ForeFlight is handling the calculations?
 
Do you think that has any effect on how ForeFlight is handling the calculations?

I believe so. I believe they take into account the climb and descent performance to give a better time(added a few updates back). But leaving blank I wouldn't think would cause issues. plug in some numbers and see what happens.
 
Yep, I'm fixing to do that.

The odd discrepancies occur on the beginning and ending legs.

Outbound: KBTF --> VPPTM 19 minutes
Inbound: VPPTM --> KBTF 14 minutes

Inbound: CDC --> KSGU 28 minutes
Outbound: KSGU --> CDC 35 minutes

Both trips are 2 hrs 26 minutes TT.

Do you guys think that ForeFlight actually is throwing in fudge factors for TOC?

Oh, totally forgot about that. I left the climb and descent information blank, cruise is 105 (when going downhill with the wind behind me and the sails up).

Do you think that has any effect on how ForeFlight is handling the calculations?

I think ForeFlight is assuming a lower number for climb because you haven't entered them.

I say this because, when I entered a test aircraft with a cruise speed of 105 and no information in the climb and descent performance parameters, I get the same results you do - More time on the first leg in each direction. However, when I added 105 to both the climb and descent performance on the airplane, I get 28 min for KSGU-CDC and 14 min for KBTF-VPPTM in both directions.

But, since you should have real performance info, you might as well fill out the rest of the aircraft section and get even more accurate numbers. :thumbsup:
 
The leg I'm specifically looking at is KBTF --> VPPTM. Altitude is 10500.

I don't want to go to ForeFlight unless it's an actual problem on their end, and not a malfunction on my end.

One other thing, I have the ETD set at 12:30 pm local tomorrow.


Don't hesitate to contact Foreflight Support. I spent the prime of my career working for software companies. Part of that time was providing tech support and supervising the tech support group. So, I know great tech support when I see it and Foreflight DOES have great tech support.

I am quite certain that I am correct when I say that they very much want to hear your question.
 
Okay Scott, thank you for your responses! I've been using ForeFlight for over a year and just learned a few things about it!
 
Yes, it does. At ForeFlight we do make some assumptions when you don't enter the climb and descent profiles. However, we don't publish what we are using to make those calculations. But it's reasonable to assume we are using values that are very representative of most aircraft as it relates to the fuel burn and TAS entered.

Speaking as a systems engineer for operational software (including a special-purpose flight planner), you don't want to hide the basic inputs going into the calculation from the user. If you say "TAS=130" and the user hasn't inputted anything else, you should either use that, or better, expose the climb and descent TAS with "TAS=90/130/140."

Otherwise, you're overriding what the user told you to do, without any feedback that you've done so. Not appropriate for mission critical software.

While "customer service" might be good for Foreflight, I don't see evidence that systems engineering is responsive. For instance, the app really really really really really needs a timer on the approach plates, and this has been asked for many times.
 
Last edited:
I'm still wondering if the OP has called FF support. I think I've seen documentation on how FF calculates leg times (for example, including winds aloft when available) someplace. I'm not looking it up for this thread, but I think it's documented.
 
Yes, it does. At ForeFlight we do make some assumptions when you don't enter the climb and descent profiles. However, we don't publish what we are using to make those calculations. But it's reasonable to assume we are using values that are very representative of most aircraft as it relates to the fuel burn and TAS entered.

With all due respect, Scott, why would FF not publish or release the default values? Even better, why not make the default visible in the data entry panel?

I can understand why a company might want to use a conservative default value for potential liability reasons, but I really can't understand why there needs to be secrecy about what that conservative default value is. After all, if a pilot is responsible for the data surrounding his/her flight, shouldn't that pilot have access to and knowledge of any and all data that the program is assuming? It really shouldn't be a trade secret, and could have potential to be problematic to both the pilot and FF in the future.

Kudos to the OP for checking into the discrepancy.

All that is just my opinion, of course, and no personal affront is intended.
 
We are not hiding anything and we're not overriding what the user entered. We are using exactly what the user has entered based on the profile or flight plan or whatever information available to the app at the time. I'll repeat...

When in flight we use the actual ground speed (if available) along with the entered fuel burn - that makes the most sense rather than to use some filed/entered TAS. For preflight planning, we will use the fuel burn, TAS and climb and descent profile entered by the user. If they don't enter a climb or descent profile (their choice), then we will make some reasonable assumptions (that we don't happen to publish) about the climb and descent profiles. By the way, we've documented much of this in the Pilot's Guide.

The user has entered only cruise data, and you have overridden that. Furthermore, you've hidden it because there is no indication in the inputs that this is taking place. You're making a distinction between "leaving blank" and "making choices." Leaving a field blank IS a choice. And a reasonable user could assume -- like the OP did -- that the choice is to use other entered data like the cruise TAS.

This is an error. If the user wanted climb data, they would have used climb data. A better interface would be to provide the defaults in the aircraft entry, rather than have them blank.

Your two paragraphs are not consistent. You ARE making choices over the user's.

You need to make a choice as to whether this software is mission critical, like a flight planner should be, or a toy. You do not hide relevant inputs (and "don't happen to publish" is a very precise synonym for "hide") in mission critical software.

The algorithmic choices you've made are reasonable. It's hiding it from the user that's problematic. If it weren't, this thread would not exist.

I figured it out the first time I planned a short flight with a long climb, and I could see the numbers didn't work. But I shouldn't have to figure out what a planning aid is doing. I might have missed that if I were in a hurry, for instance.
 
Last edited:
Speaking as a systems engineer for operational software (including a special-purpose flight planner), you don't want to hide the basic inputs going into the calculation from the user. If you say "TAS=130" and the user hasn't inputted anything else, you should either use that, or better, expose the climb and descent TAS with "TAS=90/130/140."

Otherwise, you're overriding what the user told you to do, without any feedback that you've done so. Not appropriate for mission critical software.

While "customer service" might be good for Foreflight, I don't see evidence that systems engineering is responsive. For instance, the app really really really really really needs a timer on the approach plates, and this has been asked for many times.

I don't know how close you are to the product management side of the software you are involved with, or if you are involved with a system that is sold to multiple end users. Managing and prioritizing the features to correct/improve/add/modify is a constant project in software product development. I personally would, to some degree at least, cut slack for a software companies responses at least to the point where they appear to be completely non responsive to the customers requesting the feature addition or change.

The number of features and improvements that Foreflight has added to their product since I first subscribed almost four years ago seem staggering to me, especially given the limited number of developers involved.

Doing individual systems work, or developing one off systems is a different animal as compared to software applications that have to be all things to all people.
 
Why don't you make that suggestion by sending an e-mail to team@foreflight.com. It will get in the queue (if not already).


Unfortunately, customer feedback is one of those 80/20 kind of things. Only 20% of the customers will offer constructive feedback. I would be willing to bet that there is a product manager at Foreflight that is begging for more customer feedback. Without it, he/she has no way to properly prioritize the ongoing development project choices.
 
Trust me...ForeFlight isn't lacking enough feedback. Nobody is begging here. The challenge is trying to figure out how to implement all of the suggestions and planned features that are on our plate.

That's excellent. In my nitch of the software industry, we did not get as much input as we would have liked. Ours was industrial use, without nearly as many licenses sold as what I would expect that Foreflight enjoys, so that might be the difference.

With lots of feedback, you should have the data that you need in order to prioritize.
 
Back
Top