I think it is a software “feature”, because
Sounds like nobody else with a KFC225 has ever used the VS mode enough to notice – or they like to sell their plane without too much hassle 
My Stec 55x is holding vs fine.
As for the xpdr showing silly alts this could well point to the encoder. And this could also be a reason for the oscillation if the 225 takes alt info from there.
I don’t know if the KAP140 is more recent or not, but it has a similar — but slightly different – issue.
When you load a particular VS figure, that figure remains set, but the A/P will frequently climb or descent the aircraft at a slightly (50-100 fpm) lower rate. This is most noticeable in the descent.
Curiously, in the descent the KFC225 tends to hold the set VS a lot better
But there is something fundamentally “going on” in there. There is simply no reason for this to be a design feature, and even less reason for the preset figure to change by itself. I mean, who would design a microwave on which you set the power to 80% and it changes it to 70%. It would drive everybody mad.
There is nobody at HBK (Honeywell / Bendix King) today who knows anything about this stuff. I doubt they even have sources which they can look at.
I have a KFC225 in my TB20 (sn 2204) and I do not see this behavior. If I set a VS (almost never in the climb), push the CWS or the UP or DOWN button (briefly) I see the set value.
OK; thanks for that data point. Unfortunately it seems to happen mostly in the climb
I have wondered if there was a firmware update but I don’t think so. Everybody “technical” at HBK left c. 2003, and my KC225 boxes have all had overhauls there after then. I do know that c. 2003 HBK quietly fixed a subtle and potentially dangerous bug whereby ALT ARM was sometimes ignored (or something similar; I saw it a few times).
Almost 20 years after the de facto demise of Honeywell / Bendix King, I have bumped into someone who used to work there, on these products.
I had originally speculated that the KFC225 used low-resolution integer maths for its control algorithms and this was responsible for the rough waveform going to the servos. It turns out that the 225 algorithms are purely in float arithmetic (unlike 150 which did use integer). The FD commands are output @8Hz, the AP servo command is @32Hz. This is not bad going since they are using a relatively slow CPU without hardware floating point. It is a bit like reading one of the Apollo books and no doubt some of the same people worked on these projects, although the Apollo autopilot code was all done in integer because their CPU really was slow.
The key weakness in the KFC225 is the way in which the KI256 horizon’s pitch and roll data is decoded. This was done badly and produces a poorly filtered waveform. When this is fed to the control loop it results in a lot of muck going to the servos, accounting for their short life. Especially the pitch servo. This probably cannot be fixed in software.
It was all an interesting discovery, although it didn’t illuminate the servo burnouts which apart from being airframe type dependent are also provably correlated to where one is flying… So I think there is still a bug in there whereby the 225 gets into a weird state which it eventually recovers from but not before it has destroyed one of the servos, usually the pitch one. Honeywell did bring out various servo mods trying to address this but without any understanding of electronics.
No input on the VS self modification issue though.
I now have proof it happens:
