Posts by user "Mrshed" [Posts: 56 Total up-votes: 0 Pages: 3]

Sometimes I think asking the simple questions is the best approach.

Regardless of flap state, RAT state, etc...

Is there any scenario at all that would give the apparent flight path *other than* a lack of thrust? Personally struggling to see one although as a lowly SLF I'm interested in whether this is overly simplistic - thrust but lack of lift would (presumably) result in the same outcome, but further out. Appreciating that the data we have so far on actual flight path is patchy past a certain point.

The very fact that this was so fast (and therefore relative lack of pilot correction possible or possible to take effect) means that the flight path itself should tell a story?

Then of course, if true, one can speculate to death about *why* a lack of thrust.

The image here of the comparison flight paths is interesting as (with the caveat of this data being low resolution etc) it would show two things:

1) that the data stopped around about time of peak AGL - we knew this already.
2) that the flight path was much shallower *before* whatever event caused the data to stop (note that this data should be accurate in comparison even if not in absolute).

The second point would presumably imply whatever the issue was, it wasn't solely something that happened instantaneously once the decline began, but rather at least two events (presumably not independent) - one that impaired flight, and one that stopped the data transmission (and also likely impaired flight further).

Thank you for your efforts mods - don't envy your task on this thread (from a simple long time lurker first time poster in this thread SLF!).

The fact that one of the pilots verbally asked why they were off, presumably from visually observing this (?), would seem to rule out a short?

Exactly right.

You need to take the audio together with the switch data, not in isolation.

The two combined would appear to rule out a lot of options that the data alone would leave possible.

As a non pilot, I find this statement in the report interesting (in it's inclusion if nothing else), but I assume that this reference to the replacement module in 2023 (the module including the fuel cutoff switches?) we view as pretty irrelevant to cause?

Can i respectfully suggest that an electrical fault causing these issues, given the enormous straw grasping that such a speculation requires (when taking into consideration elements we do know, from both the data feed and the CVR), should also fall into the bracket outlined in the first paragraph, as the odds of such an event still point us to the second paragraph..?

On reopening we've gone straight back into incredibly implausible (in my view so implausible as to be virtually impossible) around electrical faults and the hamster wheel of "does it record the electrical or the physical state".

Given what we do know, any conclusion other than someone physically moved the switches really requires evidence at this point rather than conjecture.

Definitely the best and most important post of this thread IMO.

I'd be extremely concerned if they didn't.

Sorry you are missing my point.

I'm talking about an electrical failure (for example a short), which is already implausibly affecting both (independent) circuits, causing an issue in a circuit that as I understand it fails open anyway, then resolving itself to become functional again - incidentally in roughly the same time frame that a pilot would notice an issue and seek to correct.

This doesn't require knowledge of the cockpit conversation or judgement on speed (or otherwise) of the recovery. It's purely that an already incredibly unlikely scenario (electrical failure) becomes even more unlikely with the spontaneous *and synchronised, but not perfectly so* removal of the fault state of whatever this failure was.

*Edit* Given my previous post has been removed it would appear that the mods also misread this to do with timing of *pilots response*, which I find a little odd as it was in response to a comment about electrical failure...

To be honest at this point for me we are immediately hamster wheeling again, and this time because any commentary around either electrical circuit issues (astronomical odds) or accidental device triggering cut off (no evidence nor can there be right now) are speculation in nature and have to be. Equally, while the obvious culprit is hands on the switches, any comments about why again are speculation and have to be.

There's nothing more anyone can get to on this one until further CVR data is released in my view. Bowing out.

On a slight tangent, I think the saddest thing about the report is learning that the plane was starting to recover.

how far off avoiding this do we think they were? 5-10 seconds?

Not sure if this is helpful for anyone or not but I thought a visual view of the timeline of events might be useful, in seconds since V1.

I've assumed 1Hz for the switch sampling rate and >1Hz for everything else (could be wrong) to give windows for the switch state changes.

I've also added in the ADS-B relevant data, although made no attempt to work out whether these timestamps are synchronised or not, so take them as you will.

I have assumed the cutoff is in chronological order from the report, albeit I have ignored the RAT supply timestamp in terms of chronology from the CVR recording, as that statement in the report at that time may just be due to contextual nature of the statement, rather than it happening prior to the RAT power supply. This gives a window for potentially when that statement was made (assuming also that it was made prior to reversing cutoff).

Don't think it neccessarily adds anything for me, other than:

- Would we expect ADS-B data to stop on engine transition to run? Note that ADS-B data was received between 08:08:43 and 08:08:51, so apparently only received in the time window that the switches were in "cutoff"
- The window between the switches being shut off and moved to run could be as short as 8 seconds, and the window between engine 1 and engine 2 being moved to run could be as short as 2 seconds
- The statement on the CVR could be a wide range of timepoints.

The ADS-B data is in my view odd, albeit this might be my lack of understanding. Yes, not synchronised, but unless the timestamps are way out (like 10 seconds out, and given the timestamp of max altitude, this feels incredibly unlikely), ADS-B data was transmitted without issue during phase 2 (both engines off, no RAT), and phase 3 (both engines off, RAT)...but NOT phase 4 (both engines firing back up, presumably still with RAT?). Bear in mind that phase 4 is almost half of the short flight. Also it would appear no data during phase 1 (both engines on), including during takeoff, despite receiving data during taxi?

*EDIT* - having looked into some other historical ADS-B data for this airport, albeit a bit cursory, it definitely appears that the lack of data in "phase 1" that I've outlined above is solely a coverage issue, with no other flights I can see having coverage in that area either. It's harder to determine the "phase 4" element as obviously no airplanes in a normal mode are in that geographical region at the altitude in question, but it does appear to be a reasonably safe bet that the missing datapoints are coverage related.

That could make sense, the data received is centred around the recorded max altitude - amended diagram below:

Seems fair, thanks! I rattled it off in 10 minutes so suggestions/error checking welcome

Latest version:

One question, from looking at my own timeline.

It appears that we went from a position of loss of both engines (i.e. trigger for auto RAT deployment) to RAT supplying power within between 3 and 5 seconds.

Does anyone know:

1. How long the RAT takes to deploy and generate power from point of trigger?
2. Is it the act of engine loss (from fuel shutoff) that is the auto trigger, or the sub idle power that is the trigger (in which case this would take around 1 of these seconds)?

Also, at peak IAS of 180kts, presumably less by the time RAT is actually deployed, combined with the RAT drag and a minimum speed of 130kts for (reliable) RAT performance, I assume that the RAT would not in fact have provided power for all that long in truth?

I personally choose to believe at present that this isn't the most likely cause (although I think it's a close second).

