Honeywell KFC225 Autopilot Failures
This summary was written to document a number of failures of this autopilot, installed in a Socata TB20 aircraft. Most other KFC225 users, in all airframes which used this autopilot, have also reported multiple failures and I have been trying to collate these to see if there is a pattern.
Up to 16 April 2004
The KFC225 has been a thoroughly unreliable product, failing a number of times in both pitch and roll. The roll failures have all been caused by the roll servo. The pitch failures have been caused by faults in the computer unit, or by the pitch servo.
The first failure in 8/2002 drove the ailerons to max deflection. The entire KFC225 system was replaced after that. This type of failure would invert the aircraft in seconds and would be pretty dangerous if it happened in IMC. This failure was the only one which I did not witness personally.
Then there were various failures where the AP randomly selected a +2000fpm or -2000fpm rate of climb. This figure was actually being loaded, during level cruise, into the VS register which appears when the VS button is pressed. No fault indication appeared on the AP computer display. The KFC225 computer was replaced after this but not as far as I know the servos.
Then there were failures where it failed to hold altitude; the appearance being as if there was a static problem, but both altimeters, the transponder and the GPS altitude all agreed. The aircraft remained in trim. Again, no fault condition was displayed. These were never fixed because they could not be reproduced, and they would tend to go away if the AP was disengaged and immediately re-engaged. The KFC225 uses the altitude data from an encoding altimeter for altitude capture, and uses an internal high-resolution barometer for altitude hold. A failure to hold altitude is thus usually a failure of the internal barometer. But the mechanism for the automatic 2000fpm VS selection is a mystery; most likely a firmware bug.
Then there were failures where the AP would disconnect, illuminating the P or R LEDs, these indicating servo failure. A re-engagement of the AP would return normal operation for say 10-20 seconds only before the fault would return. This was captured on video. The servo(s) were replaced at this point.
The recent two failures, both taking place within a few weeks, appear to both be in the roll servo, where the AP fails to control the aircraft in roll. Luckily this one was captured well on a video, and the mpeg file shows the most recent one. The roll servo was replaced after the first instance, and this article is being written after the 2nd instance so no repairs have been done yet.
Roll failure 12-04-2004 (mpeg video, 7MB)
Note that the flight director does work correctly, so it cannot be an autopilot input problem. It looks like a servo failure. However the really disturbing thing is that the KFC225 doesn't appear to realise that it is unable to achieve anything; there are no error indications on its display. Surely it must "know" that the roll servo isn't doing anything! Why doesn't the software detect the fact that the roll servo is being energised for a period of some seconds, or tens of seconds, yet the roll/heading error is steadily increasing?
Due to the beat between the KFC225 display multiplex and the camcorder's frame rate, the KFC225 display doesn't show up well in the video, but it does show the normal annunciations.
Update 16 June 2004
The failure in the above video was caused by a faulty roll servo, whose internal power amplifier burnt out. I saw the circuit board myself. Amazingly, the KFC225 still passes its normal power-up diagnostics, with a totally dud roll servo. It is also apparent that the previous identical failure had the same cause.
I did some investigations on the failed servo, detailed here.
There has been another failure since, in altitude hold. The autopilot has been replaced again and it appears that its internal altitude (barometric sensor) encoder was faulty.
There is a firmware bug in the KFC225. It is possible, through pressing buttons in a certain sequence, to place it into a mode where it shows ALT (without any qualifications e.g. ALT ARM) but in fact does not hold altitude but is probably in a VS mode with a VS value of zero. My next "job" is to capture this on video and report it to Honeywell.
Update 23rd September 2005
This video (10MB mpeg) shows another roll servo failure. This is like one I got in 2003, where the KFC225 passes it's power up tests despite the roll servo being dead. This time, the servo failure is detected during flight but not on the ground test.
Sometime in 2004 I saw an email from Honeywell to one of their dealers confirming this defect in the power-up test is correct design behaviour! This is appalling, especially as the Honeywell KFC225 brochure states
Superb Safety Features
Honeywell’s avionics engineers built impressive safety features into the
KFC 225. For example, the new KS 27XC servos used for pitch, roll and pitch
trim commands are carefully monitored and automatically disconnected when excessive
pitch and roll rates or excessive acceleration forces are sensed. Well-placed
voice messages and audible warnings keep pilots alert to the environment around
them. When the system is powered up, an extensive pre-flight test automatically
inspects the monitors and other components of the system to ensure proper operation.
Complete nonsense as far as checking the servos is concerned!
A separate fault has surfaced in the KFC225 computer unit over the past few weeks: one sets a VS of say -500fpm, when descending to a preset altitude. After some seconds, one notices that the VS reading on the VSI is not quite -500, and it is also obvious that the aircraft pitch is slightly up from what it was earlier. Entering the VS mode again reveals that the KFC225 has modified the -500fpm figure to something like -300fpm. I have asked Honeywell what kind of external problem could cause the AP to self-modify the target VS but no meaningful response was received. Occassionally the AP modifies the preset VS value even within the 3-second window during which the VS figure appears, before it reverts to its normal display.
On this occassion, Honeywell contracted a UK avionics shop to examine the whole system. A number of items (in addition to the faulty roll servo) were supposedly replaced.
It turns out that this is a long standing firmware bug. It modifies the user-preset VS slightly; in most cases by 100fpm, and usually downwards so e.g. +500fpm becomes +400fpm, and -500fpm becomes -400fpm. Normally this is not a problem in real flying, but it means the autopilot cannot be easily used to climb to the aircraft operating ceiling (20,000ft or so) because the climb rate there is only around +100fpm, and if you preset +100fpm, the KFC225 is likely to drop this by 100fpm, yielding 0fpm which is completely useless. So you preset +200fpm, which is OK if this gets modified to +100fpm, but is not OK if it gets left alone because one cannot climb at 20,000ft at +200fpm..... So, a better way to climb to these altitudes is to use the PIT (pitch hold) mode, instead of the VS mode, and adjust the pitch manually.
Update 7th December 2005
I finally got my hands on a KS271C servo maintenance manual; the latest October 2005 version. I think the design is a bit flimsy. Here is my analysis sent to Honeywell in 2005 (acknowledgement was received but no further comment at the time and they did acknowledge another report sent in 2008, again without comment).
Basically, the servo will self destructs as soon as the motor current limit circuit operates for more than a few seconds. This schematic shows a typical KFC225 servo. It is a switch-mode amplifier on which the current limit circuit has been incorrectly implemented. The motor current is sensed across R11 and when the drop across R11 reaches ~ 0.6V Q1/Q2 turn on and pull down the gates of the switching MOSFETs Q10-Q13 so as the voltage drop on R11 is limited to 0.6V. This happens at about 1.8A. The design defect here is that the current limit condition places the MOSFETs into a linear region where they dissipate anything up to 50W (with a 28V supply). This far too much for a small PCB-mounted surface mount device with no heatsinking and the result is a shorted MOSFET which in turn causes R11 to go up in smoke. So, if somehow the current limit condition was maintained for the necessary few seconds, the servo will self destruct.
There may well be a second factor in the above problem in that the current limit circuit implemented by Q1/Q2 does not have any frequency compensation and given the highly inductive nature of the load (the motor) the current limit condition is likely to pull the power amplifer into an oscillatory mode. This could do all sorts of interesting things to various components including the motor. I suspect this is happening because R11 manages to go up in smoke before the servo circuit breaker (5A) pops out, yet placing 28V across R11 would draw 84A which would pop the CB very fast. Many years ago I used to design linear and switching DC servo motor drive circuitry, and got caught by this effect a few times... If this vulnerability is present, the current limit condition would need to be entered only momentarily, and would be self sustaining thereafter.
Update 5th November 2007
The autopilot has failed again, this time with a burning smell in the cockpit, accompanied by the SERVO circuit breaker popping. This time it was a faulty KS270C pitch servo.
Honeywell have washed their hands of their previous continuous warranty, on the grounds that this servo had not previously failed. That was not actually true; the pitch servo failed in 2003 but as this was fixed under the original dealer warranty, I did not have a record of the details. What probably happened is that the servo replacement details did not filter back, via Socata's pipeline, to Honeywell's database.
The servo burning out issue was claimed to have been solved with the following mod status, current at 26/11/2007
065-00178-2200 - KS270C - Pitch Servo - Mod 8 dated Feb 04
065-00179-0200 - KS271C - Roll Servo - Mod 9 dated Aug 04
065-00180-3500 - KS272C - Pitch Trim Servo - Mod 7 dated Aug 04
The servo in question was installed in November 2005 as part of a whole-system overhaul following the 2005 failure and the label shows the expected mod status as #8.
However, on 4/12/2007 the above were found to be incorrect because the data on servo modifications is export controlled (believe it or not) and not everybody within Honeywell has access to export controlled documents. The current status is
065-00178-2200 - KS270C - Pitch Servo - Mod 9 dated Feb 06
065-00179-0200 - KS271C - Roll Servo - Mod 10 dated Feb 06
065-00180-3500 - KS272C - Pitch Trim Servo - Mod 7 dated Aug 04
However, there is no indication that the above described current limit circuit vulnerabilities have been addressed in any way in any of the above mods.
The burnt out pitch servo was opened and immediately the burnt out components were evident, as seen on previous burnt out servos
Component A (a large surface mount power resistor) got hot enough to crack open, unsolder itself and fall off, soldering itself to the next item below (another surface mount component to the left in the picture). Component B also became very hot and partly melted the plastic servo housing.
The complete PCB is coated with a hand applied conformal coating, to keep moisture off it.
There was considerable amount of black soot (from brush wear) on the motor, with some more having been deposited on the strain gauge which measures the gearbox torque. One has to wonder why they don't use brushless motors - they are common everywhere else in control systems.
An interesting observation is the attachment of a large weight on the motor/gearbox assembly. This assembly is free to rotate by a few degrees - this is necessary to enable the torque to be measured using the strain gauge, whose output is then used to drive the pitch trim servo. Evidently Honeywell had problems with stability and instead of solving it properly they fixed a weight to the moving assembly...
Update 25th April 2008
The autopilot has failed again, airborne again but thereafter consistently on the ground, this time with the computer reporting a pitch trim defect. This is around the 10th failure of the system since 2002.
The simplest scenario for reproducing this is on the ground, with the engine not running (no vacuum) when the AP completes its 12 power-up tests successfully. If left in that state, all is fine. In this state, the electric trim (only) should function. However, as soon as the pitch trim (on the yoke) is operated, the trim itself works as it should but the autopilot locks itself into a continuously repeating "check pitch trim" message. This condition cannot be terminated other than by switching off power to the AP using the autopilot master switch.
An alternative scenario is with the engine running, when in principle one should be able to do additional tests because one has the signal from the vacuum driven horizon and the vacuum status signal to the AP is also OK. However, the autopilot fails pretty fast, with the trim running backwards at full speed by itself, and with the "check pitch trim" message, eventually transitioning into a continuous beep which again cannot be terminated other than with the power disconnect.
During an airborne test, the autopilot does the same thing but functions (despite emitting the constant warnings and beeps) in ROL, HDG, ALT modes with altitude capture working. The pitch trim does not work (never moves) and when it is eventually disconnected the pitch trim is well off. The following video shows the three situations:
Amusingly (or not) the KFC225 passes all its power-up tests!
Superficially this looks like a pitch trim fault but the electric pitch trim works (for a while) which rules out a totally burnt out pitch trim servo. The KFC225 system uses a strain gauge subsystem in the pitch servo (schematic) to measure the pitch torque. The motor/gearbox assembly in the pitch servo has several degrees of freedom (in both directions) against a spring and the spring deflection is sensed by the strain gauges. The signal from this subsystem is fed to the KC225 computer which then generates a pitch trim signal to the pitch trim servo.
It was immediately found that the torque output from the pitch servo was duff. Both TRIM SENSE 1/2 outputs should be +3V when quiescent but one was at +3V and the other at +1V. Either the strain gauge(s) failed or one of the two INA-128 instrumentation amplifiers failed.
The servo was still under a 6 month warranty from the U.S. Honeywell dealer where it came from, and was returned for a swap. Honeywell's report confirmed my fault analysis.
Update 20th September 2008 - an amazing discovery!!
The autopilot has failed again, with the servo CB popping and a burning smell in the cockpit as previously. This time, on the ground, the 5A CB pops 2-3 seconds after the autopilot master is switched on. The fault is again in the pitch servo, KS270C, which was installed only 5 months ago
However, I had the GPS track for this flight and this failure led to an astonishing discovery: it happened in exactly the same place over France as the November 2007 failure for which I also happened to have kept the GPS track. The GPS track shows the altitude and one can easily tell when the autopilot failed because the altitude hold was lost and subsequent manual flight was not to the same standard.
The failure happened just north of Le Mans. This map shows the aircraft track in RED, and the location of the failure in YELLOW. The GPS data contains the following information recorded every 25 seconds:
Latitude degrees
Longitude degrees
GPS status
GPS altitude feet
Unknown field
Date DD/MM/YYYY
Time UTC
An example line is:
43.708445 -1.242245 0 10058 39711.37719 20/09/2008 09:03:09
The 2008 failure GPS data (whole flight LESO-EGKA) is here. The altitude plot from a section of it is here and it shows the loss of altitude control around the time=11:08:48 sample.
The 2007 failure GPS data (flight LEZG-EGKA; only data points around the failure are included) is here. The altitude plot from a section of it is here and is shows the loss of altitude control around the time=15:12:21 sample.
In both of the above failures, the GPS position, as closely as one can tell, is in the vicinity of
Lat 48.15129 degrees N
Long 0.28158 degrees E
Obviously this is not a coincidence and the only possible explanation is a ground based radiation source, coupled with an EMC (electromagnetic compatibility) deficiency in the autopilot equipment or installation.
I have a great deal of experience in electronic equipment design, and meeting various EMC requirements. It is very unlikely that the problem is caused by direct radiation pickup into a printed circuit board (PCB) i.e. the PCB acting as the receiving antenna. This is because the PCB tracks are very short. Much more likely, the aircraft wiring is acting as the receiving antenna. There are two possible explanations:
1) The radiation induces a voltage in the servo wiring, which upsets the servo, drives its amplifier into current limit (because the motor cannot move fast enough, so draws a heavy current) and - as described further above - the design defect in the current limit circuit causes the amplifier to self destruct. The radiation would need to be present for a few seconds only. To fix this failure mode, perhaps a filter like this one (260-6492) placed on the servo cable might help, but this would not be an approved modification.
2) The radiation induces a voltage in some part of the autopilot wiring, upsetting its circuitry or firmware and causing it to send a rapidly varying waveform to the servo, which will cause the servo to enter current limit and self destruct as above. To fix this failure mode, one could fit some clip-on ferrite filters on the wiring going to the back of the KC225 computer, but this could be problematic depending how the wiring spreads out, and again this would be an unapproved modification. I think a reasonable candidate for a clip-on ferrite filter would be the connection from the encoding altimeter to the KC225 computer; an upset picked up on that connection (if it propagated through the KC225 and out to the pitch servo) would be a perfect candidate for blowing up the pitch servos.
Option 1) above appears slightly more likely because the input circuitry of the servo contains no RF filtering. The input schematic is here and it can be seen there is no passive (i.e. broadband) filtering. R32 and C16 do form a reasonable passive filter on the CMD REF input. However the COMMAND input filter is R34 and C17 which is an active filter using the U5-B op-amp and any active filter will work only within the bandwidth of the op-amp itself; in this case it will be useless above about 1MHz. This arrangement is particularly useless since CMD REF is driven from a virtual ground - the actual control input is COMMAND. Passive filtering should have been incorporated on both inputs. Any RF signals entering the servo cable will reach the pulse width modulator and mess it up.
Another autopilot failure happened in August 2003 and also occurred in this area, on a largely straight track EGKA-LFBT, at about 5000ft, but I no longer have the routing for that flight. This makes a total of three pitch servo failures around the same area in France. This is particularly significant since my only pitch servo burnout failures happened in this location. A 4th pitch servo failure was an internal one (described earlier above) which appears unrelated to external events.
I am making some enquiries in France to see if there is some radar installation there. Nothing is marked on the aviation chart at the very spot, although one wonders what might be in the nearby LF(D) 574 A/B danger area. Possibly there is an anti-aircraft missile installation there, and the operators are routinely doing radar locks onto passing aircraft, to check how well the system works, or just for fun. The Google Earth location is around here.
Update 4th February 2009
The KFC225 failed again.
This time it was different. I had used the autopilot normally for about 15 mins, then disconnected normally by pressing the red button. I noticed the two P R LEDs and the P/T symbol came on and stayed on - not the continuous beep though which had appeared on some previous failures.
The AP would not re-engage. I turned off the AP master switch, and after a few mins turned it back on. It passed the normal 12 power-up tests, but I noticed that while the AP was holding altitude and heading (the heading bug worked) it was not driving the pitch trim. For example, if holding altitude, as one varies the power, there should be re-trimming but there wasn't. This is a particularly nasty failure mode because you can end up with a badly mis-trimmed aircraft which could - upon AP disconnect - pitch up or down violently. However, manual pitch trim (the yoke switch, working through the KC225) worked OK so this wasn't a simple failure of the pitch trim servo.
Subsequent tests found that, most of the time, the AP failed to do the power-up tests; at the end of test #2 (but before #3 appeared on the display) it illuminated the P R LEDs and the P/T annunciator symbol (within the display, as shown in the pic above) remained ON, and there was a continuous beep. Pressing the red disconnect button ended the beep but did nothing else. Very occassionally however, the power-up sequence did get completed successfully.
As I now have a complete set of spare servos and a couple of spare KC225 autopilot computers, it was quickly established that none of these was causing the problem! One can connect a replacement servo purely electrically - there is no need to mount it in the aircraft - because the AP cannot possibly tell if the servo is actually driving anything. So, it had to be something in the wiring or perhaps the sensors/switches.
It proved impossible to find an avionics shop able to look at it within a reasonable time frame.
I made up the RS232 cable for connecting a laptop to the KFC225 diagnostic port - a 1/4" jack socket normally located somewhere under the instrument panel. This uses a 4-pole "US NATO PLUG" picture which is easy enough to get from e.g. here. The diagnostic procedure is extremely simple: you use a VT100 dumb terminal - Hyperterminal at 9600,8,n,1 and XON/XOFF, on any laptop, as per instructions here. As soon as the autopilot is powered-up, it transmits a screen with a list of menu options on the laptop. I have the full installation and maintenance manuals for everything of course but cannot post them on an open website because some of them are very hard to get and somebody would eventually object...The diagnostic menu is very obvious and self-explanatory and it is easy to avoid messing around with important system parameters. However I would not recommend anybody doing this unless they really know what they are doing.
As the laptop has no physical RS232 ports, a USB-232 converter was used.
Using the diagnostic page wher the autopilot inputs can be examined, it took just minutes to check the various switches (trim up/down, CWS, etc) were fine.
The diagnostic error log showed Error 75 - "trim voltage too low". Input from one avionics old-timer suggested this is a well known one: a duff red-button disconnect switch. But this switch showed up fine in the diagnostics....
However it is seen in the schematic that the AP disconnect switch has two sets of contacts. One is used to tell the KC225 software that it is pressed. The other is used to interrupt the power to the servos - to "guarantee" that the clutches disconnect while the button is being held down. It is this second contact set which was not making a good contact. This switch is grossly under-rated for the job, because the load comprises of (among other stuff) three beefy servo clutch solenoids which are both inductive and capacitive loads so there will be significant arcing on the switch contacts. This switch failed after - very approximately - 1000 disconnects which is totally unacceptable.
By repeatedly waggling the switch, while watching the total aircraft current draw displayed on the ground power unit I was able make it work eventually - exactly as per the in-flight situation. With all three servo clutches engaged (by writing a "1" to them in the diagnostics) I could see the current changing by a couple of amps, and of course one could also hear the servo clutches operating.
These switches are horrendously overpriced but at least this time it was a simple enough cause. It would be nice to fit a better quality switch but the paperwork would be tricky...
Update 23rd November 2009
The KFC225 system has been working fine, but I decided to investigate the possibility of some kind of precautionary maintenance on the servo motor.
From one of the pitch servos that failed over that mysterious place in France, I extracted an apparently working motor+gearbox.
The easiest "servo motor maintenance" a change of the whole motor+gearbox module (like the one shown in the pics below). Unfortunately, this motor cannot be obtained from the manufacturer (GLOBE) because it is a custom motor/gearbox (custom motor windings, custom shafts at both ends, possibly even a custom gearbox) supplied only to Honeywell, and Globe won't discuss any Honeywell part numbers other than to say the motor has "custom windings". However, from the Globe website it is obvious that their IM-13 (data sheet copy) matches the Honeywell motor+gearbox (Honeywell P/N 415A... e.g. in the pitch servo it is 415A508-1) as far as the overall sizes of the motor and gearbox are concerned, and brush assembly looks identical.
So, with some hassle (Globe wanted an End User Statement; is this an F16??) I bought what looked like the closest IM-13 motor+gearbox: P/N 415A179-3. This one has the extra strong gearbox. It can always be used for some CNC project... At £160 from the UK distributor AVNET-EMG it wasn't cheap. The two motors are below; the Honeywell one has a thicker and double ended shaft (the back end drives a tachometer - another stupid idea which has another pair of brushes which will wear out, and it is driven via two gears which do wear out quite rapidly). The motors themselves may well be identical and same goes for the gearboxes, since the output RPM is almost the same...
The motor brushes are obviously identical. However, two things immediately became apparent when the old Honeywell motor was dismantled: (1) a replacement of the brush assembly is really tricky because it basically all falls apart; (2) looking at the amounts of wear on the brushes and on the commutator, it looks like the life of these two items will be quite similar! The Honeywell motor was several years old and the commutator was about 1/4 worn through, and the brushes were still somewhere near their full length. So this exercise was pointless; one has to replace the whole motor+gearbox. The Honeywell part is probably available to a few authorised avionics shops, for field servicing.
However, after I put the brushes and the rest of the old motor back together, I tested the motor on a 12V battery. As far as I could see it ran fine, but it drew 0.6A (at just 12V - it can be fed with the full 28V) and got very hot. Yet there was no apparent friction in this motor+gearbox assembly. I could not see how I could have re-assembled the brushes incorrectly. The brand new Globe motor runs at almost exactly the same RPM as the old one (that was a lucky choice from the Globe data sheet, only partly aided by RPM data from the servo maintenance manuals) but runs cold and draws 0.06A. The old motor makes considerably more noise. A resistance measurement across the terminals of the two motors shows a wide variation on the old motor (5 to 50 ohms) against a much less varying value (27-30 ohms) on the new motor.
So... it is possible that that servo (a pitch servo) failed because the motor burnt out first. This makes me wonder if we are looking at a slightly different failure mode (from that speculated earlier) in these servos: as a result of noise/RFI entering the servo input, the motor is fed with a very fast waveform which it can't follow mechanically but which doesn't push the current high enough to active the dodgy current limit circuit, the rotor windings (which have no real cooling) get too hot, the enamelled wire insulation fails somewhere, the motor draws too much current, the servo is pushed into current limiting and this blows it up.
KFC225 Yoke Switch Cluster
A picture of the internals of the switch cluster is here. A close-up of the disconnect switch is here. A close-up of the CWS switch (which is identical to the PTT switch) is here.
It took a little while to establish the correct part numbers for the various parts...
The disconnect switch is Honeywell P/N 031-00428-0000 which lists around $120. The actual switch is about $10 and is made in Japan by NKK; P/N including the screw-in red cap is most likely MB2061SS1W01-CR and the data sheet is here. It is important to specify the silver contacts as the gold ones are not rated at anywhere near enough current; this switch is not really up to the job as it is.... The switch is available from various places including Mouser whose data sheet page is here. Mouser part numbers MB2061SS1W03-BC-RO and MB2061SS1W03-RO are both suitable and are more likely to be stocked. The red screw-in cap is also available both separately and included with one of these switches - as shown in these data sheets.
The NKK switch has contacts rated at 3A 30V DC. It is difficult to find a switch with more robustly rated contacts in this mechanical style. Honeywell make the 8N2021-014-Z which in some documentation is specified at 6A 30V DC which sounds better than the NKK one, but I have taken both types apart and the contacts appear identical... This switch fits perfectly into the available space but has a different actuator and one needs to sort out a different cap; a slightly flimsy red plastic push-on cap is available (as the data sheet shows) or one could machine something up from a red material. There is a wide range of much more robust military spec switches which Honeywell/Socata should have used instead e.g. this one.
The failed NKK switch was dismantled to reveal a lot of black soot on the contacts which carry the servo power, so there must be a lot of arcing going on.
The CWS switch (which is identical to the PTT switch) is a Honeywell P/N 031-00514-0000 which lists around $120. It is a high quality mil-spec switch. The switch is made by Otto and is a variant of this one, the P/N is most likely P7-116122 and it costs around $20. An almost identical and widely used switch is another Otto model P7-126121 sold e.g. by Sigtronics but this one has a red plastic actuator.
The complete switch cluster is Honeywell P/N 300-09744-06501 and this includes all the switches and the mounting plate. This lists around $700. If the trim switch needs repair, this is perhaps the only legal means of doing that. The trim switch uses off the shelf microswitches though...
The way forward?
There is no known overall solution, although obviously the discovery of the pitch servo failures being caused by a radiation event puts a new slant on things, and probably leads to an easy fix of this particular issue.
It would be great if the servos could be fixed, to remove the current limit defect vulnerability, but Honeywell have advised me that the servo issue will not be addressed in the future.
Looking at marginal or spurious "fixes", there is an alternative roll servo that can be used on the TB20: the 065-00179-0500 - KS271C. This is claimed to burn out less often, but has been known to suffer from occassional roll axis oscillation. This is not a straight replacement for the -0200 however; the KC225 autopilot computer requires a different configuration uploaded into it. This process uses what Honeywell call a "certification file"; these files are uploaded into the KC225 during a config mode which is done using a laptop acting as a dumb terminal. I have all the installation manuals but do not have these config files.
According to one of their dealers, Honeywell have stopped manufacture of the KFC225 system sometime early 2008 (though they still make new servos; 2009) so anything available will be a secondhand refurbished item. I have therefore purchased a complete set of spares on the refurbished market.
The KFC225 failures tend to be confined (if that word is appropriate) to five areas, with the most common at the top:
1. Roll servo
2. Pitch servo
3. Pitch trim servo
4. Barometric sensor in the KC225
5. Accelerometer in the KC225
The servos can be kept going by purchasing refurbished ones at $1500 each from (for example) South Eastern Aerospace. In an extreme situation (e.g. no longer available) and therefore ignoring the fact that this is not an approved procedure, one can repair the burnt out PCB easily enough.
The only legal option for servicing the KC225 itself is a refurbished unit via Honeywell, but this can be an expensive solution, ranging from $1000 to $7000 depending on when/where. And if/when this becomes unavailable, the two relatively frequently failing items (the barometer or the accelerometer - these components are no longer manufactured but can be found via specialist electronic component sources) can be replaced without apparently any calibration being required.
The FAA offers a curious concession which allows an aircraft owner to make his own parts. I have no idea whether this could ever be applied to autopilots... . In this case, the obvious thing would be to re-make the roll servo using a brushless servo motor with integrated electronics; such motors do exist but most are too big to fit inside the KS270 servo plastic casing by the time a suitable gearbox is included. Rebuilding the pitch and pitch trim servos is slightly more tricky due to the extra functions. All three servos also need to return a VALID output (back to the KC225 computer) which is generated by a bizzare circuit which doesn't actually do anything meaningful.
It's all a bit strange since the KC225 computer appears to be reasonably competently designed in hardware terms - I have the schematics etc. It is on the servos that the ball has been totally dropped.
The more owners I speak to, the more it is obvious that every aircraft type in which the KFC225 has been installed has seen a very high failure rate - from the smallest single engine models to the Cessna Caravan. It is entirely possible that 75% of all owners have had a serious failure. It appears that KFC225 servo repair is a substantial business around the world. This company sells a fair number of their KS27xC servo test boxes at $3000 each. Honeywell started shipping the KFC225 sometime in the late 1990s but, presumably due to the very high failure rate, by around 2002 few if any aircraft manufacturers were still installing it.
I am an electronics engineer with nearly 40 years' experience and to me it is obvious from the pattern of failures, both on my system and on those owned by the large number of other pilots I have been in contact with, that the KFC225 installation is working only marginally, and every once in a while something happens which tips it over the edge. That "something" is most likely powerful ground based radio emissions. The two vulnerabilities discovered in the KFC225 servos would enable them to self destruct. One would expect the failure pattern to be highly random, in both time and who it happens to. One would also expect some users to not have any problems and this is indeed true, though they seem to be those who do not fly very much, or very far. One would also expect the issue to be affected by the airframe, which it is - it would be affected by very small details like whether a certain wire is shielded, whether belly panels are plastic or metal and if they are metal whether they are wired (bonded) to the airframe, etc. However, if this conclusion is correct then a simple ferrite filter clipped onto the servo cables could well solve the problem effectively enough.
Page last edited 25th November 2009
Any feedback, reports of dead links, corrections or suggestions much appreciated:
Contact details
