|
Seeking Feedback for DFC90 and DFC100 Improvements |
Post Reply 
|
| Author | ||
AviJake 
Admin Group 
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
 Post Options
 Thanks(0)
 Quote Reply
 Topic: Seeking Feedback for DFC90 and DFC100 ImprovementsPosted: 08 Mar 2011 at 11:37am |
|
|
Now that there are 600+ DFC 90/100s out in the field, we're very interested in soliciting any feedback for improving their design/performance.
For example, DFC100 VNAV operations - add an indication (like aural alert) that Top of Descent has been reached and descent is beginning. |
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
 |
||
|
jfourrn52
Release 9 Insiders 
Joined: 18 Mar 2011 Status: Offline Points: 18 |
Post Options
Thanks(0)
Quote Reply
Posted: 20 Mar 2011 at 1:40pm |
|
|
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. |
||
|
||
|
AviJake
Admin Group
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
Post Options
Thanks(0)
Quote Reply
Posted: 20 Mar 2011 at 2:27pm |
|
|
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.
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.
|
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
|
||
|
jfourrn52
Release 9 Insiders
Joined: 18 Mar 2011 Status: Offline Points: 18 |
Post Options
Thanks(0)
Quote Reply
Posted: 21 Mar 2011 at 10:16am |
|
|
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 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. |
||
|
||
|
AviJake
Admin Group
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
Post Options
Thanks(0)
Quote Reply
Posted: 21 Mar 2011 at 10:23am |
|
|
Thank you for this new question/input. This response is just to acknowledge your post. We'll take some time to think about the suggestion and data and come up with a more thoughtful response.
|
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
|
||
|
rdawson
Release 9 Insiders
Joined: 09 Mar 2010 Location: Daytona Beach Status: Offline Points: 14 |
Post Options
Thanks(0)
Quote Reply
Posted: 25 Mar 2011 at 5:59pm |
|
|
Another DFC 100 anomoly (not quite a suggestion).
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!.
|
||
|
||
|
AviJake
Admin Group
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
Post Options
Thanks(0)
Quote Reply
Posted: 27 Mar 2011 at 7:58am |
|
|
Hi Rick,
We spent some time trying to duplicate your scenario in the lab with a R9/DFC100 system. The DFC100 will fly what the FMS is telling it to so in this case, it looks more like an R9 FMS question than an autopilot anomaly. That being said, here's what we've come up with so far: The attached screenshots show the entry into the course reversal (hold) with a parallel entry. We didn’t see the anomaly that you described, but we wonder if it could be that you're misinterpreting the lines that are drawn. Shots 2 and 3 correctly show the barber pole on the second leg of the entry and also the leg following the hold fix. In shots 4, 5, and 6, however, the barber pole leg disappears. Once the entry is complete, the next leg goes active and the leg after that is drawn with the barber pole. Is there any chance this is representative of what you saw? If so, we fly a parallel entry by basically going around the outbound turn in the opposite direction and then proceeding back to the hold fix rather than intercepting the inbound leg early. That’s not necessarily how you would fly it by hand, but it is legal. << Rick, I'm having a bear of a time trying to format the screenshots for this posting. If you send me your email I can send you the full set of screen shots and we can go from there. Send to sjacobson@avidyne.com>> |
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
|
||
|
mvitalis
Newbie 
Joined: 20 Apr 2011 Status: Offline Points: 15 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 Apr 2011 at 12:00am |
|
|
I've written a fairly detailed set of posts about my recent experiences with flying the ILS according to the Avidyne Pilot Guide. While I don't have a suggestion for improvement on the device (yet), I do think more work needs to be done to the Pilot Guide to:
1) explain better how the system works so that the pilot can better understand what to do, and more importantly what not to do (e.g. how does CRS get set; what are the interactions between the 430/MFD/PFD in GSP and VLOC modes particularly when they are switched back and forth) 2) be more explicit on what the precise steps are for using the 430 and the DFC90. I ready the Guide thoroughly and made my own 2-page synopsis before trying the DFC90 out on an approach the first time. While I had no problems with WAAS approaches, I couldn't reliably get the ILS approaches to work consistently. Sometimes I'd get GS, sometimes not, and, as far as I could tell, I was following directions correctly (VLOC1, correct ILS, using NAV not GPSS, etc.). I have since discovered that the CRS gets set when you activate the approach, to the current bearing to the selected transition waypoint. If you continue to fly in VLOC mode, then subsequently activate a leg before the FAF (a typical situation when being vectored) while still in HDG mode or even HDG+NAV model, then the CRS will still point to the previous transition waypoint (which is now turning behind you). When I press NAV to arm the approach, the AP turns away from the approach towards the waypoint! This was most unexpected and I'm still not clear on what set of button to always push in what order in spite of spending 2.5 hours over the last week trying to figure that out. It shouldn't be this hard! The 430W is autoslewing, and the MFD always reports the correct active leg, waypoint and destination. The only thing that's wrong (some of the time), is CRS. So how does this work? Again, please refer to the more detailed post above for additional info. Maynard |
||
|
||
|
AviJake
Admin Group
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 Apr 2011 at 9:39am |
|
|
Hi Maynard,
Thank you for the feedback on both the Pilot Guide and the question on course slewing and mode switching on instrument approaches. I will make an effort to improve the Pilot Guide on this topic in the next rev, expected later this year. I'm currently on travel but when I return on Monday, I'll hit the lab and try and replicate what you're seeing and determine what I can suggest. I personally flew similar scenarios dozens of times during development and I'm not aware of anyone faced with the same challenges right now so I'll want to better understand the exact scenario you are experiencing to ensure I and accurately answer your questions. More on Monday. Steve |
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
|
||
|
jknox
Newbie
Joined: 21 Oct 2011 Location: Austin, TX Status: Offline Points: 3 |
Post Options
Thanks(0)
Quote Reply
Posted: 21 Oct 2011 at 2:39pm |
|
|
A suggestion which can be made in software alone... Improve the failure reversion capability.
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>] |
||
|
||
|
AviJake
Admin Group
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
Post Options
Thanks(0)
Quote Reply
Posted: 14 Nov 2011 at 12:25pm |
|
|
Hi James,
Thanks for the suggestion. We have considered using the STec TC (technically not a "DFC90 TC") already in the aircraft for Cirrus configurations in just such a mode. We've not found a workable Engineering solution to this type of enhancement yet. For now, we're spending our time and energy on bringing the DFC90 to the current list of announced aircraft. That being said, this type of enhancement idea is being kept around to potentially re-evaluate at a later date. |
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
|
||
|
jknox
Newbie
Joined: 21 Oct 2011 Location: Austin, TX Status: Offline Points: 3 |
Post Options
Thanks(0)
Quote Reply
Posted: 14 Nov 2011 at 12:40pm |
|
|
I agree that it would not be a "perfect" solution. However, it is one of the very few areas in which the replacement of the 55X with the DFC90 *removes* a capability. In fact, one suggestion in the Avidyne Entegra manual is, in the case of IRU failure, use the 55X. Frankly, it doesn't have to work very well (just basic "wing leveler" mode) to be very useful to the pilot in this situation.
Anyway, just a suggestion for future thought.
|
||
|
||
|
AviJake
Admin Group
Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
Post Options
Thanks(0)
Quote Reply
Posted: 14 Nov 2011 at 12:54pm |
|
|
Understood and thank you.
|
||
|
Steve Jacobson
sjacobson@avidyne.com |
||
|
||
|
Catani
Senior Member 
Joined: 21 Jan 2016 Status: Offline Points: 362 |
Post Options
Thanks(0)
Quote Reply
Posted: 15 Apr 2018 at 4:43pm |
|
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. |
||
|
||
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2249 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 Apr 2018 at 12:45pm |
|
I double checked with the autopilot guys and there has been no change to that behavior.
|
||
|
Steve Lindsley
Avidyne Engineering |
||
|
||
|
Post Reply
|
|
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
Topic Options
jfourrn52 wrote: