Flight Envelope Protection?

[BillC 135]

I suspect what just happened to me was the autopilot disconnecting for, as per QRH, Flight Envelope Protection but I'm not 100% sure...

 

I'd been happily cruising at FL370/M.85 for an hour or so when the warning horn went off and "Autopilot" came up on the EICAS. A/P, A/T, Vnav and Lnav all remained lit correctly but the A/P clearly wasn't in VNAV as the 777 booted the throttles and started climbing quite sharply to well above FMC and MCP flight levels.

 

I was connected to Vatsim, using AS2012 weather (NOT uploaded to the FMC) and the winds had been swinging around a bit where I was (between Iceland and Scotland over the ocean). I use FSUIPC wind and pressure smoothing so they're never dramatic nasty shifts or gusts. Happening somewhat unexpectedly I can't actually recall what the wind was doing at the moment it occurred so I can't describe the situation precisely and am just trying to fathom a reason for an AP disconnect like that.

 

So could, for example, a wind reversal (as in common is FSX) at a slow rate of change trigger Flight Envelope Protection or am I barking up the wrong tree?

[scandinavian13 5,192]

 

 

Happening somewhat unexpectedly I can't actually recall what the wind was doing at the moment it occurred so I can't describe the situation precisely and am just trying to fathom a reason for an AP disconnect like that. So could, for example, a wind reversal (as in common is FSX) at a slow rate of change trigger Flight Envelope Protection or am I barking up the wrong tree?

 

Do you have a hardware trim axis assigned?  Additionally, what is your auto throttle setting under PMDG Setup > Simulation?

 

If you have a hardware trim axis (like a roll wheel) assigned, ensure that you zero this out before engaging the AP.  The AP may initially engage, but then kick off later if the hardware sends a spike (or you click a button on it, even as simple as a hat).

 

If your AT setting is set to NEVER, change it to "IN HOLD/ARM ONLY," or "ALWAYS," to ensure that your hardware never overrides the AT.

[BillC 135]

Do you have a hardware trim axis assigned?  Additionally, what is your auto throttle setting under PMDG Setup > Simulation?

 

If you have a hardware trim axis (like a roll wheel) assigned, ensure that you zero this out before engaging the AP.  The AP may initially engage, but then kick off later if the hardware sends a spike (or you click a button on it, even as simple as a hat).

 

If your AT setting is set to NEVER, change it to "IN HOLD/ARM ONLY," or "ALWAYS," to ensure that your hardware never overrides the AT.

 

No trim axis assigned, default keyboard setting for that. 

 

"A/T Manual Override" is of course set to "Never" which is the totally intuitive setting for it (as in "never override the A/T"). That's how my NGX is set and that has never had a spike problem, in fact I've never had a spike problem in anything! Are you saying that "Never" means it CAN override if it gets a spike? Ummmm, why?

[scandinavian13 5,192]

 

 

Ummmm, why?

 

Ummm go with whatever makes sense because I don't have the plane sitting in front of me?

 

Think about it, without remembering the exact phraseology it could either be:

"NEVER override the FSX autothrottle."

...or

"ALWAYS override the hardware throttle."

 

Use whatever makes sense based on the prompt on the CDU.  Like I said, I don't have it sitting in front of me.  My end goal is to set you up with whatever setting ALWAYS allows the AT priority, and NEVER the hardware...

 

 

 

 

Absent the exact situation (as you noted, you can't remember exactly what was going on) I can't give you much more than that.  The AP has never kicked off like that for me, so I'm guessing it was something weather related (yes, despite the FSUIPC settings).  Unless you can reproduce it, that's my bet.

[Julian Roschlau 15]

No trim axis assigned, default keyboard setting for that.

 

"A/T Manual Override" is of course set to "Never" which is the totally intuitive setting for it (as in "never override the A/T"). That's how my NGX is set and that has never had a spike problem, in fact I've never had a spike problem in anything! Are you saying that "Never" means it CAN override if it gets a spike? Ummmm, why?

I'm sure he meant NEVER won't allow the a/t to be overriden at all.

I like mine in ARM mode.

 

Cheers,

Julian Roschlau

[WestAir 2,522]

Maybe you had a failed accelerometer or ADIRU fault? The same thing you're detailing happened on a real 777.

 

[truthknown 4]

I had the same thing happen to me 3 times last night flying across the Atlantic. First time was trying to step climb from FL370 to FL390. Slightly after FL380, alarm bells went crazy, the plane pitched up and skyrocketed to FL430 in seconds before I could even get control back to stop it. Then I pitched it down and it went below FL370 with speed in the lower yellow tape. Got it back to a normal climb profile and put it back to VNAV and the same thing happened again! Was completely lost as to what could cause it, I had never seen this behavior before. I figured I would try another long haul flight first before I reported it just incase it was a quirk last night, but since the OP had the same issue, maybe it is a real problem. At first I thought it was a weather issue, i'm using REX Overdrive plus for weather control now.

 

Chris Lezama

[downscc 1,327]

I think it is a weather issue, made many many flights without it happening then boom happened twice in one flight. First time I was watching it, second time I was reading the manual and missed it and lost the flight. At the time, I was trying x16 time compression but now I stick to x4 so I don't get the texture reloads and haven't had the A/P issue either. It's not a bug, just lousey FSX WX engine.

[BillC 135]

Hmm, "Never" for A/T override as I am set should mean that manual throttle "never" overrides the A/T and I just tested it, in the cruise I waved the throttle up and down with wild abandon and nothing happened. As far as I am concerned that rules out that setting.

 

Ref weather, that was the reason for original post, would a slow reversal of winds (smoothed by FSUIPC) trigger an AP disconnect? If it does then the 777 is more sensitive to such things than any other PMDG I've spent hundreds of hours in.

 

Incidentally, at the time of the incident in question I was totally hands off everything, mouse, k/b, joystick, PTT's everything. I never use time compression. I do agree it might well be a weather effect but with smoothing on it shouldn't be unless, as I said, the 777 is far more sensitive to it?

[downscc 1,327]

I don't any of us found this product more prone to A/P disconnects, it didn't come up. In my opinion it is not. I have FSUIPC aggressively smoothing weather, so much aggression that I can routinely use FSX real world 15 min updated weather. Only had one or two discos presumable cause by weather. By the way, really like your Woodpigeon banner. I keep waiting for them to build one.

[BillC 135]

I don't any of us found this product more prone to A/P disconnects, it didn't come up. In my opinion it is not. I have FSUIPC aggressively smoothing weather, so much aggression that I can routinely use FSX real world 15 min updated weather. Only had one or two discos presumable cause by weather. By the way, really like your Woodpigeon banner. I keep waiting for them to build one.

 

In that case, Dan, we need to nail what conditions will cause this - you've had it twice, I've now had it, as have others, and my weather is also smoothed so that FSX own so-called Weather doesn't cause issues (with anything else). I've been at this lark long enough to know that the disco I had isn't "normal" on a system set up to avoid such grief.

 

The Woodpigeon development process has dragged on too long. FSLab's version will be out before PMDGs :unsure: