Autopilot malfunctioning

[jeffhughes88]

Hello, I upgraded my panel and autopilot several months ago and over the past couple of months have been going on training flights to learn how to navigate and how to do fully coupled IFR approaches. The autopilot worked well initially but then a few weeks ago it began to malfunction on one of my flights. I set the autopilot up to follow GPS LNAV and "ALT" for vertical mode with target altitude of 2000 feet. Then after climbing out to ~1000 feet I engaged the autopilot and it wanted to dive pretty aggressively. I disengaged and recovered and continued on my training flight without using the autopilot. 20 minutes later after setting a GPS course for KPWT, I again engaged the autopilot and it behaved in a similar manner. I manually held altitude and attempted to trim up to see if that would offset the autopilot. This did prevent it from diving but the altitude wandered up and down and I could feel servo slippage. It did seem to follow LNAV but not vertical. Oddly enough, the "Level" button did seem to behave properly.

I stopped using the autopilot that day but tried it again on subsequent flights and it continued to have the same problem. Then I decided to reload firmware on the SV-Net devices using the "update" feature under admin settings. I re-calibrated after this and then went for a flight. The autopilot worked fine again for a few flights, then started misbehaving again. I went back into the Admin settings to see if I could run a diagnostic test but that doesn't seem to be an option. I *did* notice that when the SV-NET devices are listed that one of my servos shows channel "B" in red. all other devices have both A and B channels shown in green, so this seems like a problem. Can someone tell me what this means? And perhaps how to run a diagnostic on the servo?

Thanks in advance.

Jeff

[Jonathon]

Hello Jeff,
Either the servo has gone bad or the wiring has.

First check that ALL the SkyView Network DB9 connections are good and tight, it is possible that the wiring issue is elsewhere from the wiring going directly to the malfunctioning servo.

Second, check the wiring at the servo itself. Because it is left to the builder to connect the bare wires from the servo into the network, it is possible that a bad crimp or whatnot has loosened on the B channel wiring at the servo.

If neither of these checks resolves the issue, call us from the plane and we will continue to troubleshoot.

[jeffhughes88]

Hello Jonathan,

Thanks for the suggestions. Today I checked all connections per your recommendation. By disconnecting the servos one at a time, I confirmed that it is the pitch servo that is showing red on the B-channel. I chased all the wiring to the pitch servo with an ohm-meter and confirmed that all wires are connected as per figure 118 on page 10-10 of the SkyView Installation Manual v15.4. The servo is getting 12V of power on the power connection (red wire) and is connected to ground (black wire). I was going to have the AFS5600 re-scan the SkyView network but the scan button doesn't appear to do anything. Perhaps it thinks it has already scanned everything? Anyway, I pressed update to on the Skyview menu and it did then scan and update the firmware for all SkyView network devices. After backing out of all admin menus the 5600 says it will restart, and after the restart I again checked devices on the Skyview network and confirmed that the pitch servo still shows red for channel B.

Let me know what you suggest next. If we need to synch up by phone with me in the plane then we'll need to arrange a time when we can do that.

[Rob Hickman]

Sounds like one of the two B channel wires is bad.

[jeffhughes88]

Makes sense but I've checked all wires end to end using an ohm meter, including the 4 channel wires. All of them show connectivity from the DB9 connector that plugs into the SV-net hub all the way to the butt connectors that connect to the servo. See photo. Tonight I powered everything up and switched to the SV-Net admin screen so I could see the state of all SV-Net devices. Tugged on all the wires at the butt connectors while watching the indication on the 5600 to see if the b-channel came to life. Didn't happen. Also tried wiggling the connector that plugs into the SV-net hub. Again, no change in status. I've taken the cover off the db9 connector and everything looks good. And again, I've tested from the pins on the DB9 all the way to the servo. Is there any kind of diagnostic test I can run to check the servo?

520

[Jonathon]

There is no software diagnostic beyond the indications provided on the SV-Network scan page. Since the wiring is good, than the problem must be with the servo. Please email support@dynonavionics.com or call (425) 224-6736 to get set up with an RMA.

