Habsheim

[CONF iture]

Originally Posted by HN39

RE 1: In those days the BEA didn't have facilities to read DFDR tapes and decode the data. The tape was read at the CEV (Centre d'essais en vol), the french military flight test centre, which also does civil certification test flying and houses the french national test pilot school. The print looks to me like it was produced on a IBM typewriter or daisy-wheel printer and published in the report as it was received from the CEV.

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

RE 2: The DFDR GMT parameter probably records only hours and minutes (remember the timestamp of the AF447 ACARS messages?). The seconds have to be determined by counting the frames, and fractions of a second from the parameter position within the frame word sequence. Who sets the GMT clock in the airplane? The wording of the note in the Airbus memo suggests that TGEN is not a recorded parameter but a frame count added in the CEV printout of DFDR data.

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.

[AlphaZuluRomeo]

Originally Posted by CONF iture

And where my post #336 is "criticising the BEA for supplying raw data" ?
All I can see is demanding for more ... not less.

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.

[HazelNuts39]

Originally Posted by CONF iture

the DFDR has a very accurate elapsed time-base

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.

[DozyWannabe]

Originally Posted by AlphaZuluRomeo

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.

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!) :

Originally Posted by HazelNuts39

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.

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.

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?

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!

[Linktrained]

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.

[jcjeant]

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.

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?

[DozyWannabe]

Originally Posted by Linktrained

My very own ZX81 battery powered computer from 1982, recorded digitally on cassette tapes.

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

[Chris Scott]

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.

[CONF iture]

Originally Posted by AZR

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

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

Originally Posted by HN39

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?

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 ...

[HazelNuts39]

Originally Posted by CONF iture

Where is it on the Habsheim listing ?

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.

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 ...

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.

[HazelNuts39]

From the FAA Regulatory and Guidance Library:

Code of Federal Regulations

Part 121 OPERATING REQUIREMENTS: DOMESTIC, FLAG, AND SUPPLEMENTAL OPERATIONS
Appendix B--Aircraft Flight Recorder Specifications

Sec. B121.1

Appendix B--Airplane Flight Recorder Specification.


Parameter: Time (GMT or Frame Counter) (range 0 to 4095, sampled 1 per frame).
Range: 24 hours------------
Accuracy sensor input to DFDR readout: ± 0.125% Per Hour-------------------
Sampling interval (per second): 0.25 (1 per 4 seconds).
Resolution readout4: 1 sec.


4This column applies to aircraft manufactured after October 11, 1991.

Amdt. 121-197, Eff. 10/11/88

[CONF iture]

Originally Posted by HN39

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.

We were talking about the time ... remember ?
Where are the 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.

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.

[HazelNuts39]

Originally Posted by CONF iture

The time is recorded continuously on the DFDR.

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.

Where are the seconds ?

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

[DozyWannabe]

Originally Posted by CONF iture

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.

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.

[NeoFit]

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

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

[DozyWannabe]

@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.

[awblain]

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.

[CONF iture]

Originally Posted by HN39

In the Frame Counter, labelled TGEN.

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.

[CONF iture]

they may have been "dummy" units shown to the people working the site so they knew what they were looking for.

I love you too Dozy.

[DozyWannabe]

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.