Jump to content
Sign in to follow this  
DRNAV

Is entry of CG required for takeoff V speed calculations ?

Recommended Posts

Currrently, it looks like PMDG 777 requires entry of CG to get takeoff V speeds.

According to the PMDG 777 FCOM, entry of CG calculates stabilizer takeoff setting.

It does not say entry of CG is required for takeoff V speeds calculation.

Is this a bug ?

Share this post


Link to post
Share on other sites

 

 


Is this a bug ?

 

Any time you see empty boxes on the CDU, it's a required entry. Also, it's not the PMDG FCOM - it's the Boeing FCOM.

 

Also, it's a forum requirement to sign your name to your posts. Please do so in the future.

http://forum.avsim.net/topic/245586-you-must-sign-your-full-real-name-to-posts-to-use-this-forum-posts-without-names-will-be-deleted/


Kyle Rodgers

Share this post


Link to post
Share on other sites

Thank you for the comment.

As far as I know learned from other sources, entering FLAPS setting without entering CG in CDU displays V speeds.

I believe V speeds is independent of CG value.  

 

1. Entering FLAPS setting in the CDU => FMC calculates V speeds and displays on the CDU. (CG is still empty box)

2. Entering CG in the CDU => FMC displays stabilizer takeoff TRIM setting. V speeds do not update due to entering CG.

 

CDU in PMDG 777 needs both FLAPS setting and CG value to get V speeds.  I would like to confirm whether entering CG is mandatory to get V speeds.

 

Thank you,

Tetsuji Konohira

Share this post


Link to post
Share on other sites

On calculating normal take off speeds ( not the one on the CDU ), there's no requirement to enter CG position. Since, at least for the airline i know, we do the take off perf calculation before receiving the Loadsheet. And any last minute change to the Loadsheet CG ( MACTOW ) would not have an effect to the take off speed as long as the weight is within the band specified in the take off data card.

 

There's an exception to this. At certain airports, especially those quite often has high OAT and high field elevation ( Johanesberg is one of then ), to increase payload, we deliberately load the airplane up with a MACTOW >= 28% in order to increase the take of weight limit on that particular day.

 

In this case the CG from the Loadsheet will have to be more than 28% otherwise the take off data is invalid. So when we get to the airplane, we will confirm with the load controller to make sure the cargos are distributed so that we have an MACTOW >=28%.

 

There can be more exception to it which I don't know. And I am not sure about the CDU take off speed thing because I don't pay attention it before I entered the CG. But the thing is if the CG input affects the speed, any change to the CG would result to a TAKE OFF SPEED DELETED msg. However as far as I know from real life experience is I won't get that msg for a change of CG after take off speed is entered, which happens all the time when the load controller decided to change the loading position of some cargo at the very last minute.

 

Hope it helps.

Share this post


Link to post
Share on other sites

Takeoff Performance IS required to account for Aircraft CoG. The Laptop/Server/iPad software default assumes the worst possible situation which is full forward CoG and calculates takeoff data based on this setting. This impacts not only the speeds but the available thrust derate of the maximum permissible performance limited take off weight.

 

There is an option that airlines can purchase from Boeing called the Alternate CoG Takeoff pack, which allows the airline to nominate a fixed point along the CoG scale. My previous airline has this option ($$ thousands) and had the value set to 28%MAC. As such anytime the CoG was at 28% or greater, we used the ALTN CoG setting in the software and this allowed the software to calculate on the basis of 28% and therefore either more de-rate or allowed us to lift more weight for a fixed thrust setting. However if the CoG was <28%, we used "FULL" CoG which basically meant the software was assuming the CoG on the forward limit and no credit was given to the CoG being aft of this.

 

The next logical step I guess would be software where you entered the actual CoG and it calculated performance based on this but to the best of my knowledge this hasn't been done.

 

OPT (Onboard Performance Tool) is available as an iPad app from Boeing for the 737; I have heard it's coming for the 777 as well ... But I don't know whether it's accessible outside the airline environment. It's the airline infrastructure that takes on the responsibility for keeping all the airport/airline specific background data up to date on the iPad installation as well as setting the policy on the assumptions inherent in the calculation which are legion ...

 

However returning to the CoG in the FMC and it's impact on speeds - there's not a lot of detail in the FCOM (as has been noted). However the Honeywell manuals specifies that the Stab Trim is calculated after CoG is entered; it also says that Takeoff Speeds requires Weight, OAT, Runway, Flap and Thrust - but not CG. I can only assume therefore that the FMC does not have the capability to account for CG changes in the takeoff calculation - and irrespective of what you enter, it's probably assuming the worst case full FWD CG n the calculations. The FMC calculations are quite rudimentary in any case - valid, but not optimised and don't account for terrain, and can't calculated assumed derate.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...