That’s most likely (as in “bloody sure”) the trim servo. No need to look elsewhere. Just went through it all, same issue. Mine is a KFC150 but the servos are similar.
You need to replace the electric motor that’s driving the servo. Most likely it is old, with worn out brushes, and needs too much amp to get started.
You just need to go to a certified avionics guy who knows what he’s talking about. He takes the servo out and connects it on the ground. King certified repair shops have the technology to help you.
I could give you one in Germany – Avionik Straubing – but don’t know any in the UK.
GAMA, Fairoaks EGTF
@Jesse – sure; I know how it should work. The KEA130A is used
In level flight, altitude captured (i.e. my video) the KC225 uses the internal barometer which is a pressure sensor interfaced to a 16-bit A-D converter. This is not accurate at all (hence the KEA130A is used for the capture) but is fairly stable. The KEA130A is still monitored in a very slow way, to take out the barometer drift, and to make the whole thing work when you change the altimeter subscale.
There is also a pitch accelerometer inside the KC225 which is used to provide a high speed input into the pitch / altitude control loop. If one didn’t have this input, holding altitude in turbulence would be very hard. The KFC225 does it with great accuracy – within 10-20ft most of the time.
The KEA130A feeds a pressure altitude, in Gray code, with I believe a 10ft or 20ft resolution, to the KC225. The subscale knob has a multiturn pot on the back of it which is used to generate an analog voltage (probably something like 950mb = -10V and 1050mb = +10V) and this goes to the KC225 also. That way, the KC225 can capture and hold the true altitude (i.e. the actual altimeter reading), despite the KEA130A encoder feeding it only the pressure altitude (QNH=1013).
So the Q is what exactly is causing this highly intermittent change in the altitude which is being maintained.
It definitely isn’t the pitch trim servo, because that is inside the altitude hold feedback loop. If the pitch trim servo failed to move for 9 seconds, you get a TRIM IN MOTION warning. After 16 seconds of the same, the AP will disconnect.
I reckon the value from the altimeter is getting corrupted. I say it is the altimeter and not the internal baro sensor because the altimeter value is used as a very slow background process – exactly what we are seeing. If the baro value was getting corrupted, we would see a more rapid change.
The KFC225 has a build in ALT Pre-selector.
When in ALThold mode the kc225 uses only the internal transducer to monitor the static presure and the Baro input for the baro correction.
The KEA130A only outputs the graycode in 100ft resolution (only used for alt pre-select/capturing)
when the problem occurs after a period of stable level flight I would also think about the pitch servo first (and second to the expensive KI256)
If it happends shortly after capturing the selected altitude the trim servo could also be a suspect.
What I found concerning is the unstable Fly-director (dancing up and down).
This could be indicating towards an unstable Gyro-output ?? another possible cause.
succes with solving the problem.
EuroFlyer wrote:
That’s most likely (as in “bloody sure”) the trim servo. No need to look elsewhere. Just went through it all, same issue.
There are several other issues which can cause similair symptomes. Far too often people and maintance organisation start replacing or “repairing” parts without proper troubleshooting. You CAN be lucky, often it is more expensive.
- Troubleshooting is the first that needs to be done.
Peter wrote:
In level flight, altitude captured (i.e. my video) the KC225 uses the internal barometer which is a pressure sensor interfaced to a 16-bit A-D converter. This is not accurate at all (hence the KEA130A is used for the capture) but is fairly stable.
This is untrue, the interal pressure sensor has a resolution which is more then 100 times as high as the KEA130A output. The KEA130A is needed as input so it can work with different barometric settings.
Peter wrote:
There is also a pitch accelerometer inside the KC225 which is used to provide a high speed input into the pitch / altitude control loop. If one didn’t have this input, holding altitude in turbulence would be very hard. The KFC225 does it with great accuracy – within 10-20ft most of the time.
Agree, and with the internal pressure sensor. The resolution of this internal sensor is less then 1 Ft.
Peter wrote:
The KEA130A feeds a pressure altitude, in Gray code, with I believe a 10ft or 20ft resolution,
This is incorrect. It uses 100 Ft Gillham altitude output. So from 4950…5050 Ft (at 1013,25 mB) it will indicate 5000 Ft to the autopilot (and transponder and GPS)
Peter wrote:
The subscale knob has a multiturn pot on the back of it which is used to generate an analog voltage
Correct
Peter wrote:
despite the KEA130A encoder feeding it only the pressure altitude (QNH=1013).
Correct
Peter wrote:
I reckon the value from the altimeter is getting corrupted. I say it is the altimeter and not the internal baro sensor because the altimeter value is used as a very slow background process – exactly what we are seeing. If the baro value was getting corrupted, we would see a more rapid change.
It could be. If it is the encoder altimeter itself it should also show up on your GPS and transponder.
Peter wrote:
I reckon the value from the altimeter is getting corrupted. I say it is the altimeter and not the internal baro sensor because the altimeter value is used as a very slow background process – exactly what we are seeing. If the baro value was getting corrupted, we would see a more rapid change.
This is unlikely. As the KEA130A has a resolution of 100 Ft.
When you select 5000 Ft the aircraft will climb to 4950 Ft, at this point the KEA130 will switch the output from 4900 Ft to 5000 Ft. The last 50 Ft will be done on the interal altimeter. This has a 16 bit ADC as you mentioned, so 2^16=65536 steps, so about 0,5 Ft / step output, instead of 100 Ft / Step from the KEA-130
This is untrue, the interal pressure sensor has a resolution which is more then 100 times as high as the KEA130A output. The KEA130A is needed as input so it can work with different barometric settings.
Resolution is not the same as stability 
As the KEA130A has a resolution of 100 Ft.
That puts a different slant on it… Maybe this whole issue is caused simply by the altimeter’s encoder – when it displays a whole number FL e.g. FL080 – being right on the margin between FL099 and FL100.
I do have a spare, freshly overhauled, KEA130A…
There was a lot of turbulence on that flight. I stabilised the video in Sony Vegas.
Peter wrote:
Resolution is not the same as stability
Agreed, but the stability is fine. On autopilots with altitude hold only (no altitude preset) the system always works like that, and that works fine.
Now when something is wrong with the pressure sensor, making the output unstable, it could result into this kind of issues. It could also be due to partially blocked or clamped hose to the autopilot.
Peter wrote:
That puts a different slant on it… Maybe this whole issue is caused simply by the altimeter’s encoder
If it is due the KEA you would be able to see this on your GPS and transponder as well. Then it should be jumping around on those items as well. Does it behave like that at this setting only, or also others?
There are lots of possible causes for this kind of complaints, time for more troubleshooting.
The only times I observed an altitude oscillation with the KAP150 was downwind of a mountain range….ie due to mountain waves….the altimeter behaved in a remarkably similar way to Peter’s video…
Does it behave like that at this setting only, or also others?
Yes; the altitude drop is real.
The RHS altimeter showed it. Justine was watching it while I was filming it. Let me see if I can dig out the GPS track from the Oziexplorer log…
Here is the entire “FL070” portion
It is from a non-EGNOS GPS, FWIW. But it was using a dedicated rooftop antenna. The X axis is from 15:48 UTC to 16:03 UTC.
One needs to remember that the QNH itself varied by maybe 2mb over that flight. In fact probably more, as the 1200 MSLP shows
Flying from EGJA to EGKA one is flying from high to low pressure so one would be descending in true altitude, which is not really showing in the above!
The above 1200Z MSLP shows a 4mb (120ft) change (1016 to 1012) but the departure was 1530Z. I no longer have yesterday’s 1800Z chart.
The absolutely striking thing is the periodicity!!! Every 2.5 minutes. I can think of no aircraft system which could produce interference with such a long period.
Ok, so humour me….was it possible that you were in mountain wave conditions?
