"point of no return" calculation

jesse

Touchdown! Greaser!
Joined
Oct 2, 2005
Messages
16,012
Location
...
Display Name

Display name:
Jesse
How would you name a function on a mobile application that helps you determine the point in which it's faster to continue to your destination versus turn around? For example, crossing a major lake.

What would the parameters of that function be?

I'm trying to think of the best way to name and build this into an app I'm making. I know some of you have some excel spreadsheets for this stuff.

I'm not really convinced that "point of no return" is the best name. "point of no return" to me means the point in which you cannot return to your departure airport because you no longer have the fuel remaining to do so.
 
Jesse- for the second part of the question, I's guess the parameters would be air speed, wind speed, wind direction, and the distance between the two points. From that you should be able to determine the "break even" point where the travel times are the same

I'll think about a name and get back to you. I do know what you mean.
 
Critical Point perhaps?

Someone else built such a thing with the following parameters:
Distance
GS out
GS Back
Actual GS

Result:
Critical point in distance
Time to critical point

Those parameters seem kind of crappy. WTF is Actual GS vs GS Out / GS Back?
 
Those of you that have built spreadsheets to do this...what are your parameters and the result(s)?
 
How would you name a function on a mobile application that helps you determine the point in which it's faster to continue to your destination versus turn around? For example, crossing a major lake.

What would the parameters of that function be?

I'm trying to think of the best way to name and build this into an app I'm making. I know some of you have some excel spreadsheets for this stuff.

I'm not really convinced that "point of no return" is the best name. "point of no return" to me means the point in which you cannot return to your departure airport because you no longer have the fuel remaining to do so.

We used ETP (equal time point) in the airline when flying oceanic.
 
I would add two user configurable times, "time to problem recognition to best glide (in seconds)" and "time in landing pattern(?).

It would take ~20-30 seconds to recognize the failure, get your heart back in your chest, do the restart checklist and go to best glide. (Been there. Did that.)

What I have in mind for the second one is time for turning to a final to a decent put down site onshore, in other words, you aren't safe merely by reaching the first grain of sand.
 
What I have in mind for the second one is time for turning to a final to a decent put down site onshore, in other words, you aren't safe merely by reaching the first grain of sand.
I'm not sure how that would matter. The point of the calculation is to determine if you're better off proceeding across or turning around. Yes it'll take some energy to arrange a landing on the shore (if you can even make it) but that's not going to change which direction you should go.
 
I'm not sure how that would matter. The point of the calculation is to determine if you're better off proceeding across or turning around. Yes it'll take some energy to arrange a landing on the shore (if you can even make it) but that's not going to change which direction you should go.

You're right..unless you do add in all kinds of complications for wind direction...we'll just bring along a Cray so we can predict the wind patterns and weather conditions at time of landing. :D
 
Here are the equations for computing an ETP and a point of safe return.

attachment.php


attachment.php
 

Attachments

  • ScreenHunter_01 Aug. 26 18.43.gif
    ScreenHunter_01 Aug. 26 18.43.gif
    28.2 KB · Views: 141
  • ScreenHunter_02 Aug. 26 18.44.gif
    ScreenHunter_02 Aug. 26 18.44.gif
    27.3 KB · Views: 140
Jesse-
Try this:
  • Calculate the ground speed in each direction
  • Multiplier= (Slow GS)/(fast GS + Slow GS)
  • Turn point = (Distance between points)* Multiplier
This will get you the distance for one leg. Subtraction this from the total distance gives you the distance for the other leg.

Determining which leg is which from the starting point is left as an excercise for the student.
 
"PSP"

Puckered Sphincter Point.
 
Jesse- the XL file has a general solution you can walk through...

EDIT- now in a ZIP file. Please consider making the "Invalid file" message font color in red or another bright color.
 

Attachments

  • JesseXL.zip
    1.5 KB · Views: 5
Last edited:
Critical Point perhaps?

Someone else built such a thing with the following parameters:
Distance
GS out
GS Back
Actual GS

Result:
Critical point in distance
Time to critical point

Those parameters seem kind of crappy. WTF is Actual GS vs GS Out / GS Back?

Equal Time point makes sense to me if you're talking about cruise flight but for deciding whether or not to turn back when crossing a lake I think I like the term "Effective Midpoint". And BTW the latter is significantly more complicated by the fact that the windspeed and TAS will vary during the glide as the altitude decreases.

Also contrary to Mike's comment, in most cases you don't even need to reach dry land, ditching close enough to the shore to wade out would be sufficient. Trying to make it to a suitable landing area on the ground adds unnecessary risks.
 
Thanks for all the information. I'm going to have to think some about how to do this effectively. It likely will not be in the first release.
 
