Assuming the engine can be configured properly, you can get out of a stall in a number of ways. Angle of attack (the angle between where the nose points and the aircraft moves, in case anyone wonders) would be one of them, but keeping track of your nose pitch (and weight) will also work relatively well.
zeke has a good example (post 65). I wouldn't necessarily recommend that forum as an overview though unless you intend to read all ~1300 posts.;-) As you could imagine there is a certain number of posters in there that got a little carried away with their ideas. Possibly another thread might help.
My information suggests that the sensors feeding the black box either cannot or were not made available to the primary flight instrument computers, astonishingly enough.
It would indeed be astonishing. Based on all your posts here you seem to be saying that:
- One of the ADIRUs (responsible for providing air and inertial data) gave up completely. Airspeed has nothing to do with inertial data such as attitude, and furthermore there is no reason to stop providing altitude information unless the three (3) static ports showed any differences. I think it's a pretty safe estimation based on the official BEA reports so far that the underlying inputs were not a problem there. For the ADIRU to shut off completely, solely because of lack of valid airspeed information, would be a curious vulnerability to say the least, it's not how it's designed, and again we have nothing to demonstrate this.
- Somehow the other two ADIRUs also gave up completely. See above. Alternatively you have suggested that one component (such as one of the ADIRUs) may affect another independent component. This is highly speculative and we have nothing to indicate that either.
- Somehow the ISIS (providing information such as airspeed, attitude, and altitude) failed. More speculation. It is heavily isolated - it has mechanical inputs - pneumatic lines for pitot/static, and internal components for attitude calculation - and a backup power supply.
I could note that there are some people out there who read the maintenance messages sent by the aircraft, one of them mentioning ISIS. What they don't say is that it refers solely to the display of airspeed. Similar grave errors are made in interpreting the maintenance messages and various known facts. Somewhere down the line someone saying "I don't know anything about this, but maybe X, Y and Z happened" becomes "experts know that X, Y and Z happened".
Let me say this again: if someone is saying that we know that other fundamentals than airspeed / stall warning was indicated erroneously, they are not basing it on published BEA data. Prove me wrong if you can. Everything should be in there along with some explanations, so please read the reports.
They don't have GPS or even ground/ocean-bouncing radar to give them altitude info?
GPS altitude should have been available if selected. Radio altimeter has a very limited range (normally displayed below 2,500 feet or so). These two and the altimeter might be about it in terms of precise altitude.
However, the altimeter should have been working anyway. There's no evidence to conclude that any of the static ports malfunctioned, or any unrelated and independent functions such as the three artificial horizons for that matter. In fact the CVR shows they were aware of their altitude when nearing 10,000 feet.
I don't believe that any AoA indication was available in this particular A330, other than indirectly through the stall warning (which unfortunately had design limits and thus was somewhat inconsistent, read the latest report).
Still, there's no evidence to conclude that they lost any fundamental information other than airspeed indications anyway.
Let's get some facts straight, please. Everything below is based on the official report as of May 27 and the aircraft behaviour as I know it (IANAP, but I've read up quite a bit). Most if not all news reports I have read on this story have proven to be unreliable on some level (including WSJ and whatnot), many significantly so.
the pilots flew into a thunderstorm
What we can assume is that they expected only a slight increase in turbulence. The pilot in control of flying the plane told the cabin crew: "in two minutes we should enter an area where it’ll move about a bit more than at the moment, you should watch out". They also made a left turn shortly after that in hopes of avoiding even that, and then the turbulence "increased slightly".
As for visibility, they probably had no visual references prior to entering the storm. For instance, as far as I can tell with Celestia the moon was not visible from their location at 0200 UTC on 20090601.
once all 3 pitots froze
We only know for sure that 2 of the indicated airspeeds were incorrect at some points, probably due to icing in the pitot tubes. The third was not recorded.
the redundant computers started disagreeing and then finally agreed that things were ugly
the effect in the cockpit is that a serious of cascading failures were unfolding
Yes, the speed inconsistency lead to the following among other things:
- alternate law in effect (see below),
- autopilot disconnecting, and
- autothrust disconnecting (although I understand the engine thrust would have stayed the same at this point until a pilot altered it).
likely overwhelming the pilots
This is pure speculation at this point.
additionally, there would be NO functional indicators for alt, speed, horizon, etc.
Wrong. There's no evidence to support malfunctioning fundamental indicators other than loss of airspeed indication, and perhaps the somewhat inconsistent stall warning.
Once the computers have faulted, they no longer share that information
See previous point.
Also, as the computers degrade authority, in an Airbus the pilots get MORE control of the aircraft.
This is a fair statement. They degraded into alternate law.
This means that controls move through larger ranges.
More or less so (stalling etc. possible), but the computers still have an intermediary role so for instance they could not go beyond max G loads in this particular mode.
As flight control reverts to failsafe mode, the controls in the cockpit do not "auto-zero".
Are you talking about auto trim? Auto trim was still available, as shown in the report. (If the aircraft had degraded into direct law, it would have been disabled.)
And the forcefeedback goes off line.
There's no force feedback that I'm aware of, other than a stick shaker during indicated stall.
Effectively, the pilots are 100% blind, and the inputs they make have no feedback whatsoever.
The report clearly states that the engines responded, and the report seems to be consistent with the aircraft responding to all "mainly nose-up" inputs by one or both pilots. What was displayed to the pilots was inconsistent for a time, yes, but again many of the instruments may never have failed at all.
They cannot even tell if they have _stopped trying_ to turn.
What do you base that on? Again other than the stall warning and airspeed indications there is every reason to believe that many if not all other instruments were working, such as:
Art. 52 of the European Patent Convention (EPC) says clearly that software is not patentable. Yet, the EPO says it is. (But not "as such". Translation: black is white, because the money says so.)
there will always be the threat of passing some kind of legislation in the future that will enforce European software patents There is already EPLA, pushed by the EPO and currently being processed in the Council. In practice, this would give the EPO judiciary power, so they could enforce the patents they granted erroneously in the first place. Great, isn't it?
The problem is not the wording of the EPC, it's the EPO's twisting of it. But - since the EPO is not an EU institution - the Parliament, Commission or Council have no say there to stop this. In this sense, the debate is "over" for a while... In any other sense, the Commission comfortably ignores that software patents are granted here.
It'll be truly fascinating to see what rhetoric will be used next, to promote software patents while denying it.
Slashdot Mirror
Angle of attack (the angle between where the nose points and the aircraft moves, in case anyone wonders)
s/nose/wing/ to be a little more precise here. (More info.)
Assuming the engine can be configured properly, you can get out of a stall in a number of ways. Angle of attack (the angle between where the nose points and the aircraft moves, in case anyone wonders) would be one of them, but keeping track of your nose pitch (and weight) will also work relatively well. zeke has a good example (post 65). I wouldn't necessarily recommend that forum as an overview though unless you intend to read all ~1300 posts. ;-) As you could imagine there is a certain number of posters in there that got a little carried away with their ideas. Possibly another thread might help.
My information suggests that the sensors feeding the black box either cannot or were not made available to the primary flight instrument computers, astonishingly enough.
It would indeed be astonishing. Based on all your posts here you seem to be saying that:
- One of the ADIRUs (responsible for providing air and inertial data) gave up completely. Airspeed has nothing to do with inertial data such as attitude, and furthermore there is no reason to stop providing altitude information unless the three (3) static ports showed any differences. I think it's a pretty safe estimation based on the official BEA reports so far that the underlying inputs were not a problem there. For the ADIRU to shut off completely, solely because of lack of valid airspeed information, would be a curious vulnerability to say the least, it's not how it's designed, and again we have nothing to demonstrate this.
- Somehow the other two ADIRUs also gave up completely. See above. Alternatively you have suggested that one component (such as one of the ADIRUs) may affect another independent component. This is highly speculative and we have nothing to indicate that either.
- Somehow the ISIS (providing information such as airspeed, attitude, and altitude) failed. More speculation. It is heavily isolated - it has mechanical inputs - pneumatic lines for pitot/static, and internal components for attitude calculation - and a backup power supply.
I could note that there are some people out there who read the maintenance messages sent by the aircraft, one of them mentioning ISIS. What they don't say is that it refers solely to the display of airspeed. Similar grave errors are made in interpreting the maintenance messages and various known facts. Somewhere down the line someone saying "I don't know anything about this, but maybe X, Y and Z happened" becomes "experts know that X, Y and Z happened".
Let me say this again: if someone is saying that we know that other fundamentals than airspeed / stall warning was indicated erroneously, they are not basing it on published BEA data. Prove me wrong if you can. Everything should be in there along with some explanations, so please read the reports.
They don't have GPS or even ground/ocean-bouncing radar to give them altitude info?
GPS altitude should have been available if selected. Radio altimeter has a very limited range (normally displayed below 2,500 feet or so). These two and the altimeter might be about it in terms of precise altitude.
However, the altimeter should have been working anyway. There's no evidence to conclude that any of the static ports malfunctioned, or any unrelated and independent functions such as the three artificial horizons for that matter. In fact the CVR shows they were aware of their altitude when nearing 10,000 feet.
All aircraft have a "safe-mode" angle of attack
I don't believe that any AoA indication was available in this particular A330, other than indirectly through the stall warning (which unfortunately had design limits and thus was somewhat inconsistent, read the latest report).
Still, there's no evidence to conclude that they lost any fundamental information other than airspeed indications anyway.
the pilots flew into a thunderstorm
What we can assume is that they expected only a slight increase in turbulence. The pilot in control of flying the plane told the cabin crew: "in two minutes we should enter an area where it’ll move about a bit more than at the moment, you should watch out". They also made a left turn shortly after that in hopes of avoiding even that, and then the turbulence "increased slightly". As for visibility, they probably had no visual references prior to entering the storm. For instance, as far as I can tell with Celestia the moon was not visible from their location at 0200 UTC on 20090601.
once all 3 pitots froze
We only know for sure that 2 of the indicated airspeeds were incorrect at some points, probably due to icing in the pitot tubes. The third was not recorded.
the redundant computers started disagreeing and then finally agreed that things were ugly
the effect in the cockpit is that a serious of cascading failures were unfolding
Yes, the speed inconsistency lead to the following among other things:
- alternate law in effect (see below),
- autopilot disconnecting, and
- autothrust disconnecting (although I understand the engine thrust would have stayed the same at this point until a pilot altered it).
likely overwhelming the pilots
This is pure speculation at this point.
additionally, there would be NO functional indicators for alt, speed, horizon, etc.
Wrong. There's no evidence to support malfunctioning fundamental indicators other than loss of airspeed indication, and perhaps the somewhat inconsistent stall warning.
Once the computers have faulted, they no longer share that information
See previous point.
Also, as the computers degrade authority, in an Airbus the pilots get MORE control of the aircraft.
This is a fair statement. They degraded into alternate law.
This means that controls move through larger ranges.
More or less so (stalling etc. possible), but the computers still have an intermediary role so for instance they could not go beyond max G loads in this particular mode.
As flight control reverts to failsafe mode, the controls in the cockpit do not "auto-zero".
Are you talking about auto trim? Auto trim was still available, as shown in the report. (If the aircraft had degraded into direct law, it would have been disabled.)
And the forcefeedback goes off line.
There's no force feedback that I'm aware of, other than a stick shaker during indicated stall.
Effectively, the pilots are 100% blind, and the inputs they make have no feedback whatsoever.
The report clearly states that the engines responded, and the report seems to be consistent with the aircraft responding to all "mainly nose-up" inputs by one or both pilots. What was displayed to the pilots was inconsistent for a time, yes, but again many of the instruments may never have failed at all.
They cannot even tell if they have _stopped trying_ to turn.
What do you base that on? Again other than the stall warning and airspeed indications there is every reason to believe that many if not all other instruments were working, such as:
- Information from GPS etc. (such as g
Note that the post is a dupe from a number of weeks ago.
Wow. Considering the prices, I suspect they have some hidden bonus features. How about if the cables also have:
In fact, I bet they have wireless support as well. :-)
Yea, OK...
On a more serious note, as another poster points out, the original seller is not doing much better in terms of behaviour.
The blog post that TFA refers to should be this one:
http://blog.armorize.com/2010/08/iframes-and-url-stringency-mozilla.html
(Yea, their typing skills don't impress me either.)
That in turn links to a BugZilla entry, though it's locked down at the moment.
The problem is not the wording of the EPC, it's the EPO's twisting of it. But - since the EPO is not an EU institution - the Parliament, Commission or Council have no say there to stop this. In this sense, the debate is "over" for a while... In any other sense, the Commission comfortably ignores that software patents are granted here.
It'll be truly fascinating to see what rhetoric will be used next, to promote software patents while denying it.