Possible fix for the rudder, with active FBW

[nbz 11]

DISCLAIMER:

This post is done in a friendly, helpful mood, just IN CASE it is useful for anybody.

I am NOT saying that Aerosoft should "fix" anything (especially not on an aircraft that I do not yet own, since I'm waiting for the boxed version of the Airbus X) or trying to tell them what to do, I am also NOT saying that Aerosoft could not come up with a much, much better solution, IF they actually believe the rudder needs "fixing" at all.

But there just seems to be a concensus among users here that there will either be NO rudder forever, or a completely custom-written FBW system would be needed in order to get around the rudder issue of Microsofts default FBW - and this may just turn out to be wrong.

I do not want to be a troublemaker, Aerosoft is doing a splendid job at providing improvements very fast, and the last thing they need is lots of customers who MESS UP Aerosofts plane by hacking it and then complain that the plane is "broken". For this reason I will, for now, just share the idea, and not post actual code, because that would "break" some things.

----------

I have written an XML gauge for the default Microsoft A321 that provides a nicely working, precise rudder while the Fly By Wire is active. It can even gradually reduce deflection as airspeed increases.

Since Aerosoft uses the default FBW for the Airbus X, the rudder is "defunct" for the same reason it does not work on the Microsoft Bus. Therefore my gauge should (in theory) also work with the Airbus X.

The gauge is unfortunately not suitable as a general solution for the broad public, because it has several technical drawbacks (read: it is a hack that "breaks some things"). The biggest issue is that it produces a firework of key-press events. This is usually regarded as a big no-no, because it destroys multiple-keypress user inputs such as "Select Engine 2" or "Open Door 3".

However I just want to share the idea behind this, as I said just IN CASE that others might find it useful and can turn this into a more practical solution. (And I do not care if these "others" are Aerosoft, random flightsimmers, or the easter bunny.)

The FBW enforces the yaw damper ON above 100 ft, and this leaves us without any control over the rudder axis. But what we have left is the rudder TRIM position, which is not affected by the yaw damper, the FBW, or the autopilot. Since this produces basically the same aerodynamic force as the rudder in FS, we can abuse it to mimic the force that SHOULD be exerted by the rudder but isn't. Since we can still read the rudder axis input from the pilot, we just have to map the pilot's input to the rudder trim.

The obvious drawbacks:

1) A silly rudder animation on the external model (I don't really care, as I am in the VC while flying)

2) An ECAMS page that probably shows nonsensical control surface deflections (no problem on the Microsoft Bus as the ECAMS control surface page actually shows the pedal input instead of actual surface movements! So it was already showing nonsense without my gauge)

3) The purists will scream that rudder pedals do not in reality control trim. (I don't care AT ALL as long as the resulting forces give me a working rudder)

So in order to professionally incorporate this solution into an aircraft, I guess the external model, the ECAMS, and probably more stuff would need to be made aware of this.

The part I found the most difficult to solve was that FS does not have a command to set the absolute position of the rudder trim (PLEASE somebody correct me on this if I'm wrong!). For the elevator trim we have ELEVATOR_TRIM_SET and AXIS_ELEV_TRIM_SET, but we are out of luck regarding the rudder trim. We only have RUDDER_TRIM_LEFT and RUDDER_TRIM_RIGHT.

(Sidenote: there is an occurence of the string "RUDDER_TRIM_SET" in controls.dll, but it doesn't seem to work and was probably left out of the SDK for a reason...?)

However this will not restrain a determined flightsimmer, and therefore my gauge can RAPIDLY and PRECISELY set the rudder trim corresponding to the rudder axis input. And the yaw damper does not seem to be "fighting" against pilot inputs! It smells like a rudder... It flies like a rudder... It feels like a rudder... just too damn good not to share the idea here.

As mentioned above, this of course generates lots of keypress events that prevent multiple-keypress user inputs. So to me the BIG question goes to people with knowledge of SimConnect (as I have none):

Can a SimConnect application submit key events, or otherwise set the rudder trim, WITHOUT breaking user inputs and still allowing multiple-keypress user inputs?

IF that is the case, I think we may have all ingredients required for a working rudder with FBW active:

- use SimConnect to set rudder trim according to rudder input axis

- make external model aware that while yaw damper is ON, rudder animation is based on rudder TRIM not rudder AXIS

- modify ECAMS to display rudder trim as surface movement when yaw damper is ON

Happy flying everybody!

[Todd_F 38]

Sounds like good work! I did realize a couple days ago that the trim worked fairly well. I was going to see about assigning it to an axis with the Saitek software(I read somewhere that it was possible to do so). But since it seems you have found an internal way to do it I'll wait on that. Don't worry about stepping on Aerosoft's feet by trouble shooting their aircraft, I can't speak for them but they should appreciate what you're trying to do, I know that I do...

-Todd

[nbz 11]

Good luck with assigning the rudder trim axis to a controller.... because as far as I'm aware, FSX simply does not have such an axis. Unlike the elevator, for which a trim axis exists.

I am worried about stepping on Aerosofts feet, it's not like they aren't very busy working on improvements. They also don't need me to tell them anything new about FSX they didn't already know. I just had to post my idea, because the contrast was too big between the posts here complaining that FBW makes any rudder use impossible, and the nicely working rudder I hacked up for the default A321.

Also, maybe the idea of flying through trim is so stupid, crazy or too-obvious-to-come-up-with, that some amateur like me just had to actually try it and do a proof-of-concept, because a professional FSX developer would have immediately dismissed the idea as BS...?

I realize that in principle, Aerosoft welcomes community contributions.... as they have said when explaining that almost anyting in the Bus X is done using XML.

But as much as I would like to share my (admittedly half-baked) solution, in this current pre-SP1 timeframe I would find it counter-productive to post my code when I already know it will solve 1 thing but break 3 other things. For my personal use, I can live with no multiple-keypress inputs and a messed-up rudder animation. This however cannot be expected from the "broad public".