Nothing wrong with assembler 
I have written megs of software in assembler and in most of the products nobody ever found a single bug, after it was released.
I think modern software development is much worse than it used to be. Managing a team of programmers doing something what really has to work must be quite a challenge.
However I don't think the KFC225 issue is radiated RF. The KC225 computer is in a metal box, as are nearly all avionics. It is very well enclosed and shielded. I think the crashing problem is triggered by conducted RF, via the wiring, combined with flaky software which runs the control algorithm using crude 8 bit arithmetic and if it gets too much of some input it starts to lose bits (see my writeup) and sends a very rough waveform to the servo.
As you say it's easy to shield a box against radiated RF. The old industrial (CE EN specs) were 3V/m and 15V/m (IIRC) but everybody submitting products for these tests chooses the wiring and the wire quality carefully so as to pass the test! I hear that big jet FADEC boxes are tested to 250V/m, and presumably they use really good cabling too.
What you can't guard against is what you don't know, or forgot to protect against... as a result autopilots do crash, some more than others, and some a lot more than others. There is also quite a history of avionics crashes in "plastic planes" although few people will talk about their experiences other than privately (dealer relationship issues) and it is gradually improving.
What you can't guard against is what you don't know, or forgot to protect against...
Or didn't even exist when the avionics were designed! People now carry devices on board that transmit GSM, DCS, Buetooth, WLAN,... these frequency bands were unoccupied 20 or 15 years ago when most of our avionics (even the fly-by-wire computers of Airbusses!) were designed and tested.
And regarding "forgotten": When the Tornado was introduced to service in the early 1980ies, one of the first German Tornados crashed on a low-level sortie because it had come too close to a civilian radio mast. They has immunised it against all known military frequencies, but forgotten high-intensity civilian TV transmission.
Also you can't control how some chimp does the wiring, for example.
I don't know how low you overfly the SAM site, but I guess there should be at least 500' distance. If some pulsed GHz RF energy seriously upsets the microcontroller in your autopilot, something's seriously wrong with the AP hardware.
But then again this is hardly surprising, aviation electronics isn't exactly robust against interference. Yesterday I found out that the CDI output of my GPS produces 1.5 dot deviation to the left when I connect my tablet PC to the cigarette lighter connector for recharging. This is a DC signal, it could have been easily filtered so that even if a chimp did the wiring, nothing bad happens.
Or didn't even exist when the avionics were designed!
So? But broadband amplifiers and lab signal generators and EMI test chambers did exist, even 50 years ago.
Furthermore, SAM sites existed too, in even greater numbers...
So? But broadband amplifiers and lab signal generators and EMI test chambers did exist, even 50 years ago.
They sure did exist. But there was no requirement to test (GA) avionics over the full spectrum.
I was 5000-15000ft over the French site. You can see the GPS altitude plots in the writeup.
Re EMC testing, it is generally meaningless unless the punter is actually trying to achieve a specific resistance to a specific environment which he either knows accurately or actually controls.
Most equipment that goes to a test lab (and I have spent countless hours in these labs, paying up to €1000/day) goes there to get the CE (or whatever) sticker, or as a due diligence exercise to support a ENxxxxxx line in the product spec. The manufacturer doesn't generally give a damn, and will use every trick (e.g. making up really good cabling for the test) to get it through. Everybody knows that one can almost never test in a representative environment so you just go through the motions...
If you take a typical GA plane, you have wiring going all over the place and you have no control over how well that is done. But even if it is shielded (which it normally is, and Socata wiring was done to a high standard) if you irradiate say 3m of a shielded cable with say 1kW at some microwave frequency, the shield isn't going to be doing an awful lot, due to its impedance at those frequencies. You are then relying heavily on airframe shielding and if e.g. the belly panels are painted then they may not be grounded to the airframe too well. I have bonding straps on mine now, but really any microwave shielding needs to be continuous, with every belly panel screw actually connecting the two.
Curiously I have never seen interference between any on board gadgets (phones etc) and navigation gear. One can hear the interference in the headsets easily, and cheap cigar lighter connected power supplies often interfere with VHF comms (on some frequencies, not all), but I have never seen nav affected.
However there seems to be a correlation (with a very tiny sample size) between planes fitted with heavy radiating gear (TCAS, RADALT) and the KFC autopilot failures. One TB owner had servos burning out every 20-30hrs. Those weren't missile sites! So, when I had the TCAS fitted, I free issued the shop with RG400 cable which they should use but weren't going to.
PiperArcher - you will find the exciting 411 page IM for the Century 2B here.
Have a look on e.g. page 9 of the PDF
Thanks Peter. I am away at the moment so have limited internet access. I had only seen the shorter version of that documents and couldnt image that 411 pages could be written about a 1970´s AP. Thanks for finding it, and looking forward to catching up with other forum messages when I get back.
I have a huge collection of avionics manuals. Just let me know if you want anything...
Nothing wrong with assembler I have written megs of software in assembler and in most of the products nobody ever found a single bug, after it was released.
Same here but it was long time ago. I also used to write some portions of code in assembler for DOS applications if I wanted them to run faster, direct video managing or communicating with external devices.
I think modern software development is much worse than it used to be. Managing a team of programmers doing something what really has to work must be quite a challenge.
Oh, don't remind me what I have to do today
I think modern software development is much worse than it used to be.
I tend to disagree. There was a time in the 90-00s where vastly increased complexity was not under control but we are better than ever today. Look at things like iPhones and Android phones. They are hugely complex (iOS is a Mach 3 microkernel mixed with a BSD operating system and on top of that the Nextstep windowing environment, how more complex can it get?) and yet very reliable. Earlier in my career, I would restart my computer a dozen or more times a day, now only when one of those "important" updates want so.
The biggest issue with avionics is that there is no competent after sales support. The companies are not interested in improving the products. The best example is the KFC225 which is a faulty design but one that would be easy to improve, if only the manufacturer had any competence or interest in it.
One reason is the business model. Remember the good old Nokia phones? They were "sell and forget" from Nokia's point of view. There was no reason to keep on improving them beyond fixing embarrassments that created bad press. Apple changed that because they established a continuous revenue stream and customer relationship.
One avionics company that does this rather well is Aspen. They keep on adding features and charge money for it. Since I bought their PFD, I purchased three additional things from them: 1) synthetic vision, 2) extended 5 year warranty, 3) DFC90 autopilot support. In return I keep getting firmware updates with lots of improvements so it's a fair deal. If they're really smart, they will at one point develop a more powerful hardware and offer an exchange at cost price so they can keep on adding features and charging users.
