Honeywell KFC-225 Autopilot Failures
This summary was written to document a number of failures of this autopilot, installed in a Socata TB20 aircraft. Most other KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 display multiplex and the camcorder's frame rate, the KFC-225 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 KFC-225 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 KFC-225. 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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
(the above mod versions were confirmed current 3/2010 so evidently Honeywell are not doing any work on this issue)
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 KFC-225 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 KFC-225 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 the 4 strain gauges (which are arranged as a bridge, for temperature compensation) is amplified by two INA128 instrumentation amplifiers and the resulting two signals (voltages which are normally +3V and vary from +2V to +4V under operation) are fed to the KC-225 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 KC-225 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 KC-225 computer; an upset picked up on that connection (if it propagated through the KC-225 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 KFC-225 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 KC-225) 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 KC-225 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 KFC-225 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 KC-225 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 November 2009
The KFC-225 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.
KFC-225 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...
Update April 2010
The autopilot has failed again. This time it was the KS270C pitch servo, yet again, but from the failure mode it was not a burn-out; it was like the April 2008 failure above i.e. the torque sensing output. It was nearly new but was out of warranty when it failed and its exchange value was derisory, so I bought a new (overhauled) one from the USA, as usual, and opened up the failed one. It took only minutes with a +28V supply to establish that the torque output (which is used to drive, via the KC-225 computer, the pitch trim servo) was faulty. The two INA128 chips were fine; it was the strain gauge assembly which had something loose in it.
The strain gauge torque measuring feature has been notoriously unreliable in this servo model. Honeywell issued a mod (Mod 6, issued 3/2003, and implemented on all S/Ns above 5399) to "improve" it but a lot of Honeywell's mods are issued without an understanding of the fault, and sure enough this servo had this mod implemented... It is very hard to establish what the actual failure is; nothing is visible and I suspect that the design itself is defective in that the strain (the bending of the steel bar to which the gauges are glued) is too great for the gauges being used, and they simply crack...
There is no legal way to return this servo to service but it is obvious that one could take a strain gauge assembly out of a burnt-out servo (of which there must be plenty around) and move it over. According to the MM, the only calibration involves adjusting two trimpots to make both outputs read +3V, and adjusting two grub screws (which form adjustable stops on the motor/gearbox axial rotation freedom, which is sensed by the strain gauge assembly) to set the output limits to +2V and +4V. Nobody I know in the UK will touch a KFC-225 servo but there must be plenty of "field repairs" of this type around the world... The strain gauge assembly is P/N 137-00038-0000, on all the KS270C servos. Also, any company which manufactures strain gauges would be capable of gluing four gauges (which appear to be standard 350 ohm types) to the existing steel bar.
The way forward?
Nowadays, I fly all long trips with a box of the three spare servos in the back of the aircraft, and have not had any failures all the time I have been doing that ;)
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. At trade shows, I keep hearing rumours from Honeywell reps that this will change, but I have not seen any evidence of it. One would think Honeywell would have an incentive to fix this simple problem, because e.g. Cessna (who had massive KFC-225 issues on the Caravan fleet) have evidently designed-out Honeywell avionics as far as they could out of their aircraft, and the jet avionics market must be significant to Honeywell even if the piston market isn't.
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 KC-225 autopilot computer requires a different configuration uploaded into it. This process uses what Honeywell call a "certification file"; these files are uploaded into the KC-225 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. I think any difference in the -0500 burn-out rate is illusory and just an artefact of the smaller numbers installed.
According to one of their dealers, Honeywell have stopped manufacture of the KFC-225 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. However, they evidently (2010) still make the servos, which is not suprising since I recently received one with a serial number of around 10,000 and looking at past numbers this suggests they have made aound 6000 of them since the last OEM customer dropped the KFC-225, around 2002. Clearly, at $2000 each, making servos to replace the burnt out ones is a big moneyspinner for Honeywell. Only the burnt-out servos are declared beyond economic repair; the other faults result in an exchange overhaul.
The KFC-225 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 KC-225
5. Accelerometer in the KC-225
The servos can be kept going by purchasing refurbished ones at $1500-$1800 each from the USA. 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 KC-225 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 KC-225 computer) which is generated by a bizzare circuit which doesn't actually do anything meaningful.
It's all a bit strange since the KC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 KFC-225 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 address the problem effectively enough to make a big difference to the average servo life.
KFC-225 Calibration
On a new system, a number of operations need to be performed which are beyond the scope of a little web article like this. One needs to use a Honeywell dealer with the KFC-225 system approval. However, for subsequent adjustments, things are a lot easier, largely because the KFC-225 is a digital (software controlled) autopilot, is self contained, and does not need complicated tweaking.
As mentioned in the Feb 2009 update above, most settings are accessed via an RS232 link with a laptop, but an existing installation will rarely need these to be tweaked because most of them are stored in a separate configuration module so if the KC-225 computer is changed, the configuration is loaded into it automatically. This is especially relevant for loading a so-called Configuration Diskette which specifies the control loop parameters; this is available only to KFC-225 dealers and despite some efforts I have been unable to get my hands on one... but luckily the data resides in the configuration module. Only if this module got trashed would one need to find a suitably equipped Honeywell dealer.
A different long term issue with the KFC-225 system is that most installations are using the KI-256 vacuum horizon, whose reliability is highly variable depending on its history, who last overhauled it, etc, and is probably comparable to the reliability of the vacuum pump! The KI-256 costs between $11k and $24k to buy new although an overhauled exchange unit can be sourced for about $3k (2010 prices from the USA). My last one came from Castleberry Instruments in Texas; I can highly recommend them for both customer service and the accuracy of the unit they supplied. If the KI-256 is changed, the KC-225 computer needs to be recalibrated in pitch and roll, which involves accessing two trimpots in the side of it. This is a stupid design feature on an otherwise fully digital and RS232-configurable product... To gain access to these trimpots while the KC-225 computer is in situ and running (on the ground) one needs a vacuum source (to erect the KI-256; normally this is a vacuum pump driven from a standard electric motor - example) and also a special Honeywell bus extender which costs $1400 or so. Mains power driven vacuum pumps are common on the avionics scene but very very few Honeywell dealers have the bus extender and those that don't have one don't want to do KFC-225 work... I have this extender; it was bought between two KFC-225 owners who shared out the cost.
When replacing a KI-256, always source a Mod 11 unit because they are much more interchangeable (in terms of whether the KC-225 recalibration is actually required) than previous KI-256 versions. With a bit of luck, you may need only to tweak the roll null which is done in flight with a small pozi screwdriver using the KC-225 front panel accessible pot.
Some notes on how to get rid of the KI-256 completely can be found here. None of them are easy or cheap though.
Page last edited 12th August 2010
Any feedback, reports of dead links, corrections or suggestions much appreciated:
Contact details
