Coming from you, I am usually expecting more solid argumentation ...

the DFDR has a very accurate elapsed time-base and however erroneous the airplane clock could be set, what matters is the full DFDR time for the duration of the flight and the correlation with the CVR that can be established for the total duration of that flight.

Conf,
Like you, I would feel more confortable with a precise and clear timing.

But when you demand "more" (i.e. precise GMT timing), then by definition you are demanding something that is not raw data.

Indeed I think Dozy'point was that raw data should not be altered ; that means nothing added nor removed.
If not, then they are no raw data anymore, but a transcription.

Cheers.

That may be so (and probably that makes the frame count an accurate measure of elapsed time), but apparently this DFDR records GMT (or UTC) obtained from an aircraft system clock. Large aircraft in the public transport category are equipped with flight data acquisition units (FDAUs). (*). The FDAU (or equivalent) orders data and sends them to the DFDR, whose function is limited to data recording.

Data acquisition systems output a binary file sequenced in four-second frames.
Each frame is divided into four one-second-subframes.
Each subframe is divided into 64, 128, 256 or 512 “words” of 12 bits each, depending on the FDR’s technology.
The bit is the basic binary unit whose value is either 0 or 1.

A 12 bit word can have values from 0 to 4095. The time parameter is recorded in the first 'word' of a data frame.

That 12 bit word can contain the 24*60=1440 minutes in a 24 hour day, but 24*60*60=86400 seconds requires at least 5 bits more.

According to the Habsheim accident report the DFDR recorded 200 parameters, including 141 'discretes' (yes/no parameters). The attachment shows that this number of parameters required reducing the recording frequency of many parameters to once every 4 seconds. Wouldn't it be a waste of valuable capacity to record GMT with a resolution of one second when 1 minute is sufficient because the seconds can be derived from the frame count?



(*) This and other quotes are from a BEA report "Flight Data Recorder Read-Out - Technical and Regulatory Aspects". The quotes are edited for continuity.

P.S.
BTW, subtracting 141 discretes from 200 recorded leaves 59 parameters. Counting the parameters in Tome 1 through 6 that readout must be pretty complete for the number of parameters.

Got it in one. Also, if HN39 is correct that they had to go to an outside agency to extract the data in a format they could use (apparently hard copy in this case), then they would not have been able to easily rework it into a digital format again. I reiterate - in computing/information science terms the state of the art in 1988 would by today's standards be considered not just incredibly primitive, but also awkward to use, time-consuming and expensive. Particularly of note is that not only did microcomputer paradigms differ from mainframe/minicomputers in general, but even among microcomputers there was no universal standard for representing data - the norm was a mishmash of proprietary formats, all of them incompatible with each other. Transferring data was theoretically possible, but every byte would have to be individually hand-checked to ensure the data was identical at both ends.

It is therefore entirely understandable that the BEA simply tacked a copy of the raw output to the report as an appendix. I'd also be inclined to suggest that because the output is clearly raw data dumped to hard copy, it rather undermines the "tampered data" allegations. Ironically, according to Airbus's response it was the outside investigator's lack of experience with this new data format that caused him to misinterpret the synchronisation.

