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 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 sensitive 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.
The way forward?
There is no known 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.
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 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. If one needed to change the motor brushes (an eventual certainty) the easiest way is to change the whole motor. Unfortunately, this motor cannot be obtained from the manufacturer (GLOBE) because it is a specially wound motor supplied only to Honeywell. However, it is virtually certain that the brushes are standard Globe items.
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.
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.
Page last edited 8th October 2008
Any feedback, reports of dead links, corrections or suggestions much appreciated:
Contact details
