OK, one more on this subject, then if you want to talk to me about this it's going to have to be via PM (don't want to derail the thread further)
Originally Posted by
airtren
Whatever the extend of the ring was, the idiotic message went around, and it seems that nobody alerted the Moderator to delegate the impersonation problem to him.
Not so idiotic if you bear in mind the situation at the time, and I figured that if the mods had to be involved then the people giving me a heads-up would be doing so themselves.
But to help with your implying of unawareness of what was going on regarding your post, I will remind you that you were cc-ed on my communication to the moderator, so you were well aware of the link between your post, my reaction, my request to the moderator, and the removing of your post, so had plenty of info of why your post was removed.
And I heard nothing from the moderator other than noticing in passing that the post, along with a number of others, had been removed.
Nevertheless you continued recently in two instances, with repeating the spreading of context of the older idiotic messages...
Am I not permitted to be only partially convinced? It may be a coincidence, but your language skills seem to go to pot in similar ways when you get agitated.
This is so ridiculously amateurish ...
Do you need me to teach you how to act like a computer professional?
If you don't have access to the IP addresses, the Moderator does, and if he doesn't, the WEB master does, and so you should have asked the Moderator to look into it, if you had a suspicion, and wait for their answer, before posting publicly content of idiotic PMs...
Look, I've been posting on forums of all kinds for 15 years. As much as I have a high regard for this place, sorting out interpersonal spats and catching sockpuppeting is considerably low on my list of priorities - if the mod team take an interest, or if someone wants to get the mod team involved, that's down to them. Also, being a netizen (eurgh) that could be considered somewhat "old-school" I remember the days when this sort of thing was sorted out between users without resorting to "telling teacher". In most cases, the mod teams are busy sorting out obvious trolling and deliberate manure-blending and don't need to be bothered about a bunch of people who've got the wrong end of the stick about something.
As for "amateurish", when I'm getting paid for something, you have my undivided attention and will receive my best efforts. When I'm taking part in a conversation in my down-time it's my own damn business how involved I want to get. If I have reason to suspect I'm being played, I take that as an insult and tend to respond accordingly
Right - let's get on-topic.
Originally Posted by
airtren
I have asked you a clarification on your mentioning of the Airbus design problem with the pitot tubes, and you have not provided that yet. That's not even a new question like you've asked.
I can't find it using the search function. Apologies if it sounds rude, but would you care to repeat the question?
Anyway - a couple of minor corrections:
An algorithm is simply a set of instructions followed to take data in, perform an operation with it, and pass data out - these are the basic "bricks" of software. A program tends to consist of a collection of algorithms that perform a specific task, and would be a "wall", to continue the construction analogy. A system in software terms is a collection of programs that together perform the tasks required by the end user, so these would be a "building". Requirements are gathered from end users (in this case pilots, aero engineers and airlines). Specification tends to happen from the top down, based on those requirements, so you'd start with a system specification, break that down into the program modules required, and then each program module is broken down into the required algorithms. The A320 project was probably the most exhaustively specified software project of it's kind at the time, and I should know because I've seen examples! The algorithms themselves were deliberately designed with as few lines of code as possible to keep the implementation simple, and where the heavy intellectual lifting was required was using and combining those simple algorithms to meet the specification.
Implementation in this case involved the low-level algorithms being coded as per usual (albeit tested at a level several orders of magnitude higher than even the average safety-critical project), but rather than "hand-stitch" them together (and potentially introduce errors), the software team developed a graphical logic-tree builder to build the systems up. The individual modules were then exhaustively tested, and then each system was exhaustively tested by feeding them flight data captured from existing aircraft and also data outside the specified limits of operation in order to make sure that no logical errors had crept in. They then performed regression testing, which basically bombards the software with a lifetime's worth of flight data over the course of a few days and studied the output to see if there were any issues, fixing accordingly. This testing and refinement process alone went on for almost a year, if I recall correctly.
No system is perfect, but this one had to fall in line with aviation certification requirements, and as such the chances of failure had to fit an infinitessimally small number.
So that's a slightly off-topic ramble out of the way, just to drive home that anything that comes out of this regarding stall warning or anything else relates to the original requirements and specification, not the design or implementation.
CONF - the "IMO" regarding yokes pleases me greatly, and makes all the difference to how I read what you're saying.
Originally Posted by
airtren
Firstly, I suspect your making the assumption that the visual information and sound information are of same duration, which is not correct.
The visual information duration needed is a fraction of a second.
The sound information duration is the time needed to pronounce the words, perceive the words, and transpose that mentally in a mental visual image of what that means - a couple, to perhaps several seconds.
That difference of a couple, to several seconds, is not infinitesimal in my math at all - particularly when the time to take actions is very limited, measured in seconds, or tens of seconds.
That's fine theoretically, but realistically would you grab the control column or stick from your colleague without first verifying what is going on? Except in the extremest of circumstances I can't imagine that being the case. Whether you see/feel movement in a fraction of a second or a second or two via the instruments, would it not be prudent to first find out why they're doing what they appear to be doing?
While the difference may not be infinitesimal taken in isolation, in this case the zoom climb lasted for approxmately a minute before the aircraft stalled and began to descend, which gives, based on your numbers plus, say 10 seconds to confirm, at least 45 seconds to take control and perform corrective action before the aircraft stalls, and at a conservative estimate another 45 seconds while the aircraft is stalled to begin effecting a recovery before it passes through 30,000ft on the way down.