EDIT (as HN39's post is a useful illustration!) :

And if that description sounds complicated enough to begin with, I suspect that in 1988 one would require specialist hardware and software to translate that binary data into a human-readable format (as in the hard copy of the appendix). To transfer it digitally in the human readable form would still require specialist, bespoke software to make sure the values were not corrupted in translation (ASCII or EBCDIC? MSB or LSB?), and the internal RAM capacity of even high-end business machines may not have been enough to process the data in one pass, let alone manipulate it.

Indeed, and I think with today's level of technology in everyday use it's easy to lose sight of the fact that the growth in storage capacity and processing power is not linear, but practically exponential. The example I use is of my current cellphone, which is two years old and even back then was considered only modestly powerful, yet it has more raw processing power and storage capacity than the state-of-the-art desktop PC I built for my own use in 2002 - i.e only a little more than a decade ago, and almost a decade and a half after Habsheim. Extending that analogy, a decade before Habsheim computers were the size of a room, and reel-to-reel tape was the preferred storage medium if you were lucky - some were still using punch cards!

Doxy,
The Wirek Wire recorder issued to me as a 20 year old in 1948 recorded data DIGITALLY on a long steel wire. It couldn't do anything else, just ON or NOT ON..... It was the size of a small suitcase - but heavier.


Some 30 years later, my employers had their B707 Flight plans prepared at JFK ( or was it Idlewild ?) and telexed, digitally to the UK.


My very own ZX81 battery powered computer from 1982, recorded digitally on cassette tapes. (I learned just a little binary, too !) I saw one used with a digital camera (B&W) a year or two later.


Once data is recorded digitally, surely the use of a checksum tended to prevent or at least identify possible errors.

Read it all .. it begs the question of who authorized and certified such a system .. which is one of the elements that can (should) participate in the improvement of safety ... how to record music can have multiple incompatible formats .. but in this case it is not for fun it is for safety
These competent authorities ... are they were really competent at the time?
Certified a system that has no common standards .. the results become uncertain because of the difficulty to analyze .. is this serious?

Actually, the recordings were analogue, and Sinclair machines used DA/AD conversion to translate between the two. This was why my Spectrum-owning friends all had tape recorders with a spot of Tipp-Ex on the volume and mic pots marking the "sweet spot" where that particular Speccy could make sense of what was on the tape.

In reference to what you're saying though, all the examples you give are of digital transmissions where the source and target spoke the same digital "language". Going back to your ZX81 example, you could not take the tape with your program on it and load that program into, say, a Spectrum - which shared the same processor but the ROM kernel and architecture was different - or a Vic-20, which had a different CPU as well as a very different architecture.

Checksums only work if the algorithms at each end are identical, and even then you still have the issue of how the data is processed at each end. It is the interpretation, processing and storage of the data between different architectures rather than the transmission that is the key problem here.

@jcj : Whoa there - the system used by the CEV on behalf of the BEA had common standards, *was* compatible and *was* certified. It seems the BEA wisely chose to avoid any further processing of the data beyond using the certified systems to provide a human-readable hard copy for the very reasons I've suggested. These days, the technologies used to process, store and render the data in different forms are several orders of magnitude more capable than they were back then.

Let me make this clear - the post extract of mine you just quoted does not relate to how the data was actually handled, it relates purely to the difficulty level, technically speaking, that would have been involved in attempting to transfer the data to another machine to reformat it, a process which is commonplace today. I was trying to explain why CONF iture's complaint about the GMT time formatting etc. was somewhat unreasonable given the technical state of the art at the time.

Here's a copy of the FAA regs pertaining to DFDRs : 14 CFR 121.344 - Digital flight data recorders for transport category airplanes. | LII / Legal Information Institute

1988 rules for Flight Recorders
 

Hi jcjeant,

I think you'll find that in 1988 many airliners (particularly American ones) were still using scratch-foil (analogue) flight recorders, monitoring about 7 parameters. The DFDR on the A320 was advanced for its time.

BTW, it was unfortunate that the QAR cassette in the electronics bay was (presumably) destroyed in the ensuing fire, because that would have revealed even more data than the DFDR. ***


PS [by EDIT on Jan24]

Now that DozyW has provided that useful link to the relevant FARs for the present day, it may be worth having a look at the FAA regulations pertaining, at the time of Habsheim (1988), to turbine-powered airplane types that had been type-certificated before October 1969.

14 CFR 121.343 - Flight data recorders. | LII / Legal Information Institute

Types still enjoying the leniency of the above FARs in 1988 would have included all derivative models of B737 and DC-9 (and presumably the MD-80 series, which was certificated by amendment to the DC-9 type-certificate).

To summarise the relevant parts:
aircraft in that category (type-certificated before Oct 1969) needed only 6 parameters (one of which was time), although by 25MAY1989 the 6 parameters had to be recorded digitally (so the scratch-foil recorder was no longer acceptable), and by 25MAY1995 the minimum number of parameters rose to 11;
and individual aircraft manufactured after 26MAY1989 needed a DFDR with a minimum of 17 parameters.

So in the case of a B737-400, which was competing for sales head-on with the A320, I infer that hulls manufactured at the time of the Habsheim accident could have been registered in the U.S. with a 6-parameter DFDR, or even a scratch-foil recorder initially.

*** [by EDIT on Jan27]
Re the A320 QAR, further enquiry suggests that - on the contrary - it only records roughly the same number of parameters (and the same sampling rates) as the DFDR, although the precise specification may vary from airline to airline. A print-out of a 1988 BCAL/BA A320 QAR confirms this, and is presented in 5 "passes" - roughly corresponding to the 5 "tomes" shown in the BEA report for Habsheim.

You are misinformed - It is raw data.
The time is recorded continuously on the DFDR.

That is why one sampling every 4 seconds is practiced and is enough... Where is it on the Habsheim listing ?

Bad luck, as the pilots did not die during the crash, they had their own testimony to produce, and it appears to be slightly different from the BEA account.
Now, if you want to quickly discredit the pilots version, all you need to do is opening the data on the table, ALL the data, not the very limited amount the BEA chose to share ...

You could look, for example, at the fragment you copied in your post #336 to see that FL and MACH are recorded at intervals of 4 seconds.

As I said, I believe the DFDR readout published in the accident report contains all parameters recorded on the DFDR for the relevant part of the accident flight.

From the FAA Regulatory and Guidance Library:

We were talking about the time ... remember ?
Where are the seconds ?

The crew has questioned the engines response and thrust operation for the latest part of that flight but also for the earliest part as well as the middle one, so the "relevant part" of that flight has to be the all flight starting from engines light up ... and we're not talking about a transatlantic flight here.

Nothing is recorded 'continuously' on a DFDR. All parameters, including time, are sampled by the FDAU at specific intervals, with a certain accuracy and a certain resolution, and sent to the DFDR to be recorded. The DFDR does not generate a 'time' parameter as such. I don't know if the 'very accurate elapsed time-base' resides in the FDAU or in the DFDR, but it only serves to write subframes at intervals of very accurately one second.

In the Frame Counter, (range 0 to 4095, sampled 1 per subframe of 1 second and labelled TGEN in the printout).

You've got it backwards. For one thing, the allegations regarding aircraft performance (such as elevator behaviour and engine performance) were made by Capt. Asseline *during* the investigation, *before* the BEA report was released. We have already ascertained that the BEA's response was to take those allegations seriously, checked the DFDR data and flew an identical profile to ascertain why the aircraft behaved as it did. The engine performance was shown to be within normal limits, and the elevator behaviour shown to be a result of alpha protection. All this is included in the report. There was no need to "discredit" anyone, merely prove scientifically and by example that the aircraft behaved normally - a requirement satisfied by the report.

Notably, once things had settled, it was only Asseline who kept insisting that the aircraft had failed him - nothing was heard from his first officers since. If the crew as a whole had such faith in Asseline's position, why did they not put their names to his book? Why did his lawyers never pursue the fact - laid out clearly in the BEA's report - that the airline's standard of operations were not fit for purpose in this case? I reckon SNPL union politics have a lot to answer for here - I don't think they ever had his interests at heart, and instead saw him as a tool in their ongoing vendetta with Airbus.

However certain details are surprising

translate.google.com

Quote:

---

The two flight recorders are recovered intact but disappear the same night, transported by the director of the DGAC, a Daniel Tenenbaum without counsel Mulhouse Jean WOLF considered it appropriate to affix court sealed !

The following evening, Monday, June 27, all authorities will conclude the innocence of the accident airplane charging multiple pilot errors. The plane was flying too slowly, too low and the gas were delivered too late. All control systems of the aircraft worked perfectly. A survey at least expeditious ...

---

As per design

@NeoFit

The "tampered flight recorder" argument was based on a misreading of the data by the independent investigator hired by Asseline's SNPL team, which amateur investigators tied to a photo in which a Swiss photo expert said the two sets of flight recorder casings were different.

The problem with the latter is that no-one from the investigation ever said that the cases in the photo were those recovered from the aircraft - they may have been "dummy" units shown to the people working the site so they knew what they were looking for.

The photos of the "wrong recorders" don't even look convincingly "wrong".

It really does show how ambitious doing FBW was at the start in the 1980s, when the recorder technology is compared.

Those are not the seconds that would allow us to validate the correlation FDR CVR for the total duration of that short flight and definitely establish that the pilots were wrongly questioning the aircraft functioning.

I love you too Dozy.

CONF, every bit of footage of a search briefing involving police and volunteers I've ever seen includes a display of examples of what they will be searching for, whether that be a photo or a near-identical object.

The report states that engine behaviour was normal, meaning that the investigators compared the full FDR data to expected behaviour. They flew the aircraft for real to determine why the elevators briefly deflected nose-down. In other words, they acted on the allegations made by Asseline and in the latter case backed up what he said, though that behaviour also turned out to be expected.

Yes it does, the CVR doesn't.
Where does the labelled GMT H MN on the Habsheim listing come from then ?

If the DFDR is able to restitute every second and confirm them every 4 seconds, that's pretty 'continuous' to me.


I didn't know that one, but it seems to be a pretty good resume on the Justice side ...

He already told you:

Regarding the blog post, not only does it get significant allegations wrong (translated):

We've already established that the report does not conclude pilot error to be the only factor, and I've explained that it would be practically impossible for anyone to have manipulated the data. Plus the fact that the only extraction employed and performed by the CEV was a direct dump to paper hard copy indicates there was no intermediate process where data could have been changed (at least not without being glaringly obvious to the naked eye).

There's those four letters again - they can throw around as many allegations about the judicial handling of the case as they like, but it doesn't prove malfeasance on the judicial side and it certainly doesn't have any bearing on the technical investigation.

Hi DW,
If we all agree on the end of recording (impact) at time 339 seconds, then is there any point about discussing when the recording started?

If you look at data on TOME 4, at time 240 secs, the engine N1s (1,2 %)follow the TL positions (Manettes 1,2 DA (angle)). As the TLs are closed (+014 to -0), the engine revs decay slowly from 68% to about 30% - which appears normal.

Between time 328 to 330, the TLs are advanced to the GA position (+45) and the engine revs increase from 29% to 83% by time 334.
The TLs are then closed briefly (-0) at time 336, and then advanced to +25 position at time 338. Meanwhile the engine revs decay from 83% to 56% then back to 86/87% - then end of recording.

It appears that the engines did respond normally (they achieved 83% within 4 to 6 seconds of moving the TLs from idle), but Capt. Asseline thought they had not and briefly closed them seconds before impact.

Interesting. Am I right in thinking that procedure of going back to the idle detent and thence forward to climb or TOGA only really applied to situations where A/THR is active? If so, it might indicate a last-ditch reversion to trained behaviour on the part of the Captain, even though A/THR was supposed to be disengaged?

That reduction to 56% certainly wasn't going to help matters in front of the trees; it would also have set the computers an unusual - if not difficult - task, to hold the aircraft stable close to maximum AoA as the power cycled up, half- way down and then up again.

I wonder if that power reduction about 5 seconds before impact agrees with the much-discussed-on-documentaries sound recording timing from the crowd's video? Perhaps the conspiracy-minded are hearing and timing the second rise in N1 just before impact with the trees, when in fact they should be timing the first rise in N1 after which the throttles were cycled. I remember "5s" is always quoted as the claimed engine delay.

I also wonder whether the perceived lack of apparent response from the engines that led to Asseline cycling the power levers was reinforced by odd cues from being lower and slower than expected?

Hi DW,
If you select TOGA, you should get TOGA power irrespective of whether the A/T is engaged or not.
It appears to me, that had he maintained the TLs in the TOGA position, then he would have had TOGA thrust by time 335 (engines accelerate very quickly at high power settings).

Hi rrr,

"If we all agree on the end of recording (impact) at time 339 seconds, ..."

Afraid not... HN39 and I have discussed this at some length. The last time frame whose data is totally uncorrupted is TGEN 334.0, and is treated, IIRC, as t-zero in the reports.

During TGEN 335.0, the data start to unhinge. That, following what appear to be uncorrupted signs of the initial impact, is particularly noticeable in the 4 sequential values of x and y accelerations (longitudinal and lateral respectively), and the 8 values of z (normal) acceleration presented in Tome 3. In Tome 1, the single sample of GS glitches to 648 kt.

Just to be clear, this should not be seen as anything particularly untoward in terms of process. As it turned out, the Loral-branded F800 DFDRs fitted to early A320s had issues with data corruption when subjected to shocks over a given threshold:

G-KMAM Incident

A320 Spoiler Disconnection

And all at 10 46 GMT when the crash was at 12 45 ...
You are all very confused, and the BEA made sure you would be with such a 'pitiful' report.
Never wonder why the English version was not on the BEA site ... ?

Gentlemen,

Although the DFDR itself has the advantage of being in a protective compartment at the tail of the a/c, the scores of sensors that supply the data to it, not to mention the FDIU/FDAU itself, are not afforded that luxury. They wouldn't be much use if they were...

Hi Chris,
Thanks for the correction.
In which case, Capt. Asseline didn't select TOGA until sometime after 328 and before 330.
That was only 4 to 6 seconds before impact with the tree tops, and the engines had accelerated to 83% & 84%.

Edit: I don't see what was unusual about the engines response.

http://www.blackholes.org.uk/PP/Typi...ponseChart.jpg

Am I? How convenient :)

