Hi,

 

the A/T behaves quite erratic if you change the ALT value during a climb in THR mode.

 

Consider following situation:

 

* Aircraft is flying with A/T, A/P on at 10000ft

  >> FMA says: SPD | HDG SEL | ALT

 

* Now dial in 12000ft and press FLCH

  >> FMA says: THR | HDG SEL | FLCH SPD

  >> A/T does not spool up to full CLB limit, because the new alt can be reached within a certain amount of time (120sec? ... there is a certain logic behind FLCH which might be more complex.)

 

* Let the airplane start its climb and then dial the alt further up, e.g. 20000ft - that's the point where A/T somehow gets out of control

  >> The commanded thrust very suddenly jumps up to high values

  >> These "thrust spikes" sometimes reach up to full thrust (so even beyond current thrust limit) before settling at CLB limit thust

 

My guess is that the FLCH logic recoginizes that the new target alt cannot be reached within 120sec any longer and thus commands full thrust. But the transition / spool up is very erratic and "unpleasant".

 

Does anybody else observe this?

I have tried nearly all different throttle-axis hardware settings. So I am pretty sure that it is not a faulty ("spiky") hardware / wrong setting, which would probably the first guess.

 

Thanks,

Robert

I have tried nearly all different throttle-axis hardware settings. So I am pretty sure that it is not a faulty ("spiky") hardware / wrong setting, which would probably the first guess.

 

If you set throttle override to 'never' then you can go from pretty sure to absolutely sure! That's where I'd start anyway (if you've not already done so).

 

* Now dial in 12000ft and press FLCH

  >> FMA says: THR | HDG SEL | FLCH SPD

  >> A/T does not spool up to full CLB limit, because the new alt can be reached within a certain amount of time (120sec? ... there is a certain logic behind FLCH which might be more complex.)

 

* Let the airplane start its climb and then dial the alt further up, e.g. 20000ft - that's the point where A/T somehow gets out of control

 

  >> The commanded thrust very suddenly jumps up to high values

  >> These "thrust spikes" sometimes reach up to full thrust (so even beyond current thrust limit) before settling at CLB limit thust

 

My guess is that the FLCH logic recoginizes that the new target alt cannot be reached within 120sec any longer and thus commands full thrust. But the transition / spool up is very erratic and "unpleasant".

  

Thanks,

Robert

No more logic behind it, it as simple as you described :-) Will try and see if I get erratic behavior tomorrow or day after tomorrow. The throttle should not go passed CLB.

I get the same erratic behaviour. If you adjust the altitude up or down thrust command changes rapidly up and down, overshooting there it will end up and then correcting back. It looks like there should be some filtering there which is missing. Thrust commmand changes shouldn't be that sudden.

 

When you dial in a large altitude change and select FLCH the commanded N1 behaves as it should, running slowly up to CLB (or down to IDLE). So some filtering is there for the initial thrust setting, but not if altitude is changed subsequently.  Looks very much like a bug to me.

Ok, "happy" to hear that I am not the only one with this behaviour.

 

If (only if) this is really a bug which everyone experiences, it surprises me that this neither come up earlier nor is listed in the issue tracking thread.

 

Personally, I find this erratic A/T behaviour quite annoying and unmissable. Why? It basically affects all non-VNAV take-offs after you have been established in a climb and then dial up speed or altitude in the MCP.

So far I have only noticed erratic throttle behavior during Go Arounds.

I was going to ask PMDG about that but wanted to do some more Go Arounds.

 

Maybe it is the same problem as you have with FL Change.

I played around with FLCH a bit.

And I find it not too bad actually.

Is there room for improvement?....Yes, but its not bad I think.

 

Initial FLCH behavior is quite good as it realy tries to do what the real airplane does (120sec target to new altitude).

When I change the altitude a little (like an extra 2000ft) while already climbing in FLCH, the AT sets a bit higher N1 resulting in an appropriately increased vertical speed.

 

But you are correct that when you increase altitude a lot (like an additional 10.000ft) while already climbing in FLCH the AT does exagertate a bit initially. I saw the the thrust target (white) go beyond CLB limit for a split second, but in my case the actual N1 needle never got there.

The AT recovered quickly from it exageration and did set CLB thrust as it should

 

I think the N1 just reacts way too fast to an increased new large altitude change.

N1 shoots up while in real life I have not noticed it doing that.

In real life everything in the 777 is quite slow and smooth.

(but on a side note, you would revert back to Vnav for a climb like that too......but that should not be an excuse ofcourse)

 

If the PMDG would just slowly (not too slow ofcourse, but smooth) increase N1 to its new target N1 then things would look better I think.

 

It is worth putting in a ticket I think.

 

 

I think the N1 just reacts way too fast to an increased new large altitude change.
N1 shoots up while in real life I have not noticed it doing that.
In real life everything in the 777 is quite slow and smooth.
(but on a side note, you would revert back to Vnav for a climb like that too......but that should not be an excuse ofcourse)

If the PMDG would just slowly (not too slow ofcourse, but smooth) increase N1 to its new target N1 then things would look better I think.

The quick N1 reaction to the rapid changes in N1 command are probably inherent in the engine model. There isn't so much lag at the top end of the rpm range. When you see N1 changing more slowly in real life it may be because the commanded N1 is changing much more slowly than in this sim. Basically if PMDG could get the rate of change of N1 command the same for subsequent changes as it was for the initial selection it should solve the problem.

 

As you say, it definitely needs a ticket.

So far I have only noticed erratic throttle behavior during Go Arounds.

 

Yes, during go arounds I have this, too.

 

 

As you say, it definitely needs a ticket.

 

Is the ticket system really made to report bugs?

I would think (and hope) that PMDG also follows their own support forum to become aware of such things.

A little official feedback would be nice, though.

I have put in a ticket about the go around thing already.

 

And maybe that and the FLCH thing are connected.....so....

 

When I get an Email reply on my ticket....I will mention the FLCH erratic AT behavior then.

 

That should take care of it

Is the ticket system really made to report bugs?

I would think (and hope) that PMDG also follows their own support forum to become aware of such things.

.

The idea is to seek help n the forums to see if you have a bug or are doing something wrong or are having a problem that is not caused by PMD, etc. And then when/if you know you have a bug, you use the tocket system to report it.

 

PMDG difinately follows the forums but I am sure they have other things to do as well :-)

Is the ticket system really made to report bugs?

 

I would think (and hope) that PMDG also follows their own support forum to become aware of such things.

 

A little official feedback would be nice, though.

That's one of its purposes yes. Things mentioned in the forum may or may not get noticed. If you open a ticket it will certainly get attention.