PDA

View Full Version : A320 - should Airbus be more accountable for ATHR system


DescendNow
11th Aug 2015, 09:25
Whilst new to the A320 series, I have seen 2 important incidents which Airbus deny happen, but both should be addressed accordingly by Airbus.

First, G/S* and commenced descent FLAP 2 SPD selected 180kts, then SPD set managed, Gear Down and N1 increased from 34% to 83% immediately. A quick disconnect of autopilot and ATHR, immediate pull up to save the rapid speed increase to be told later, Airbus say leave the ATHR system alone it will not increase above FLAP Limit speed.

Second, FLAP 2 speed 165kts, gear down and n1 38%, due to very late ATC descent leaving the aircraft 1000ft high at 13 nms, the nose was pushed down to 2600 FPM, speed naturally increased towards VFE max-10 (190kts) then N1 responded to 82% pushing the speed to 207kts (VFE+7).

Has anyone else suffered at the hands of Airbus and Thales ? and what was your outcome?

In addition, the speed often reduces to VLS before the autothrust, but again Airbus deny this is a problem, but just cite "This is how it is designed to work!"

Certainly this is not acceptable behaviour by the auto system, lets get a thread going if this is the norm and maybe Airbus will provide pilots with a good tool for the job.

Fursty Ferret
11th Aug 2015, 10:25
Airbus say leave the ATHR system alone it will not increase above FLAP Limit speed.

I love the A320 but in this situation trust it as far as I can throw it.

Have never seen the situation you described - did it happen on different aircraft or the same one? My experience is that A/T is lazy to react sometimes on the A320 but never have I seen it add inappropriate power*.

Autothrust will allow speed decay below VAPP but not into VLS (in theory).

* Yes, yes, A319 speedbrake-with-flap exception...

vilas
11th Aug 2015, 12:53
First about ATHR, since it requires 5kts. addition to VLS obviously the system allows speed decay to that value some time. The other incidents something is amiss.

Microburst2002
11th Aug 2015, 13:56
Case 2, u need to give more details, like the automation mode.

Stone_cold
11th Aug 2015, 14:16
Are you sure the Approach Phase was activated ?

Sounds like this could be the case as the A/thr should not command an increase in thrust if the target speed is below present speed and it also would explain your "diving" towards the target speed (250) .

Other than this "finger " trouble , never seen what you describe .

altselect
11th Aug 2015, 14:19
Stone Cold is spot on, only time i've ever seen that was finger trouble and approach phase not activated.

kbrockman
11th Aug 2015, 14:25
due to very late ATC descent leaving the aircraft 1000ft high at 13 nms, the nose was pushed down to 2600 FPM

Is that correct ? or did you mean 10.000ft ?

Microburst2002
11th Aug 2015, 17:19
I assume it is 1,000 high with respect to the profile.

That would be about 5,000 AGL. I understand the mode used was V/S? Like in an above glideslope capture?

In every mode there is a form of protection from overspeeding. That shouldn't happen. In V/S mode, the target will be reduced to remain below VFE. In OP DES the A/THR will revert to SPEED and keep speed below VFE. If you are hand flying and ignoring the FD the A/THR will also revert to SPEED.

If speed was exceeded something was really wrong.

It happens, sometimes, that a pilot first tries to steepen the gradient by means of descending in OP DES at high speed (that is, close to VFE) then once he gets LOC*, he arms/checks G/S is blue and sets the FCU ALT above actual altitude, thus inducing a reversion to V/S (and therefore SPEED). The problem is that selected speed target remains high and in case your actual speed is less than target, because you were still accelerating to it in OP DES at the time, as soon as SPEED engages the engines will spool up. It is fixed by reducing the speed then checking/activating approach phase and managing speed. But if you don't, there should be no overspeed, though. V/S mode has a protection.

sierra_mike
12th Aug 2015, 02:33
not a big fan of A/THR but ruling out finger troubles or so-called "wrong levels of automation" as mentioned before i've never experienced any of the first 2 situations described. but yes, A/THR is quite lazy at times and/or doesn't work 100% to plan and sometimes isn't helpful at all in my eyes (i.e. gusty situations). disconnect it then if you don't like it/if out of limits.
A/THR going below VAPP: yes, but i've never seen it going below VLS. since you have VLS+5kt for A/THR ON (or even more for whatever) and considering the PM callouts required for speed deviations (-5kt,+10kt) it's within limits i'd say. but again: if you don't like it, disconnect ATHR and to quote FCTM
If the A/THR performance is unsatisfactory, the pilot should disconnect it and control the thrust manually.

