P
Peter
- Jan 1, 1970
- 0
In the two years from new I have had perhaps a dozen failures. Some of
these are in the computer unit (e.g. sudden selection of +2000fpm or
-2000fpm VS, with interesting results especially if the latter...)
whereas others have been in the roll servos (several have failed, the
last one having burned out a component on the circuit board).
The most worrying feature is the software design which doesn't seem to
act on or even report total control failures. The following is a video
I did showing that a total failure in roll control (this is the
above-mentioned burned out roll servo)
www.peter2000.co.uk/aviation/kfc225-1.html
doesn't get noticed by the AP at all; it just sits there quite
happily, even though obviously the control loop error must be
constantly increasing...
I have just had a different failure, this time in pitch, but the
manifestation is the same. The AP was in a simple altitude-hold
heading-bug mode, and suddenly the plane dived from 2400ft to 2000ft,
at which point the red button was used to disconnect it. Subsequently,
it would not hold altitude, very slowly climbing. It would also not
intercept a preset altitude. At no time did the computer show any
fault condition. I have no video of this one but two engineers as
witnesses.
The inability to hold altitude happened once before, several months
ago, briefly, and didn't come back.
Both altimeters are fine and agree with the GPS altitude. As far as I
can tell, the transponder's flight level readout (which comes from the
same encoding altimeter as the AP is driven from) has always been fine
too. Is it possible for the gilham code to the AP to be corrupted,
without the AP noticing this? Gilham Code is same as Gray Code; only 1
bit changing at a time, so corruption should be obvious.
Is it possible for the baro subscale pot output (which is analog
AFAIK) to get disconnected, without the AP noticing this? There is
certainly the potential for at least 1000ft of deviation if the
subscale signal was faulty.
Ground tests have, I gather, showed nothing wrong. This doesn't mean
very much because I know the KFC225 passes the standard preflight self
tests even with the roll servo burned out! The problem here is that
while an avionics engineer can attach a laptop to the unit and check
that it is getting the correct inputs (the gilham code from the
encoding altimeter, the voltage from the altimeter's baro subscale
pot, etc, and he can see if there is anything in the error log), this
cannot be at all easily done in flight. There is no way to isolate
faults unless they are obvious on the ground.
The roll servo is a brand new unit, not a reworked one, which has just
been fitted, so if that is faulty, it lasted just half an hour in the
air... The reason I think it might be faulty is that I have
established the KFC225 doesn't notice a dud roll servo, so it probably
doesn't notice a dud pitch servo. It should notice a dud pitch TRIM
servo, in that there is a timeout on how long the trim is driven for
before it automatically disconnects; that's an obvious
certification/safety requirement.
The pitch trim portion is driven from a strain gauge fitted to the
pitch servo, and the pitch trim servo drives the pitch trim so as to
maintain the strain within some limits. (It isn't all that precise
because the aircraft is usually slightly out of trim when the AP is
disconnected). Now... if the pitch servo was dud, or doing its own
thing, or was commanded to do something spurious, would there be a
trim problem? I don't think so, and in the last failure there wasn't.
This system has a history of faults which left no trace on the ground
(except the burned-out servo(s), nothing was ever found; if Honeywell
found a fault subsequently they certainly didn't say so). The computer
unit has been changed twice.
Can anyone suggest any way forward, anything that could be done to
narrow it down?
Peter.
these are in the computer unit (e.g. sudden selection of +2000fpm or
-2000fpm VS, with interesting results especially if the latter...)
whereas others have been in the roll servos (several have failed, the
last one having burned out a component on the circuit board).
The most worrying feature is the software design which doesn't seem to
act on or even report total control failures. The following is a video
I did showing that a total failure in roll control (this is the
above-mentioned burned out roll servo)
www.peter2000.co.uk/aviation/kfc225-1.html
doesn't get noticed by the AP at all; it just sits there quite
happily, even though obviously the control loop error must be
constantly increasing...
I have just had a different failure, this time in pitch, but the
manifestation is the same. The AP was in a simple altitude-hold
heading-bug mode, and suddenly the plane dived from 2400ft to 2000ft,
at which point the red button was used to disconnect it. Subsequently,
it would not hold altitude, very slowly climbing. It would also not
intercept a preset altitude. At no time did the computer show any
fault condition. I have no video of this one but two engineers as
witnesses.
The inability to hold altitude happened once before, several months
ago, briefly, and didn't come back.
Both altimeters are fine and agree with the GPS altitude. As far as I
can tell, the transponder's flight level readout (which comes from the
same encoding altimeter as the AP is driven from) has always been fine
too. Is it possible for the gilham code to the AP to be corrupted,
without the AP noticing this? Gilham Code is same as Gray Code; only 1
bit changing at a time, so corruption should be obvious.
Is it possible for the baro subscale pot output (which is analog
AFAIK) to get disconnected, without the AP noticing this? There is
certainly the potential for at least 1000ft of deviation if the
subscale signal was faulty.
Ground tests have, I gather, showed nothing wrong. This doesn't mean
very much because I know the KFC225 passes the standard preflight self
tests even with the roll servo burned out! The problem here is that
while an avionics engineer can attach a laptop to the unit and check
that it is getting the correct inputs (the gilham code from the
encoding altimeter, the voltage from the altimeter's baro subscale
pot, etc, and he can see if there is anything in the error log), this
cannot be at all easily done in flight. There is no way to isolate
faults unless they are obvious on the ground.
The roll servo is a brand new unit, not a reworked one, which has just
been fitted, so if that is faulty, it lasted just half an hour in the
air... The reason I think it might be faulty is that I have
established the KFC225 doesn't notice a dud roll servo, so it probably
doesn't notice a dud pitch servo. It should notice a dud pitch TRIM
servo, in that there is a timeout on how long the trim is driven for
before it automatically disconnects; that's an obvious
certification/safety requirement.
The pitch trim portion is driven from a strain gauge fitted to the
pitch servo, and the pitch trim servo drives the pitch trim so as to
maintain the strain within some limits. (It isn't all that precise
because the aircraft is usually slightly out of trim when the AP is
disconnected). Now... if the pitch servo was dud, or doing its own
thing, or was commanded to do something spurious, would there be a
trim problem? I don't think so, and in the last failure there wasn't.
This system has a history of faults which left no trace on the ground
(except the burned-out servo(s), nothing was ever found; if Honeywell
found a fault subsequently they certainly didn't say so). The computer
unit has been changed twice.
Can anyone suggest any way forward, anything that could be done to
narrow it down?
Peter.
