The A2A Simulations Community

Hello

Is here someone who flies liners ? if so, i have a question regarding vnav behaviour, when changing baro setting for altimeter.

In normal VNAV cruise, above transition altitude, if the altitude readout changes because you set the barometric correction to something else (im not talking about setting the STANDARD ON, more like setting 29.92 manually and then changing it), will the aircraft automatically climb or descend to recapture the MCP altitude ? or will it do so only if the change in altitude readout is caused by an actual change in outside air pressure ?

It's been a while, but I'm pretty sure the aircraft will automatically adjust for changes if you dial in another altimeter setting without standard on on even above transition.

Thanks for an ansfer, what i observed in some payware planes, is that after the change i would need to disconnect the vnav and reconnect it to obtain climb/descent, thats why i was curious, it looks like an obvious thing, that these should do it without resetting vnav, but heck .

It happened only if i was already on established MCP altitude and then changed this parameter, not when i was climbing/descending at the moment,... strange.

Well, considering that standard is 29.92...

Real plane, the autopilot should automatically adjust as it's holding a pressure altitude, not absolute altitude, however if you're cruising over Transition Level, then it shouldn't be an issue because you should have already set STD pressure when passing TL. Same in the descent. You should leave the altimeter on STD until passing TA.

_________________

Yup, i agree , i was just messing with the stuff.

One more thing I just thought about though. If you're using VNAV and your cruise page is set to ECON Cruise, the plane may not climb or descend with altimeter changes because the FMC is attempting to fly the aircraft in the most energy conservative way possible. To climb or descend a few feet is a waste of energy and fuel, so unless the altitude moves more than 100 feet and stays there, the system may "reject" the altitude change as either erroneous or temporary and not change altitude for a certain amount of time or make very small corrections.

Now, mind you this would be with the real airplane. I can't speak to whether the FS version gets into that kind of sophisticated logic. Even with PMDG's very extensive programming, they are still using the default FSX autopilot basic functions behind everything so by cycling the VNAV button, you may be forcing the default autopilot logic on the sim and the airplane is changing altitudes even though the gauge programming was correctly not changing altitude.

_________________

Thanks for this suggestion, i checked this, setting the baro on both sides so the altitude difference betwenn MCP and altimeter was much greater than 100 feet , still i needed to give it a kick with the vnav button.

One more clarification if you may, vnav tracks the indications of the altimeter for the cruise altitude yes ?

I've never really gotten super deep into how the integrated autoflight system works, but the understanding I get is that with the FMC running the flight (i.e. VNAV and/or LNAV modes engaged) the pilots are somewhat taken out of the direct loop and certain things happen automatically based on what was entered into the FMC. Thus, once you get above Transition Level, the system rejects the manually set altimeter (thus why the yellow box around it) and flies based on standard altimeter setting (essentially meaning that the FMC has it's own "fourth" altimeter and Kollsman window that it sets itself) unless manually overrided. I don't know what will allow for manual override, but it's not just turning the altimeter selector on the MCP. It may be that recycling the VNAV mode does that, but the idea with the FMC is that its only concern is flying the airplane based on the profile given and pretty much ignoring anyone "mucking about" with other stuff, including being able to set and track radio navigation beacons independently of what the pilots are following. It's a really neat system when it works, but on the occasion it fails, it can be one hell of a kick in the pants.

_________________

Thanks for your time, i will need to dive more into the subject, luckily i already know more now .

Edit: I just went to the SmartCockipt site, and there is a test for 737ng with ALMOST the same question:

"When in ALT HOLD FL80 you change the barometric setting from STD to QNH 1030. What will the aircraft do?

1.The aircraft will climb 500 feet to the new pressure level
2.The aircraft will descend 500 feet to the new pressure level
3.You cannot change altitude when in ALT HOLD
4.The aircraft will continue at FL80 but the altitude readout will change

Turns out, that the number 4 is a correct ansfer.

Well vnav and altitude hold are quite different, but still, altitude hold CAN make small adjustments to the vertical speed isn't it? But it won't do it in this situation, same as vnav did in the sim, maybe there is a connection here.

ALT HLD is what it claims to be. It holds the present altitude. What you're thinking of is ALT SELECT/CMD (depending on make/model) which is a mode that the aircraft has prior to entering ALT HLD mode. On the real MCP's you can change the selected altitude in the MCP box and nothing will happen until you push in the rotator knob which enables ALT SELECT/CMD. There is a sub-mode, LVL CHNG which integrates the autothrottle either in N1 HOLD or IDLE DESCENT mode with the Vertical Speed being varied to maintain the commanded airspeed.

_________________

Does this mode kick in, when there is for example a strong wind or windshear that pushes the aircraft off the current altitude being held by ALT HOLD ? would there be an indication of this mode on the PFD ?

Well, neither crosswind or windshear would do so (they are both horizontal changes in velocity, not vertical), so it's not really germane, but I get the idea you're conveying.

The system is holding an altitude based on absolute pressure being input from the Air Data Computer. The plane doesn't necessarily "know" what altitude it is at, only the pressure being read by the static port. That pressure is then translated to altitude by taking into account the altimeter setting or standard pressure for display on the screens. When you're running any select or command mode, it is reading the translated data. When you're running in a hold mode (airspeed, altitude, even vertical speed to an extent) it is attempting to hold a set raw information (static pressure, dynamic pressure, or rate of static pressure change) as that information is much more precise coming in and doesn't suffer from the delay of needing to be translated first. Because of this, it tends to be able to be more accurate and react faster than you can because it "knows" that something is changing before the system has even started to show the change on the instruments in front of you.

_________________

So, the system doesn't wait for the altimeter readings, but gets its data directly from Air Data Computer in this mode, alright.

Would such a managment fit to some of the vnav modes too ?

...Windshear can create the circumstances, where i WILL come crushing down, and lose some altitude in the process, thats, what i meant

If you're in a position where windshear is significant enough to cause a stall, then you shouldn't be using ALT HLD anyway.

Windshear is not an instant thing when flying level (yes I know in FS it can be, but that's what FSUIPC, ActiveSky, or REX are for), so the airplane would be able to pitch sufficiently to retain altitude as the engines spool to begin recovering the lost/gained airspeed.

All autopilot operation is direct through the ADC raw feeds in one way or another. There is very little that is done down-stream from the cockpit displays on modern aircraft. The idea with doing it this way is that it makes the autoflight system more accurate and responsive when it isn't having to wait on the data to go into the ADC, get translated, sent to the displays, displayed, information sent back from the display and other inputs (like heading command bug and altitude command bug) get fed into the autoflight module and then the autopilot begin to respond. By taking the raw data and the only inputs being the command bug information for airspeed, heading, altitude, and vertical speed, the autoflight computer can then translate that once into a value that corresponds to a raw datapoint that it wants to maintain and then run from there, independent of the display data. This allows the autoflight computer to continue operating normally even if significant portions of the air data computer and flightdeck display computers are inoperable. As long as it's getting input from the raw data feed, the MCP command components, and/or the FMC command components, it can operate.

_________________

So i guess, this kind of behaviour that i spoke about at the begining of the topic can be a genuine autopilot logic for some of its modes, its not a 100% sure bet, as it can be an fs thing as well, but im much more calm about this case now.

Can windshear occur at cruising altitudes ? if so, vnav or alt hold would be most of the time running, i dont think, that a pilot would disconnect them, or maybe this is imperative to fly manually in those conditions