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

SIms and their limits
 

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

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

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.

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?

Hi bear,

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

Thanks.

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.

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?

Doze

2:10:29 WRN/WN 090601 [2:10] 2288300206 FLAG ON CAPT PFD SPD LIMIT

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:

This is not an indication of overspeed that I can see, nor would it trigger an overspeed warning.

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

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.

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

RR NDB, 2003
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 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 :8 ...

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.

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. :8. At this time i characterized back panel daughter boards connectors using TDR reflectometers. Very interesting results. :8

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?

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.

daved128

DEC's PDP-9, the first system I worked on, used 30-gauge wire. (The wire-wrapped backplanes did anyway.)

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:

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

PDP9
 

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