Wow, that doesn't look good!!
This is a little update.
Not a lot to say but some new evidence has come to light over the past year or so.
As my writeup shows, there is absolutely clear evidence that the problem is caused by RF (3 or 4 burnouts over the same spot in France, etc).
What remains unknown is whether the cause is RF picked up by the servo signal/power wires (definitely a possibility) or whether it gets into the KC225 autopilot computer, causing it to go haywire and generate an aggressive waveform which then drives the servo into current limit. My money is on the latter. But it could also be the former in some cases and then the ferrite filters may help. It isn’t always the former because there have been loads of burnouts with the ferrite filters fitted.
A lot of people in Europe have been working on this issue (since Honeywell is basically a defunct/disfunctional company now) and some data I have recently received strongly suggests that it is the KC225 that goes haywire and it then sends the aggressive waveform to the servo and burns it out (via the mechanism documented in my writeup).
Crucially, the data suggests that the KC225 recovers from this condition after very roughly a minute, and the only evidence which the pilot may see is a gradual loss of altitude hold of about 50ft (normally the fluctuations are about 10ft) due to the pitch servo control voltage having some garbage component superimposed on it.
The slight problem is that the pitch or roll servo motor armature will have melted within that minute, which causes the pilot (who is guaranteed to be awake, not least because the cockpit fills up with a strong smell of burning enamelled copper wire 
) to reach for the red button at the speed of light, so the fact that the KC225 did actually recover from it is never noticed, and anyway the servo is gone.
It is in situations where the servo survived that the altitude deviation is visible and potentially gets noted.
This is in line with my speculation in the writeup which is that the KC225 firmware has some bug, which may be triggered by a severe integer maths underflow. Looking at the size of the steps in the servo control voltage, the algorithm appears to be implemented with just 8-bit integers, and if you e.g. divide an 8-bit signed int (max +127) by say 20 you have chucked away all but 4 bits so the servo control voltage will now have massive steps in it, and if the algorithm then enters a steady state condition in which it alternates up/down by one LSB (which is kind of likely, in binary 
) the servo will go up in smoke fast.
I don’t think it’s eactly true what you wrote (but am not sure). I think that S-ET WILL support servos in DFC90 installations, and I think that they also MUST. If there is an STC for the TB20 my bet would be that the DFC90 is (by far) the best autopilot for the plane. I’ve had it for 70 hours now, and except hat I had to change the (900 h old) roll servo it flew just perfect.
PS: I see that you like to entertain yourself with that stuff. A normal “consumer” would have thrown away that A/P by now … I think it’s pretty incredible that stuff they sell for THAT much money doesn’t work …
I have the KFC225 in my Jetprop, which was installed by Rocket Engineering as part of the Jetprop STC in 2005 since the original factory fitted STEC55 could not cope with the higher turbine speeds.
The AP has been rock solid touch wood in my 6 years of ownership since 2008.
Coupled to a GNS530W and Aspen have made it an extremely accurate AP. I am very happy with it.
Going back through the airframe logs reveals the aileron servo was replaced two years after the original install. No reason was given. Other than that no issues since.
The attitude control comes from the original KI256. I bought a spare for the day it eventually toples.
It does seem to me the issues are airframe specific. I am not aware of any reoccurring failures being reported on the Malibu owners site either.
E
I suspect the biggest number of these autopilots have been sold to Beech. Does anyone on here fly a Bonanza or Baron with a KFC225?
EAL,
what Peter suggests (if I understand it correctly) is that this occurrs in a specific spot in France due to outside signal interference. And for him at an altitude band much lower than you’d fly with the Jet Prop.
2 reasons why it can happen to him but has not happened so far to you.
Question in my mind is, is it possible to avoid the area in a wide enough distance and see if there is a re-occurrence without it? And what about shielding the wires as well as the box?
The KFC225 issues (which are almost wholly servo burnouts; the KC225 computer is very good) are highly airframe specific, and within each airframe they are highly variable too.
It is not known why.
My feeling is that since the whole thing is related to RF throwing the KC225 into some weird mode, a variation in the way the whole system is wired could explain it.
However some PA46 owners have had burnouts, as have some Beech owners, as have some C182 owners, and a huge % of Caravan owners got multiple failures (I saw a confidential internal Cessna document with the numbers).
Another factor is how much emitting stuff you have. The worst case I know, with a servo MTBF of 10-30hrs, was a TB with TCAS and a RADALT.
There is more than one thing in play. The panel vibration affecting the KI256 (not present in turboprops) will help to trash the roll servo fairly quickly. But not always…
The only way to possibly prove this once and for all would be to rig up a TB20 with data acquisition gear on the servo inputs and fly it around that Le Mans area. Or just fly around for a year with the gear in place; I happen to be very sure that you would get at least 10 occurences during a year, just doing the longer trips I occasionally do. It never fails within the UK, for me.
But even that would still not prove why the KC225 computer is going haywire – if indeed that is the cause, which I am 99% sure it is. Debugging that would need the original programmer who has prob99 moved on to more interesting pastures because nothing could be more dreary (and bad for your CV) than working at Honeywell in Olathe over the past decade.
They probably need to rewrite the code. It is stupid to use 8 bit ints; it is possible like anything else but complex integer maths needs an exceptionally clever programmer who completely understands the range of values being handled. But it could also be something different e.g. subtracting two similar numbers and then scaling the result – even in floats that will give you garbage. And it is massively unlikely anybody in R&D would have noticed because “you” just don’t go around testing your software with a scope on the DAC outputs to check the outputs really are what you expect…
There is no DFC90 STC and won’t be. I spoke to Avidyne multiple times and they always showed zero interest. More so they just thought I was a hassle even asking them. They were out of resources for any serious R&D.
Eal – all the wiring is already very well shielded in the TB20. I have been right through the plane. Socata’s wiring is mostly outstanding.
Honeywell staff meeting:
Sales director: “This peter2000 guy is becoming a problem. He’s about to discover why the servos burn out. If this gets widely known, our servo revenue will sharply decline.”
Engineer: “We can suggest to Socata to come up with a worthless modification, something like an anti-vibration kit in the panel. This will distract him for sure.”-
Sales director: “Peter2000 has just discovered our secret site in France that generates 50% of our European servo revenue. What should we do?”
Engineer: “I fear we have to admit that our product is faulty. I suggest we do so by getting FAA/EASA to issue an AD on the autopilot but let’s wait until we have a $9999 modification kit ready which just disables the servo-jitter-generator. This should more than offset the lost servo revenue.”
Sales director: “Great, get started, that will be the first R&D effort at Honeywell in over 10 years!”
Another example of a probable servo burnout situation
This happens very rarely – probably once every X hours – so is hard to catch on a video. But finally I got it.
I think it is quite possibly related to the servo burnouts but the only way to prove it would be to fly with an oscilloscope (or some kind of high speed data logger) connected to the pitch servo control input.
The altimeter is a KEA130A and I am sure the overall change (50ft) is more than just one increment on it’s encoder.
Could there be a software or other systems explanation?
It doesn’t use the KEA130A output is not used directly for altitude hold. It is used as a reference for flight level or altitude which you can set trough KAS297 or auto pilot depending on which version. This is in 100 Ft incr. The actual sensor used for the altitude hold is inside the autopilot computer. This is also the reason it has a static input.
