Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF447 Thread No. 3

Tech Log The very best in practical technical discussion on the web

AF447 Thread No. 3

Old 14th Jun 2011, 14:20
  #2001 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
Received 0 Likes on 0 Posts
With all due respect, I'd like to add that crimped connections, when done properly, are just as good (if not superior) as soldered connections in all respects, including resistance to corrosion. What's more important, crimped connections - again, using the right tool - are far more consistent, even when done by underpaid and ignorant personnel, which is often the case (hope that does not apply to Airbus).
Agreed. A crimped joint is effectively a cold welded gas tight joint and
without a skilled workforce, better than solder. Crimp tools do need to be
tested /calibrated to ensure that that the crimp pressure is not
too low (bad connection) or too high (embrittle the wire or even
partially shear through). Soldered joints can have a much greater
variability: "dry" if the joint is not heated enough and intermittent if
too little solder / flux or not properly wetted. Other problems with soldered
joints include embrittlement with temperature cycling and vibration.

A lot of early avionics, computer and mil kit was "wirewrapped", where
you get 16 or more cold welded joints as the wire is wrapped round a
square pin. Just about the most reliable board level interconnection
system ever devised and still used here occasionally for quick prototyping
work...
syseng68k is offline  
Old 14th Jun 2011, 15:11
  #2002 (permalink)  
 
Join Date: Aug 2009
Location: Texas
Age: 64
Posts: 7,190
Received 384 Likes on 238 Posts
SIms and their limits

Dozy:
At this point, BEA and Airbus know what was being displayed on at least one set of instruments, they know which versions of the software was installed on the aircraft's computers and they know what the timestamped ACARS messages were.

That's enough to gain a reasonable idea of what that particular aircraft did in terms of systems behaviour, over and above what control inputs were from the pilots.
Up until stall, yes.

How they determine validity of airmass data will be an interesting revelation, given spurious airmass data as contribution to the event.
This should be enough to run simulator tests with crews to gauge their responses to the situation that presented itself, in much the same manner as the Birgenair investigation did. The systems are not so complex that recreation of the incident is impossible.
Yes, except for the simulation of what happens once the aircraft stalls ... which goes back to "how do you train to get out of a stall once in?"

Up to that point, both stall prevention and error/trend detection processes and habits may be usefully analyzed.

There is a danger in making assumptions about what was on the PF's display set ... maybe BEA can figure out and publish more of that between now and when their final report comes out.

Also, crews put into the scenario ought to be unalerted, if you want to collect some data on the man-machine interface. <--- That appears to be a critical performance node that must be examined.
Lonewolf_50 is online now  
Old 14th Jun 2011, 15:21
  #2003 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Connection faults

We assembled a big System (SPC Telephone switching System) prototype using "wire wrap". Big dense boards presenting complex testability issues.

I am amazed they were used also in avionics. (you lost precious volume due pins lenght).
RR_NDB is offline  
Old 14th Jun 2011, 15:25
  #2004 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Lonewolf_50:

Absolutely correct on your last point (I said something similar before), though simulations are inherently limited by the fact that any crew in the sim will be expecting something to go wrong.

That said, the Birgenair sim tests almost universally ended with a crash into the sea, even with the most experienced and capable pilots at the controls. The combination of overspeed and stick-shaker warnings seemed to induce a psychological "freeze". Of course in this case there's no evidence of overspeed detection, warning or protection activation, but I'm fairly sure that the warnings would have been just as overwhelming even if not as disorientating due to their completely contradictory nature.
DozyWannabe is offline  
Old 14th Jun 2011, 15:31
  #2005 (permalink)  
bearfoil
Guest
 
Posts: n/a
Doze

"Of course in this case there's no evidence of overspeed detection,"
I don't remember what the speed (Mach) ACARS record was about then. I thought it meant too much speed?
 
Old 14th Jun 2011, 15:36
  #2006 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Hi bear,

None of the ACARS lists (raw and interpreted) that I can find give a MACH warning. Could you provide a link?

Thanks.
DozyWannabe is offline  
Old 14th Jun 2011, 15:40
  #2007 (permalink)  
 
Join Date: Aug 2009
Location: Texas
Age: 64
Posts: 7,190
Received 384 Likes on 238 Posts
bear/dozy:

If I may, we need to be careful and aware as we discuss this regarding the difference between what speed was through the airmass, and what speed was indicated, since an axiom in this case is that the sensed and processed airspeed was (for at least part of the event chain) unreliable, and not a reflection of the actual speed through the airmass.