You're right..unless you do add in all kinds of complications for wind direction...we'll just bring along a Cray so we can predict the wind patterns and weather conditions at time of landing. :D

Nah - too big, too heavy, too much support equipment. Besides, your iPhone is just as powerful as the original Crays. But incredibly more difficult to program...
 
One thing I've found incredibly interesting - common functions like True Airspeed derived from pressure altitude, OAT, and CAS produce different results across all kinds of different E6B's (from electronic devices to mobile apps to javascript calculators).

The Sporty's E6b App seems to produce density altitudes different then almost everything else.

My true airspeed calculation seems to resemble an actual e6b more accurately.

How one decides if their function is truly "correct" is pretty damn difficult.

I suspect most of it comes down to the math capabilities of whatever language, the types used, level of rounding, and whatever floating point errors may exist.
 
Last edited:
I think the navy calls this bingo fuel FWIW...sorta the same but more oriented to getting back home
 
I think the navy calls this bingo fuel FWIW...sorta the same but more oriented to getting back home

Unless I'm mistaken, I don't think Jesse's question necessarily has anything to do with fuel. It's just a point at which it's equal time to go back vs proceed. That could be between two airports, over water, etc.

If I have a fuel or bladder related issue or a rough running engine, I just want to know how long it'll take to get to the nearest airport regardless of where I've come from or where I'm headed. So the nearest function would be what I'd be reaching for and not a Point of Equal time.

But having said that, I'm curious what you use PET for Greg?
 
But having said that, I'm curious what you use PET for Greg?

It is an ETOPS thing. On two engine airplanes, you must have an alternate within so many minutes. Depending on the operation, it can be anywhere from 90 to 207 minutes. On a typical Atlantic crossing, one might use Gander Newfoundland, Keflavic Iceland, and Shannon Ireland as ETOPS alternates. In that scenario, you would have two points of equal time, one between Gander and Keflavic, and one between Keflavic and Shannon. The PETs are calculated to determine which way one has to turn if one needed to get on the ground the quickest. That would be in the event of an engine failure.

It is only an issue on two engine airplanes, because on three or more, unless something really unusual happened, you would never be down to one engine.
 
And if you only have one engine, why in hell are you flying over a lake that big anyway?
 
One thing I've found incredibly interesting - common functions like True Airspeed derived from pressure altitude, OAT, and CAS produce different results across all kinds of different E6B's (from electronic devices to mobile apps to javascript calculators).

The Sporty's E6b App seems to produce density altitudes different then almost everything else.

My true airspeed calculation seems to resemble an actual e6b more accurately.

How one decides if their function is truly "correct" is pretty damn difficult.

I suspect most of it comes down to the math capabilities of whatever language, the types used, level of rounding, and whatever floating point errors may exist.

Rounding and precision shouldn't generate significant errors in these calculations as they are generally not very "sensitive" equations. IME the differences you've noticed are more often due to the programmer substituting a "thumb rule" for one or more portions of the process instead of using the correct mathematical formula.

This website contains a pretty good set of correct formulae along with an occasional estimating shortcut where the shortcut's errors are explained:

http://williams.best.vwh.net/avform.htm
 
Rounding and precision shouldn't generate significant errors in these calculations as they are generally not very "sensitive" equations. IME the differences you've noticed are more often due to the programmer substituting a "thumb rule" for one or more portions of the process instead of using the correct mathematical formula.

This website contains a pretty good set of correct formulae along with an occasional estimating shortcut where the shortcut's errors are explained:

http://williams.best.vwh.net/avform.htm
Very possible. It's pretty much impossible to figure out what most of these apps out there are using for their formulas since it's all closed-source and they don't publish any of that. I have seen some aggressive rounding in some javascript calculators that did in fact effect the result, albeit by on a few whole numbers using rather large inputs.

At the end of the day, even the "correct" formulas are mostly just approximations because of the limited data the pilot can provide about the current conditions.
 
Last edited:
I'm really struggling to find the formula out there to calculate true airspeed based on CAS, TAT, and pressure altitude. Anyone have it somewhere?
 
And if you only have one engine, why in hell are you flying over a lake that big anyway?

We still fly single engine in the Gulf of Mexico. I used to fly a B206 180nm out on my 'paper route'. PNR calculations were required anytime we were one-way fuel, which in a SE helicopter was pretty much every flight and even in the medium twins I was more often than not one-way fuel. We calculated the PNR prior to takeoff, put it in the GPS and 10 minutes prior to reaching we started to run fuel calculations to ensure we had enough to make it to the rig with 20 minute reserve and verify the rig we were landing on had fuel available (we did this prior to takeoff as well) before we could proceed past the PNR.

