Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > aus.aviation > #27472 > unrolled thread
| Started by | Sylvia Else <sylvia@email.invalid> |
|---|---|
| First post | 2025-01-21 13:28 +0800 |
| Last post | 2025-01-28 15:57 +1100 |
| Articles | 20 on this page of 25 — 3 participants |
Back to article view | Back to aus.aviation
Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-21 13:28 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-23 04:21 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-23 12:50 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-23 20:09 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-24 14:14 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-24 19:21 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-24 21:59 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-25 03:46 +1100
Re: Dash-8 incorrect takeoff configuration. Daryl <dwalford@westpine.com.au> - 2025-01-25 09:19 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-25 13:17 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-25 19:34 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-25 16:44 +0800
Re: Dash-8 incorrect takeoff configuration. Daryl <dwalford@westpine.com.au> - 2025-01-25 22:36 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-25 22:12 +0800
Re: Dash-8 incorrect takeoff configuration. Daryl <dwalford@westpine.com.au> - 2025-01-26 09:36 +1100
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-26 10:07 +1100
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-26 02:21 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-26 16:29 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-26 20:14 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-27 12:17 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-27 19:52 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-27 16:56 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-28 04:33 +1100
Re: Dash-8 incorrect takeoff configuration. Sylvia Else <sylvia@email.invalid> - 2025-01-28 11:52 +0800
Re: Dash-8 incorrect takeoff configuration. "Rod Speed" <rod.speed.aaa@gmail.com> - 2025-01-28 15:57 +1100
Page 1 of 2 [1] 2 Next page →
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-21 13:28 +0800 |
| Subject | Dash-8 incorrect takeoff configuration. |
| Message-ID | <lv8pjuFqa3bU1@mid.individual.net> |
https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 It's time all public transport aircraft had takeoff performance monitoring, no matter the size. Sylvia.
[toc] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-23 04:21 +1100 |
| Message-ID | <op.20sc59v9byq249@pvr2.lan> |
| In reply to | #27472 |
Sylvia Else <sylvia@email.invalid> wrote > https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 > It's time all public transport aircraft had takeoff performance > monitoring, no matter the size. That isnt going to result in the problem being fixed quickly enough to stop an accident
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-23 12:50 +0800 |
| Message-ID | <lve051Fl5i1U1@mid.individual.net> |
| In reply to | #27473 |
On 23-Jan-25 1:21 am, Rod Speed wrote: > Sylvia Else <sylvia@email.invalid> wrote > >> https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 > >> It's time all public transport aircraft had takeoff performance >> monitoring, no matter the size. > > That isnt going to result in the problem being fixed quickly enough to > stop an accident Well before an abort becomes risky, the system has enough information to determine whether the crew calculated v1 and vr are correct, and whether the aircraft will be able to both continue a takeoff, and stop, at v1. It can issue an abort alert if not. This covers at least miscalculated v1, miscalculated vr, wrong thrust settings, wrong flap settings, starting from the wrong intersection, takeoff from the wrong runway, and no doubt others that I haven't even thought of. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-23 20:09 +1100 |
| Message-ID | <op.20tk2vlxbyq249@pvr2.lan> |
| In reply to | #27474 |
Sylvia Else <sylvia@email.invalid> wrote > Rod Speed wrote >> Sylvia Else <sylvia@email.invalid> wrote >>> https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 >>> It's time all public transport aircraft had takeoffperformance >>> monitoring, no matter the size. >> That isnt going to result in the problem beingfixed quickly enough to >> stop an accident > Well before an abort becomes risky, the system has enough informationto > determine whether the crew calculated v1 and vr are correct, Bullshit with that incorrect flaps setting. > and whether the aircraft will be able toboth continue a takeoff, and > stop, at v1. Bullshit with that incorrect flaps setting, let alone tell the pilots that the flaps setting is wrong. It would make much more sense to compare the actual settings with that has been entered at the preflight config calculations and tell the pilots that they have not set what was required with flaps and boost etc before they actually applied takeoff power and not allow takeoff power to be applied before those were set correctly. > It can issue an abort alert if not. See above > This covers at least miscalculated v1, miscalculated vr, wrong thrust > settings, wrong flap settings, starting from the wrong intersection, > takeoff from the wrong runway, and no doubt others that I haven't even > thought of. It would be stupid to try to measure that while taking off instead of doing that before takeoff power is applied Yes, there is also a different problem with the engines not being able to deliver the power they were assumed to be able to deliver the power they were supposed to be able to deliver in the preflight calculations, but that was not the case in the incident being discussed and it would be much easier to discover than much earlier in the takeoff run than V1 or VR
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-24 14:14 +0800 |
| Message-ID | <lvgpdlF3t5nU2@mid.individual.net> |
| In reply to | #27475 |
On 23-Jan-25 5:09 pm, Rod Speed wrote: > Sylvia Else <sylvia@email.invalid> wrote >> Rod Speed wrote >>> Sylvia Else <sylvia@email.invalid> wrote > >>>> https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 > >>>> It's time all public transport aircraft had takeoffperformance >>>> monitoring, no matter the size. > >>> That isnt going to result in the problem beingfixed quickly enough >>> to stop an accident > >> Well before an abort becomes risky, the system has enough >> informationto determine whether the crew calculated v1 and vr are >> correct, > > Bullshit with that incorrect flaps setting. > >> and whether the aircraft will be able toboth continue a takeoff, and >> stop, at v1. > > Bullshit with that incorrect flaps setting, let alone > tell the pilots that the flaps setting is wrong. > > It would make much more sense to compare the > actual settings with that has been entered at the > preflight config calculations and tell the pilots > that they have not set what was required with > flaps and boost etc before they actually applied > takeoff power and not allow takeoff power to be > applied before those were set correctly. > >> It can issue an abort alert if not. > > See above > >> This covers at least miscalculated v1, miscalculated vr, wrong thrust >> settings, wrong flap settings, starting from the wrong intersection, >> takeoff from the wrong runway, and no doubt others that I haven't even >> thought of. > > It would be stupid to try to measure that while taking off > instead of doing that before takeoff power is applied > > Yes, there is also a different problem with the engines > not being able to deliver the power they were assumed > to be able to deliver the power they were supposed to > be able to deliver in the preflight calculations, but that > was not the case in the incident being discussed and > it would be much easier to discover than much earlier > in the takeoff run than V1 or VR The question the system needs to ask is "In the current configuration, with the measured acceleration [*], current airspeed, and current position on the current runway, can the aircraft reach the specified V1 at a point where it can continue the takeoff or abort, and will it be able to rotate at the specified Vr. [*] This also gives a reasonable estimate of the mass, assuming that the engine thrust is as commanded, or the engine thrust assuming that the mass is as configured, and allows an abort alert if the mass, acceleration, and thrust are not consistent with each other. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-24 19:21 +1100 |
| Message-ID | <op.20vdh9dzbyq249@pvr2.lan> |
| In reply to | #27476 |
Sylvia Else <sylvia@email.invalid> wrote > Rod Speed wrote >> Sylvia Else <sylvia@email.invalid> wrote >>> Rod Speed wrote >>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 >>>>> It's time all public transport aircraft had takeoff >>>>> performance monitoring, no matter the size. >>>> That isnt going to result in the problem being >>>> fixed quickly enough to stop an accident >>> Well before an abort becomes risky, the system has enough >>> informationto determine whether the crew calculated v1 and vr are >>> correct, >> Bullshit with that incorrect flaps setting. >>> and whether the aircraft will be able toboth continue a takeoff, and >>> stop, at v1. >> Bullshit with that incorrect flaps setting, let alone >> tell the pilots that the flaps setting is wrong. >> It would make much more sense to compare the >> actual settings with that has been entered at the >> preflight config calculations and tell the pilots >> that they have not set what was required with >> flaps and boost etc before they actually applied >> takeoff power and not allow takeoff power to be >> applied before those were set correctly. >>> It can issue an abort alert if not. >> See above >>> This covers at least miscalculated v1, miscalculated vr, wrong thrust >>> settings, wrong flap settings, starting from the wrong intersection, >>> takeoff from the wrong runway, and no doubt others that I haven't even >>> thought of. >> It would be stupid to try to measure that while taking off >> instead of doing that before takeoff power is applied >> Yes, there is also a different problem with the engines >> not being able to deliver the power they were assumed >> to be able to deliver the power they were supposed to >> be able to deliver in the preflight calculations, but that >> was not the case in the incident being discussed and >> it would be much easier to discover than much earlier >> in the takeoff run than V1 or VR > The question the system needs to ask is "In the current configuration, > with the measured acceleration [*], current airspeed, and current > position on the current runway, can the aircraft reach the specified V1 > at a point where it can continue the takeoff or abort, and will it be > able to rotate at the specified Vr. The problem with that approach is that is far too late during the takeoff run to be doing that by measurement when its much too late for the pilots to be fixing what the problem is, particularly when the engines arent actually performing the way they were meant to when the prefight calculations were done Like I said, it makes much more sense to check that the pilots have set what they have caculated nees to be set before takeoff power is allowed to be applied > [*] This also gives a reasonable estimate of the mass, assuming that the > engine thrust is as commanded, or the engine thrust assuming that the > mass is as configured, and allows an abort alert if the mass, > acceleration, and thrust are not consistent with each other. Not reasible to measure that during the takeoff run before V1
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-24 21:59 +0800 |
| Message-ID | <lvhkmqF8lmsU1@mid.individual.net> |
| In reply to | #27477 |
On 24-Jan-25 4:21 pm, Rod Speed wrote: > Sylvia Else <sylvia@email.invalid> wrote >> Rod Speed wrote >>> Sylvia Else <sylvia@email.invalid> wrote >>>> Rod Speed wrote >>>>> Sylvia Else <sylvia@email.invalid> wrote > >>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 > >>>>>> It's time all public transport aircraft had takeoff >>>>>> performance monitoring, no matter the size. > >>>>> That isnt going to result in the problem being >>>>> fixed quickly enough to stop an accident > >>>> Well before an abort becomes risky, the system has enough >>>> informationto determine whether the crew calculated v1 and vr are >>>> correct, > >>> Bullshit with that incorrect flaps setting. > >>>> and whether the aircraft will be able toboth continue a takeoff, >>>> and stop, at v1. > >>> Bullshit with that incorrect flaps setting, let alone >>> tell the pilots that the flaps setting is wrong. > >>> It would make much more sense to compare the >>> actual settings with that has been entered at the >>> preflight config calculations and tell the pilots >>> that they have not set what was required with >>> flaps and boost etc before they actually applied >>> takeoff power and not allow takeoff power to be >>> applied before those were set correctly. > >>>> It can issue an abort alert if not. > >>> See above > >>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>> thrust settings, wrong flap settings, starting from the wrong >>>> intersection, takeoff from the wrong runway, and no doubt others >>>> that I haven't even thought of. > >>> It would be stupid to try to measure that while taking off >>> instead of doing that before takeoff power is applied > >>> Yes, there is also a different problem with the engines >>> not being able to deliver the power they were assumed >>> to be able to deliver the power they were supposed to >>> be able to deliver in the preflight calculations, but that >>> was not the case in the incident being discussed and >>> it would be much easier to discover than much earlier >>> in the takeoff run than V1 or VR > >> The question the system needs to ask is "In the current configuration, >> with the measured acceleration [*], current airspeed, and current >> position on the current runway, can the aircraft reach the specified >> V1 at a point where it can continue the takeoff or abort, and will it >> be able to rotate at the specified Vr. > > The problem with that approach is that is far too late > during the takeoff run to be doing that by measurement > when its much too late for the pilots to be fixing what > the problem is, particularly when the engines arent > actually performing the way they were meant to when > the prefight calculations were done There would be no expectation that the pilots would fix it. The idea is to abort the takeoff while that can still be done safely. > > Like I said, it makes much more sense to check that > the pilots have set what they have caculated nees to > be set before takeoff power is allowed to be applied > >> [*] This also gives a reasonable estimate of the mass, assuming that >> the engine thrust is as commanded, or the engine thrust assuming that >> the mass is as configured, and allows an abort alert if the mass, >> acceleration, and thrust are not consistent with each other. > > Not reasible to measure that during the takeoff run before V1 Why not? Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-25 03:46 +1100 |
| Message-ID | <op.20v0u0ikbyq249@pvr2.lan> |
| In reply to | #27478 |
Sylvia Else <sylvia@email.invalid> wrote > Rod Speed wrote >> Sylvia Else <sylvia@email.invalid> wrote >>> Rod Speed wrote >>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> Rod Speed wrote >>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/report/ao-2024-038 >>>>>>> It's time all public transport aircraft had takeoff >>>>>>> performance monitoring, no matter the size. >>>>>> That isnt going to result in the problem being >>>>>> fixed quickly enough to stop an accident >>>>> Well before an abort becomes risky, the system has enough >>>>> informationto determine whether the crew calculated v1 and vr are >>>>> correct, >>>> Bullshit with that incorrect flaps setting. >>>>> and whether the aircraft will be able toboth continue a takeoff, >>>>> and stop, at v1. >>>> Bullshit with that incorrect flaps setting, let alone >>>> tell the pilots that the flaps setting is wrong. >>>> It would make much more sense to compare the >>>> actual settings with that has been entered at the >>>> preflight config calculations and tell the pilots >>>> that they have not set what was required with >>>> flaps and boost etc before they actually applied >>>> takeoff power and not allow takeoff power to be >>>> applied before those were set correctly. >>>>> It can issue an abort alert if not. >>>> See above >>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>> thrust settings, wrong flap settings, starting from the wrong >>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>> that I haven't even thought of. >>>> It would be stupid to try to measure that while taking off >>>> instead of doing that before takeoff power is applied >>>> Yes, there is also a different problem with the engines >>>> not being able to deliver the power they were assumed >>>> to be able to deliver the power they were supposed to >>>> be able to deliver in the preflight calculations, but that >>>> was not the case in the incident being discussed and >>>> it would be much easier to discover than much earlier >>>> in the takeoff run than V1 or VR >>> The question the system needs to ask is "In the current configuration, >>> with the measured acceleration [*], current airspeed, and current >>> position on the current runway, can the aircraft reach the specified >>> V1 at a point where it can continue the takeoff or abort, and will it >>> be able to rotate at the specified Vr. >> The problem with that approach is that is far too late >> during the takeoff run to be doing that by measurement >> when its much too late for the pilots to be fixing what >> the problem is, particularly when the engines arent >> actually performing the way they were meant to when >> the prefight calculations were done > There would be no expectation that the pilots would fix it. The idea is > to abort the takeoff while that can still be done safely. No way to detect the wrong flap setting by measurement of the aircraft performance before V1, that is only going to be possible once its past VR and the pilots discover that the plane won't leave the runway when it is sposed to. Even if you are attempting to determine if the engines are performing properly and something in the engines has failed to deliver the thrust they should be delivering or TOGA has not been commanded, there is no way to measure that the plane has not reached V1 by the time it was supposed to.. >> Like I said, it makes much more sense to check that >> the pilots have set what they have caculated nees to >> be set before takeoff power is allowed to be applied >>> [*] This also gives a reasonable estimate of the mass, assuming that >>> the engine thrust is as commanded, or the engine thrust assuming that >>> the mass is as configured, and allows an abort alert if the mass, >>> acceleration, and thrust are not consistent with each other. >> Not reasible to measure that during the takeoff run before V1 > Why not? See above
[toc] | [prev] | [next] | [standalone]
| From | Daryl <dwalford@westpine.com.au> |
|---|---|
| Date | 2025-01-25 09:19 +1100 |
| Message-ID | <lvihukFd5foU1@mid.individual.net> |
| In reply to | #27478 |
On 25/1/2025 12:59 am, Sylvia Else wrote: > On 24-Jan-25 4:21 pm, Rod Speed wrote: >> Sylvia Else <sylvia@email.invalid> wrote >>> Rod Speed wrote >>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> Rod Speed wrote >>>>>> Sylvia Else <sylvia@email.invalid> wrote >> >>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ >>>>>>> report/ao-2024-038 >> >>>>>>> It's time all public transport aircraft had takeoff >>>>>>> performance monitoring, no matter the size. >> >>>>>> That isnt going to result in the problem being >>>>>> fixed quickly enough to stop an accident >> >>>>> Well before an abort becomes risky, the system has enough >>>>> informationto determine whether the crew calculated v1 and vr are >>>>> correct, >> >>>> Bullshit with that incorrect flaps setting. >> >>>>> and whether the aircraft will be able toboth continue a takeoff, >>>>> and stop, at v1. >> >>>> Bullshit with that incorrect flaps setting, let alone >>>> tell the pilots that the flaps setting is wrong. >> >>>> It would make much more sense to compare the >>>> actual settings with that has been entered at the >>>> preflight config calculations and tell the pilots >>>> that they have not set what was required with >>>> flaps and boost etc before they actually applied >>>> takeoff power and not allow takeoff power to be >>>> applied before those were set correctly. >> >>>>> It can issue an abort alert if not. >> >>>> See above >> >>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>> thrust settings, wrong flap settings, starting from the wrong >>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>> that I haven't even thought of. >> >>>> It would be stupid to try to measure that while taking off >>>> instead of doing that before takeoff power is applied >> >>>> Yes, there is also a different problem with the engines >>>> not being able to deliver the power they were assumed >>>> to be able to deliver the power they were supposed to >>>> be able to deliver in the preflight calculations, but that >>>> was not the case in the incident being discussed and >>>> it would be much easier to discover than much earlier >>>> in the takeoff run than V1 or VR >> >>> The question the system needs to ask is "In the current >>> configuration, with the measured acceleration [*], current airspeed, >>> and current position on the current runway, can the aircraft reach >>> the specified V1 at a point where it can continue the takeoff or >>> abort, and will it be able to rotate at the specified Vr. >> >> The problem with that approach is that is far too late >> during the takeoff run to be doing that by measurement >> when its much too late for the pilots to be fixing what >> the problem is, particularly when the engines arent >> actually performing the way they were meant to when >> the prefight calculations were done > > There would be no expectation that the pilots would fix it. The idea is > to abort the takeoff while that can still be done safely. I assume that you are talking about some sort of automated system to alert pilots of a configuration error? If so wouldn't that rely on data input by the pilots prior to takeoff so the system would be only as good as the data therefore it doesn't completely eliminate the chances of an error? In this incident did the pilots self report? If they didn't why would the ATSB investigate? -- Daryl
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-25 13:17 +0800 |
| Message-ID | <lvjafdFgsnkU1@mid.individual.net> |
| In reply to | #27480 |
On 25-Jan-25 6:19 am, Daryl wrote: > On 25/1/2025 12:59 am, Sylvia Else wrote: >> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>> Sylvia Else <sylvia@email.invalid> wrote >>>> Rod Speed wrote >>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>> Rod Speed wrote >>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>> >>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ >>>>>>>> report/ao-2024-038 >>> >>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>> performance monitoring, no matter the size. >>> >>>>>>> That isnt going to result in the problem being >>>>>>> fixed quickly enough to stop an accident >>> >>>>>> Well before an abort becomes risky, the system has enough >>>>>> informationto determine whether the crew calculated v1 and vr are >>>>>> correct, >>> >>>>> Bullshit with that incorrect flaps setting. >>> >>>>>> and whether the aircraft will be able toboth continue a takeoff, >>>>>> and stop, at v1. >>> >>>>> Bullshit with that incorrect flaps setting, let alone >>>>> tell the pilots that the flaps setting is wrong. >>> >>>>> It would make much more sense to compare the >>>>> actual settings with that has been entered at the >>>>> preflight config calculations and tell the pilots >>>>> that they have not set what was required with >>>>> flaps and boost etc before they actually applied >>>>> takeoff power and not allow takeoff power to be >>>>> applied before those were set correctly. >>> >>>>>> It can issue an abort alert if not. >>> >>>>> See above >>> >>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>> that I haven't even thought of. >>> >>>>> It would be stupid to try to measure that while taking off >>>>> instead of doing that before takeoff power is applied >>> >>>>> Yes, there is also a different problem with the engines >>>>> not being able to deliver the power they were assumed >>>>> to be able to deliver the power they were supposed to >>>>> be able to deliver in the preflight calculations, but that >>>>> was not the case in the incident being discussed and >>>>> it would be much easier to discover than much earlier >>>>> in the takeoff run than V1 or VR >>> >>>> The question the system needs to ask is "In the current >>>> configuration, with the measured acceleration [*], current airspeed, >>>> and current position on the current runway, can the aircraft reach >>>> the specified V1 at a point where it can continue the takeoff or >>>> abort, and will it be able to rotate at the specified Vr. >>> >>> The problem with that approach is that is far too late >>> during the takeoff run to be doing that by measurement >>> when its much too late for the pilots to be fixing what >>> the problem is, particularly when the engines arent >>> actually performing the way they were meant to when >>> the prefight calculations were done >> >> There would be no expectation that the pilots would fix it. The idea >> is to abort the takeoff while that can still be done safely. > > I assume that you are talking about some sort of automated system to > alert pilots of a configuration error? > If so wouldn't that rely on data input by the pilots prior to takeoff so > the system would be only as good as the data therefore it doesn't > completely eliminate the chances of an error? > In this incident did the pilots self report? > If they didn't why would the ATSB investigate? > > > > I sent a reply to this, but I'm not seeing it. If you can't see it either, I'll post it again. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-25 19:34 +1100 |
| Message-ID | <op.20w8r9rcbyq249@pvr2.lan> |
| In reply to | #27481 |
On Sat, 25 Jan 2025 16:17:01 +1100, Sylvia Else <sylvia@email.invalid> wrote: > On 25-Jan-25 6:19 am, Daryl wrote: >> On 25/1/2025 12:59 am, Sylvia Else wrote: >>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> Rod Speed wrote >>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> Rod Speed wrote >>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>> >>>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ >>>>>>>>> report/ao-2024-038 >>>> >>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>> performance monitoring, no matter the size. >>>> >>>>>>>> That isnt going to result in the problem being >>>>>>>> fixed quickly enough to stop an accident >>>> >>>>>>> Well before an abort becomes risky, the system has enough >>>>>>> informationto determine whether the crew calculated v1 and vr are >>>>>>> correct, >>>> >>>>>> Bullshit with that incorrect flaps setting. >>>> >>>>>>> and whether the aircraft will be able toboth continue a takeoff, >>>>>>> and stop, at v1. >>>> >>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>> tell the pilots that the flaps setting is wrong. >>>> >>>>>> It would make much more sense to compare the >>>>>> actual settings with that has been entered at the >>>>>> preflight config calculations and tell the pilots >>>>>> that they have not set what was required with >>>>>> flaps and boost etc before they actually applied >>>>>> takeoff power and not allow takeoff power to be >>>>>> applied before those were set correctly. >>>> >>>>>>> It can issue an abort alert if not. >>>> >>>>>> See above >>>> >>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>>> that I haven't even thought of. >>>> >>>>>> It would be stupid to try to measure that while taking off >>>>>> instead of doing that before takeoff power is applied >>>> >>>>>> Yes, there is also a different problem with the engines >>>>>> not being able to deliver the power they were assumed >>>>>> to be able to deliver the power they were supposed to >>>>>> be able to deliver in the preflight calculations, but that >>>>>> was not the case in the incident being discussed and >>>>>> it would be much easier to discover than much earlier >>>>>> in the takeoff run than V1 or VR >>>> >>>>> The question the system needs to ask is "In the current >>>>> configuration, with the measured acceleration [*], current airspeed, >>>>> and current position on the current runway, can the aircraft reach >>>>> the specified V1 at a point where it can continue the takeoff or >>>>> abort, and will it be able to rotate at the specified Vr. >>>> >>>> The problem with that approach is that is far too late >>>> during the takeoff run to be doing that by measurement >>>> when its much too late for the pilots to be fixing what >>>> the problem is, particularly when the engines arent >>>> actually performing the way they were meant to when >>>> the prefight calculations were done >>> >>> There would be no expectation that the pilots would fix it. The idea >>> is to abort the takeoff while that can still be done safely. >> I assume that you are talking about some sort of automated system to >> alert pilots of a configuration error? >> If so wouldn't that rely on data input by the pilots prior to takeoff >> so the system would be only as good as the data therefore it doesn't >> completely eliminate the chances of an error? >> In this incident did the pilots self report? >> If they didn't why would the ATSB investigate? > I sent a reply to this, but I'm not seeing it. If you can't see it > either, I'll post it again. Definitely some glitch, please try sending again
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-25 16:44 +0800 |
| Message-ID | <lvjmkaFiof3U1@mid.individual.net> |
| In reply to | #27480 |
On 25-Jan-25 6:19 am, Daryl wrote: > On 25/1/2025 12:59 am, Sylvia Else wrote: >> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>> Sylvia Else <sylvia@email.invalid> wrote >>>> Rod Speed wrote >>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>> Rod Speed wrote >>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>> >>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ >>>>>>>> report/ao-2024-038 >>> >>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>> performance monitoring, no matter the size. >>> >>>>>>> That isnt going to result in the problem being >>>>>>> fixed quickly enough to stop an accident >>> >>>>>> Well before an abort becomes risky, the system has enough >>>>>> informationto determine whether the crew calculated v1 and vr are >>>>>> correct, >>> >>>>> Bullshit with that incorrect flaps setting. >>> >>>>>> and whether the aircraft will be able toboth continue a takeoff, >>>>>> and stop, at v1. >>> >>>>> Bullshit with that incorrect flaps setting, let alone >>>>> tell the pilots that the flaps setting is wrong. >>> >>>>> It would make much more sense to compare the >>>>> actual settings with that has been entered at the >>>>> preflight config calculations and tell the pilots >>>>> that they have not set what was required with >>>>> flaps and boost etc before they actually applied >>>>> takeoff power and not allow takeoff power to be >>>>> applied before those were set correctly. >>> >>>>>> It can issue an abort alert if not. >>> >>>>> See above >>> >>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>> that I haven't even thought of. >>> >>>>> It would be stupid to try to measure that while taking off >>>>> instead of doing that before takeoff power is applied >>> >>>>> Yes, there is also a different problem with the engines >>>>> not being able to deliver the power they were assumed >>>>> to be able to deliver the power they were supposed to >>>>> be able to deliver in the preflight calculations, but that >>>>> was not the case in the incident being discussed and >>>>> it would be much easier to discover than much earlier >>>>> in the takeoff run than V1 or VR >>> >>>> The question the system needs to ask is "In the current >>>> configuration, with the measured acceleration [*], current airspeed, >>>> and current position on the current runway, can the aircraft reach >>>> the specified V1 at a point where it can continue the takeoff or >>>> abort, and will it be able to rotate at the specified Vr. >>> >>> The problem with that approach is that is far too late >>> during the takeoff run to be doing that by measurement >>> when its much too late for the pilots to be fixing what >>> the problem is, particularly when the engines arent >>> actually performing the way they were meant to when >>> the prefight calculations were done >> >> There would be no expectation that the pilots would fix it. The idea >> is to abort the takeoff while that can still be done safely. > > I assume that you are talking about some sort of automated system to > alert pilots of a configuration error? > If so wouldn't that rely on data input by the pilots prior to takeoff so > the system would be only as good as the data therefore it doesn't > completely eliminate the chances of an error? > In this incident did the pilots self report? > If they didn't why would the ATSB investigate? > > > > My thinking is that the system has access to the settings for flap, thrust, mass, V1 and Vr. None of these is assumed to be correct. Also access to GPS and airspeed. In the following, the system would allow some level of discrepancy so as not to cause unnecessary aborts. Once the aircraft is accelerating, its direction together with the GPS calculated position allows the system to determine which runway the aircraft is on (position alone may not be sufficient, where runways intersect). The acceleration to be expected from a given thrust setting depends on the aircraft's mass, and its airspeed. So the system waits until there is a reliable airspeed. It then can calculate the mass from the expected thrust, the acceleration and the airspeed. The result should match the setting. If it doesn't this means that either the mass is set wrong, or the expected thrust, based on the thrust setting, is not being achieved. Either of these aborts the takeoff. Vr can now be calculated based the mass and flap setting. If the calculated Vr differs from the set Vr, this aborts the takeoff. From the current position, the acceleration and the mass, the braking distance can be calculated [*], and from that V1. If the calculated V1 is lower than the set V1, then abort take off. [*] This is one area of uncertainty, since braking distance depends on runway condition (wet, dry, etc.). Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | Daryl <dwalford@westpine.com.au> |
|---|---|
| Date | 2025-01-25 22:36 +1100 |
| Message-ID | <lvk0m9Fk87oU1@mid.individual.net> |
| In reply to | #27483 |
On 25/1/2025 7:44 pm, Sylvia Else wrote: > On 25-Jan-25 6:19 am, Daryl wrote: >> On 25/1/2025 12:59 am, Sylvia Else wrote: >>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> Rod Speed wrote >>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> Rod Speed wrote >>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>> >>>>>>>>> https://www.atsb.gov.au/publications/ >>>>>>>>> investigation_reports/2025/ report/ao-2024-038 >>>> >>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>> performance monitoring, no matter the size. >>>> >>>>>>>> That isnt going to result in the problem being >>>>>>>> fixed quickly enough to stop an accident >>>> >>>>>>> Well before an abort becomes risky, the system has enough >>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>> are correct, >>>> >>>>>> Bullshit with that incorrect flaps setting. >>>> >>>>>>> and whether the aircraft will be able toboth continue a >>>>>>> takeoff, and stop, at v1. >>>> >>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>> tell the pilots that the flaps setting is wrong. >>>> >>>>>> It would make much more sense to compare the >>>>>> actual settings with that has been entered at the >>>>>> preflight config calculations and tell the pilots >>>>>> that they have not set what was required with >>>>>> flaps and boost etc before they actually applied >>>>>> takeoff power and not allow takeoff power to be >>>>>> applied before those were set correctly. >>>> >>>>>>> It can issue an abort alert if not. >>>> >>>>>> See above >>>> >>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>>> that I haven't even thought of. >>>> >>>>>> It would be stupid to try to measure that while taking off >>>>>> instead of doing that before takeoff power is applied >>>> >>>>>> Yes, there is also a different problem with the engines >>>>>> not being able to deliver the power they were assumed >>>>>> to be able to deliver the power they were supposed to >>>>>> be able to deliver in the preflight calculations, but that >>>>>> was not the case in the incident being discussed and >>>>>> it would be much easier to discover than much earlier >>>>>> in the takeoff run than V1 or VR >>>> >>>>> The question the system needs to ask is "In the current >>>>> configuration, with the measured acceleration [*], current >>>>> airspeed, and current position on the current runway, can the >>>>> aircraft reach the specified V1 at a point where it can continue >>>>> the takeoff or abort, and will it be able to rotate at the >>>>> specified Vr. >>>> >>>> The problem with that approach is that is far too late >>>> during the takeoff run to be doing that by measurement >>>> when its much too late for the pilots to be fixing what >>>> the problem is, particularly when the engines arent >>>> actually performing the way they were meant to when >>>> the prefight calculations were done >>> >>> There would be no expectation that the pilots would fix it. The idea >>> is to abort the takeoff while that can still be done safely. >> >> I assume that you are talking about some sort of automated system to >> alert pilots of a configuration error? >> If so wouldn't that rely on data input by the pilots prior to takeoff >> so the system would be only as good as the data therefore it doesn't >> completely eliminate the chances of an error? >> In this incident did the pilots self report? >> If they didn't why would the ATSB investigate? >> >> >> >> > > My thinking is that the system has access to the settings for flap, > thrust, mass, V1 and Vr. None of these is assumed to be correct. > > Also access to GPS and airspeed. > > In the following, the system would allow some level of discrepancy so as > not to cause unnecessary aborts. > > Once the aircraft is accelerating, its direction together with the GPS > calculated position allows the system to determine which runway the > aircraft is on (position alone may not be sufficient, where runways > intersect). > > The acceleration to be expected from a given thrust setting depends on > the aircraft's mass, and its airspeed. So the system waits until there > is a reliable airspeed. It then can calculate the mass from the expected > thrust, the acceleration and the airspeed. The result should match the > setting. If it doesn't this means that either the mass is set wrong, or > the expected thrust, based on the thrust setting, is not being achieved. > Either of these aborts the takeoff. > > Vr can now be calculated based the mass and flap setting. If the > calculated Vr differs from the set Vr, this aborts the takeoff. > > From the current position, the acceleration and the mass, the braking > distance can be calculated [*], and from that V1. If the calculated V1 > is lower than the set V1, then abort take off. > > [*] This is one area of uncertainty, since braking distance depends on > runway condition (wet, dry, etc.). > > Sylvia. > > My piloting experience is 5hrs training in a helicopter so not much but to me it sounds a bit complex and still open to input error to be of much value? Might be feasible on newer complex aircraft but retrofitting such a system on older aircraft would most likely be very expensive and maybe not even possible. You didn't answer the question about self reporting, was that mentioned in the ATSB report? -- Daryl
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-25 22:12 +0800 |
| Message-ID | <lvk9r1FllumU1@mid.individual.net> |
| In reply to | #27484 |
On 25-Jan-25 7:36 pm, Daryl wrote: > On 25/1/2025 7:44 pm, Sylvia Else wrote: >> On 25-Jan-25 6:19 am, Daryl wrote: >>> On 25/1/2025 12:59 am, Sylvia Else wrote: >>>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>> Rod Speed wrote >>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>> Rod Speed wrote >>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> >>>>>>>>>> https://www.atsb.gov.au/publications/ >>>>>>>>>> investigation_reports/2025/ report/ao-2024-038 >>>>> >>>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>>> performance monitoring, no matter the size. >>>>> >>>>>>>>> That isnt going to result in the problem being >>>>>>>>> fixed quickly enough to stop an accident >>>>> >>>>>>>> Well before an abort becomes risky, the system has enough >>>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>>> are correct, >>>>> >>>>>>> Bullshit with that incorrect flaps setting. >>>>> >>>>>>>> and whether the aircraft will be able toboth continue a >>>>>>>> takeoff, and stop, at v1. >>>>> >>>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>>> tell the pilots that the flaps setting is wrong. >>>>> >>>>>>> It would make much more sense to compare the >>>>>>> actual settings with that has been entered at the >>>>>>> preflight config calculations and tell the pilots >>>>>>> that they have not set what was required with >>>>>>> flaps and boost etc before they actually applied >>>>>>> takeoff power and not allow takeoff power to be >>>>>>> applied before those were set correctly. >>>>> >>>>>>>> It can issue an abort alert if not. >>>>> >>>>>>> See above >>>>> >>>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>>>> that I haven't even thought of. >>>>> >>>>>>> It would be stupid to try to measure that while taking off >>>>>>> instead of doing that before takeoff power is applied >>>>> >>>>>>> Yes, there is also a different problem with the engines >>>>>>> not being able to deliver the power they were assumed >>>>>>> to be able to deliver the power they were supposed to >>>>>>> be able to deliver in the preflight calculations, but that >>>>>>> was not the case in the incident being discussed and >>>>>>> it would be much easier to discover than much earlier >>>>>>> in the takeoff run than V1 or VR >>>>> >>>>>> The question the system needs to ask is "In the current >>>>>> configuration, with the measured acceleration [*], current >>>>>> airspeed, and current position on the current runway, can the >>>>>> aircraft reach the specified V1 at a point where it can continue >>>>>> the takeoff or abort, and will it be able to rotate at the >>>>>> specified Vr. >>>>> >>>>> The problem with that approach is that is far too late >>>>> during the takeoff run to be doing that by measurement >>>>> when its much too late for the pilots to be fixing what >>>>> the problem is, particularly when the engines arent >>>>> actually performing the way they were meant to when >>>>> the prefight calculations were done >>>> >>>> There would be no expectation that the pilots would fix it. The idea >>>> is to abort the takeoff while that can still be done safely. >>> >>> I assume that you are talking about some sort of automated system to >>> alert pilots of a configuration error? >>> If so wouldn't that rely on data input by the pilots prior to takeoff >>> so the system would be only as good as the data therefore it doesn't >>> completely eliminate the chances of an error? >>> In this incident did the pilots self report? >>> If they didn't why would the ATSB investigate? >>> >>> >>> >>> >> >> My thinking is that the system has access to the settings for flap, >> thrust, mass, V1 and Vr. None of these is assumed to be correct. >> >> Also access to GPS and airspeed. >> >> In the following, the system would allow some level of discrepancy so >> as not to cause unnecessary aborts. >> >> Once the aircraft is accelerating, its direction together with the GPS >> calculated position allows the system to determine which runway the >> aircraft is on (position alone may not be sufficient, where runways >> intersect). >> >> The acceleration to be expected from a given thrust setting depends on >> the aircraft's mass, and its airspeed. So the system waits until there >> is a reliable airspeed. It then can calculate the mass from the >> expected thrust, the acceleration and the airspeed. The result should >> match the setting. If it doesn't this means that either the mass is >> set wrong, or the expected thrust, based on the thrust setting, is not >> being achieved. Either of these aborts the takeoff. >> >> Vr can now be calculated based the mass and flap setting. If the >> calculated Vr differs from the set Vr, this aborts the takeoff. >> >> From the current position, the acceleration and the mass, the braking >> distance can be calculated [*], and from that V1. If the calculated V1 >> is lower than the set V1, then abort take off. >> >> [*] This is one area of uncertainty, since braking distance depends on >> runway condition (wet, dry, etc.). >> >> Sylvia. >> >> > My piloting experience is 5hrs training in a helicopter so not much but > to me it sounds a bit complex and still open to input error to be of > much value? > Might be feasible on newer complex aircraft but retrofitting such a > system on older aircraft would most likely be very expensive and maybe > not even possible. > You didn't answer the question about self reporting, was that mentioned > in the ATSB report? > > I can't find a specific reference to how this came to the attention of the ATSB. Most likely it was reported to Qantas Link by the pilots, and Qantas Link then reported it to the ATSB. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | Daryl <dwalford@westpine.com.au> |
|---|---|
| Date | 2025-01-26 09:36 +1100 |
| Message-ID | <lvl7bkFq9oqU1@mid.individual.net> |
| In reply to | #27485 |
On 26/1/2025 1:12 am, Sylvia Else wrote: > On 25-Jan-25 7:36 pm, Daryl wrote: >> On 25/1/2025 7:44 pm, Sylvia Else wrote: >>> On 25-Jan-25 6:19 am, Daryl wrote: >>>> On 25/1/2025 12:59 am, Sylvia Else wrote: >>>>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> Rod Speed wrote >>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>>> Rod Speed wrote >>>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>> >>>>>>>>>>> https://www.atsb.gov.au/publications/ >>>>>>>>>>> investigation_reports/2025/ report/ao-2024-038 >>>>>> >>>>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>>>> performance monitoring, no matter the size. >>>>>> >>>>>>>>>> That isnt going to result in the problem being >>>>>>>>>> fixed quickly enough to stop an accident >>>>>> >>>>>>>>> Well before an abort becomes risky, the system has enough >>>>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>>>> are correct, >>>>>> >>>>>>>> Bullshit with that incorrect flaps setting. >>>>>> >>>>>>>>> and whether the aircraft will be able toboth continue a >>>>>>>>> takeoff, and stop, at v1. >>>>>> >>>>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>>>> tell the pilots that the flaps setting is wrong. >>>>>> >>>>>>>> It would make much more sense to compare the >>>>>>>> actual settings with that has been entered at the >>>>>>>> preflight config calculations and tell the pilots >>>>>>>> that they have not set what was required with >>>>>>>> flaps and boost etc before they actually applied >>>>>>>> takeoff power and not allow takeoff power to be >>>>>>>> applied before those were set correctly. >>>>>> >>>>>>>>> It can issue an abort alert if not. >>>>>> >>>>>>>> See above >>>>>> >>>>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>>>> intersection, takeoff from the wrong runway, and no doubt >>>>>>>>> others that I haven't even thought of. >>>>>> >>>>>>>> It would be stupid to try to measure that while taking off >>>>>>>> instead of doing that before takeoff power is applied >>>>>> >>>>>>>> Yes, there is also a different problem with the engines >>>>>>>> not being able to deliver the power they were assumed >>>>>>>> to be able to deliver the power they were supposed to >>>>>>>> be able to deliver in the preflight calculations, but that >>>>>>>> was not the case in the incident being discussed and >>>>>>>> it would be much easier to discover than much earlier >>>>>>>> in the takeoff run than V1 or VR >>>>>> >>>>>>> The question the system needs to ask is "In the current >>>>>>> configuration, with the measured acceleration [*], current >>>>>>> airspeed, and current position on the current runway, can the >>>>>>> aircraft reach the specified V1 at a point where it can continue >>>>>>> the takeoff or abort, and will it be able to rotate at the >>>>>>> specified Vr. >>>>>> >>>>>> The problem with that approach is that is far too late >>>>>> during the takeoff run to be doing that by measurement >>>>>> when its much too late for the pilots to be fixing what >>>>>> the problem is, particularly when the engines arent >>>>>> actually performing the way they were meant to when >>>>>> the prefight calculations were done >>>>> >>>>> There would be no expectation that the pilots would fix it. The >>>>> idea is to abort the takeoff while that can still be done safely. >>>> >>>> I assume that you are talking about some sort of automated system to >>>> alert pilots of a configuration error? >>>> If so wouldn't that rely on data input by the pilots prior to >>>> takeoff so the system would be only as good as the data therefore it >>>> doesn't completely eliminate the chances of an error? >>>> In this incident did the pilots self report? >>>> If they didn't why would the ATSB investigate? >>>> >>>> >>>> >>>> >>> >>> My thinking is that the system has access to the settings for flap, >>> thrust, mass, V1 and Vr. None of these is assumed to be correct. >>> >>> Also access to GPS and airspeed. >>> >>> In the following, the system would allow some level of discrepancy so >>> as not to cause unnecessary aborts. >>> >>> Once the aircraft is accelerating, its direction together with the >>> GPS calculated position allows the system to determine which runway >>> the aircraft is on (position alone may not be sufficient, where >>> runways intersect). >>> >>> The acceleration to be expected from a given thrust setting depends >>> on the aircraft's mass, and its airspeed. So the system waits until >>> there is a reliable airspeed. It then can calculate the mass from the >>> expected thrust, the acceleration and the airspeed. The result should >>> match the setting. If it doesn't this means that either the mass is >>> set wrong, or the expected thrust, based on the thrust setting, is >>> not being achieved. Either of these aborts the takeoff. >>> >>> Vr can now be calculated based the mass and flap setting. If the >>> calculated Vr differs from the set Vr, this aborts the takeoff. >>> >>> From the current position, the acceleration and the mass, the >>> braking distance can be calculated [*], and from that V1. If the >>> calculated V1 is lower than the set V1, then abort take off. >>> >>> [*] This is one area of uncertainty, since braking distance depends >>> on runway condition (wet, dry, etc.). >>> >>> Sylvia. >>> >>> >> My piloting experience is 5hrs training in a helicopter so not much >> but to me it sounds a bit complex and still open to input error to be >> of much value? >> Might be feasible on newer complex aircraft but retrofitting such a >> system on older aircraft would most likely be very expensive and maybe >> not even possible. >> You didn't answer the question about self reporting, was that >> mentioned in the ATSB report? >> >> > > I can't find a specific reference to how this came to the attention of > the ATSB. Most likely it was reported to Qantas Link by the pilots, and > Qantas Link then reported it to the ATSB. > > Sylvia. Would it be mandatory for the pilots to report to the airline or just good practice? If the airlines culture encouraged them to report without consequence then its a good safety measure, maybe that's why airlines in Australia have such a good safety record? -- Daryl
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-26 10:07 +1100 |
| Message-ID | <op.20yc6azibyq249@pvr2.lan> |
| In reply to | #27487 |
On Sun, 26 Jan 2025 09:36:36 +1100, Daryl <dwalford@westpine.com.au> wrote: > On 26/1/2025 1:12 am, Sylvia Else wrote: >> On 25-Jan-25 7:36 pm, Daryl wrote: >>> On 25/1/2025 7:44 pm, Sylvia Else wrote: >>>> On 25-Jan-25 6:19 am, Daryl wrote: >>>>> On 25/1/2025 12:59 am, Sylvia Else wrote: >>>>>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>> Rod Speed wrote >>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>>>> Rod Speed wrote >>>>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> >>>>>>>>>>>> https://www.atsb.gov.au/publications/ >>>>>>>>>>>> investigation_reports/2025/ report/ao-2024-038 >>>>>>> >>>>>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>>>>> performance monitoring, no matter the size. >>>>>>> >>>>>>>>>>> That isnt going to result in the problem being >>>>>>>>>>> fixed quickly enough to stop an accident >>>>>>> >>>>>>>>>> Well before an abort becomes risky, the system has enough >>>>>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>>>>> are correct, >>>>>>> >>>>>>>>> Bullshit with that incorrect flaps setting. >>>>>>> >>>>>>>>>> and whether the aircraft will be able toboth continue a >>>>>>>>>> takeoff, and stop, at v1. >>>>>>> >>>>>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>>>>> tell the pilots that the flaps setting is wrong. >>>>>>> >>>>>>>>> It would make much more sense to compare the >>>>>>>>> actual settings with that has been entered at the >>>>>>>>> preflight config calculations and tell the pilots >>>>>>>>> that they have not set what was required with >>>>>>>>> flaps and boost etc before they actually applied >>>>>>>>> takeoff power and not allow takeoff power to be >>>>>>>>> applied before those were set correctly. >>>>>>> >>>>>>>>>> It can issue an abort alert if not. >>>>>>> >>>>>>>>> See above >>>>>>> >>>>>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>>>>> intersection, takeoff from the wrong runway, and no doubt >>>>>>>>>> others that I haven't even thought of. >>>>>>> >>>>>>>>> It would be stupid to try to measure that while taking off >>>>>>>>> instead of doing that before takeoff power is applied >>>>>>> >>>>>>>>> Yes, there is also a different problem with the engines >>>>>>>>> not being able to deliver the power they were assumed >>>>>>>>> to be able to deliver the power they were supposed to >>>>>>>>> be able to deliver in the preflight calculations, but that >>>>>>>>> was not the case in the incident being discussed and >>>>>>>>> it would be much easier to discover than much earlier >>>>>>>>> in the takeoff run than V1 or VR >>>>>>> >>>>>>>> The question the system needs to ask is "In the current >>>>>>>> configuration, with the measured acceleration [*], current >>>>>>>> airspeed, and current position on the current runway, can the >>>>>>>> aircraft reach the specified V1 at a point where it can continue >>>>>>>> the takeoff or abort, and will it be able to rotate at the >>>>>>>> specified Vr. >>>>>>> >>>>>>> The problem with that approach is that is far too late >>>>>>> during the takeoff run to be doing that by measurement >>>>>>> when its much too late for the pilots to be fixing what >>>>>>> the problem is, particularly when the engines arent >>>>>>> actually performing the way they were meant to when >>>>>>> the prefight calculations were done >>>>>> >>>>>> There would be no expectation that the pilots would fix it. The >>>>>> idea is to abort the takeoff while that can still be done safely. >>>>> >>>>> I assume that you are talking about some sort of automated system to >>>>> alert pilots of a configuration error? >>>>> If so wouldn't that rely on data input by the pilots prior to >>>>> takeoff so the system would be only as good as the data therefore it >>>>> doesn't completely eliminate the chances of an error? >>>>> In this incident did the pilots self report? >>>>> If they didn't why would the ATSB investigate? >>>>> >>>>> >>>>> >>>>> >>>> >>>> My thinking is that the system has access to the settings for flap, >>>> thrust, mass, V1 and Vr. None of these is assumed to be correct. >>>> >>>> Also access to GPS and airspeed. >>>> >>>> In the following, the system would allow some level of discrepancy so >>>> as not to cause unnecessary aborts. >>>> >>>> Once the aircraft is accelerating, its direction together with the >>>> GPS calculated position allows the system to determine which runway >>>> the aircraft is on (position alone may not be sufficient, where >>>> runways intersect). >>>> >>>> The acceleration to be expected from a given thrust setting depends >>>> on the aircraft's mass, and its airspeed. So the system waits until >>>> there is a reliable airspeed. It then can calculate the mass from the >>>> expected thrust, the acceleration and the airspeed. The result should >>>> match the setting. If it doesn't this means that either the mass is >>>> set wrong, or the expected thrust, based on the thrust setting, is >>>> not being achieved. Either of these aborts the takeoff. >>>> >>>> Vr can now be calculated based the mass and flap setting. If the >>>> calculated Vr differs from the set Vr, this aborts the takeoff. >>>> >>>> From the current position, the acceleration and the mass, the >>>> braking distance can be calculated [*], and from that V1. If the >>>> calculated V1 is lower than the set V1, then abort take off. >>>> >>>> [*] This is one area of uncertainty, since braking distance depends >>>> on runway condition (wet, dry, etc.). >>>> >>>> Sylvia. >>>> >>>> >>> My piloting experience is 5hrs training in a helicopter so not much >>> but to me it sounds a bit complex and still open to input error to be >>> of much value? >>> Might be feasible on newer complex aircraft but retrofitting such a >>> system on older aircraft would most likely be very expensive and maybe >>> not even possible. >>> You didn't answer the question about self reporting, was that >>> mentioned in the ATSB report? >>> >>> >> I can't find a specific reference to how this came to the attention of >> the ATSB. Most likely it was reported to Qantas Link by the pilots, and >> Qantas Link then reported it to the ATSB. > Would it be mandatory for the pilots to report to the airline or just > good practice? Its manditory > If the airlines culture encouraged them to report without consequence > then its a good safety measure, maybe that's why airlines in Australia > have such a good safety record? Its not just manditory here, that is true right thruout the entire industry world wide, but not followed in the 3rd world necessarily
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-26 02:21 +1100 |
| Message-ID | <op.20xrlxc5byq249@pvr2.lan> |
| In reply to | #27483 |
On Sat, 25 Jan 2025 19:44:58 +1100, Sylvia Else <sylvia@email.invalid> wrote: > On 25-Jan-25 6:19 am, Daryl wrote: >> On 25/1/2025 12:59 am, Sylvia Else wrote: >>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> Rod Speed wrote >>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> Rod Speed wrote >>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>> >>>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ >>>>>>>>> report/ao-2024-038 >>>> >>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>> performance monitoring, no matter the size. >>>> >>>>>>>> That isnt going to result in the problem being >>>>>>>> fixed quickly enough to stop an accident >>>> >>>>>>> Well before an abort becomes risky, the system has enough >>>>>>> informationto determine whether the crew calculated v1 and vr are >>>>>>> correct, >>>> >>>>>> Bullshit with that incorrect flaps setting. >>>> >>>>>>> and whether the aircraft will be able toboth continue a takeoff, >>>>>>> and stop, at v1. >>>> >>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>> tell the pilots that the flaps setting is wrong. >>>> >>>>>> It would make much more sense to compare the >>>>>> actual settings with that has been entered at the >>>>>> preflight config calculations and tell the pilots >>>>>> that they have not set what was required with >>>>>> flaps and boost etc before they actually applied >>>>>> takeoff power and not allow takeoff power to be >>>>>> applied before those were set correctly. >>>> >>>>>>> It can issue an abort alert if not. >>>> >>>>>> See above >>>> >>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>>> that I haven't even thought of. >>>> >>>>>> It would be stupid to try to measure that while taking off >>>>>> instead of doing that before takeoff power is applied >>>> >>>>>> Yes, there is also a different problem with the engines >>>>>> not being able to deliver the power they were assumed >>>>>> to be able to deliver the power they were supposed to >>>>>> be able to deliver in the preflight calculations, but that >>>>>> was not the case in the incident being discussed and >>>>>> it would be much easier to discover than much earlier >>>>>> in the takeoff run than V1 or VR >>>> >>>>> The question the system needs to ask is "In the current >>>>> configuration, with the measured acceleration [*], current airspeed, >>>>> and current position on the current runway, can the aircraft reach >>>>> the specified V1 at a point where it can continue the takeoff or >>>>> abort, and will it be able to rotate at the specified Vr. >>>> >>>> The problem with that approach is that is far too late >>>> during the takeoff run to be doing that by measurement >>>> when its much too late for the pilots to be fixing what >>>> the problem is, particularly when the engines arent >>>> actually performing the way they were meant to when >>>> the prefight calculations were done >>> >>> There would be no expectation that the pilots would fix it. The idea >>> is to abort the takeoff while that can still be done safely. >> I assume that you are talking about some sort of automated system to >> alert pilots of a configuration error? >> If so wouldn't that rely on data input by the pilots prior to takeoff >> so the system would be only as good as the data therefore it doesn't >> completely eliminate the chances of an error? >> In this incident did the pilots self report? >> If they didn't why would the ATSB investigate? >> > > My thinking is that the system has access to the settings for flap, > thrust, mass, V1 and Vr. None of these is assumed to be correct. > > Also access to GPS and airspeed. > > In the following, the system would allow some level of discrepancy so as > not to cause unnecessary aborts. > > Once the aircraft is accelerating, its direction together with the GPS > calculated position allows the system to determine which runway the > aircraft is on (position alone may not be sufficient, where runways > intersect). > The acceleration to be expected from a given thrust setting depends on > the aircraft's mass, and its airspeed. So the system waits until there > is a reliable airspeed. It then can calculate the mass from the expected > thrust, the acceleration and the airspeed. The result should match the > setting. If it doesn't this means that either the mass is set wrong, or > the expected thrust, based on the thrust setting, is not being achieved. > Either of these aborts the takeoff. Not possible to MEASURE that the flaps haven't been set correctly before V1 because you can only measure the effect of that after VR when rotation has been attempted and it can measure that it doesnt see the weight leaving the wheels in the way that it should have, And given that it is already past V1, no way to abort by then Makes a lot more sense to enter all the paramaters that will be used like thrust settings and flaps etc and them before takeoff power can be applied, check that that has been done. > Vr can now be calculated based the mass and flap setting. If the > calculated Vr differs from the set Vr, this aborts the takeoff. Too late by then, its already past V1 so it can't be aborted > From the current position, the acceleration and the mass, the braking > distance can be calculated [*], and from that V1. If the calculated V1 > is lower than the set V1, then abort take off. > [*] This is one area of uncertainty, since braking distance depends on > runway condition (wet, dry, etc.). And can't be measured during the takeoff run
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-26 16:29 +0800 |
| Message-ID | <lvma2mFtngU1@mid.individual.net> |
| In reply to | #27486 |
On 25-Jan-25 11:21 pm, Rod Speed wrote: > On Sat, 25 Jan 2025 19:44:58 +1100, Sylvia Else <sylvia@email.invalid> > wrote: > >> On 25-Jan-25 6:19 am, Daryl wrote: >>> On 25/1/2025 12:59 am, Sylvia Else wrote: >>>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>> Rod Speed wrote >>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>> Rod Speed wrote >>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>> >>>>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ report/ao-2024-038 >>>>> >>>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>>> performance monitoring, no matter the size. >>>>> >>>>>>>>> That isnt going to result in the problem being >>>>>>>>> fixed quickly enough to stop an accident >>>>> >>>>>>>> Well before an abort becomes risky, the system has enough >>>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>>> are correct, >>>>> >>>>>>> Bullshit with that incorrect flaps setting. >>>>> >>>>>>>> and whether the aircraft will be able toboth continue a >>>>>>>> takeoff, and stop, at v1. >>>>> >>>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>>> tell the pilots that the flaps setting is wrong. >>>>> >>>>>>> It would make much more sense to compare the >>>>>>> actual settings with that has been entered at the >>>>>>> preflight config calculations and tell the pilots >>>>>>> that they have not set what was required with >>>>>>> flaps and boost etc before they actually applied >>>>>>> takeoff power and not allow takeoff power to be >>>>>>> applied before those were set correctly. >>>>> >>>>>>>> It can issue an abort alert if not. >>>>> >>>>>>> See above >>>>> >>>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>>>> that I haven't even thought of. >>>>> >>>>>>> It would be stupid to try to measure that while taking off >>>>>>> instead of doing that before takeoff power is applied >>>>> >>>>>>> Yes, there is also a different problem with the engines >>>>>>> not being able to deliver the power they were assumed >>>>>>> to be able to deliver the power they were supposed to >>>>>>> be able to deliver in the preflight calculations, but that >>>>>>> was not the case in the incident being discussed and >>>>>>> it would be much easier to discover than much earlier >>>>>>> in the takeoff run than V1 or VR >>>>> >>>>>> The question the system needs to ask is "In the current >>>>>> configuration, with the measured acceleration [*], current >>>>>> airspeed, and current position on the current runway, can the >>>>>> aircraft reach the specified V1 at a point where it can continue >>>>>> the takeoff or abort, and will it be able to rotate at the >>>>>> specified Vr. >>>>> >>>>> The problem with that approach is that is far too late >>>>> during the takeoff run to be doing that by measurement >>>>> when its much too late for the pilots to be fixing what >>>>> the problem is, particularly when the engines arent >>>>> actually performing the way they were meant to when >>>>> the prefight calculations were done >>>> >>>> There would be no expectation that the pilots would fix it. The idea >>>> is to abort the takeoff while that can still be done safely. >>> I assume that you are talking about some sort of automated system to >>> alert pilots of a configuration error? >>> If so wouldn't that rely on data input by the pilots prior to takeoff >>> so the system would be only as good as the data therefore it doesn't >>> completely eliminate the chances of an error? >>> In this incident did the pilots self report? >>> If they didn't why would the ATSB investigate? >>> >> >> My thinking is that the system has access to the settings for flap, >> thrust, mass, V1 and Vr. None of these is assumed to be correct. >> >> Also access to GPS and airspeed. >> >> In the following, the system would allow some level of discrepancy so >> as not to cause unnecessary aborts. >> >> Once the aircraft is accelerating, its direction together with the GPS >> calculated position allows the system to determine which runway the >> aircraft is on (position alone may not be sufficient, where runways >> intersect). > >> The acceleration to be expected from a given thrust setting depends on >> the aircraft's mass, and its airspeed. So the system waits until there >> is a reliable airspeed. It then can calculate the mass from the >> expected thrust, the acceleration and the airspeed. The result should >> match the setting. If it doesn't this means that either the mass is >> set wrong, or the expected thrust, based on the thrust setting, is not >> being achieved. Either of these aborts the takeoff. > > Not possible to MEASURE that the flaps haven't been set correctly > before V1 because you can only measure the effect of that after VR > when rotation has been attempted and it can measure that it doesnt > see the weight leaving the wheels in the way that it should have, The issue is only whether the aircraft will take off at the set Vr, which is a function of the flap setting, and aircraft mass. This is something that can be determined from the aircraft's flight performance data - the same data that the crew use. If the flaps are not at the position set for them, that's something that should already have been alerted. > > And given that it is already past V1, no way to abort by then > > Makes a lot more sense to enter all the paramaters that will > be used like thrust settings and flaps etc and them before > takeoff power can be applied, check that that has been done. > >> Vr can now be calculated based the mass and flap setting. If the >> calculated Vr differs from the set Vr, this aborts the takeoff. > > Too late by then, its already past V1 so it can't be aborted Why is it already past v1? > >> From the current position, the acceleration and the mass, the braking >> distance can be calculated [*], and from that V1. If the calculated V1 >> is lower than the set V1, then abort take off. > >> [*] This is one area of uncertainty, since braking distance depends on >> runway condition (wet, dry, etc.). > > And can't be measured during the takeoff run No, it cannot, hence the uncertainty. But if the system assumes good braking, and the calculated v1 is less than the set v1, then the set v1 is wrong regardless of the actual braking conditions. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2025-01-26 20:14 +1100 |
| Message-ID | <op.20y5a4xebyq249@pvr2.lan> |
| In reply to | #27489 |
On Sun, 26 Jan 2025 19:29:10 +1100, Sylvia Else <sylvia@email.invalid> wrote: > On 25-Jan-25 11:21 pm, Rod Speed wrote: >> On Sat, 25 Jan 2025 19:44:58 +1100, Sylvia Else <sylvia@email.invalid> >> wrote: >> >>> On 25-Jan-25 6:19 am, Daryl wrote: >>>> On 25/1/2025 12:59 am, Sylvia Else wrote: >>>>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> Rod Speed wrote >>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>>> Rod Speed wrote >>>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>> >>>>>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ >>>>>>>>>>> report/ao-2024-038 >>>>>> >>>>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>>>> performance monitoring, no matter the size. >>>>>> >>>>>>>>>> That isnt going to result in the problem being >>>>>>>>>> fixed quickly enough to stop an accident >>>>>> >>>>>>>>> Well before an abort becomes risky, the system has enough >>>>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>>>> are correct, >>>>>> >>>>>>>> Bullshit with that incorrect flaps setting. >>>>>> >>>>>>>>> and whether the aircraft will be able toboth continue a >>>>>>>>> takeoff, and stop, at v1. >>>>>> >>>>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>>>> tell the pilots that the flaps setting is wrong. >>>>>> >>>>>>>> It would make much more sense to compare the >>>>>>>> actual settings with that has been entered at the >>>>>>>> preflight config calculations and tell the pilots >>>>>>>> that they have not set what was required with >>>>>>>> flaps and boost etc before they actually applied >>>>>>>> takeoff power and not allow takeoff power to be >>>>>>>> applied before those were set correctly. >>>>>> >>>>>>>>> It can issue an abort alert if not. >>>>>> >>>>>>>> See above >>>>>> >>>>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>>>> intersection, takeoff from the wrong runway, and no doubt others >>>>>>>>> that I haven't even thought of. >>>>>> >>>>>>>> It would be stupid to try to measure that while taking off >>>>>>>> instead of doing that before takeoff power is applied >>>>>> >>>>>>>> Yes, there is also a different problem with the engines >>>>>>>> not being able to deliver the power they were assumed >>>>>>>> to be able to deliver the power they were supposed to >>>>>>>> be able to deliver in the preflight calculations, but that >>>>>>>> was not the case in the incident being discussed and >>>>>>>> it would be much easier to discover than much earlier >>>>>>>> in the takeoff run than V1 or VR >>>>>> >>>>>>> The question the system needs to ask is "In the current >>>>>>> configuration, with the measured acceleration [*], current >>>>>>> airspeed, and current position on the current runway, can the >>>>>>> aircraft reach the specified V1 at a point where it can continue >>>>>>> the takeoff or abort, and will it be able to rotate at the >>>>>>> specified Vr. >>>>>> >>>>>> The problem with that approach is that is far too late >>>>>> during the takeoff run to be doing that by measurement >>>>>> when its much too late for the pilots to be fixing what >>>>>> the problem is, particularly when the engines arent >>>>>> actually performing the way they were meant to when >>>>>> the prefight calculations were done >>>>> >>>>> There would be no expectation that the pilots would fix it. The idea >>>>> is to abort the takeoff while that can still be done safely. >>>> I assume that you are talking about some sort of automated system to >>>> alert pilots of a configuration error? >>>> If so wouldn't that rely on data input by the pilots prior to takeoff >>>> so the system would be only as good as the data therefore it doesn't >>>> completely eliminate the chances of an error? >>>> In this incident did the pilots self report? >>>> If they didn't why would the ATSB investigate? >>>> >>> >>> My thinking is that the system has access to the settings for flap, >>> thrust, mass, V1 and Vr. None of these is assumed to be correct. >>> >>> Also access to GPS and airspeed. >>> >>> In the following, the system would allow some level of discrepancy so >>> as not to cause unnecessary aborts. >>> >>> Once the aircraft is accelerating, its direction together with the GPS >>> calculated position allows the system to determine which runway the >>> aircraft is on (position alone may not be sufficient, where runways >>> intersect). >> >>> The acceleration to be expected from a given thrust setting depends on >>> the aircraft's mass, and its airspeed. So the system waits until there >>> is a reliable airspeed. It then can calculate the mass from the >>> expected thrust, the acceleration and the airspeed. The result should >>> match the setting. If it doesn't this means that either the mass is >>> set wrong, or the expected thrust, based on the thrust setting, is not >>> being achieved. Either of these aborts the takeoff. >> Not possible to MEASURE that the flaps haven't been set correctly >> before V1 because you can only measure the effect of that after VR >> when rotation has been attempted and it can measure that it doesnt >> see the weight leaving the wheels in the way that it should have, > The issue is only whether the aircraft will take off at the set Vr, > which is a function of the flap setting, and aircraft mass. Yes > This is something that can be determined from the aircraft'sflight > performance data - the same data that the crew use. That isnt MEASUREMEMT of the plane's performance during the takeoff run > If the flaps are not at the position set for them, that'ssomething that > should already have been alerted. What I said right from the start >> And given that it is already past V1, no way to abort by then >> Makes a lot more sense to enter all the paramaters that will >> be used like thrust settings and flaps etc and them before >> takeoff power can be applied, check that that has been done. >>> Vr can now be calculated based the mass and flap setting. If the >>> calculated Vr differs from the set Vr, this aborts the takeoff. >> Too late by then, its already past V1 so it can't be aborted > Why is it already past v1? Because that's the only time you know that it can't rotate at the time that it should have been able to, because the flap setting is wrong. >>> From the current position, the acceleration and the mass, the braking >>> distance can be calculated [*], and from that V1. If the calculated V1 >>> is lower than the set V1, then abort take off. >>> [*] This is one area of uncertainty, since braking distance depends on >>> runway condition (wet, dry, etc.). >> And can't be measured during the takeoff run > No, it cannot, hence the uncertainty. But if the system assumes good > braking, and the calculated v1 is less than the set v1, then the set v1 > is wrong regardless of the actual braking conditions. So its too late to abort the takeoff So the only thing that makes any sense is to check that the pilots have actually set stuff like flaps and takeoff power they way they have calculated needs to be BEFORE the takeoff can happen. No point in measuring anything once the takeoff run has started except with the engine performance and that isnt what is being discussed with this incident.
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@email.invalid> |
|---|---|
| Date | 2025-01-27 12:17 +0800 |
| Message-ID | <lvofn3FbmkvU1@mid.individual.net> |
| In reply to | #27490 |
On 26-Jan-25 5:14 pm, Rod Speed wrote: > On Sun, 26 Jan 2025 19:29:10 +1100, Sylvia Else <sylvia@email.invalid> > wrote: > >> On 25-Jan-25 11:21 pm, Rod Speed wrote: >>> On Sat, 25 Jan 2025 19:44:58 +1100, Sylvia Else >>> <sylvia@email.invalid> wrote: >>> >>>> On 25-Jan-25 6:19 am, Daryl wrote: >>>>> On 25/1/2025 12:59 am, Sylvia Else wrote: >>>>>> On 24-Jan-25 4:21 pm, Rod Speed wrote: >>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>> Rod Speed wrote >>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>>>>> Rod Speed wrote >>>>>>>>>>> Sylvia Else <sylvia@email.invalid> wrote >>>>>>> >>>>>>>>>>>> https://www.atsb.gov.au/publications/investigation_reports/2025/ report/ao-2024-038 >>>>>>> >>>>>>>>>>>> It's time all public transport aircraft had takeoff >>>>>>>>>>>> performance monitoring, no matter the size. >>>>>>> >>>>>>>>>>> That isnt going to result in the problem being >>>>>>>>>>> fixed quickly enough to stop an accident >>>>>>> >>>>>>>>>> Well before an abort becomes risky, the system has enough >>>>>>>>>> informationto determine whether the crew calculated v1 and vr >>>>>>>>>> are correct, >>>>>>> >>>>>>>>> Bullshit with that incorrect flaps setting. >>>>>>> >>>>>>>>>> and whether the aircraft will be able toboth continue a >>>>>>>>>> takeoff, and stop, at v1. >>>>>>> >>>>>>>>> Bullshit with that incorrect flaps setting, let alone >>>>>>>>> tell the pilots that the flaps setting is wrong. >>>>>>> >>>>>>>>> It would make much more sense to compare the >>>>>>>>> actual settings with that has been entered at the >>>>>>>>> preflight config calculations and tell the pilots >>>>>>>>> that they have not set what was required with >>>>>>>>> flaps and boost etc before they actually applied >>>>>>>>> takeoff power and not allow takeoff power to be >>>>>>>>> applied before those were set correctly. >>>>>>> >>>>>>>>>> It can issue an abort alert if not. >>>>>>> >>>>>>>>> See above >>>>>>> >>>>>>>>>> This covers at least miscalculated v1, miscalculated vr, wrong >>>>>>>>>> thrust settings, wrong flap settings, starting from the wrong >>>>>>>>>> intersection, takeoff from the wrong runway, and no doubt >>>>>>>>>> others that I haven't even thought of. >>>>>>> >>>>>>>>> It would be stupid to try to measure that while taking off >>>>>>>>> instead of doing that before takeoff power is applied >>>>>>> >>>>>>>>> Yes, there is also a different problem with the engines >>>>>>>>> not being able to deliver the power they were assumed >>>>>>>>> to be able to deliver the power they were supposed to >>>>>>>>> be able to deliver in the preflight calculations, but that >>>>>>>>> was not the case in the incident being discussed and >>>>>>>>> it would be much easier to discover than much earlier >>>>>>>>> in the takeoff run than V1 or VR >>>>>>> >>>>>>>> The question the system needs to ask is "In the current >>>>>>>> configuration, with the measured acceleration [*], current >>>>>>>> airspeed, and current position on the current runway, can the >>>>>>>> aircraft reach the specified V1 at a point where it can continue >>>>>>>> the takeoff or abort, and will it be able to rotate at the >>>>>>>> specified Vr. >>>>>>> >>>>>>> The problem with that approach is that is far too late >>>>>>> during the takeoff run to be doing that by measurement >>>>>>> when its much too late for the pilots to be fixing what >>>>>>> the problem is, particularly when the engines arent >>>>>>> actually performing the way they were meant to when >>>>>>> the prefight calculations were done >>>>>> >>>>>> There would be no expectation that the pilots would fix it. The >>>>>> idea is to abort the takeoff while that can still be done safely. >>>>> I assume that you are talking about some sort of automated system >>>>> to alert pilots of a configuration error? >>>>> If so wouldn't that rely on data input by the pilots prior to >>>>> takeoff so the system would be only as good as the data therefore >>>>> it doesn't completely eliminate the chances of an error? >>>>> In this incident did the pilots self report? >>>>> If they didn't why would the ATSB investigate? >>>>> >>>> >>>> My thinking is that the system has access to the settings for flap, >>>> thrust, mass, V1 and Vr. None of these is assumed to be correct. >>>> >>>> Also access to GPS and airspeed. >>>> >>>> In the following, the system would allow some level of discrepancy >>>> so as not to cause unnecessary aborts. >>>> >>>> Once the aircraft is accelerating, its direction together with the >>>> GPS calculated position allows the system to determine which runway >>>> the aircraft is on (position alone may not be sufficient, where >>>> runways intersect). >>> >>>> The acceleration to be expected from a given thrust setting depends >>>> on the aircraft's mass, and its airspeed. So the system waits until >>>> there is a reliable airspeed. It then can calculate the mass from >>>> the expected thrust, the acceleration and the airspeed. The result >>>> should match the setting. If it doesn't this means that either the >>>> mass is set wrong, or the expected thrust, based on the thrust >>>> setting, is not being achieved. Either of these aborts the takeoff. > >>> Not possible to MEASURE that the flaps haven't been set correctly >>> before V1 because you can only measure the effect of that after VR >>> when rotation has been attempted and it can measure that it doesnt >>> see the weight leaving the wheels in the way that it should have, > >> The issue is only whether the aircraft will take off at the set Vr, >> which is a function of the flap setting, and aircraft mass. > > Yes > >> This is something that can be determined from the aircraft'sflight >> performance data - the same data that the crew use. > > That isnt MEASUREMEMT of the plane's performance during the takeoff run > >> If the flaps are not at the position set for them, that'ssomething >> that should already have been alerted. > > What I said right from the start > >>> And given that it is already past V1, no way to abort by then >>> Makes a lot more sense to enter all the paramaters that will >>> be used like thrust settings and flaps etc and them before >>> takeoff power can be applied, check that that has been done. > >>>> Vr can now be calculated based the mass and flap setting. If the >>>> calculated Vr differs from the set Vr, this aborts the takeoff. > >>> Too late by then, its already past V1 so it can't be aborted > >> Why is it already past v1? > > Because that's the only time you know that it can't rotate at the time > that it should have been able to, because the flap setting is wrong. > >>>> From the current position, the acceleration and the mass, the >>>> braking distance can be calculated [*], and from that V1. If the >>>> calculated V1 is lower than the set V1, then abort take off. > >>>> [*] This is one area of uncertainty, since braking distance depends >>>> on runway condition (wet, dry, etc.). > >>> And can't be measured during the takeoff run > >> No, it cannot, hence the uncertainty. But if the system assumes good >> braking, and the calculated v1 is less than the set v1, then the set >> v1 is wrong regardless of the actual braking conditions. > > So its too late to abort the takeoff > > So the only thing that makes any sense is to check that the pilots > have actually set stuff like flaps and takeoff power they way they > have calculated needs to be BEFORE the takeoff can happen. > > No point in measuring anything once the takeoff run has started except with > the engine performance and that isnt what is being discussed with this > incident. Do you agree that, knowing only the aerodynamic properties of the air-frame, the actual flap position and the actual takeoff weight, the correct Vr can be calculated? If not, what else is needed? Sylvia.
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | aus.aviation
csiph-web