This got me to thinking. Will BEA be able to compare inertial references to isolate when true airspeed was being detected before things went awry. You could backwards compute it from ground track for x minutes before the event. You would come up with wind and true airspeed then, and maybe get a better handle on (by using ground track compared to Airspeed during the event) a finer estimate of what the plane was doing despite what it was displaying ... airmass wise.

Hopeful.
Lonewolf_50 is online now  
Old 14th Jun 2011, 15:46
  #2008 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
LW_50, of course. I'm not concerned about what the actual speed was in terms of this discussion so much as what warnings and annunciations were presented to the pilots. They already knew their speed indications were unreliable, but I suspect things will become clearer once we know what aural warnings were sounding at the time.

Birgenair proved that insistent and contradictory warnings can overwhelm a crew, and procedures were developed in the wake of that incident to better cope with that situation. Were the crew able to recognise their situation and apply those procedures accordingly?
DozyWannabe is offline  
Old 14th Jun 2011, 16:14
  #2009 (permalink)  
bearfoil
Guest
 
Posts: n/a
Doze

2:10:29 WRN/WN 090601 [2:10] 2288300206 FLAG ON CAPT PFD SPD LIMIT
 
Old 14th Jun 2011, 16:26
  #2010 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Bear : According to this FCOM analysis:

http://www.keepandshare.com/doc/1319...m-1-7-meg?da=y

it refers only to the target speed displays:

- FLAG ON CAPT PFD SPD LIM and FLAG ON F/O PFD SPD LIM: characteristic speeds (green dot, VLS, ...) lost due
to loss of calculating function
This is not an indication of overspeed that I can see, nor would it trigger an overspeed warning.
DozyWannabe is offline  
Old 14th Jun 2011, 16:35
  #2011 (permalink)  
 
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by RR_NDB
We assembled a big System (SPC Telephone switching System) prototype using "wire wrap". Big dense boards presenting complex testability issues.
I am amazed they were used also in avionics. (you lost precious volume due pins lenght).
From my own experience, I think you'll find that in avionics "wire-wrap" was only used for the "mother-board" wiring, and not for the circuit boards themselves, so "volume loss" was not really an issue.

BTW, I think the whole "wiring" issue is a red herring.... I was hoping somebody with enough knowledge of the ACARS system would come forward with an exact definition of the "WRG" message label, but so far that hasn't happened (or did I miss that?)..

I would have expected faults such as a faulty SSM, or NCD, or parity errors, to have been flagged "BUS" rather than "WRG".
ChristiaanJ is offline  
Old 14th Jun 2011, 16:40
  #2012 (permalink)  
bearfoil
Guest
 
Posts: n/a
Thank you, Sir..

I'd be interested to find out if that indicates the warning Flag is unavailable, or that it is ON. Isn't ACARS just a sensing and recording (reporting) system? Kind of like a snitch? It doesn't compute, so how would it "know" that the PFD is bananas re: a/s? Is it told by the FMC what to report, or does it just record anomalous data? "Observe Only" kind of.

thanks for all,

Yesterday I jumped from the bridge down to the salon deck on my boat, rather hard. The GPU started up. Spooky.
 
Old 14th Jun 2011, 16:50
  #2013 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
@bear - I think the effective word is "lost" - i.e. FLAG ON is a notification to maintenance that the PFD SPD LIM has become unavailable. The PFD isn't "bananas", so much as it has lost some data that it would usually present.
DozyWannabe is offline  
Old 14th Jun 2011, 16:58
  #2014 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
Received 0 Likes on 0 Posts
RR NDB, 2003
We assembled a big System (SPC Telephone switching System) prototype
using "wire wrap". Big dense boards presenting complex testability
issues.
Wirewrap was used extensively in the old strowger exchanges and probably
electronic as well, though iirc, they used bigger pins and something
like 22swg wire, rather than the 0.025" pins and 30swg wire commonly
used in electronics. All the early Dec computers, pdp8, 11 etc and vax
used wirewrapped backplanes, because it has low capacitance, lends itself
to tape controlled machine wiring and makes it easy to reconfigure the
machine.

I did some work for a company in the early 80's who free issued an electric
w/w gun etc and a big box of pre stripped wires of various lengths. They
said keep it when the work was done and am still using the tools and wire
even now, from time to time.

I am amazed they were used also in avionics. (you lost precious volume
due pins length).
I don't have many examples, but have seen an early analog fuel
control "computer" that used wirewrapping between modules. Also, the sea
slug seeker head (really) that I saw at a show. The sea slug used
an X band'ish radar rx, painted externally. The analog electronics boards
were fitted into slots in a heavy ali extrusion, with each board having
wire wrap pins at each end. Pcbs at each end of the extrusion had associated
w/w pins that wirewrapped to the board pins, with the result that there were
no connectors in the system at all, other than a few 'D' series and sma for
the rf bits. Quite an impressive piece of kit, rf head and dc servos to
control the dish in azimuth and elevation. The sort of technology you don't
see very often, unless you work in that area, but interesting and it all
adds to the knowledge base.

Apologies for the drift ...
syseng68k is offline  
Old 14th Jun 2011, 17:29
  #2015 (permalink)  
bearfoil
Guest
 
Posts: n/a
Doze I get your description. I also appreciate your great patience. I am not getting the 'language' used in ACARS. "FLAG ON". If that means it is recorded, wouldn't the MX know that? It sounds like "A Warning that is displayed on PFD has been recorded." Is that so that it can be read by Mx more eassily? As in "Speed Limit" .functionality' is lost? Or is all this just bunk airspeed data at the Peetos?

Thanks, you are a gold mine.
 
Old 14th Jun 2011, 17:39
  #2016 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
WRG FLR

Hi, syseng68k

Being "hardware oriented" it seems they had a lot of stray capacitance and inductance with no ground plane, therefore "non controlled impedance. Just basing in my RF intuition. . At this time i characterized back panel daughter boards connectors using TDR reflectometers. Very interesting results.

Back to main program

Like, ChristiaanJ put:

2:11:55 FLR/FR0906010210 27933406EFCS1 X2,EFCS2X,,,,,,FCPC2 (2CE2) /WRG:ADIRU1 BUS ADR1-2 TO FCPC2,HARD

What kind of Failure is this?
RR_NDB is offline  
Old 14th Jun 2011, 17:43
  #2017 (permalink)  
 
Join Date: Mar 2008
Location: France
Age: 80
Posts: 70
Likes: 0
Received 0 Likes on 0 Posts
wire-wrap

syseng68k, you can add DEC pdp9 in the mid sixties to that list. Can't remember the wire gauge tho, and we did occasionally re-jig the wiring.
daved123 is offline  
Old 14th Jun 2011, 18:27
  #2018 (permalink)  
 
Join Date: Aug 2000
Location: Patterson, NY
Age: 66
Posts: 436
Likes: 0
Received 0 Likes on 0 Posts
daved128

DEC's PDP-9, the first system I worked on, used 30-gauge wire. (The wire-wrapped backplanes did anyway.)
rgbrock1 is offline  
Old 14th Jun 2011, 18:35
  #2019 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by bearfoil
It sounds like "A Warning that is displayed on PFD has been recorded." Is that so that it can be read by Mx more eassily? As in "Speed Limit" .functionality' is lost? Or is all this just bunk airspeed data at the Peetos?

Thanks, you are a gold mine.
No problem.

Now, I'm pretty sure that MX will have a lookup table to cross-reference what those brief text statements actually mean. If you read the PDF I linked, you'll find all the FCOM references to those ACARS messages and what they mean. In the case of the message you're talking about, the "green dot" display on the PFD which gives the manouvering speed and the VLs (minimum selectable airspeed) has disappeared because the airspeed information has dropped out. In this case SPD LIM means that those limiting speeds are not displayed.

If I've done my homework right, an ACARS overspeed message would be similar to the ECAM messages and would clearly be identified as OVER SPEED.

@RR_NDB:

These are the ACARS messages that are effectively maintenance-only:

2:11:49 - .1/FLR/FR0906010210 34111506 EFCS2 1,EFCS1,AFS,,,,,PROBE-PITOT 1X2 / 2X3 / 1X3 (9DA),HARD
2:11:55 - .1/FLR/FR0906010210 27933406 EFCS1 X2,EFCS2X,,,,,,FCPC2 (2CE2) /WRG:ADIRU1 BUS ADR1-2 TO
FCPC2,HARD
They're listed in the same PDF. FCOM information is given, but if I understand it correctly, the first message refers to pitot data failure, and the second refers to the same data discrepancy in the computer system itself (ChristiaanJ : note the presence in the full message of BUS, implying data transmission rather than physical wiring problem).

Last edited by DozyWannabe; 14th Jun 2011 at 18:47.
DozyWannabe is offline  
Old 14th Jun 2011, 19:16
  #2020 (permalink)  
 
Join Date: Mar 2008
Location: France
Age: 80
Posts: 70
Likes: 0
Received 0 Likes on 0 Posts
PDP9

Remember adding in a - gasp - 64K ferrite core store as an upgrade.
daved123 is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.