I've never heard of airplanes using PNR's, only the ETP and CP that has been mentioned here. I thought the PNR term was a helicopter thing and more of a Gulf of Mexico thing. Flying offshore in Canada they call it a CP.
 
We still fly single engine in the Gulf of Mexico. I used to fly a B206 180nm out on my 'paper route'. PNR calculations were required anytime we were one-way fuel, which in a SE helicopter was pretty much every flight and even in the medium twins I was more often than not one-way fuel. We calculated the PNR prior to takeoff, put it in the GPS and 10 minutes prior to reaching we started to run fuel calculations to ensure we had enough to make it to the rig with 20 minute reserve and verify the rig we were landing on had fuel available (we did this prior to takeoff as well) before we could proceed past the PNR.

I've never heard of airplanes using PNR's, only the ETP and CP that has been mentioned here. I thought the PNR term was a helicopter thing and more of a Gulf of Mexico thing. Flying offshore in Canada they call it a CP.

What were the input parameters and the result?
 
I'm really struggling to find the formula out there to calculate true airspeed based on CAS, TAT, and pressure altitude. Anyone have it somewhere?


From the website I posted above:

True airspeed from CAS and DA:
TAS =CAS/(1-6.8755856*10^-6 * DA)^2.127940 (DA<36,089.24ft)DA from pressure Alt and temperature

DA=P_alt+(T_s/T_r)*(1.-(T_s/T)^0.2349690)
(Standard temp T_s and actual temp T in Kelvin)
 
We just used simple formula that I generally did with scratch paper and pencil.

Endurance X GS Home
___________________
(GS Out + GS Home)

That of course gives me a time which I'd convert to distance for a waypoint. Based on what I was actually seeing for GS compared with what I estimated before takeoff I'd do a quick recalc and adjust in flight. Don't know if that helps you or not.
 
From the website I posted above:

True airspeed from CAS and DA:
TAS =CAS/(1-6.8755856*10^-6 * DA)^2.127940 (DA<36,089.24ft)DA from pressure Alt and temperature

DA=P_alt+(T_s/T_r)*(1.-(T_s/T)^0.2349690)
(Standard temp T_s and actual temp T in Kelvin)
Well that'll get you true airspeed. But will that take compressibility into account and use total air temperature and calibrated airspeed as parameters? Is the actual temperature supposed to be total air temperature or ambient ?
 
Last edited:
Okay, so I'm (one of) the geek(s) with the spreadsheet for this.

Input parameters: Best glide airspeed, actual descent rate at best glide, cruise altitude, water level MSL, cruise speed, distance across the water, and average head/tailwind component.

Output: Glide forward range, return glide range, total glide range, exposure distance (ie unable to glide to either shore), total exposure time, and altitude for zero exposure. I actually don't calculate an exact PET in the spreadsheet, as I mainly use it for pre-flight planning. I use the Garmin 430 to help me calculate a PET once I'm in the air, using the actual winds aloft rather than just forecast winds aloft.
 
Well that'll get you true airspeed. But will that take compressibility into account and use total air temperature and calibrated airspeed as parameters? Is the actual temperature supposed to be total air temperature or ambient ?


When compressibility is taken into account, the calculation of the TAS is more elaborate:
DP=P_0*((1 + 0.2*(IAS/CS_0)^2)^3.5 -1)
M=(5*( (DP/P + 1)^(2/7) -1) )^0.5 (*)
TAS= M*CS

P_0 is standard sea level pressure
P_0= 29.92126 "Hg = 1013.25 mB = 2116.2166 lbs/ft^2

P is pressure altitude.
P= P_0*(1-6.8755856*10^-6*PA)^5.2558797, pressure altitude, PA<36,089.24ft

CS is the speed of sound (dependent on ambient air temp).
CS= 38.967854*sqrt(T+273.15) where T is the (static/true) OAT in Celsius.

CS_0 is the speed of sound at sea level in the standard atmosphere.
CS_0=38.967854*sqrt(15+273.15)=661.4786 knots

Watch the units!
 
Last edited:
All nice to know, maybe, but absolutely worthless when you want to fly over Lake Texoma low enough to see the party girls on the raft-up at north island.

Okay, so I'm (one of) the geek(s) with the spreadsheet for this.

Input parameters: Best glide airspeed, actual descent rate at best glide, cruise altitude, water level MSL, cruise speed, distance across the water, and average head/tailwind component.

Output: Glide forward range, return glide range, total glide range, exposure distance (ie unable to glide to either shore), total exposure time, and altitude for zero exposure. I actually don't calculate an exact PET in the spreadsheet, as I mainly use it for pre-flight planning. I use the Garmin 430 to help me calculate a PET once I'm in the air, using the actual winds aloft rather than just forecast winds aloft.
 
Back
Top