Post by Tom/CalClassic on Aug 9, 2008 0:13:40 GMT -5
Re: Descent Problem
« Reply #8 on: Jul 28th, 2008, 9:25am » Quote Modify
--------------------------------------------------------------------------------
Hi,
Here is FSAviator's reply:
In aviation there are no dumb questions, only dumb silences.
<<How is Gate to Gate time computed (in the real world)>>
An average local holding and ground congestion delay is assumed per location and added to the planned time from take off to IAF.
<<When does flight time start; at time of takeoff roll or time that the plane is actually flying? >>
An aircraft is in flight from the time it moves 'for the purpose of taking off' until it next ceases to move. Normally we are not in flight whilst we taxi to the holding point. However once we release the brakes and move with the intention of not stopping again until after landing we are in flight, potentially before we enter the departure runway.
However for both aircrew and ATC the key times are actual airborne time and updated estimate for the Initial Approach Fix (IAF).
As the 2008 Propliner Tutorial explains (*in real life*) we update (*all*) our Expected Times of Arrival (ETAs) based on our Actual Times of Arrival (ATAs) for two reasons;
1) 4D Navigation
2) 4D Traffic separation
In real life we must inform ATC of our estimate for each (the next) waypoint on our flight plan. If we are cruising at 16000 QNH and estimate DEF at 1015 and another aircraft on an airway crossing at 45 degrees, also at 16000 QNH, estimates DEF at 1024, one aircraft must change cruising level. There must be 10 minutes separation at the same level. If we originally expected to cross ABC at 1001 and DEF at 1014 having actually crossed ABC at 1008 we now also expect to be seven minutes late at DEF and must inform ATC that our ETA has become 1021. The expected safe separation has been lost. We will be forced to change cruising level. We will usually be instructed to descend 2000 feet to 14000 QNH even if we were recently cleared to climb to 16000 QNH based on our original false estimate of 1014 for DEF.
MSFS is different! It matters.
When using a text flight plan in MSFS, although we always and continuously update the ETA for the IAF to compare it to Route fuel exhaustion time (RF=0 time) we nevertheless *retain the original intermediate waypoint ETAs unaltered* so that we can compare the interval of those planned nil wind ETAs to the interval of ATAs which resulted from the 'perceived headwinds' we actually encountered.
We must use that difference to calculate the 'perceived headwind' upon which we base our decision whether to descend and apply more power. We do that using *unaltered* intermediate waypoint ETAs versus ATAs. We write one alongside the other. We must *not* change the flight plan ETA for intermediate waypoints. We only record the ATA and note the difference. To the contrary during the same captaincy decision making cycle we add or subtract that difference to modify *only* ETA for the IAF and and we recalculate RF=0 to make our diversion decision. These two different processes take careful thought to understand and apply. One process causes us to change level and power applied, the other causes us to divert, or not.
We need to put ourselves through both processes concurrently at least every 30 minutes and preferably every 20 or so. The Calclassic notepads (currently available only for the Starliner) use and impose a 20 minute captaincy decision making cycle, differentiate the two processes and issue all relevant warnings of both types to promote realistic choice of cruising altitude, realistic choice of cruise power and realistic diversion decision making. They also calculate TOD as it varies
Under all circumstances (MSFS or real life) the ETA for our destination is the ETA for its Initial Approach Fix. We have no idea how long we will be required to hold at that fix before being given approach clearance. We cannot offer either ATC or ourselves an estimate for the runway, let alone the stand. Much of the traffic that will be below us in the hold at destination and delaying our approach has not yet even departed airfields closer to our destination. ATC cannot estimate our approach delay either (yet).
TOD is a variable number of minutes before our constantly varying ETA for the IAF. TOD varies, both as our cruising altitude varies, (by four minutes per 2000 feet), and as our ETA for the IAF varies due to 'perceived headwind'. If we originally expected to reach the IAF at 1400 GMT and now have ETA = 1407 GMT then TOD is also seven minutes later. We have no idea whether we will 'catch up' those seven minutes. We have no idea what winds we will actually encounter further down route
Our flight plan is just a starting assumption which varies greatly as we progress down route, being assigned cruising levels we did not want, meeting winds we did not expect, carrying ice we hoped to avoid. We load substantial fuel reserves accordingly. The new Calclassic Notepads will help us to load appropriate route fuel and appropriate reserve fuel, once the beta test is over and they are available for a range of 'Calclassic Aircraft'.
If we record ATA alongside unchanged planned ETA, in pen on our text flight plan, we know how exactly many minutes early or late we are running. TOD changes accordingly
<<is the projected flight time given by the MSFS Flight Planner gate to gate time or time from takeoff until arrival at IAF?>>
A planning tool has no idea what speed we will taxi at, how much AI traffic will be in the way, or how far our stand is from the runways for take off and landing. Both runways may change after we plan because weather is a variable, not a constant. Even user defined weather and weather themes have variable weather unless the user applies zero change for a given training exercise.
It is our job to include the real IAF in the flight plan, or if we cannot determine the real IAF, it is our job to designate a flight plan waypoint as the IAF. All our captaincy decisions revolve around that waypoint even if we plan beyond it because;
1) We must have somewhere safe to hold whilst we await weather improvement at destination (if we need to), and
2) We must use our ever changing ETA for that location versus our ever changing RF=0 time; to make our diversion decisions long before arriving at that designated IAF (hold).
Remember even if there is no delay at destination we will often need to cross inbound obstructions at high altitude and descend in the destination hold (usually at the IAF) clear of those obstructions, (see PT part 3). Holds are where we climb and descend versus the nearby obstructions as mandated by the real ATC procedures. Holds are not primarily places associated with traffic delay. We always need to plan the minimum safe level to leave the departure hold, and to arrive at the destination hold. The obstructions may be mountains, military training areas, or cold war flak zones at the adjacent border.
Continued in next post...
IP Logged
--------------------------------------------------------------------------------
Tom Gibson
California Classic Propliners: www.calclassic.com/
AlcoHauler Locomotive Page: www.calclassic.com/alco/
Freeflight Design Shop: www.freeflightdesign.com/
Tom Gibson
Forum Administrator
Jets are for Kids!
Posts: 2890
Re: Descent Problem
« Reply #9 on: Jul 28th, 2008, 9:25am » Quote Modify
--------------------------------------------------------------------------------
<<Supposedly, according to the plan that I printed up, when I descend I should be very near to, if not on top of, the IAF. But I'm not, I'm way short (like near 20 minutes) so I end up flying 20 minutes to the IAF at 5000 ft, wasting time and gas and always coming in late. >>
<< I'm flying an L-049 with "altitude hold" set and I use the autopilot altitude hold to descend. My airspeed indicator reads about 160 KIAS at 24000 ft and never really rises much above that reading during the descent. When I get to 5000 ft it indicates about 150-160 KIAS. >>
How to descend the L-049A is the worked example in the Propliner Tutorial. Use the find feature of a text editor to find;
FLYING the DESCENT in a PROPLINER.
I think you are actually using VSI hold to control rate of descent correctly and you seem to be controlling IAS correctly too; so you are probably implementing that worked example correctly throughout. Regardless,if you descended 38 minutes before the IAF then to have been level 20 minutes before the IAF you must have descended 19000 feet in 18 minutes at 1050 VSI which is double the mean rate in the worked example. If you had descended at 1050 VSI you would have driven your profile drag well above 150-160 KIAS, *but you didn't*.
So you can only have been using false estimates for the IAF with matching false estimate for TOD provided by broken software.
If prolonged L-049A descent terminates at <= 160 KIAS you must be miscalculating TOD, and descending too soon. You cannot be descending too steeply. You are allowing over complicated software to destroy the simple data you need.
You simply expect to implement TOD as early or late as you were at the last waypoint you passed before TOD!
Using software that pointlessly updates that intermediate ETA in MSFS is your problem. You are destroying the data you need. You must retain the original flight plan ETAs on a printed plan and compare them to ATA entered by pen and simply vary TOD by that difference every time it changes!
Of course the 'printed plan' can actually be a text document on screen into which we type each ATA alongside the planned ETA and on which we vary TOD accordingly by the difference.
Location ETA ATA
ABC 1000 1007
DEF 1007 1015
GHI 1022
.....
.....
TOD(FL240) 1400 (1408 )
IAF 1438 (1446)
We wrote 1408 into the ATA box for TOD when we passed DEF at 1015 and wrote 1015 into its ATA box.
If we are 9 minutes late at GHI we will alter TOD = 1408 to 1409 and IAF = 1446 to 1447.
If we descend 2000 feet due to a perceived headwind we will alter *both* values in our text flight plan
TOD(FL220) 1404 (1412)
But if nothing changes, and we cross all waypoints 8 minutes late, and have no need to descend before TOD due increasing headwinds that became significant, we will descend at TOD = 1408 and it will become the ATA.
We use the ABC/DEF/GHI data sequence to *preserve* and thereby monitor the data *trend*. Are we getting later and later which means the headwind is getting worse? During captaincy decisions we use that trend for other things than TOD planning, especially diversion planning. TOD planning and execution is very simple.
Part of the idea behind the Calclassic Notepads is to automate that necessary process for those who do not flight plan, or who use 'flight planning tools' that destroy the data needed to make the required captaincy decisions. Flight plans exist to force us to make decisions about cruising level, power applied and diversion. They are not a record of a flight for posterity. They are the trending warning data upon which we must act to alter our 4D navigation in real time. The Calclassic Notepads will bring that reality to everyone who bothers to use them.
FSAviator.
« Last Edit: Jul 28th, 2008, 9:26am by Tom Gibson »
« Reply #8 on: Jul 28th, 2008, 9:25am » Quote Modify
--------------------------------------------------------------------------------
Hi,
Here is FSAviator's reply:
In aviation there are no dumb questions, only dumb silences.
<<How is Gate to Gate time computed (in the real world)>>
An average local holding and ground congestion delay is assumed per location and added to the planned time from take off to IAF.
<<When does flight time start; at time of takeoff roll or time that the plane is actually flying? >>
An aircraft is in flight from the time it moves 'for the purpose of taking off' until it next ceases to move. Normally we are not in flight whilst we taxi to the holding point. However once we release the brakes and move with the intention of not stopping again until after landing we are in flight, potentially before we enter the departure runway.
However for both aircrew and ATC the key times are actual airborne time and updated estimate for the Initial Approach Fix (IAF).
As the 2008 Propliner Tutorial explains (*in real life*) we update (*all*) our Expected Times of Arrival (ETAs) based on our Actual Times of Arrival (ATAs) for two reasons;
1) 4D Navigation
2) 4D Traffic separation
In real life we must inform ATC of our estimate for each (the next) waypoint on our flight plan. If we are cruising at 16000 QNH and estimate DEF at 1015 and another aircraft on an airway crossing at 45 degrees, also at 16000 QNH, estimates DEF at 1024, one aircraft must change cruising level. There must be 10 minutes separation at the same level. If we originally expected to cross ABC at 1001 and DEF at 1014 having actually crossed ABC at 1008 we now also expect to be seven minutes late at DEF and must inform ATC that our ETA has become 1021. The expected safe separation has been lost. We will be forced to change cruising level. We will usually be instructed to descend 2000 feet to 14000 QNH even if we were recently cleared to climb to 16000 QNH based on our original false estimate of 1014 for DEF.
MSFS is different! It matters.
When using a text flight plan in MSFS, although we always and continuously update the ETA for the IAF to compare it to Route fuel exhaustion time (RF=0 time) we nevertheless *retain the original intermediate waypoint ETAs unaltered* so that we can compare the interval of those planned nil wind ETAs to the interval of ATAs which resulted from the 'perceived headwinds' we actually encountered.
We must use that difference to calculate the 'perceived headwind' upon which we base our decision whether to descend and apply more power. We do that using *unaltered* intermediate waypoint ETAs versus ATAs. We write one alongside the other. We must *not* change the flight plan ETA for intermediate waypoints. We only record the ATA and note the difference. To the contrary during the same captaincy decision making cycle we add or subtract that difference to modify *only* ETA for the IAF and and we recalculate RF=0 to make our diversion decision. These two different processes take careful thought to understand and apply. One process causes us to change level and power applied, the other causes us to divert, or not.
We need to put ourselves through both processes concurrently at least every 30 minutes and preferably every 20 or so. The Calclassic notepads (currently available only for the Starliner) use and impose a 20 minute captaincy decision making cycle, differentiate the two processes and issue all relevant warnings of both types to promote realistic choice of cruising altitude, realistic choice of cruise power and realistic diversion decision making. They also calculate TOD as it varies
Under all circumstances (MSFS or real life) the ETA for our destination is the ETA for its Initial Approach Fix. We have no idea how long we will be required to hold at that fix before being given approach clearance. We cannot offer either ATC or ourselves an estimate for the runway, let alone the stand. Much of the traffic that will be below us in the hold at destination and delaying our approach has not yet even departed airfields closer to our destination. ATC cannot estimate our approach delay either (yet).
TOD is a variable number of minutes before our constantly varying ETA for the IAF. TOD varies, both as our cruising altitude varies, (by four minutes per 2000 feet), and as our ETA for the IAF varies due to 'perceived headwind'. If we originally expected to reach the IAF at 1400 GMT and now have ETA = 1407 GMT then TOD is also seven minutes later. We have no idea whether we will 'catch up' those seven minutes. We have no idea what winds we will actually encounter further down route
Our flight plan is just a starting assumption which varies greatly as we progress down route, being assigned cruising levels we did not want, meeting winds we did not expect, carrying ice we hoped to avoid. We load substantial fuel reserves accordingly. The new Calclassic Notepads will help us to load appropriate route fuel and appropriate reserve fuel, once the beta test is over and they are available for a range of 'Calclassic Aircraft'.
If we record ATA alongside unchanged planned ETA, in pen on our text flight plan, we know how exactly many minutes early or late we are running. TOD changes accordingly
<<is the projected flight time given by the MSFS Flight Planner gate to gate time or time from takeoff until arrival at IAF?>>
A planning tool has no idea what speed we will taxi at, how much AI traffic will be in the way, or how far our stand is from the runways for take off and landing. Both runways may change after we plan because weather is a variable, not a constant. Even user defined weather and weather themes have variable weather unless the user applies zero change for a given training exercise.
It is our job to include the real IAF in the flight plan, or if we cannot determine the real IAF, it is our job to designate a flight plan waypoint as the IAF. All our captaincy decisions revolve around that waypoint even if we plan beyond it because;
1) We must have somewhere safe to hold whilst we await weather improvement at destination (if we need to), and
2) We must use our ever changing ETA for that location versus our ever changing RF=0 time; to make our diversion decisions long before arriving at that designated IAF (hold).
Remember even if there is no delay at destination we will often need to cross inbound obstructions at high altitude and descend in the destination hold (usually at the IAF) clear of those obstructions, (see PT part 3). Holds are where we climb and descend versus the nearby obstructions as mandated by the real ATC procedures. Holds are not primarily places associated with traffic delay. We always need to plan the minimum safe level to leave the departure hold, and to arrive at the destination hold. The obstructions may be mountains, military training areas, or cold war flak zones at the adjacent border.
Continued in next post...
IP Logged
--------------------------------------------------------------------------------
Tom Gibson
California Classic Propliners: www.calclassic.com/
AlcoHauler Locomotive Page: www.calclassic.com/alco/
Freeflight Design Shop: www.freeflightdesign.com/
Tom Gibson
Forum Administrator
Jets are for Kids!
Posts: 2890
Re: Descent Problem
« Reply #9 on: Jul 28th, 2008, 9:25am » Quote Modify
--------------------------------------------------------------------------------
<<Supposedly, according to the plan that I printed up, when I descend I should be very near to, if not on top of, the IAF. But I'm not, I'm way short (like near 20 minutes) so I end up flying 20 minutes to the IAF at 5000 ft, wasting time and gas and always coming in late. >>
<< I'm flying an L-049 with "altitude hold" set and I use the autopilot altitude hold to descend. My airspeed indicator reads about 160 KIAS at 24000 ft and never really rises much above that reading during the descent. When I get to 5000 ft it indicates about 150-160 KIAS. >>
How to descend the L-049A is the worked example in the Propliner Tutorial. Use the find feature of a text editor to find;
FLYING the DESCENT in a PROPLINER.
I think you are actually using VSI hold to control rate of descent correctly and you seem to be controlling IAS correctly too; so you are probably implementing that worked example correctly throughout. Regardless,if you descended 38 minutes before the IAF then to have been level 20 minutes before the IAF you must have descended 19000 feet in 18 minutes at 1050 VSI which is double the mean rate in the worked example. If you had descended at 1050 VSI you would have driven your profile drag well above 150-160 KIAS, *but you didn't*.
So you can only have been using false estimates for the IAF with matching false estimate for TOD provided by broken software.
If prolonged L-049A descent terminates at <= 160 KIAS you must be miscalculating TOD, and descending too soon. You cannot be descending too steeply. You are allowing over complicated software to destroy the simple data you need.
You simply expect to implement TOD as early or late as you were at the last waypoint you passed before TOD!
Using software that pointlessly updates that intermediate ETA in MSFS is your problem. You are destroying the data you need. You must retain the original flight plan ETAs on a printed plan and compare them to ATA entered by pen and simply vary TOD by that difference every time it changes!
Of course the 'printed plan' can actually be a text document on screen into which we type each ATA alongside the planned ETA and on which we vary TOD accordingly by the difference.
Location ETA ATA
ABC 1000 1007
DEF 1007 1015
GHI 1022
.....
.....
TOD(FL240) 1400 (1408 )
IAF 1438 (1446)
We wrote 1408 into the ATA box for TOD when we passed DEF at 1015 and wrote 1015 into its ATA box.
If we are 9 minutes late at GHI we will alter TOD = 1408 to 1409 and IAF = 1446 to 1447.
If we descend 2000 feet due to a perceived headwind we will alter *both* values in our text flight plan
TOD(FL220) 1404 (1412)
But if nothing changes, and we cross all waypoints 8 minutes late, and have no need to descend before TOD due increasing headwinds that became significant, we will descend at TOD = 1408 and it will become the ATA.
We use the ABC/DEF/GHI data sequence to *preserve* and thereby monitor the data *trend*. Are we getting later and later which means the headwind is getting worse? During captaincy decisions we use that trend for other things than TOD planning, especially diversion planning. TOD planning and execution is very simple.
Part of the idea behind the Calclassic Notepads is to automate that necessary process for those who do not flight plan, or who use 'flight planning tools' that destroy the data needed to make the required captaincy decisions. Flight plans exist to force us to make decisions about cruising level, power applied and diversion. They are not a record of a flight for posterity. They are the trending warning data upon which we must act to alter our 4D navigation in real time. The Calclassic Notepads will bring that reality to everyone who bothers to use them.
FSAviator.
« Last Edit: Jul 28th, 2008, 9:26am by Tom Gibson »