[jeffhughes88]

Ok thanks Jonathon. Will do.

[jeffhughes88]

I received the servo back a couple weeks ago and installed it last weekend. I'm happy to report that this did solve the problem. When I scan SV devices I now see that both A and B channels are green for this servo, which is great! However, on flight testing the plane this weekend I confirmed that I still have the same/similar problem with the autopilot pitch axis. Engaging the autopilot causes the plane to nose down aggressively. I have confirmed that "Alt" is selected in the autopilot menu and I have repeated this test after setting several different values for target altitude (at or above my current altitude) and I see the same results. I also tried hitting the Level button and I get the same results.

After confirming this behavior, I turned off the autopilot and started watching the flight director. Lateral indication seems fine, but the flight director does have a problem with the vertical. Regardless of my altitude settings, it indicates that I should lower the nose aggressively to follow the flight plan I have entered. I had not noticed this before, but I don't normally pay attention to the flight director, so perhaps it has been doing this for a while. Not sure. But when I engage the auto pilot it does what it is supposed to do and pushes the nose down to align with what the flight director is telling it. So the problem is with the FD. It seems like there would be 2 possible reasons why the pitch-axis of the flight director would indicate the need for an aggressive nose-down pitch. The first would be if there was a problem with the signal it is getting from the ADAHARS and the second would be if it thought the aircraft had dropped below the minimum speed and a nose-down action was required.

After completing the flight, I started examining the ADAHRS and looking at the ADAHRS settings. I have a Garmin G5 wired in as a backup ADAHRS, and when I switched between the primary and secondary ADAHRS on the ground I could see a slight difference between the resting pitch attitude of the plane. I had previously set the proper pitch for both units, so it's a little odd that this would be off, but it was only off by a couple of degrees and nothing that should cause the in-flight behavior I've observed. Nonetheless, I made a small pitch adjustment to the ADAHRS pitch so it would read the same as the G5 pitch (which is correct). One odd thing is that when I power down the G5 and cycle through my ADAHRS choices (ADHRS1, EFIS backup, Auto, etc.), it indicates that ADHRS 1 is offline. I would have thought that ADAHRS 1 would be the SV-ADAHRS unit, not the G5, so this is weird.

I also dumped all of the logs after my test flights yesterday. Nothing unexpected in the "ALD" flight log file. I could see the pitch ranged from +15 to -13 degrees during the test flight. The KRNLOG file does show a a bunch of file errors though. And the Syslog does show ADAHRS errors - although I can't tell if those occurred during flight or if those happened on the ground afterward when I intentionally turned of the G5. Regadless, I see multiple of these errors below in the syslog. Please advise as to what you think I might do to troubleshoot this further. I am keenly interested in resolving this problem.

[ 29.546681] AF5000.AFE[2382] INFO: ADAHRS Primary Index changed from 0 to -1 @02:40:51.044Z
[ 29.546722] AF5000.AFE[2382] WARNING: G_AdahrsCtrl.priIdx OOB:-1
[ 29.546751] AF5000.AFE[2382] INFO: ADAHRS Backup Index changed from 1 to -1 @02:40:51.044Z
[ 29.546774] AF5000.AFE[2382] AHRS: SEL: AHRS 1
[ 29.546802] AF5000.AFE[2382] ERROR: AHRS:1 (SV-ADAHRS) Offline Data Timeout @02:40:51.044Z


Note that I also see these errors occasionally in the syslog:
[ 28.382649] AF5000.AFE[2382] ERROR: AFS_NetworkThread: Register multicast failed <Invalid argument>

[Shawn McGinnis]

[ 29.546681] AF5000.AFE[2382] INFO: ADAHRS Primary Index changed from 0 to -1 @02:40:51.044Z
When reading these lines the first block, [ 29.546681], is the system run time in seconds. So its perfectly normal indications of the equipment being discovered.

[jeffhughes88]

Shawn, do you have any idea what would cause the Flight Director to indicate an aggressive nose-down pitch during normal flight if the altitude bug is set higher than the current altitude?

