I've just read that on the DA40/42 the "IFR Annual" requires the removal of the autopilot servos (which I believe are the KS270C/KS271C/KS272C) for some purpose. Does anyone know what they do with them?
Whenever I go to my A&P and he's got a DA20/40 in his shop, after some time he starts cursing about its maintenance. Diamond requires a lot of complex checks and maintenance operations that are not found anywhere else. One example is that you have to remove the wings every x hours. Even with the latest SIDs from Cessna, you don't even have to get close to touching a a wing spar, even if your Cessna is from 1950.
Whenever I go to my A&P and he's got a DA20/40 in his shop, after some time he starts cursing about its maintenance.
I get the same when I speak to anybody working on these.
Whether the extra work is financially material I don't know. One can expect a modern aircraft to require different procedures to a 40 year old design, and one can expect this will irritate a lot of "old" engineers used to the Cessnas and Pipers which they normally deal with and whose maintenance requirements are for the most part discharged by the use of this
Even the mostly-American and really basic French-made TB aircraft cause irritation and confusion among engineers, especially in the USA.
Back to the KFC225, I have just received the special instrument panel mounting modification kit
which as you can see from the drawing is an ultra high technology solution to the KI256 horizon vibration which Honeywell are trying to pin the whole "smoking servo" blame on. You are supposed to slip two of these grommets over each of the existing rubber mounts. I've updated the KFC225 writeup at the end, with the details. It might make a small difference to a small facet of the issue.
Given that they don't find people with knowledge of electronics, it's probably the best they could come up with. Eventually they will have to hire you. Part of your agreement will be that you will not allowed to claim that Honeywell's designs are imperfect.
HoneyWell UK are hiring at the moment. Maybe if we all put in a good word for him, they'll give Peter a job 
After more bench testing, I now think the ultimate reason for these servo burnouts is that the KC225 computer goes "mad", for maybe 1 minute, and outputs a waveform which is of the order of 10Hz and about 1V P-P i.e. 10% of the maximum possible output.
And looking at my GPS altitude data, does it while still controlling the aircraft.
The motor cannot mechanically follow such a waveform, so this does not cause the servo output gear to move, so the pilot cannot see anything, but it drives the servo amplifier into current limit, and blows it up as described earlier.
I have simulated this in the bench, with a signal generator. Slower and/or larger spurious signals will cause the ailerons or elevator to move so you would notice. But AFAIK nobody has ever noticed anything at all, prior to the aircraft losing control along the failed axis.
The defective current limit circuit in the servo merely allows the servo to burn out... so servo fixes could prevent the servos burning out but they cannot fix the basic cause.
The other day I came across a schematic of the KS271C roll servo from 2005 (i.e. very recent) and that shows yet another bizzare attempt to fix it, by measuring the servo temperature with a thermistor and adjusting the current limit downwards at higher temperatures...
Why does the KC225 go "mad"?
That I don't know. Most likely it is RF interference. Certainly external RF is one cause; I have lost four pitch servos over exactly the same spot in France, between 2003 and 2012. But I also lost servos over wide open water. A missile radar on a warship?
This waveform was captured from a servo just sitting on the ground, connected to the KC225
The smallest Y-axis quantum, about 30mV, corresponds fairly well to 1 LSB of an 8-bit D-A converter (with a ~10V FS) so this stuff is probably the result of some crude computation done with 8-bit integers. Maybe Honeywell implemented the whole control loop using 8-bit integers? In that case they are probably suffering from integer underflow and the resulting loss of precision, which would explain the constant noise on the output which is worth about 10 LSBs.
And if some input noise causes a few more bits to be thrown away, you don't have a lot left since you only started with 7 or 8
I have often wondered, being as charitable to Honeywell as possible, why they don't just fix this autopilot. I think the reason is the same as why they could not fix the KSN770: reportedly, the software was written (by an outside contractor) in a manner which could not be certified and fixing it would be a complete rewrite. And they don't have the inclination to do that, on a product which has zero new sales, and Garmin are eating their lunch on all new aircraft.
The KC225 contains quite a few k lines of code, quite a lot of it probably goes back to older autopilots, so we are looking at code with 20+ year old bits, and god knows what development tools were used. It probably all needs a PC running DOS 6.2 to compile it. PROB99 the original developer is no longer around. And chasing after underflows / loss of precision in integer maths is very hard work. No wonder they don't want to re-open it.
A proper filter between the computer and the servos should solve the problem, shouldn't it? Even though the correct approach would be to fix the AP, a good design ensures that no matter what commands you give to the servos, they won't set the aircraft on fire.
Why don't you just come up with a good filter module? Offer your design to Avionik Straubing, they get it certified and sell it to all owners of the KFC225 (and thereby kill their lucrative servo replacement business but I'm sure they'd do it).
1) Not possible to do a filter which would block this but not affect control loop performance. Flight testing would be necessary, and difficult.
2) I am not sure if the KC225 exits that state once it has entered it. Normally, upon an autopilot failure, the pilot quickly reaches for the red disconnect button and then probably for the master switch.
3) I take it the suggestion of Straubing was a joke Previous correspondence with them rarely elicited more than a 1 line reply.
Actually, I would not put it past Straubing to take something like that on board and make it work! They are a quite progressive shop, last I heard, having been at the forefront with STC's for the Aspen and other things like their own device for the Aspen/S-TEC interface which provides automatic switching to the ALT HOLD mode based on the altitude set in the Aspen.
Why not talk to them? They know darn well which strings to pull for such stuff. And I am sure they would love to hear about your findings!
Straubing did the "research" work for Honeywell, to try to find out what was burning out the servos.
AFAIK from other people (Straubing won't talk) all they discovered was that KI256 AI vibration was being transmitted to the roll servo (yes, another stupid design feature of the KC225 software) and wearing it out fast. This resulted in the Socata "rubber grommet kit" mod referred to earlier in this thread.
They know about the stuff I found.
I fitted the grommets, BTW, and they do reduce the visually obvious vibration of the panel. So, FWIW, that mod is definitely worth doing.
However the mod is badly conceived because the bottom grommets have to be trimmed off with a knife, to clear a piece of trim which lies too close...... if you don't do this, you need to be a superhuman bodger to force them in. Saying that, I got an avionics shop to fit the LH ones when they were doing something else and, guess what... they did get them in untrimmed The RH ones I fitted myself during the subsequent Annual.
I thought about doing a new servo design (brushless motor etc) and getting an STC on it. I contacted Honeywell to see if they might be interested, but they never replied.
However now that it looks very likely the real problem is in the computer, fixing the servos is not going to deliver a solution which somebody could sell with a straight face.
And fixing the servos so they don't burn out when subjected to the spurious output from the KC225 is very easy. I know people who have done it - not in the UK of course.
I have just realised that the continuous motor movement, depicted in this video in my KFC225 writeup, is in fact present even when the autopilot is not engaged.
The motor waggles back/forth in this way all the time the system is powered up...
They should have put in a motor drive inhibit, when the servo clutch is not engaged.
