Bendix/King KAS 297B Altitude Selector
-
Thanks for reviving this thread.
I'm eager to hear the developers view on this, or any real world pilot with KAS 297B experience.
Also, I have another interaction 'issue' in the TBM I'm curious about:
https://community.justflight.com/post/26789 -
I have addressed the shortcomings of the KAS 297B in several places, but I'm not sure this forum is one of them. The behavior that you speak of is not accurate to the real world unit. It is caused by the fact that the native MSFS autopilot lacks any sense of vertical speed arming. With the experience I've gained from working on the Starship, I suspect that I could create my own solution for this now. I will experiment with it before the major update to the TBM. I'll answer your other question in its respective thread.
-
@limbo696 said in Bendix/King KAS 297B Altitude Selector:
I'm surprised nobody has notice issues with the KAS 297B Altitude Selector since it is a frequently used item. I do not believe that the unit is modelled correctly based on my reading of official manuals from several different aircraft available online, but I may be I'm wrong.
In response to @GunStrauss' question, the ft/minute setting always seems to reset to your current vertical speed which would be zero in many cases but not always. You cannot pre-select a vertical climb rate and then press engage since the VS always gets reset. I believe this behavior is incorrect based on my readings as I've read about the ability to preselect vertical speeds.
I also don't think hitting the ARM button should automatically engage VS mode. If you watch Steveo1kinevo's videos, he usually hits the ARM key followed immediately by pressing the ENG key. But with BlackSquare's modelling, pressing the ARM key automatically engages VS Mode negating the need to press the ENG key. I've also seen the ARM mode come on when pressing the ENG key even though I had no desire for altitude capture.
Anybody else's thoughts on this issue? Do any other aircraft use this unit which I can test for free to see if the behavior is the same?
Hello,
I just flew the new version of the TBM 850 (excellent) but I still don't understand how the KAS 297B Altitude Selector works (I read and reread page 44). @limbes696 above describes very well the problems I am facing.
Do you have any advice? -
Here's how I use it (regardless of the real world unit):
- Use the knob left/right to select target altitude
- Press VS
- Click (pull) knob to change from Altitude to VS selection
- Use the knob left/right to select target vertical speed
- Click (push) knob to change from VS to Altitude selection
-
I don't use either VS & ARM buttons or the push/pull knob on the KAS297B.
Only turn knobs to select desired altitude and that's it.
I only use IAS mode for climb & descent and it's quite challenging especially at the beginning of descent.I really hope the KAS297B fixed not too long after the Starship comes.
-
Please don't fix it so hard that it stops working with the regular input binds though, because that works great as is. Doing the unit "realistically" would result in a situation like with the SWS PC-12 where it's an absolute kludge in terms of usability since you're forced to use the mouse for anything altitude-related whereas the current implementation in the TBM "just works" with the default binds on, e.g., the Honeycomb Bravo using the "select AP ALT/VS" and "plus/minus" binds for all major operations.
-
@Laurreth Unfortunately, you've put your finger on the problem exactly. I've implemented true altitude preselect and arming in the Starship, because the Starship's avionics are so radically different that I don't expect anyone to have prior hardware solutions that they expect to work with it. You will still be able to use hardware, of course, but with the custom bindings required to control the many multifunction displays. I generally try to stay away from overriding the default input events for this exact reason. I know that my aircraft exist in a slightly odd place, not being perceived as inherently as complex as a 737, but also possessing a realism greatly beyond your average light aircraft for MSFS. As a result, I often have to walk a fine line between my more casual users and my power-user real world pilots.
-
@Black-Square said in Bendix/King KAS 297B Altitude Selector:
I've implemented true altitude preselect and arming in the Starship, because the Starship's avionics are so radically different that I don't expect anyone to have prior hardware solutions that they expect to work with it.
Some months ago you said above that the native MSFS autopilot lacks any sense of vertical speed arming and you'll experiment with it before the major update to the TBM. Have you found a remedy for the Starship but was it not apt for the TBM?
I'm worried if the real solution eventually comes. It's not only the TBM but also Bonanza/Baron that need the fix. -
@Black-Square What about making “Require Altitude Arm” an EFB option that defaults to off?”
-
Unfortunately, the other reason the Starship was a compliant host for this new feature was because I am in control of all the avionics. In my other aircraft, autopilot behaviors are swapped in and out with the GPS units, and several of them have slightly different behavior compared to the others. I would have to separate my autopilot into its own instrument, dynamically toggle the intercepting of native events (I believe I've seen this done, but never tried it myself), and then make sure it works correctly with every GPS combination. It's not impossible, but it would be a lot of work. I will continue to think about the best way to accomplish this, don't worry. Thank you for the suggestion, though!
-
@Laurreth said in Bendix/King KAS 297B Altitude Selector:
Please don't fix it so hard that it stops working with the regular input binds though, because that works great as is. Doing the unit "realistically" would result in a situation like with the SWS PC-12 where it's an absolute kludge in terms of usability since you're forced to use the mouse for anything altitude-related whereas the current implementation in the TBM "just works" with the default binds on, e.g., the Honeycomb Bravo using the "select AP ALT/VS" and "plus/minus" binds for all major operations.
I wholeheartedly disagree, I've used a lot of time to bind the inputs for Honeycomb Bravo, logically and systematically so that you never need to use the mouse. Even though the KAS 297B is possible to use as it is, it's obvious from a UX standpoint that it does not currently function as the unit is intended by its original manufacturer.
-
@Black-Square I understand that this might be quite low on the list of what that can be prioritised, and I must admit that even after reading one of the documentations I've found online for the real unit, I'm not really sure how it's supposed to work :) ...if you however would like to revisit this unit at one time, I would be very interested in testing, and do my best to provide some feedback on how to map it to hardware.
-
I hope it doesn't come across like I am ignoring these requests. This is actually quire high on my list of items to fix in many of my aircraft. Unfortunately, it's not just a matter of "putting in the hours" like many other features, for reasons I explained above regarding usability, hardware, 3rd party GPS units, and backwards compatibility. All of these combine to make for a very ugly proposition unless you control all of the autopilot environment, which is why I have only implemented my own solution in my Starship so far.
That being said, could you explain why you consider VS mode to be "INOP" with the current implementation? I take that claim very seriously, as I do not want anyone to consider any part of my aircraft to be "INOP", as this is nearly claimed in my advertising materials for every one of my aircraft. As it currently stands, the lack of altitude arming should only prevent you from setting a desired vertical speed before you intend to climb/descend. While this is imperfect, I have found that it has only the most negligible impact on my workload while flying the airplane. If you are encountering more issues than that, please let me know and I can look into them or discuss further.
-
Oh no!
That's not what I meant!
Sorry I caused possible misunderstanding.The current implementation is definitely NOT "INOP", nooooo way!
I CAN do VS descent/climb if I want & need.
So I choose the word "pretend", (not "regard" or "take") which means "do something NOT TRUE".What I meant was that there is little quirks that we all know in this 99% perfect simulation, so that I "pretend" such situation as if it was a 100% perfect simulation. Kind of every simmers' role-play you know. ;-)
I am happy enough to hear that this is high on your list and looking forward to fly the Starship!
-
I understand! Thank you for explaining. I hope you didn't take my message to be accusatory either, by the way. I really take the claims in my marketing to heart, so I just wanted to make sure that I was not running afoul of my own promises in someone's eyes. Indeed, I will continue to think about how this can be done, but I do not have any immediate solutions that I would be willing to deploy retroactively. Usually the way this works for me is that I design something new (Starship), with a new solution (altitude arming), learn how my users interact with it, and then find a way to work that polished solution back into my older products, if possible.
