Air India 787 Crashes in Western India

tobnpr said:
That would be the incident aircraft, 787-8...
Click to expand...
No it isn’t. The -8 in your link is a turboprop DeHavillan of Canada. Did you read the link you posted?
 
Last edited:
tobnpr said:
Very interesting.
Documented electrical problems immediately prior to the incident would certainly be relevant. Wonder if any dash-8 pilots can see a possible correlation.
Click to expand...
Doesn't the air conditioning always suck when they're on the ground not moving? I'm not so sure there's actual issues in that clip.
 
Racerx said:
I'm not so sure there's actual issues in that clip.
Click to expand...
I've read where it takes three GPUs or an APU to run the AC. When unavailable, some pilots have used the "ground test enable" switch to run one pack off of just one or two GPUs — though not approved by Boeing. I wish I could find more information online. If that was being done, then the question is, "What would happen if the switch remained in "Enable" rather than "Normal" for engine start and takeoff?" Would be nice to hear from somebody with Boeing experience.

EDIT: Here's what Google's AI says:
​
If the ground test enable switch on a b787-8 is in the 'enable" position, would the pilots be unable to start the engines and make a takeoff?​
​
Based on the provided search results, it seems that if the Ground Test Enable switch on a Boeing 787-8 is in the 'enable' position during attempted engine start and takeoff, it could cause issues with engine start and potentially compromise the ability to safely make a takeoff, but not directly by inhibiting engine start in all cases.​
Here's why:​
  • Ground Test Enable for engineers/maintenance: The Ground Test Enable switch is primarily intended for maintenance personnel to run specific system tests on the ground that would normally be inhibited. It allows systems to operate during tests that would otherwise be restricted.
  • Running CACs from external power: Some pilots have used the Ground Test Enable switch to run the cabin air conditioning (CAC) system from external ground power when only two GPUs are connected. Normally, this requires either the APU or three GPUs.
  • Extra load on ground power: Using the Ground Test Enable switch to run systems like the CAC from only two GPUs places a significant load on the external power source, which could potentially cause it to trip off.
  • Compromised troubleshooting: If engineers are working on the aircraft and the Ground Test Enable switch is in the 'enable' position, it's possible that troubleshooting results could be compromised.
  • Engine start requires sufficient power: The 787's engines are started electrically, and the aircraft requires sufficient electrical power, usually from the APU or external power, to perform a successful engine start.
  • Three GPUs are often necessary for engine start: According to one source, you cannot start the engines with just one GPU attached. Starting both engines simultaneously may be possible with sufficient electrical power.
  • Not a standard operational procedure: Running systems like CACs from external power with the Ground Test Enable switch engaged is not an approved Boeing procedure and is not recommended by the design team.
  • Potential hazards: There are potential hazards associated with using this switch without being fully aware of the aircraft's status.
Therefore, while the Ground Test Enable switch doesn't directly prevent engine start in all cases, using it improperly, especially during preparations for takeoff, could lead to unexpected electrical system behavior, compromised systems, or insufficient power for a successful engine start. This would prevent a timely and safe takeoff.​
​
AI responses may include mistakes. Learn more​
 
Last edited:
dtuuri said:
I've read where it takes three GPUs or an APU to run the AC. When unavailable, some pilots have used the "ground test enable" switch to run one pack off of just one or two GPUs — though not approved by Boeing. I wish I could find more information online. If that was being done, then the question is, "What would happen if the switch remained in "Enable" rather than "Normal" for engine start and takeoff?" Would be nice to hear from somebody with Boeing experience.

EDIT: Here's what Google's AI says:
​
If the ground test enable switch on a b787-8 is in the 'enable" position, would the pilots be unable to start the engines and make a takeoff?​
​
Based on the provided search results, it seems that if the Ground Test Enable switch on a Boeing 787-8 is in the 'enable' position during attempted engine start and takeoff, it could cause issues with engine start and potentially compromise the ability to safely make a takeoff, but not directly by inhibiting engine start in all cases.​
Here's why:​
  • Ground Test Enable for engineers/maintenance: The Ground Test Enable switch is primarily intended for maintenance personnel to run specific system tests on the ground that would normally be inhibited. It allows systems to operate during tests that would otherwise be restricted.
  • Running CACs from external power: Some pilots have used the Ground Test Enable switch to run the cabin air conditioning (CAC) system from external ground power when only two GPUs are connected. Normally, this requires either the APU or three GPUs.
  • Extra load on ground power: Using the Ground Test Enable switch to run systems like the CAC from only two GPUs places a significant load on the external power source, which could potentially cause it to trip off.
  • Compromised troubleshooting: If engineers are working on the aircraft and the Ground Test Enable switch is in the 'enable' position, it's possible that troubleshooting results could be compromised.
  • Engine start requires sufficient power: The 787's engines are started electrically, and the aircraft requires sufficient electrical power, usually from the APU or external power, to perform a successful engine start.
  • Three GPUs are often necessary for engine start: According to one source, you cannot start the engines with just one GPU attached. Starting both engines simultaneously may be possible with sufficient electrical power.
  • Not a standard operational procedure: Running systems like CACs from external power with the Ground Test Enable switch engaged is not an approved Boeing procedure and is not recommended by the design team.
  • Potential hazards: There are potential hazards associated with using this switch without being fully aware of the aircraft's status.
Therefore, while the Ground Test Enable switch doesn't directly prevent engine start in all cases, using it improperly, especially during preparations for takeoff, could lead to unexpected electrical system behavior, compromised systems, or insufficient power for a successful engine start. This would prevent a timely and safe takeoff.​
​
AI responses may include mistakes. Learn more​
Click to expand...
So it seems the only possible way it would affect takeoff is if it prevented engine start. But I don't see anything in there suggesting that there'd be any effects after the engine is started.
 
Last edited:
For reference, the 787 was built with more electrical systems then most other airliners. The air packs, one hydraulic system, and a few other systems are electric vs pneumatic/hydraulic based. So the electrical systems and redundancy systems are somewhat complex as well as the load shedding architecture. However, its the design direction most OEMs are pursuing in an attempt to squeeze out all the efficiencies with the existing legacy designs. Will be interesting to know what if any electrical system issues the aircraft had on the previous flight and prior to the accident flight.
 
Lindberg said:
So it seems the only possible way it would affect takeoff is if it prevented engine start. But I don't see anything in there suggesting that there'd be any effects after the engine is started.
Click to expand...
Here is chatgpt's take on the ground test switch: (Don't shoot the messenger.)

On a $300 million aircraft like the Boeing 787-8, failure to prevent takeoff under known unsafe configurations—such as having the Ground Test Enable switch in "ENABLE"—would indicate a software and systems design failure, not just pilot error.

Key Points:

1. Fail-Safe Design Expectation:
Modern aircraft software is expected to lock out or inhibit critical operations—such as takeoff or thrust application—if the system is in a test or maintenance configuration that compromises safety. This is standard in fail-safe engineering, particularly on fly-by-wire aircraft like the 787.

2. Comparative Precedents:
Airbus aircraft, for instance, incorporate takeoff configuration warnings that inhibit takeoff when flight controls, flaps, trim, or systems are not in an acceptable state. A ground-test mode should logically trigger a similar constraint, especially if it affects flight control laws, electrical logic, or air data processing.

3. Pilot Responsibility vs. System Responsibility:
While crews are responsible for preflight checks, human error is expected and mitigated in aviation through layered design defenses. If an obscure or easily-overlooked switch allows the aircraft to enter a state unfit for flight, and no automated system blocks engine start, taxi, or takeoff thrust, the primary fault lies with software and certification compliance, not the crew.

4. If This Occurred on Air India:

Assigning blame solely to the pilots would be an overreach, especially if:

The switch was not accompanied by prominent ECAM/ECIS alerts, or

There was no takeoff configuration warning, or

The Ground Test Mode allowed silent overrides of protections.

Boeing and regulatory oversight would bear responsibility for certifying a system that permits such a lapse.

Conclusion:

On an aircraft of this complexity and cost, software should prevent or at minimum warn explicitly if the aircraft is in test mode. If that fails, and a takeoff is initiated, blame cannot credibly be limited to the flight crew. It becomes a design failure, and reflects systemic accountability lapses.
 
Himayeti said:
Here is chatgpt's take on the ground test switch: (Don't shoot the messenger.)

On a $300 million aircraft like the Boeing 787-8, failure to prevent takeoff under known unsafe configurations—such as having the Ground Test Enable switch in "ENABLE"—would indicate a software and systems design failure, not just pilot error.

Key Points:

1. Fail-Safe Design Expectation:
Modern aircraft software is expected to lock out or inhibit critical operations—such as takeoff or thrust application—if the system is in a test or maintenance configuration that compromises safety. This is standard in fail-safe engineering, particularly on fly-by-wire aircraft like the 787.

2. Comparative Precedents:
Airbus aircraft, for instance, incorporate takeoff configuration warnings that inhibit takeoff when flight controls, flaps, trim, or systems are not in an acceptable state. A ground-test mode should logically trigger a similar constraint, especially if it affects flight control laws, electrical logic, or air data processing.

3. Pilot Responsibility vs. System Responsibility:
While crews are responsible for preflight checks, human error is expected and mitigated in aviation through layered design defenses. If an obscure or easily-overlooked switch allows the aircraft to enter a state unfit for flight, and no automated system blocks engine start, taxi, or takeoff thrust, the primary fault lies with software and certification compliance, not the crew.

4. If This Occurred on Air India:

Assigning blame solely to the pilots would be an overreach, especially if:

The switch was not accompanied by prominent ECAM/ECIS alerts, or

There was no takeoff configuration warning, or

The Ground Test Mode allowed silent overrides of protections.

Boeing and regulatory oversight would bear responsibility for certifying a system that permits such a lapse.

Conclusion:

On an aircraft of this complexity and cost, software should prevent or at minimum warn explicitly if the aircraft is in test mode. If that fails, and a takeoff is initiated, blame cannot credibly be limited to the flight crew. It becomes a design failure, and reflects systemic accountability lapses.
Click to expand...
What were your prompts?
 
MauleSkinner said:
“Hey, ChatGPT, I just took off in my 787, and both engines quit. I’m 183 feet off the ground. What should I do?”
Click to expand...
I thought it would be more appropriate to ask my Copilot, not ChatGPT:

"Hey, Copilot, I just took off in my 787, and both engines quit. I’m 183 feet off the ground. What should I do?"​
​
David, that sounds like a critical situation. If this is a real emergency, contact air traffic control immediately and follow established emergency procedures.​
​
​
Assuming you're describing a simulation or training scenario, here’s what would typically be expected in an event like this in a Boeing 787:​
​
​
  • Pitch for best glide speed immediately to preserve altitude and control.
  • Maintain aircraft control—fly the plane first, then troubleshoot.
  • If altitude is extremely low (183 feet), look for a suitable landing area straight ahead, as turning back may not be an option.
  • Alert ATC and declare an emergency if possible.
  • Attempt an engine restart only if there's enough time and altitude—at 183 feet, priorities are likely limited to aviate and land.
​
Would you like to walk through a specific simulator procedure, or are we working through a scenario together?​
 
MauleSkinner said:
“Hey, ChatGPT, I just took off in my 787, and both engines quit. I’m 183 feet off the ground. What should I do?”
Click to expand...
"Cook pork along with onion and garlic until cooked through but not tender. Strain out extra pork liquid, reserving for sauce. Add pork back into the pot, cooking until slightly brown.

"Toast arbol chiles and rehydrate guajillos. Add arbol chiles, guajillo peppers, onion, garlic, cloves, whole cumin seeds, all-purpose flour, reserved strained pork liquid, and salt to a blender and blend until smooth, reserving some of the finished sauce for later. Strain guajillo sauce over the pork and add some water, then cook until thickened.

"Boil water in a large pot. Off-heat, add dried cork husks, pushing to submerge them in the water. Soak for at least 30 minutes."
 
dtuuri said:
I thought it would be more appropriate to ask my Copilot, not ChatGPT:

"Hey, Copilot, I just took off in my 787, and both engines quit. I’m 183 feet off the ground. What should I do?"​
​
David, that sounds like a critical situation. If this is a real emergency, contact air traffic control immediately and follow established emergency procedures.​
​
​
Assuming you're describing a simulation or training scenario, here’s what would typically be expected in an event like this in a Boeing 787:​
​
​
  • Pitch for best glide speed immediately to preserve altitude and control.
  • Maintain aircraft control—fly the plane first, then troubleshoot.
  • If altitude is extremely low (183 feet), look for a suitable landing area straight ahead, as turning back may not be an option.
  • Alert ATC and declare an emergency if possible.
  • Attempt an engine restart only if there's enough time and altitude—at 183 feet, priorities are likely limited to aviate and land.
​
Would you like to walk through a specific simulator procedure, or are we working through a scenario together?​
Click to expand...
I used to have a friend who said that “CRM is a bunch of BS. If I’m taking off in an overloaded C-46 and an engine quits, I’m not going to slide my seat back, pour a cup of coffee, and ask the copilot what he thinks I should do. I’m gonna feather the #@%* thing!”

I said, “Bob, if you start to push the wrong feather button, is it acceptable if the copilot slaps your hand away from the button?”

“Well, of course!”

Me: “THAT’S CRM!”

:rofl:
 
MauleSkinner said:
“Hey, ChatGPT, I just took off in my 787, and both engines quit. I’m 183 feet off the ground. What should I do?”
Click to expand...
1) Place your heels on the glareshield while tightly seat belted in your seat. 2) Lean forward aggressively placing your head as far as possible between your knees. 3) In this position you should be able to see your backside ... kiss it goodbye! :biggrin:
 
And here is Deepseek, the Chinese AI. Again, don't shoot the messenger.

Based on the available investigation details from the search results, I surmise the following sequence of events and probable causes for the Air India Flight 171 crash:

### ⚙️ 1. **Catastrophic Power Loss**
- The crew's **mayday call** explicitly reported "loss of power and thrust" seconds after takeoff .
- Data confirmed the **Ram Air Turbine (RAT)** deployed during the crash, indicating a total electrical failure . This emergency system activates only when primary and backup power are lost.
- ADS-B tracking showed the aircraft stalled at **625 feet** before plummeting at ~475 ft/min, consistent with dual-engine failure .

### 2. **Potential Causes of Power Loss**
- **Engine Failure**:
- Both **GE GEnx-1B engines** likely failed simultaneously. The right engine was newly installed (March 2025), while the left was due for maintenance in December 2025 .
- Investigators are examining **fuel contamination**, **FADEC system faults** (which autonomously manage engine performance), or **mechanical defects** in Life Limited Parts .
- **Electrical System Sabotage or Error**:
- The **ground switch theory** (if left enabled) could cause power conflicts, though modern safeguards make this improbable without compounded failures .
- Separate **digital video recorders** from cabin/external cameras were recovered and may reveal internal anomalies .

### ️ 3. **Contributing Factors**
- **Maintenance Lapses**: An Indian aviation audit revealed recurring defects and "unserviceable ground equipment" in Air India's operations . The DGCA ordered emergency checks on fuel systems, engine controls, and cabin compressors post-crash .
- **Aircraft Load & Configuration**:
- Landing gear reportedly remained extended post-takeoff, increasing drag .
- Flaps were confirmed properly configured, ruling out takeoff preparation errors .
- **Environmental Risks**: Densely populated areas around Ahmedabad airport amplified ground casualties. The plane struck a medical hostel, killing 34 on the ground .

### ‍✈️ 4. **Human & Operational Elements**
- **Pilot Response**: Captain Sumeet Sabharwal (8,200 flight hours) and First Officer Clive Kunder (1,100 hours) had limited time to react—only 30 seconds elapsed from takeoff to crash .
- **Airline Pressures**: Air India had recently merged with Vistara and faced operational strain, reducing flights by 15% post-crash due to "compounding circumstances" .

### Key Investigation Findings to Date
| **Investigation Focus** | **Findings** | **Significance** |
|-------------------------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
| **Black Boxes (EAFRs)** | Recovered; data shows RAT activation & thrust loss | Confirms dual-engine/power failure |
| **Engine Analysis** | Right engine new (March 2025); left last serviced 2023 | Rules out age-based failure but not defects |
| **Maintenance Records** | DGCA audit found "lapses" in Air India procedures; ordered fleet-wide checks | Suggests systemic safety gaps |
| **Aircraft Configuration** | Flaps correct; landing gear possibly extended | Excludes pilot error in setup; gear issue may indicate hydraulic failure |
| **Crash Site Forensics** | Extreme heat (1,500°C) hindered DNA identification ; fuel load for 10-hour flight ignited | Explains rapid fireball and high fatality rate |

### Conclusion
The crash likely resulted from a **dual-engine failure** triggered by fuel system defects, FADEC malfunctions, or maintenance oversights. The power loss caused an unrecoverable stall at low altitude. While terrorism was initially probed, no evidence supports it . Final determination awaits black box analysis (due July 2025) and engine teardowns . This tragedy exposes critical risks in **engine monitoring systems** and **maintenance rigor** for aging Dreamliners.

For ongoing updates, track DGCA reports or the AIB's 3-month preliminary findings .
 
Early assumption… RAT •••ONLY••• deploys with primary and backup electrical failure. It can be deployed.
 
Himayeti said:
And here is Deepseek, the Chinese AI. Again, don't shoot the messenger.

Based on the available investigation details from the search results, I surmise the following sequence of events and probable causes for the Air India Flight 171 crash:

### ⚙️ 1. **Catastrophic Power Loss**
- The crew's **mayday call** explicitly reported "loss of power and thrust" seconds after takeoff .
- Data confirmed the **Ram Air Turbine (RAT)** deployed during the crash, indicating a total electrical failure . This emergency system activates only when primary and backup power are lost.
- ADS-B tracking showed the aircraft stalled at **625 feet** before plummeting at ~475 ft/min, consistent with dual-engine failure .

### 2. **Potential Causes of Power Loss**
- **Engine Failure**:
- Both **GE GEnx-1B engines** likely failed simultaneously. The right engine was newly installed (March 2025), while the left was due for maintenance in December 2025 .
- Investigators are examining **fuel contamination**, **FADEC system faults** (which autonomously manage engine performance), or **mechanical defects** in Life Limited Parts .
- **Electrical System Sabotage or Error**:
- The **ground switch theory** (if left enabled) could cause power conflicts, though modern safeguards make this improbable without compounded failures .
- Separate **digital video recorders** from cabin/external cameras were recovered and may reveal internal anomalies .

### ️ 3. **Contributing Factors**
- **Maintenance Lapses**: An Indian aviation audit revealed recurring defects and "unserviceable ground equipment" in Air India's operations . The DGCA ordered emergency checks on fuel systems, engine controls, and cabin compressors post-crash .
- **Aircraft Load & Configuration**:
- Landing gear reportedly remained extended post-takeoff, increasing drag .
- Flaps were confirmed properly configured, ruling out takeoff preparation errors .
- **Environmental Risks**: Densely populated areas around Ahmedabad airport amplified ground casualties. The plane struck a medical hostel, killing 34 on the ground .

### ‍✈️ 4. **Human & Operational Elements**
- **Pilot Response**: Captain Sumeet Sabharwal (8,200 flight hours) and First Officer Clive Kunder (1,100 hours) had limited time to react—only 30 seconds elapsed from takeoff to crash .
- **Airline Pressures**: Air India had recently merged with Vistara and faced operational strain, reducing flights by 15% post-crash due to "compounding circumstances" .

### Key Investigation Findings to Date
| **Investigation Focus** | **Findings** | **Significance** |
|-------------------------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
| **Black Boxes (EAFRs)** | Recovered; data shows RAT activation & thrust loss | Confirms dual-engine/power failure |
| **Engine Analysis** | Right engine new (March 2025); left last serviced 2023 | Rules out age-based failure but not defects |
| **Maintenance Records** | DGCA audit found "lapses" in Air India procedures; ordered fleet-wide checks | Suggests systemic safety gaps |
| **Aircraft Configuration** | Flaps correct; landing gear possibly extended | Excludes pilot error in setup; gear issue may indicate hydraulic failure |
| **Crash Site Forensics** | Extreme heat (1,500°C) hindered DNA identification ; fuel load for 10-hour flight ignited | Explains rapid fireball and high fatality rate |

### Conclusion
The crash likely resulted from a **dual-engine failure** triggered by fuel system defects, FADEC malfunctions, or maintenance oversights. The power loss caused an unrecoverable stall at low altitude. While terrorism was initially probed, no evidence supports it . Final determination awaits black box analysis (due July 2025) and engine teardowns . This tragedy exposes critical risks in **engine monitoring systems** and **maintenance rigor** for aging Dreamliners.

For ongoing updates, track DGCA reports or the AIB's 3-month preliminary findings .
Click to expand...
This is even more useless than necessary without knowing what you told and asked it.
 
Himayeti said:
Here is chatgpt's take on the ground test switch: (Don't shoot the messenger.)
Click to expand...
Himayeti said:
And here is Deepseek, the Chinese AI. Again, don't shoot the messenger.
Click to expand...

PLEASE. STOP.

AI doesn't know anything. It strings words together based on probabilities from the data it was trained on. And now they're feeding it the Internet.

In spite of that, yesterday I asked a popular AI to give me about 50 lines of easy-to-find, non-controversial data and it was only getting about the first 10-15 lines right. I kept updating the prompt, asking it to verify the data, and finally even specified a specific source, and it STILL couldn't get the numbers right. They were formatted exactly how I asked, but the numbers were just flat wrong even after I specified the exact source to get them from. Had I not checked the full series, it'd have been really easy to check the first 5-10 rows and assume the rest were correct.

But what's worse, is that when you post the crap answers that AI gives you right now on the Internet, you are also becoming part of the training data for future versions, which means that you're reinforcing the wrong answers for future users.

So, if you're going to use AI in private, knock yourself out (but I'd recommend you learn how to seek out true answers for yourself, using and developing critical thinking skills). But PLEASE don't repost these garbage answers on a public forum... And you won't have to ask anyone not to shoot you.
 
Last edited:
flyingcheesehead said:
PLEASE. STOP.

AI doesn't know anything. It strings words together based on probabilities from the data it was trained on. And now they're feeding it the Internet.

In spite of that, yesterday I asked a popular AI to give me about 50 lines of easy-to-find, non-controversial data and it was only getting about the first 10-15 lines right. I kept updating the prompt, asking it to verify the data, and finally even specified a specific source, and it STILL couldn't get the numbers right. They were formatted exactly how I asked, but the numbers were just flat wrong even after I specified the exact source to get them from. Had I not checked the full series, it'd have been really easy to check the first 5-10 rows and assume the rest were correct.

But what's worse, is that when you post the crap answers that AI gives you right now on the Internet, you are also becoming part of the training data for future versions, which means that you're reinforcing the wrong answers for future users.

So, if you're going to use AI in private, knock yourself out (but I'd recommend you learn how to seek out true answers for yourself, using and developing critical thinking skills). But PLEASE don't repost these garbage answers on a public forum... And you won't have to ask anyone not to shoot you.
Click to expand...
No. Keep the gibberish going. The more error prone and gibberish-ful we make "AI" the longer it is until Skynet arrives.

AND, more importantly, we can easier identify the lazy idiots that use it instead of using their brain. Though I guess if they had one (a brain), they wouldn't use ChatGPT or the like.
 
Himayeti said:
Here is chatgpt's take on the ground test switch: (Don't shoot the messenger.)

On a $300 million aircraft like the Boeing 787-8, failure to prevent takeoff under known unsafe configurations—such as having the Ground Test Enable switch in "ENABLE"—would indicate a software and systems design failure, not just pilot error.

Key Points:

1. Fail-Safe Design Expectation:
Modern aircraft software is expected to lock out or inhibit critical operations—such as takeoff or thrust application—if the system is in a test or maintenance configuration that compromises safety. This is standard in fail-safe engineering, particularly on fly-by-wire aircraft like the 787.

2. Comparative Precedents:
Airbus aircraft, for instance, incorporate takeoff configuration warnings that inhibit takeoff when flight controls, flaps, trim, or systems are not in an acceptable state. A ground-test mode should logically trigger a similar constraint, especially if it affects flight control laws, electrical logic, or air data processing.

3. Pilot Responsibility vs. System Responsibility:
While crews are responsible for preflight checks, human error is expected and mitigated in aviation through layered design defenses. If an obscure or easily-overlooked switch allows the aircraft to enter a state unfit for flight, and no automated system blocks engine start, taxi, or takeoff thrust, the primary fault lies with software and certification compliance, not the crew.

4. If This Occurred on Air India:

Assigning blame solely to the pilots would be an overreach, especially if:

The switch was not accompanied by prominent ECAM/ECIS alerts, or

There was no takeoff configuration warning, or

The Ground Test Mode allowed silent overrides of protections.

Boeing and regulatory oversight would bear responsibility for certifying a system that permits such a lapse.

Conclusion:

On an aircraft of this complexity and cost, software should prevent or at minimum warn explicitly if the aircraft is in test mode. If that fails, and a takeoff is initiated, blame cannot credibly be limited to the flight crew. It becomes a design failure, and reflects systemic accountability lapses.
Click to expand...

Himayeti said:
And here is Deepseek, the Chinese AI. Again, don't shoot the messenger.

Based on the available investigation details from the search results, I surmise the following sequence of events and probable causes for the Air India Flight 171 crash:

### ⚙️ 1. **Catastrophic Power Loss**
- The crew's **mayday call** explicitly reported "loss of power and thrust" seconds after takeoff .
- Data confirmed the **Ram Air Turbine (RAT)** deployed during the crash, indicating a total electrical failure . This emergency system activates only when primary and backup power are lost.
- ADS-B tracking showed the aircraft stalled at **625 feet** before plummeting at ~475 ft/min, consistent with dual-engine failure .

### 2. **Potential Causes of Power Loss**
- **Engine Failure**:
- Both **GE GEnx-1B engines** likely failed simultaneously. The right engine was newly installed (March 2025), while the left was due for maintenance in December 2025 .
- Investigators are examining **fuel contamination**, **FADEC system faults** (which autonomously manage engine performance), or **mechanical defects** in Life Limited Parts .
- **Electrical System Sabotage or Error**:
- The **ground switch theory** (if left enabled) could cause power conflicts, though modern safeguards make this improbable without compounded failures .
- Separate **digital video recorders** from cabin/external cameras were recovered and may reveal internal anomalies .

### ️ 3. **Contributing Factors**
- **Maintenance Lapses**: An Indian aviation audit revealed recurring defects and "unserviceable ground equipment" in Air India's operations . The DGCA ordered emergency checks on fuel systems, engine controls, and cabin compressors post-crash .
- **Aircraft Load & Configuration**:
- Landing gear reportedly remained extended post-takeoff, increasing drag .
- Flaps were confirmed properly configured, ruling out takeoff preparation errors .
- **Environmental Risks**: Densely populated areas around Ahmedabad airport amplified ground casualties. The plane struck a medical hostel, killing 34 on the ground .

### ‍✈️ 4. **Human & Operational Elements**
- **Pilot Response**: Captain Sumeet Sabharwal (8,200 flight hours) and First Officer Clive Kunder (1,100 hours) had limited time to react—only 30 seconds elapsed from takeoff to crash .
- **Airline Pressures**: Air India had recently merged with Vistara and faced operational strain, reducing flights by 15% post-crash due to "compounding circumstances" .

