I don't think anyone is taking this personally against PMDG. The "big deal" remains how it will look to those who don't want it appearing on the FMC CDU pages. As long as the FMC pages are realistic with the feature turned off everyone will be happy. The "auto-F/O" idea Ryan mentioned is a good way to achieve this. It might do other stuff as well, as on the LDS-767

 

I think it's safe to assume that most members in the PMDG forums would be concerned.

This is PMDG though so I am not at all concerned since they do everything right or not at all (weather radar?).

That's the big plus to Boeing aircraft. They are designed to have pilots in full control. The aircraft will not deviate from the altitude set in the Mode Control Panel unless it's changed. Typically in cruise, vertical speed in an option as well as remaining in VNAV and after the MCP altitude is changed, the new altitude will pop up into the scratchpad in the MCDU (FMS). Copying that new altitude into the altitude box on the cruise page will initiate a FLCH climb in VNAV.

 

I'm rather rusty on the Airbus but to initiate descent on the A320 you have to command the plane to descend yourself otherwise it will overfly the T/D regardless of what altitude is on the MCP. Airbus planes will always follow a pilot's command unless the plane is about to stall or roll over.

I would think initiating the descent by rolling back the MCP altitude is permission enough to start it.

If you do not want to descend don't roll it down.

 

Why does Airbus bother to bug the pilot with anymore than that?

I would think initiating the descent by rolling back the MCP altitude is permission enough to start it.

If you do not want to descend don't roll it down.

 

Why does Airbus bother to bug the pilot with anymore than that?

It doesn't really make sense just for top of descent though, and it only works at or after TOD. Every other altitude change in a Boeing requires the pilot to command it, just like an Airbus.

I think I am misunderstanding. I thought it was said above that you have to roll down the mcp before t/d and it will not descend after the t/d until the pilot tells it to again.

I am waiting for FSLabs to release theirs so I can figure these things out.

Thanks.

I think I am misunderstanding. I thought it was said above that you have to roll down the mcp before t/d and it will not descend after the t/d until the pilot tells it to again.

I am waiting for FSLabs to release theirs so I can figure these things out.

Thanks.

No, in an Airbus it's just like any other altitude change, select the new cleared altitude and either push for managed (like VNAV) or pull for open descent (like FLCH). You can command the descent any time you wish. What Alex was saying was that if you just selected a lower altitude an Airbus will not descend at TOD, unlike a Boeing which will automatically enter a VNAV descent if in VNAV.

Ok, thanks for explaining. What is wrong with the way Boeing does it that Airbus feels its not sufficient?

Boeing VNAV descent must be commanded by the pilot also.

Rolling down to the next cleared altitude seems very intuitive to me and I would expect a descent to begin without further interaction.

Rolling down to the next cleared altitude seems very intuitive to me and I would expect a descent to begin without further interaction.

 

Forgive me for jumping into the mix here, but I think it's just a difference in operating opinion.

 

