News:

Precision Simulator update 10.174 (26 April 2024) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

Takeoff Performance Analysis

Started by Eric Volmer, Thu, 10 Nov 2022 14:15

Eric Volmer

Good afternoon Hardy,
Recently, I updated my Precision Simulator to the latest version 10.157.
For that release, you announced under 157.07. that the quote- acceleration factor on the ground in the range above 75 knots is now lower by circa 15 % (gradual) -unquote.
This triggered me, to see  in detail what happens during takeoffs.
I selected a scenario with a departure from EHAM runway 36L (TORA 3800m, RWY elevation between -12FT and -13FT, 0° slope) at MTOW (396.9 tons).
To be able to reproduce the resulting takeoff data, I activated the Aerowinx Virtual Pilot to perform the takeoff with full available power (CF6-80C2B1F, no derate).
The takeoff run with KLM B744 PAX "PH-BFN" was on a dry runway in ISA conditions (+15°C, 1013 hPa) and still air, with flaps 20 and packs and anti-ice switched off.
The (NG) FMC calculated V1=153, VR=169 and V2=180. CG was 31.% with STAB trim +4.5.
The V2 was entered into the MCP IAS window. Furthermore, LNAV, VNAV and HDG HOLD were pre-selected.
To analyse the takeoff data, I selected a Time acceleration of .25 and the Recorder with File format called "Embry-Riddle-1".
After reviewing the Excel data sheets of various trials, I observed:
Liftoff (gear lock lever solenoid `clicks' ) happened at about 175-176 knots with an aircraft pitch of approximately  12.5°.
The target V2+10 airspeed was never reached at screen height (35FT AGL).
Then, I tried the same takeoff with the Virtual Pilot and a Time acceleration factor of .50 and also 1.0.
Surprisingly, I noticed different pitch behaviours! I repeated my trials quite often, but came to the same results every time.
Please check my visualisation of the collected data in the attached file.
Hardy, do you have an explanation for my findings? Or, did I oversee important influence factors?
Thank you very much for your valuable feedback in advance.
Best regards,
Eric Volmer
https://www.mycloud.ch/l/L000B78310F73D4CF7DF380537349C2580BAC0FDACF81FC74070F529C94C9D948

Hardy Heinlin

Hi Eric,

time acceleration factors below 1.0 don't work well in such fine-adjusted processes like takeoff rotation during airspeed acceleration. This is due to the variable frame rate granularity provided by the CPUs. The same problems occur during the autopilot's altitude acquiring phase, for example -- certain time acceleration factors tend to cause overshooting, some other factors cause undershooting. In such phases I recommend to use the normal time factor of 1.0. (I think this isn't related to the update 10.157.)

In short words, please use time factor 1.0 for any analysis. The ERAU recorder uses 20 Hz anyway; that provides a pretty high time resolution even in real-time.


Regards,

|-|ardy

Jeroen Hoppenbrouwers

In other words, time accelleration/decelleration does not adjust the coefficients of the PID controllers, so short-term automatics behaviour will be different, though you can use it with good results for longer cruise segments, for which I think the feature was meant?


Hoppie

Hardy Heinlin

It does adjust the frame rate time deltas. That's the very core of it. But the deltas are rounded integers (rounded milliseconds). The aerodynamics and autopilot algorithms, however, are in 64 bit floating point -- this resolution is neccessary to achieve the precision in the flight model. When these are factored by integers, there'll be very complex rounding errors within the concert. In addition to that, this quantization of the time frame system can eventually delete essential information within a series of frames. E.g. when you make a quick needle-impulse-like pull on the yoke this pull might not even get into the algorithm because of the time frame granularity, especially at very high time acceleration factors at low frame rates. That's why bank oscillations occur e.g. at FMC waypoint sequencing when using high time acceleration factors. Below a certain frame rate there's just too much act and react information to be put into the integer grid, and the dampening will fail completely -- for plain mathematical reasons.

PSX is tuned for time acceleration factor 1.0. All other factors are just for raw repositioning purposes etc., not for analysis work.

Eric Volmer

Thank you very much for your comprehensive reply (as always  :) ), Hardy.
Based on your feedback, I will further analyse the takeoff performance in detail, now with Time Acceleration factor 1.0 only. In particular, I am interested to see the interaction in the takeoff parameters like speed, acceleration, roll distance, pitch, altitude, etc. It is fascinating to produce and see graphics with the recorded PSX raw takeoff data!
As said, your announcement of a correction in speed acceleration after 75 knots triggered me. By the way, why became this necessary?
Best regards,
Eric

Hardy Heinlin

Quote from: Eric Volmer on Fri, 11 Nov 2022 06:12By the way, why became this necessary?

The PSX project is an ongoing evolution, not a dogma :-)

All science is theory. There are always new details to discover ...


Regards,

|-|ardy

Hardy Heinlin

To avoid user confusion, the takeoff controlled by the virtual pilot is now inhibited at any time factor above or below 1.0.

PSX update 10.158:

https://aerowinx.com/board/index.php/topic,4191.0.html


|-|ardy