vilas
12th Aug 2015, 04:07
DescendNow
I find your statements paradoxical. You say you are new to Airbus and you make a statement putting A320 on the mat. The examples you gave have a greater element of mishandling due to insufficient knowledge than any real systemic fault. I can understand you asking clarifications at this stage but the eureka like nature of statement and the title of your post appears a bit presumptuous. To put it simply what you experienced and the way you say it happened is not possible. There is definitely an omission or commission that is not noticed by you.

Amadis of Gaul
12th Aug 2015, 11:42
Relax, vilas, it's not like he's the only one around here who's "paradoxical"...

Microburst2002
12th Aug 2015, 12:20
but i've never seen it going below VLS


Well, I have seen it. And what was the A/THR doing?

:zzz:

Uplinker
12th Aug 2015, 15:39
MB, I don't disbelieve you but do you mean the actual speed - not the trend arrow - actually settled below VLS and the A/THR did nothing? Or was it only below VLS for a split second in a gust or just very slow to correct?

tubby linton
12th Aug 2015, 16:53
The A332 I used to fly had a very lazy Athr and would quite happily do nothing if the speed went towards or into Vls at low level.

Microburst2002
13th Aug 2015, 15:13
MB, I don't disbelieve you but do you mean the actual speed - not the trend arrow - actually settled below VLS and the A/THR did nothing? Or was it only below VLS for a split second in a gust or just very slow to correct?


Actual speed below, well below VLS, and lasting for several seconds of unresponsive A/THR. PM says "speed", now… What do you answer? "Don't tell me, tell to the A/THR". So in the end the only answer is that you have go around. You can't fix it, if you take over manually Airbus is saying somewhere that you should have done that before 1,000 ft, and you have the stabilized approach criteria to meet. There are too many restrictions, so just go around and send the bill to Toulouse.

Cak
14th Aug 2015, 03:25
Disconnecting A/THR before 1000ft is recommendation, not obligation (it says should, not must) and if you are visual with the RWY you are allowed to be stabilized at 500 ft. Also you are allowed to make small corrections anyway according to FCOM. I don't think there is a need to make a go around.
And I don't see why is such a problem to use manual thrust. If you are not satisfied with A/THR, don't use it. It's not mandatory. With just a little practice, with manual control of the THR, you can control it more precisly then A/THR. And with some specific crosswinds with heavy gusts, A/THR is almost unusable.
I was flying for years using only manual thrust because it was mandatory to switch off A/THR when you switch off A/P. We were using Lufthansa procedures and whole Lufthansa was also flying like this for years

FCOM:
If the aircraft is not stabilized on the approach path in landing configuration in the following
conditions:
‐ at 1 000 ft above airfield elevation in instrument conditions, or
‐ at 500 ft above airfield elevation in visual conditions, or
‐ as required by Operator policies/regulations.
Then a go around must be initiated unless the flight crew estimates that only small corrections are
necessary to rectify minor deviations from stabilized conditions due, amongst others, to external
perturbations.

mikedreamer787
18th Aug 2015, 13:07
Autothrust will allow speed decay below VAPP but not into VLS (in theory).

Yes...IN THEORY. :rolleyes:

PS - my bolding.

vilas
18th Aug 2015, 14:02
The OP DescendNow has given a howler and disappeared. He knows what he has done. So time to move on.

donpizmeov
18th Aug 2015, 21:19
VLS on approach is actually Vref. The +5kts (Vapp) is for A/thrust lag, ground speed mini is for the wind. Trend arrow is where the speed will be in 10secs if nothing changes. Understand this and the Bus auto flight system works well. It may involve opening an FCOM though, so I see where the confusion may lie.

PS...To a poster above, 1000 feet high at 10nm would be 4000 AGL not 5000. You need to multiply the distance by three not the altitude. This use to be taught before P2F was invented.

c100driver
18th Aug 2015, 21:47
With almost 6,000 A320 series flying plus the A330/340/380 the non moving TL does not really appear to be a serious issue does it:ok:

vilas
19th Aug 2015, 04:00
donpizmeov and all
After Stone_cold diagnosed correctly the original issue is closed. Imagine a radar vector with a speed restriction so speed was selected without activating approach. After GS* flaps selected to 2 and G/down initially the thrust goes to 34% to maintain 180KTS then when speed is managed it increases to 83% to speed target of 250KTS. ATHR behaviour as designed. Second case instead of being 4000ft. aircraft was at 5000ft. It appears the nose was pushed down disregarding the FDs in ALT. Otherwise VS of MAX minus two thousand should have been selected and FDs followed with approach armed. If that was not enough and by one thousand feet A/C did not meet the stabilisation criteria a GA should have been executed. But the real problem here also is when going managed speed aircraft accelerated towards 250KTS and was saved by the protection. The answer to these incidents can easily be found by their safety department by checking the DFDR. However, now we are obliging to his second request by keeping the thread going.