The Airbus (and some of MD's) operating model seems to be a lot of command and confirm. I, as the pilot have changed the heading selector, or altitude selection, and I have confirmed this action was intentional. It's the same reason a lot of aircraft have autopilots that continue blaring until you hit the AP disconnect switch a second time. I have acted, and I have confirmed that this action was intentional. Airbus, as an entity, has decided that a crew member should confirm his or her actions through human-automation interfaces.

 

The Boeing operating model seems to be more permissive. I have acted (though some actions require a secondary action, like the AP disconnect previously mentioned). Boeing, as an entity, has decided that a crew member should confirm his or her actions through human checks and rechecks.

 

Which is right or wrong will always have supporters on both sides. I personally don't like the dark cockpit principle for my own reasons, but there are many who support it for their own.

Any idea why the 777 and the 787 both have opt at FL330 and recmd at FL370?

 

 

 

Actually there can be situations like this. Recmd accounts for winds at different levels, so for instance if you have a massive head wind on the Optimum crz level you probably don't wanna stick there, Optimum only calculates for still air.

I personally don't like the dark cockpit principle for my own reasons, but there are many who support it for their own.

 

Kyle

 

What is the dark cockpit principle you are writing about in your post?

 

Michael Cubine

What is the dark cockpit principle you are writing about in your post?

 

Michael,

 

The dark cockpit principle runs off of the idea that if everything is okay, no lights are displayed. Since you have the MD-11, I'll use that as an example. With limited exceptions, if you look at the overhead of the MD-11, you'll see that very few lights are displayed when the systems are operating normally/automatically. The idea is that it is more obvious that something is wrong when a light is displayed when everything is normally dark.

 

While I understand that reasoning, I prefer a positive feedback system. I like seeing that it is ON or OFF through an indication, and not a lack thereof. It's just a personal preference, as there are merits to both ideas.

 

In support of the dark cockpit principle, it is very true that the human mind will subconsciously filter out unnecessary signals. If a button displays ON all the time, and then displays OFF later, it may not be caught because the orange light, beginning with 'O' has been tuned out. Granted, a change in light or color tends to fix that issue (as an example most EICAS use Informational, Caution, Warning colors to make messages more obvious), but it is still true that the lack of a stimulus (no light, in this case) followed by a stimulus (the button lighting up) is more obvious to the human operator than a simple change in that stimulus (a light changing from one color to another, or a different word).

 

The thing that actually strikes me as odd, is that the manufacturers seem to have conflicting views on their implementations:

Airbus:

Dark Cockpit (passive - nothing's wrong unless we say it's wrong)

Confirmation-based MCP (active - nothing is official until confirmed)

 

Boeing:

Active Cockpit (active - status is actively displayed: ON/OFF, white bar, etc)

Partially Passive MCP (passive - systems may act without a confirmed pilot input, e.g.: rolling the altitude down before T/D)

 

Just an observation...

STEP TO and AT commands exist in the FMC for preprogramed step profiles completed at preflight, but do not automatically climb or descend the aircraft. They are primarily used by the FMC to calculate fuel burn and routine or optimal altitudes based on enroute data. As the previous poster said, they are there to optimize the climb.

The dark cockpit principle runs off of the idea that if everything is okay, no lights are displayed. Since you have the MD-11, I'll use that as an example. With limited exceptions, if you look at the overhead of the MD-11, you'll see that very few lights are displayed when the systems are operating normally/automatically. The idea is that it is more obvious that something is wrong when a light is displayed when everything is normally dark.

 

I loved that system, just a quick glance on the A320 panel is all I need during the cruise flows and we can monitor whether a system is working or not through the ECAM status screens or check for any FAULT or off lights on on the overhead. I also prefer having buttons vs turn knobs (such as the apu) since information can be readily displayed on a button that you are about to push, just a personal preference.

Airbus:

Dark Cockpit (passive - nothing's wrong unless we say it's wrong)

Confirmation-based MCP (active - nothing is official until confirmed)

 

Boeing:

Active Cockpit (active - status is actively displayed: ON/OFF, white bar, etc)

Partially Passive MCP (passive - systems may act without a confirmed pilot input, e.g.: rolling the altitude down before T/D)

The only time the Boeing MCP allows an altitude change from selection without a confirmation is at top of descent. I wouldn't call that partially passive as it's an exception. Airbus is at least consistent in always requiring a push or pull to confirm selection.

 

The 737 cockpit is basically dark cockpit, as there are no lights to show switch positions, unlike the 757/767 and later Boeings. All amber lights out means you're good to go, blue or green shows a system temporarily on which is normal, like A/I or window heat. Airbus also uses colours like blue and green to show that. So in this case Boeing and Airbus are not far apart.

 

Airbus pushbuttons positions can also be checked by feel, just like toggle switches. Normal position will mean the button is flush with the panel, abnormal means it will either be proud or recessed, depending on whether ON or OFF is the normal state. Boeing's switchlights aren't like that and rely on the illuminated mechanical indicator.

 

Embraer uses an extension of the dark cockpit philosophy with their rotary switches. Switches vertically aligned are in the normal/auto position. So a quick glance at the overhead with lights out, switches vertical means it is properly set.

I loved that system, just a quick glance on the A320 panel is all I need during the cruise flows and we can monitor whether a system is working or not through the ECAM status screens or check for any FAULT or off lights on on the overhead. I also prefer having buttons vs turn knobs (such as the apu) since information can be readily displayed on a button that you are about to push, just a personal preference.

 

I think you're on the wrong forum.. :lol: :lol: