How Was This Even LEGAL?! | The Tragic Story of MK Airlines Flight 1602

Overview

The video recounts the crash of MK Airlines Flight 1602, focusing on how a software/performance calculation error—enabled by fatigue, weak training, and broken safety barriers—led to a fatal underpowered takeoff from Halifax (Runway 24) in the early hours of October 2004.

Background: aircraft, crew, and operational pressure

• Aircraft: A Boeing 747 freighter (built in 1980, later converted to a dedicated freighter). It had extensive flight experience but no obvious mechanical red flags.
• Operational demands: The planned route required multiple long-distance legs with demanding duty patterns.
• Crew staffing constraint: The first officer had to be present for every takeoff and landing across the trip due to qualification restrictions (neither captain was a “training captain”).
• Organizational emphasis (as presented): The video describes MK Airlines’ reliance on “family” trust and informal peer oversight.
• Investigation findings (as presented): Later investigations found high turnover and that understaffing was increasingly addressed by stretching duty times rather than reducing schedules.

MK Airlines as an organization: “flexibility” turning into corner-cutting

The video describes MK’s origins in a region where airlines often had to operate with limited infrastructure and spare parts, fostering self-reliance. Over time, the company grew globally while retaining a small-airline culture:

• Long duty periods, often exceeding limits (scheduled 24 hours, with real exceedances far beyond that).
• Frequent ground delays and operational disruptions, with crews expected to absorb them.
• Weak oversight, because MK Airlines held its certificate in Ghana—meaning Ghana’s aviation authority did not effectively scrutinize duty-time and flight operations.
• Highlighted warning: A warning sent by the Flight 1602 captain to the company is used as evidence that pilots were already concerned about staffing shortages and the risk of fatigue worsening.

Lead-up to the fatal departure (Halifax)

Before Flight 1602’s Halifax takeoff, the earlier leg (Flight 1601) had been delayed and affected by issues such as:

• Late aircraft arrival from Johannesburg
• Excess cargo requiring unloading
• Cargo contamination requiring cleaning/handling to satisfy import restrictions

By the time Flight 1602 departed, the video emphasizes that crews were extremely fatigued, noting:

• Long duty times for pilots
• Extended, near-continuous work for ground/load personnel

The core technical chain: correct weight, wrong performance

• In Halifax, the aircraft loaded about 353 tons (within certified limits).
• Takeoff performance was calculated using Boeing’s BLT (Laptop Tool), designed to reduce errors via built-in checks and layered confirmation steps:
  • Loadmaster manual load planning
  • Optional independent BLT entry by the loadmaster
  • First officer calculates performance and copies/uses takeoff cards
  • Captain should independently repeat checks
  • A final “gross error check” compares speeds/EPR for plausibility

Investigators’ reconstruction (central finding)

The video presents investigators’ reconstruction as follows:

• The first officer likely handled the BLT incorrectly due to memory/interaction between software pages:
  • After the BLT reopened in reduced thrust mode (carrying previous data from the Bradley departure),
  • the operator may have opened/closed the weight & balance page without updating it,
  • causing the software to silently copy the Bradley weight (~240 tons) into the planned weight field on the performance page.
• As a result, the BLT produced takeoff numbers appropriate for a much lighter aircraft:
  • EPR ~1.3 and rotation speed ~129 knots (reduced thrust/performance),
  • instead of near‑maximum-thrust values needed for ~353 tons:
    • EPR ~1.6, rotation ~162 knots

Why the safety barriers failed

The video argues that although independent cross-checks should have caught the mismatch (wrong weight → implausible speeds/EPR), those checks were likely not actually performed.

Contributing factors proposed include:

• Extreme fatigue
• Insufficient familiarity/training with BLT behaviors
• Informal operating practices and reluctance to challenge peers
• Organizational schedule design that assumed humans could keep making safety-critical decisions under severe fatigue

The accident sequence

• The aircraft began its takeoff roll on Runway 24 with thrust set to the erroneously low reduced setting.
• The 747 accelerated too slowly and rotated at too low a speed for the actual weight.
• It became airborne late and too close to obstacles, with the tail striking the localizer antenna barrier beyond the runway.
• The tail was torn away, flight control was lost, and the aircraft crashed into the forest.
• All seven crew members died.

Role of the obstacle (localizer barrier)

The video stresses that investigators found the barrier (berm/localizer base) met relevant optical clearance requirements and was not considered a primary cause.

• Boeing’s reconstruction suggested the aircraft might still have hit trees even if the berm hadn’t been present.
• However, the berm impact made recovery impossible by destroying the tail.

Investigative outcome and broader lessons

Because the aircraft was destroyed, key evidence was lost (including the cockpit voice recording tape, which melted, and the takeoff card, which was not recovered). Investigators therefore relied on:

• Flight data recorder reconstruction
• Software re-performance

Immediate cause (as presented)

• Mismatch between aircraft weight and computed takeoff performance

Organizational conclusion (as presented)

• Safety barriers degraded over time.

TSB recommendation (as presented)

• Equip aircraft with systems that monitor takeoff performance and warn pilots if acceleration is insufficient—ideally allowing rejection before rotation.

Stated takeaways from the video

• Improve UI/design to prevent silent wrong-mode/wrong-page interactions
• Provide formal training and testing for takeoff computation tools
• Show software-used weight more clearly on final takeoff documentation
• Require strict independent repetition of critical calculations
• Never schedule operations assuming error-free performance while crews are profoundly fatigued

Presenters or contributors

• Peter Hornfeld (host / presenter; “Mentor Pilot”)
• Canadian Transportation Safety Board (TSB) (investigative body referenced)
• Boeing (software behavior and reconstruction referenced)
• NordVPN (sponsor mentioned)