[Shawn McGinnis]

Have you verified your AP MIN and MAX speeds are correct? The flight director will nose down if your minimum speed is set too high. Your MIN and MAX speeds should be a little above Vs1 and little below Vne.

[jeffhughes88]

Doh! Just checked and yes, the min airspeed was 135. I can't believe I missed that.

[jeffhughes88]

My autopilot is now functioning as expected under almost all circumstances. However, I still have a problem where the plane will sometimes dive below glidepath partway through a fully coupled approach. Min Airspeed is set to 70 on my AFS5600, which I have triple-verified after my previous error above, and I've confirmed through flight logs that my actual airspeed was well above that minimum (I saw 76 knots minimum in my log for the most recent approach where this occurred).

After experimenting with this at altitude in slow flight, flaps-down configuration (normal behavior observed) and then on multiple approaches (where the plane sometimes but not always dives below glideslope), I have a theory. I believe this is due to the aircraft being out of trim, and the autopilot not being able to overpower the out-of-trim condition. On my last flight, I was on glideslope to KPWT on ILS 20 approach with autopilot on and properly tracking glideslope on final. Then about 1/2 way down final, it started to dive below glidepath with autopilot still engaged. I disengaged autopilot and could feel that the stick was pretty heavy in the forward trim state. I'm sure that's because I had trimmed for cruise on my way to KPWT and did not re-trim when I slowed down and lowered flaps on final. After taking control from autopilot, I trimmed the plane correctly, leveled off and re-engaged the autopilot, which then correctly followed glideslope again. This strongly suggests to me that this is an out-of-trim problem, although I don't recall feeling any servo slippage from the autopilot before it dived below glideslope, which seems odd. Have you seen any other issues where the autopilot can't overcome an out-of-trim condition?

Related to this... I have searched multiple AFS and Skyview manuals trying to find out whether the AFS5600 displays any sort of "out of trim" indicator when autopilot is on. It doesn't appear so. There is one mention of a "pitch slip alert" in the Pilot's guide, but no mention of how I enable that or see it anywhere. Maybe it is an audible?? Don't know. Let me know if I'm missing that somewhere.

[jeffhughes88]

OK I'm going to reply to my own post... I have confirmed that the problem I reported above was due to an out of trim condition. I did this by conducting experiments at altitude - engaging autopilot and then manually forcing the plane into an out of trim condition. Autopilot loses the battle and some point and the plane dives (or climbs) depending on which direction you are out of trim. The surprising thing about this is that the autopilot seems to suddenly 'release' without warning and the plane begins to dive or climb aggressively thereafter. My hands are always on the controls even with autopilot engaged and I would expect to feel the servo slipping for a while prior to this happening but I haven't noticed it doing so. I did notice that the Autopilot portion of the EFIS does show a flashing yellow up arrow or down arrow when the autopilot detects this out of trim condition, so it is possible for the pilot to manually correct the trim problem before the autopilot gives up. When flying an IFR approach, there are quite a few other things on your mind, however, so it's quite easy to miss that yellow arrow.

As I mentioned in my post above, I was unable to find anything in the Pilot's Guide, the AFS installation manual or Skyview installation manual pertaining to this 'out of trim' indicator. It must be somewhere because after I saw it on the screen I vaguely recalled seeing it in one of the manuals... but I've groped through all of these manuals again and still can't find it.

I think it would make sense to add an audible warning for the situation where autopilot is engaged but encounters a significant out of trim condition. This condition is likely to occur when you are flying a fully coupled approach because the trim condition changes significantly when reducing airspeed and bringing in flaps on final but you might not notice that while the autopilot is still in control. An audible warning would help avoid any surprises. Maybe this is already a configurable option and I missed it? Anyway I think it would also help to document the out of trim arrow in the manual in some more prominent way.

Love your products. Just trying to offer some suggestions.

[rvdave]

The Vizion autopilot head has scrolling bars to indicate which way it is out of trim, would be nice to see a display of some kind on the efis.