@ CONF, post 383

If the crew questioned the aircraft functioning BEFORE their presentation at Habsheim, they have been even more stupid to start such an unusual flight, very close to the limits of any operation particularly with passengers on board!

@ Bidule, post 398

It is not forbidden to read the thread first.
Habsheim #312

@CONF:

The BEA aren't hiding the earlier (known) malfunction, it simply isn't relevant to the incident. They are hiding nothing else. People who are still tilting at windmills, like yourself and your chums at the SNPL however, are very much on a hiding to nothing if this thread is anything to go by.

Not even the English version of the report or the annexe VII ... but why am I asking that to a guy who even don't know the CONF setting used in Habsheim but cannot stop commenting on things he simply has no knowledge on ... !?

If you use the report search facility on the BEA's website, you'll note that even today the BEA do not routinely publish a report in a language other than French unless one of the major parties involved comes from - or unless the accident itself occurred - outside of France. No "hiding" there.

Annexe VII covers the period directly concerning the accident only - it was, and in many cases still is, standard practice for most agencies to do this. Any data from other phases of the flight is quoted in short form during the narrative section of the report - again, nothing "hidden" and nothing untoward.


I was tempted to report your post for this unnecessary personal swipe, but haven't done so as I don't want to seem petty.

For what its worth I've deliberately restricted my input to the computer systems design and specification as much as possible - any comment of mine outside of those bounds only refers to aspects that can be understood with a little basic aero knowledge plus a decent level of reading comprehension (or explicitly quotes people with the requisite qualification when responding to them).

Far more qualified minds than mine have been picking apart the technical and piloting aspects - not to mention the operations angle in which, as the BEA correctly stated in their report, AF are deservedly found significantly wanting (I found gums' sense of disbelief very appropriate on that point). You've got A320 line pilots both current and former - as well as at least one A320 TRE - saying that the aircraft behaviour seems normal.

From my point of view, and I've said this before, I take back my initial reservations about going over this again because I've learned a whole new raft of information for which I am very grateful. I came into this new discussion ready to defend my existing position that the BEA report was fit for purpose and the aircraft's behaviour expected, but prepared to be open to change that opinion if evidence showed otherwise - I have to say that the new or clarified information uncovered has tended to strengthen that opinion (for what little my opinion is worth) rather than undermine it.

As far as the non-technical aspects of the aftermath go, it seems to me that it was the parties acting for Capt. Asseline and the union who showed more interest in pursuing a predetermined agenda than the judiciary, Airbus or the BEA. Of the latter three parties, it is the BEA who in retrospect come across as by far the most even-handed, going to considerable lengths to take evidence, both primary and secondary (from all parties) into consideration when trying to determine what happened. The oft-repeated myths that the authorities sought to solely blame the flight crew, ignored allegations made by Asseline and the SNPL and tampered with flight data simply do not stand up to scrutiny when even a cursory review of the evidence is undertaken.

I do have some sympathy for Capt. Asseline, because while his judgement skills regarding conduct of the flight undoubtedly fell short of the standards required, he and his flight crew were poorly prepared and briefed by the airline prior to the flight (and the airline subsequently had no qualms about using a contradictory rule regarding minimum altitude for display flights to throw him under the bus). Not only that, but as Chris Scott suggests, I'm beginning to think he was poorly advised by those representing him - leading him away from what may have been a reasonable argument against the airline and instead convincing him to pursue allegations of technical failure against the manufacturer, a much more difficult proposition legally, but more in keeping with their long-held desire to score points against Airbus.

That it can be inferred such advice was given to an undoubtedly traumatised man wrestling with his own sense of responsiblity - of which a natural psychological factor is denial - does little to endear them in my opinion.

@ CONF

It had been read but as you again went this way, the repetition seems to be useful!

Quote from Linktrained (January 13th):
"The flight had been briefed to be at 100 ft along R/W 34 L.
Perhaps due to the realignment with grass R/W 34 R the aircraft used some of its potential energy (now only height and airspeed, with flight idle having been set at 12.44.14) the descent to 46 ft became inevitable. This required more of a climb than hadbeen planned - or an earlier selection of TOGA by a few seconds ( 10 ?)."

Sorry to respond so late. First, perhaps it's worth reminding ourselves and others again that the fly-past was ill-conceived by the airline, with no provision made for a recce-flight or a ground inspection, and minimal preparation by both the airline and the crew. The notion of making an approach with a load of commercial passengers to a platform of 100ft QFE on an unknown non-runway (in A320 terms) - followed by a level-off, during which the a/c would be decelerated to within a couple of degrees of the stall AoA; followed by a high-alpha go-around - must rate as one of the most irresponsible in public-transport ops since the flying circuses of the 1920s and 30s.

Once committed, there would be little room for even one technical failure or significant crew-misjudgement. This crew seems to have made at least three serious errors in the execution of the briefed game-plan.

(1) The a/c arrived at the airfield boundary with far too much energy - kinetic and potential - to achieve the briefed game-plan of establishing stable flight at high AoA, using thrust to maintain speed in level flight during the transit of the airfield.

(2) The a/c levelled off at an indicated barometric height of about 60 ft above the reference altitude of the airfield - on both the pilots’ altimeters. (This assumes they had been correctly set to the QFE of 984 hPa, as announced in the CVR transcript). During the next 14 seconds before first impact, the barometric height fell slightly to about 50 ft, finally recovering to about 60 ft. Allowing for pressure-altimeter tolerances, together with the forward position of the static-pressure port and the aircraft’s high pitch-attitude, as much as 20 feet could be subtracted from the above values to “guess-timate” the actual heights.
It seems clear that, however foolish the airline and the captain were to plan the flypast at 100 ft on the QFE, the a/c would in all probability have cleared the trees had it been flown thus.

(3) The go-around was initiated too late to achieve any significant climb before the tree line was reached. In the event, insufficient time was allowed for the certificated time of engine acceleration from idle thrust, and the a/c was carrying a negligible surplus of kinetic energy to convert to any increase in altitude.
Prior to selecting TOGA thrust, the crew may have neither been aware of the horizontal distance to the tree line; nor the fact that the engine nacelles, landing-gear, and rear fuselage were lower than the tree tops. Their opportunities to recognise the hazard of the trees may have been limited: due initially to the rushed approach, and later to the visibility restrictions of the high pitch-attitude.

Is it usual to see such mistakes punished by nine months firm jail?