### Key Investigation Findings to Date
| **Investigation Focus** | **Findings** | **Significance** |
|-------------------------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
| **Black Boxes (EAFRs)** | Recovered; data shows RAT activation & thrust loss | Confirms dual-engine/power failure |
| **Engine Analysis** | Right engine new (March 2025); left last serviced 2023 | Rules out age-based failure but not defects |
| **Maintenance Records** | DGCA audit found "lapses" in Air India procedures; ordered fleet-wide checks | Suggests systemic safety gaps |
| **Aircraft Configuration** | Flaps correct; landing gear possibly extended | Excludes pilot error in setup; gear issue may indicate hydraulic failure |
| **Crash Site Forensics** | Extreme heat (1,500°C) hindered DNA identification ; fuel load for 10-hour flight ignited | Explains rapid fireball and high fatality rate |

### Conclusion
The crash likely resulted from a **dual-engine failure** triggered by fuel system defects, FADEC malfunctions, or maintenance oversights. The power loss caused an unrecoverable stall at low altitude. While terrorism was initially probed, no evidence supports it . Final determination awaits black box analysis (due July 2025) and engine teardowns . This tragedy exposes critical risks in **engine monitoring systems** and **maintenance rigor** for aging Dreamliners.

For ongoing updates, track DGCA reports or the AIB's 3-month preliminary findings .
Click to expand...
I find it amusing that someone who distrusts the automation in modern aircraft trusts current AI which is more complex, and provides much more rubbish because the data being supplied is also rubbish. The saying "garbage in = garbage out " applies just as much now as it did at the dawn of computing.
 
I gave up with the Google generation, who all thought they were smarter because of it…We are doomed by the ChatGPTgeneration…I’m calling it now…lol
 
Last edited:
Cap'n Jack said:
I find it amusing that someone who distrusts the automation in modern aircraft trusts current AI which is more complex, and provides much more rubbish because the data being supplied is also rubbish. The saying "garbage in = garbage out
Click to expand...
I think you're missing the point!

I am trying to highlight that it is these systems that are flying your plane and perhaps writing the code that controls them. If you find their answers insulting, (like many do here) to your intelligence, remember that these same software engines are being used to write the algorithms and code that controls your FADEC and every other system in your plane, and that by the way also logs every erroneous input you make in the cockpit.

So yes, the discussion must now be brought back to what role we want for automation in aviation. Do we want one extreme where it runs all, we have little input and are there just to sip coffee and wear cool Ray Bans? Or do we want to retain some control of the plane, where we share responsibility with these systems and can at times even fully override them.

Yes, automation has made flying safer. But these systems will sometimes fail. Are we to sit back and always allow the software to prioritize the plane instead of its passengers? Or should we reclaim some control of the cockpit, to be used in extreme cases when the automation algorithm fails at 600 ft on takeoff? Right now, full throttle is a FADEC request.

In a plane like a 787, automation does some 95% of the flying. Pilots still mostly control taxi, rotation and short visual approaches. Some in this forum will come back with other tasks, but again the point is that the list gets shorter every day. Even checklists today are just a human audit of the automation state. The plane knows well what it should do!

This is the real discussion that I suggest we need to have. Should we give up all control to automation? Or should we make the cockpit a workplace of shared responsibilities where we are passenger advocates and can override automation decisions in order to attempt to save them and not the plane.
 
Himayeti said:
Are we to sit back and always allow the software to prioritize the plane instead of its passengers? Or should we reclaim some control of the cockpit, to be used in extreme cases when the automation algorithm fails at 600 ft on takeoff?
Click to expand...
Except that argument went out the door 60+ years ago when fly-by-wire flight controls (and engine controls) started to be installed. So unless you want to revert back to physical control tubes and cables there is no path to reclaiming that control. However, if you dig a bit you'll find the software tends to be just fine. Its the physical sensors that are sending the corrupted signals which causes the software to react in the very way it was programed.
 
Himayeti said:
This is the real discussion that I suggest we need to have. Should we give up all control to automation? Or should we make the cockpit a workplace of shared responsibilities where we are passenger advocates and can override automation decisions in order to attempt to save them and not the plane.
Click to expand...

If you want to have a philosophical discussion about this, fine. But start a new thread, please. This isn't the place.
 
kayoh190 said:
If you want to have a philosophical discussion about this, fine. But start a new thread, please. This isn't the place.
Click to expand...
I think it IS the place, at least unless you know the crash was intentional by one or both of the pilots. If they didn't do it, then automation probably is the culprit. If so, this accident will surely be a game-changer for how much control we turn over to software programs going forward. Don't you want control of your fuel shut-off valve? I bet the dead pilots would if they could talk.
 
dtuuri said:
I think it IS the place, at least unless you know the crash was intentional by one or both of the pilots. If they didn't do it, then automation probably is the culprit. If so, this accident will surely be a game-changer for how much control we turn over to software programs going forward. Don't you want control of your fuel shut-off valve? I bet the dead pilots would if they could talk.
Click to expand...
I'm getting tired of people saying game changer. It's lost all meaning at this point. Were the mcas crashes also game changers?

