Has Avidyne considered bringing the "always armed" ALT mode of the DFC 100 over to the DFC 90? I understand and appreciate that you were trying to keep the existing interface of the STEC autopilot in order to keep the same habits working for pilot.  BUT---  In almost all cases you want the ALT mode armed when climbing or descending. Doesn't it make sense to make that the default?  Clearly it does for the DFC100.

Somewhat intermingled with this question is the behavior of the altitude bug when the ALT mode is engaged by pressing the ALT button.  Presently the DFC 90 resets the altitude bug (just like the STEC does).  Often the button press is accidental (a botched VS+ALT press perhaps?).

The sequence of events usually goes something like this.  ALT mode is entered (accidentally), aircraft begins to level, now the pilot has a moment of confusion because the autopilot starts to level,   and now must reset the altitude bug (easy to do until you try to rush-- then you can seem to get the 1000,100,10 cursor to end up where you want it), then reengage the autopilot and rearm the ALT mode (don't screw it up again).

If the DFC 90 was give the logic of the DFC 100 where the altitude bug just STAYS where the pilot puts it-- then all this would be resolved, a inadvertent push of the ALT button wouldn't reset a bug the pilot had just set and often struggles to reset when under pressure.

As I'm sure you know, habit patterns are extremely powerful and instead of trying to break some, we tried to take advantage of them.

Since deploying the DFC100, we did re-evaluate our position on the Alt-Always-Armed behavior and if we should roll that back into the DFC90.   We continue to convince ourselves that it still makes sense to leave it the way it is for DFC90 mostly for similarity-to-what-you're-used-to reasons.

We wondered how much feedback there would be on this topic.  It has been surprising to me to note that this is the first such question/request on that topic.

Thank you for the question.

Yes, but once those habits were broken the pilot would be flying a "friendlier" or more intuitive system.  If we didn't change things for the better now and again we would never see any improvement.

It would only really be a problem for people that had a fleet of aircraft and had to switch between different logic systems.

But we could go round and round with this because you still do have a powerful argument.


Somewhat hidden in my in first post was a second question.  Have you considered changing the behavior of the DFC 90 ALT bug to match that of the DFC 100?  Meaning that the autopilot will never automatically reset the altitude bug when capturing ALT.  

I have seen some pilots get seriously confused when the ALT bug gets changed by the autopilot.  (By way of an incomplete VS+ALT push or accidental ALT push.)

It was even played a role in the SR-22 crash is Cleveland. (Factor is a little strong there because there were MANY other mistakes made there and the pilot just plain forgot to fly the airplane when the automation gave him unexpected results.)

http://www.ntsb.gov/ntsb/GenPDF.asp?id=CEN09FA267&rpt=fi - http://www.ntsb.gov/ntsb/GenPDF.asp?id=CEN09FA267&rpt=fi
quote from the accident report. Emphasis mine..

“... The  autopilot  bugs  were  set to the assigned heading and initial altitude prior to takeoff. However, after takeoff  the  pilot  failed  to  properly  engage  the autopilot altitude preselect mode; the altitude hold mode was entered instead. As a result,  the  altitude  and  vertical  speed bug settings were reset automatically to maintain the airplane’s altitude.”

So the pilot got so wrapped up in the unexpected result of automation-- that the lost control of the aircraft.

But my point is not to discuss this accident. But to make the point that by only allowing the pilot to change that value of the altitude bug you would have a more straightforward system.

Consider a holding pattern lying east-west and northeast of fix with an entry from the north. This implies a parallel entry and a map item showing an eastbound parallel eg south of the hold, an aproximate 200 deg left turn returning to the fix, and then a standard hold with right turns. (This example comes from the RNAV 27 approach at KLAL.)

When I flew this hold, whils southbound still north of the fix, the map item was drawn as described. The anomoly is that 1) the alert was for a parallel entry (correct). The barber poll next leg indication on the MFD was the east-bound parallel entry leg (correct). The barber poll next leg indication on the PFD was a leg departing the fix at about a 70 degree track (incorrect). The leg with the barber poll on the PFD was actually the leg returning to the fix aftr the parallel entry.

Surely not serious, but I assume that someone at Avidyne is gathering these anomolies so they can be thrown into the engineering hopper.

By the way -- Great autopilot!.

 

Right now there are a number of event in the SR22 which will simply drop the DFC90 offline.  Perhaps the most serious is the loss if the IRU (attitude) in the PFD - the pilot loses both the main PFD function *and* the autopilot backup capability.  This is a greater loss than in the equivalent aircraft with an S-Tec 55X, where the autopilot is the *recommended* way out of the situation. 

 

In the event of PFD failure (whether IRU or communications with the DFC 90) the original automatic disconnect and aural warnings is reasonable.  But how about providing some fallback - for example, hit the "straight and level" three times and you get wing leveler functionality, supported by the DFC 90's TC?  [Gotta be better than hitting the chute! <G>]

 

 

Anyway, just a suggestion for future thought.

AviJake wrote: We have considered it and spent a great deal of time debating it internally during original DFC90 development.  At the time we felt that since every single person who is purchasing a DFC90 is coming from a STec 55, we thought it made more sense to keep it like the STec...

This is an old thread, but I'm just now considering a DFC90 to replace my 55X.  Personally, I feel the behavior of the 55X as described above is a bug.  In the years since AviJake posted Avidyne's position on the issue, has this inadvertent "reset the bug" problem (as I and some others see it) been fixed?

There are several differences between the DFC90 and the 55X, all done in the name of improvements (the reason for the DFC90 after all).  I don't think changing the behavior of the inadvertent altitude bug would add much workload to the task of learning the differences, and I'm surprised some thought that was a dealbreaker.  

Like the other DFC90 improvements, eliminating this altitude bug issue would be welcomed I think.  Not only because it would help put things back after an inadvertent ALT push, but also to help when ALT is pushed on purpose to achieve an intermediate level off for any of several reasons - doing so would not require remembering to reset the bug, and also remembering what it was supposed to be set to.

If you do want to intentionally reset or "sync" the altitude bug to present altitude, there are ways to do that, on purpose.  Doing so accidentally can be distracting.

I double checked with the autopilot guys and there has been no change to that behavior.