PDA

View Full Version : A330 trim: '35 minus actual C.G. divided by 2'?

UFO-flying-Airbus
5th Feb 2015, 10:40
Hello all,

A Captain colleague of mine and I have been discussing where this formula comes from, does anyone know?
We can't seem to find it in any Airbus related document(s).

At our airline (an Asian Carrier flying the A330-200) most crews take the actual trim value and take that value away from 35. They then divide the resulting number by 2 to obtain the Take off trim setting.

For example;

Take off CG = 30.
35-30 = 5.
5 divided by 2= 2.5 (UP).

So I'm just curious as to where this comes from. Could anyone perhaps provide a reference?

5th Feb 2015, 10:46
You forgot to add the square root of pi, then subtract .042, then add 1.

5th Feb 2015, 13:26
Question: why are you guessing at the trim setting and not using what the loadsheet specifies?

Is it some sort of cross check?

C_Star
5th Feb 2015, 13:30
Why don't you jest set c.g directly on the pitch trim wheel?

5th Feb 2015, 13:42
Way too easy.

MD83FO
5th Feb 2015, 13:46
I've seen that some airlines still use the trim units when it seems completely useless. where in the FCOM can i find support so i can stop the useless practice of inserting the trim units on the MCDU.

woodja51
5th Feb 2015, 13:47
The formula comes from the linear relation ship of the two values... If you look on the QRH there is a small " nomo graph " that starts at 35% etc. So if you subtract the Mac from 35 and divide by 2 it lines up the two variables.

You set stab NU etc in the MCDU performance and this is part of the trigger for stab not set warnings etc.

I recall that in non auto trim setting 330s this is how you set the trim whereas in the auto trim type , it sets it after the first engine start to the ECAM value of CoG.

That is why some companies seem to check and state the stab with reference to % , and others state the stab value.

Either way , the value should be set accurately by the PNF. I think it is just to ensure the MCDU Value is close enough to the actual set value to prevent the config warning if >2%? But I have been known to be wrong !

UFO-flying-Airbus
5th Feb 2015, 19:25
Thanks Woodja51,

That logic seems perfectly correct. And indeed it works. I was just wondering why there is no reference to it anywhere?

C Star mentioned 'why not just set C.G. directly on the pitch trim wheel'?- You're quite right and we (at least I) do. Yet most other pilots use that formula.

The result is the same however it's part of the discipline of our profession, in my humble opinion, to treat with suspicion any colloquial 'formula'/procedure' which the manufacturer has (apparently) absolutely no data on.

I'm not saying that to do so is 'wrong' (since it clearly produces the very same result) but a piece of, even semi-official, data regarding such a formula would be nice to see. If no such data exists then so be it :-)

woodja51
5th Feb 2015, 21:24
You might note that the stab from the load sheet is not always the exactly the same as the actual one measured by the ECAM.

After fuel is in (it could be out by some LMC , a bit more gas on board etc .. even though fuel LMCs are (generally) not allowed for at least the 330, and

The FMC initialised etc.

Hence often you,get the" ZFW/CG ECAM "disagree warning on occasion after setting up the init page. Which everyone seems to (mindlessly) clear but it is just a warning of an input disagreement.

If one simply put the load sheet stab into the box, the auto trim system will set the ECAM CG ( lower ND value). However then when you set/check the stab in the after start checks the FTCTL page will be slightly different. If it's within 2% ( one unit?) no one cares ....

But some folks like accuracy , and of course the PNF may then adjust the THS to match the MCDU, which is not exactly the same as the accurate CG from the system.

Not a biggy but incorrect stabs have/ reduce tail strike margins etc so there might be a level of paranoia , especially in longer Airbii , to make it more accurate than the 2% allowed??

They are just my ideas , no factual basis other than 16 years on 330.

john_tullamarine
5th Feb 2015, 22:59
I was just wondering why there is no reference to it anywhere?

Generally, such stuff may make a sentence in weight control or loading manuals but, more generally, it is background calculation material which surfaces only as some sort of final guidance result.

My guess, in this case, is that the formula derives from someone's idle playing with the graphs over a beer as Matt implies.

You might note that the stab from the load sheet is not always the exactly the same as the actual one measured by the ECAM.

Generally, ANY manual trimsheet will be tweaked to suit the design error analyses - if it's all done by computer there still is a need for such analyses and workarounds as the assumptions built into the loading system contain approximations and fiddle factors which only go so far to achieving end accuracy ... the aim is to end up with the aircraft's departing inside the envelope rather than a strictly accurate MAC value from the sheet.

The latter goes into the stab trim setting lookup which, in turn, is generally a little in error so far as the AFM data might be concerned.

Mind you, this presumes that the designer is competent .. I have reverse engineered numerous trimsheets over the years to figure out why they don't do what they should .. only to find basic errors getting through the design process.

As a consequence, the envelope limits as printed will have "apparent errors" should the enquiring pilot compare TCDS data with the trimsheet and other calculation inputs will be tweaked to end up with something which keeps things safe and sound rather than output-numerically exact.

I haven't any A330 background but, should the OP like to post some relevant data, we can comment on the specifics rather than in generalities.

6th Feb 2015, 10:05

Hence often you,get the" ZFW/CG ECAM "disagree warning on occasion after setting up the init page. Which everyone seems to (mindlessly) clear but it is just a

We get this from time to time. My personal observation and theory is that it only seems to appear when we do a manual loadsheet. In that situation some of the figures are entered into one MCDU, the rest into the other. Not by SOPs, just the practicalities in the cockpit when doing a manual load-sheet. As the manual loadsheet is being completed by one guy, he will calculate and announce the ZFW first, which the other guy inputs. Only later, when the drop line has been completed can the ZFW CG and the THS setting be derived, and they tend to get input on the other MCDU. For some reason, the MCDUs don't always talk to each other about this, giving rise to the ZFW/CG disagree caution.

woodja51
7th Feb 2015, 11:07
Up linker ...you hit it on the head.. The ECAM is due to cross talk delays I think.

And yes, at CSA we only do manual entry, no uplink of load data.

I 'hear ' your load sheet / data entry cross check procedure as it was similar at EK,,, I might add none of that is done at CSA. Even the old green dot check to pick up gross weight errors ( as has occurred several times ) is not considered. Yet....

Romasik
8th Feb 2015, 09:11
From the Airbus:

Description
1) What are the conditions to trigger the "FUEL: ZFW/ZFCG DISAGREE" message?

2) How can be triggered a spurious "FUEL: ZFW/ZFCG DISAGREE" message?

Solution
1) The conditions for the FCMC to trigger the ECAM warning "FUEL: ZFW/ZFCG DISAGREE" are the following:
1- the value of ZFW sent by the FMS differs between side 1 and side 2 of more than 100 lbs,
or
2- the value of ZFWCG sent by the FMS differs between side 1 and side 2 of more than 0.025 %,
or
3h- during the initialization/re-initialization process, the status of ZFW/ZFWCG sent by the FMS differs between side 1 and side 2 during more than 2 seconds.

2) Investigation of the spurious cases of ECAM warnings "FUEL: ZFW/ZFCG DISAGREE" on A330/A340 basic aircrafts showed that when a ZFW/ZFWCG is inserted on one MCDU, each FMS will send these values to their onside FCMC with a boolean set to high (to indicate to the FCMC to init/re-init the values) during a few seconds. But, the setting/resetting of the high position for this boolean is not synchronized between both FMSs. A delta of more than 4 s may be observed.
And because of the 3rd condition, the FCMC issues the message.

This FMS/FCMC interface issue is addressed in the FMS "Release 1A" (R1A) standard.