However, from a potentially naive position, my gut tells me this is actually an incredibly effective method of achieving that goal, moreso than the more obvious rapid descent from altitude, mainly because you have effectively removed any window of recovery.

As such if your goal was to crash the plane, theoretically speaking, I'd say this was very effective. There's a question mark around the severity of the outcome of the crash perhaps, although even from relatively low vertical speed crashing into an urban area with full fuel loadout I'm not sure it's that big a question mark.

Just because it's not what has been done before doesn't make it less likely I'd say, and while I (as I say) still believe it more likely not intentional, I think the possibility of intentional behaviour here is easily high enough to warrant it's discussion. IMHO.

I'm pleased you said this as I've realised that my image is wrong, as the timestamp is not +/- 1 second, but only -0-1 seconds.

Corrected (FWIW):

I think the drawing is correct, you just cant count the window as the total possible elapsed time, rather that its within a 1 second window within that broader window (that in all liklihood spans seconds and doesnt tick over exactly as a second ticks over). There's a difference here between reporting timeliness, which is what we are discussing here, and reporting accuracy - both are factors in the possible actual event window.

Engine 1 transition to RUN, reported at 08:08:52, which is 19 seconds post V1. However, at 1Hz this change could have occurred up to 1 second before, i.e. 18 seconds post V1.
Engine 2 transition reported at 08:08:56, 23 seconds post V1, but same logic, so either 22 seconds post or 23 seconds post.

This does indeed give a maximum window of 4.99 seconds, although this is still approximate as it presumes that both switches are sampled at the same point in time, and it also ignores the fact that a second isnt a discrete point in time, but its close enough.

Note that if both switches arent sampled at the same point in time, which I'd assume they probably aren't, this makes the maximum possible actually 5.98 seconds, and the minimum possible elasped time just 2.02 seconds.

e.g. Engine 1 switch is sampled at the 990th ms per second, hence recording the time as 08:08:52, but this was actually 08:08:52.99, and assume this is when the switch actually changed. Engine 2 samples exactly on the second, but changed 990ms ago. Recorded as 08:08:56, but actually occurred t/f at 08:08:55.01. This makes the difference 2.02.

This assumes the timing is recorded as "within" the second in question, rather than rounding to the nearest second, but I'd strongly presume it does this as its fundamentally how computer clocks work.

Basically, when looking at two 1Hz samples and comparing, you need to add +/- 1.98 seconds to the timestamp differences to give true range. Of course, assuming stochastic sampling and assuming that the events are independent to clocks (i.e. are not triggered by a time event), then on average the most likely difference in time between them by the distribution will be exactly what it says on the tin - i.e. 4 seconds. But other time differences are possible across the distribution.

It should be noted though that under these assumptions, the probability of an actual time difference of <3 seconds reporting as 4 seconds is pretty vanishingly small (less than 0.01%), although the chances then increase significantly. But an actual 4 to 4.5 second time difference only has about 68% chance of being *reported* as a 4 second time difference, so the time deltas here do have only around a two thirds accuracy given the time granularity reported in the report.

I do assume that those more accurate records exist, *but* we dont have data records with millisecond or better accuracy, these havent been shared. So with accuracy to the second, these are the realistic possibilities.

Even with millisecond accuracy, it's not generally held practice that you would round to the nearest second using those milliseconds when reporting to a lower accuracy, generally speaking you simply remove the milliseconds, although this will vary case by case. In this case, as we don't have the methodologies, the *possibility* is very much that they have just removed the milliseconds, and as such this method gives the *possible* (albeit not probable) range of actual time deltas. Given the data we have been shared, and the lack of methods, this is the possible (NOT neccessarily the likely) range of true values.

If the report spoke about a 4 second difference, then I'd assume that 4 second difference was deduced with more accurate data and would, to your point, narrow the time window. However, they don't say that - they just report the timestamps, which introduces this wider range of possibilities.

Gracias and apologies if I wasnt clear enough on which element I was referring to! But good to have the debate for validation regardless!