And once again, this is still just rampant speculation.

What do we actually know besides it crashed. We don't actually know definitively they lost thrust. We don't know the RAT wasnt deployed by the guy claiming a loss of thrust. Certainly it's more likely it deployed automatically.

We do know it had an emergency on a previous flight. We do know maintenance in that country can be wishful thinking.

Automation may have contributed. But I don't think the only two likely causes are the crew did it or the automation did it. Which is why the discussion on automation should be in another thread.
 
I am doing pre-funding & pre-publication research that I don’t want to use AI for because I don’t trust that my questions and prompting won’t inform a competitor in my field or in another country. If I had a way to misinform AI about my topic I would definitely do so until I get published first.
 
flyingcheesehead said:
PLEASE. STOP.

AI doesn't know anything. It strings words together based on probabilities from the data it was trained on. And now they're feeding it the Internet…..
Click to expand...

So do we great majority of time … the so called “vast experience” that allows some of us to make instant connections that appear to outsiders as “knowing how to react” is the same process , we string together conclusions based on probabilities from the data we were trained on - when you see something and can extrapolate from what you see and arrive at certain conclusions is because you have seen this pattern before - thats all there is to it.
Admittedly, AI cannot come close to what we would refer as a genius or at least somebody with a creative streak … but most of us don’t either, most of us operate on daily basis using the same set of well learned patters we have acquired during our “data training” just like your typical AI and for a good reason - our brains are composed out of bazillions of binary switches that operate at the same level like basic computer transistors and approach complexity the same way.
 
Himayeti said:
I think you're missing the point!
Click to expand...
No, I'm not. First, you used a science fictional computer to make a point, next, you used a summary from AI that read much like the contents of this thread. It was a fair summary of the rumors floating around. I suspect your expertise is something other than writing software. I don't pretend to be a code expert, but I still need to understand it reasonably well.
Himayeti said:
I am trying to highlight that it is these systems that are flying your plane and perhaps writing the code that controls them. If you find their answers insulting, (like many do here) to your intelligence, remember that these same software engines are being used to write the algorithms and code that controls your FADEC and every other system in your plane, and that by the way also logs every erroneous input you make in the cockpit.
Click to expand...
These AI systems, such as Chat GPT and the others, aren't flying your plane. The AIs you cited are very different software from almost anything else you use. The software for our planes and commercial jets was created prior to AI becoming popular. People are using AI to write code, but capable people still look through the code. The AI generates exactly what someone asks for, but won't handle exceptional circumstances unless those were part of the query. In some ways, AI creating code may be better as it will "close" code blocks better. I've seen bugs from people failing to close loops or decisions. The compiler or interpreter should have caught them, but there was sufficient ambiguity that the problem appeared at run time. I've noticed bugs when a user entered data that was interpreted as a hex code, which later caused memory leaks.- an abbreviation for 10% ethyl acetate was entered as 10%EA which the system interpreted as something else. I don't know if AI generated code would have handled that any better or worse.
Himayeti said:
Yes, automation has made flying safer. But these systems will sometimes fail. Are we to sit back and always allow the software to prioritize the plane instead of its passengers? Or should we reclaim some control of the cockpit, to be used in extreme cases when the automation algorithm fails at 600 ft on takeoff? Right now, full throttle is a FADEC request.
Click to expand...
The failures are lapses in training, people cutting costs, or an unanticipated problems. In a small plane, there are some options at 600 feet, but in a 787, the best option with dual engines out is simply to pick the best place to crash because there isn't time for anything else. As we don't know whether the automation failed, this is a straw-person argument.
Himayeti said:
In a plane like a 787, automation does some 95% of the flying. Pilots still mostly control taxi, rotation and short visual approaches. Some in this forum will come back with other tasks, but again the point is that the list gets shorter every day. Even checklists today are just a human audit of the automation state. The plane knows well what it should do!
Click to expand...
The 777 and earlier aircraft seem to do most of the flying in the same fashion. This paragraph contradicts your earlier comments as I parse it, especially the last sentence.
 
dtuuri said:
I think it IS the place, at least unless you know the crash was intentional by one or both of the pilots. If they didn't do it, then automation probably is the culprit. If so, this accident will surely be a game-changer for how much control we turn over to software programs going forward. Don't you want control of your fuel shut-off valve? I bet the dead pilots would if they could talk.
Click to expand...
Or there was a mechanical or electrical problem. I don't see what the fuel shutoff valve has to do with anything until we have more suggesting a cause.
 
You must log in or register to reply here.
Back
Top