A reasonably accurate Turn Coordinator for FSX...

[Guest jcomm]

Do something for your Turn-Coordinators...The subject is not new, and indeed there have been alternative implementations of turn coordinators for MSFS because, as most of you know, the default aircraft, and many of the add-on GA fleet lack an accurate TC instrument. I was inspired by the gauge Tom Goodrick once designed and made available at the fs2004 forums.There are basicaly two sorts of TCs in MSFS - Turn Coordinators and Turn & Slip instruments, although both are based on the same pieces of code that make use in their calculations of a token variable: DELTA_HEADING_RATE.Just as mentioned in the FS SDK, this variable "Specifies heading change rate (pseudodegrees/sec)". What exactly is meant by "pseudodegrees" I do not know, but one thing is for sure - most of the time your standard rate turns when performed based on the TC will take 1'30'' instead of the expected 2'I have designed a TC myself. It's very basic and the graphics poor, but I was not really looking for graphics perfection. Instead, I tried to get reasonably accurate turn rate indications, and I was able to approach these values in two ways:1) We can apply an Euler transformation to the value "DELTA_HEADING_RATE", to correct for the bank angle because apparently this token variable is actually measuring yaw rate relative to the aircraft inertial reference system and we should compensate (based on COS(Bank Angle)).2) Calculate the Theoretical Turn Rate, based on Bank Angle and TAS, using the formula:Omega = g * TAN(Bank Angle) / TAS for a value in Radians, orOmega = 180 * g * TAN(Bank Angle) / (pi * TAS) for degreesOn instrument panels based on XML it's easy to edit and adapt the code for the Turn Rate component of the instrument. For instance, on de Beaver we have:NORTH-0.6000.600 ...and can easily change it to incorporate this new formula:(A : PLANE BANK DEGREES, radians) tg 5760.0 * (A : AIRSPEED TRUE, feet/second) pi * / /-/Further to this one can define Min/Max values and use a "Nonlinearity" element to define the gauge positions at -3.0, 0.0 and 3.0 degrees per second (Remember a standard rate turn is performed at 3 degrees per second...)To give you an hint for the code I use in my own gauges you have:EAST-3.000206.000,100.0000.000210.000,128.0003.000206.000,156.00090.000DEGREES_PER_SECONDIf possible one should also invest in the graphical quality of the gauge, and make it big enough to allow for proper align with the 2' marks in the instrument. On my TC gauge I display a digital reading of the Turn rate at the center of the gauge which can be enabled / disabled with a simple mouse click.

[Guest Patrick_Waugh]

Finally, someone that uses more of a jack hammer than I do!!!Not sure why you think you have to compensate for bank angle. That would be assuming an aweful lot about how their yaw rate is not based on a point model that doesn't really care about yaw at all.Frankly, while the ball is not at all accurate for reasons many with much more knowledge than I have previously cited, I have found that I have no problem getting correct 2 mins turns out of my turn coordinators.Here are two of my turn coordinators:Both give very precise standard rate turns.But an interesting post and formulas anyway.

[Guest jcomm]

Those two look simply great, graphicaly - where did you get both from? I had to design my own using MS Paint :-( and it looks awful...If those instruments are "attached" to XML gauge files then it would be easy to check the associated calculations - I'm curious if both are using the standard DELTA_HEADING_RATE, sometimes multiplied by a scalar...The default TCs are accurate on some aircraft, not quite like so on others. For instance, they are completely out of schedule when you fly the Goose ore even the Caravan. In the Goose, for instance, it takes about 1' 25'' !!!

[Guest Patrick_Waugh]

>Those two look simply great, graphicaly - where did you get>both from? I had to design my own using MS Paint :-( and it>looks awful...I created these in Photoshop CS2, thank you.>If those instruments are "attached" to XML gauge files then it>would be easy to check the associated calculations - For testing, just use the MS gauge artwork and save yourself some trouble.>I'm curious if both are using the standard DELTA_HEADING_RATE,>sometimes multiplied by a scalar...Actually, I use TURN_INDICATOR_RATE as it gives you the rate you need directly (degs per second). I could never figure out the conversion to the other variable.>The default TCs are accurate on some aircraft, not quite like>so on others. For instance, they are completely out of>schedule when you fly the Goose ore even the Caravan. In the>Goose, for instance, it takes about 1' 25'' !!!Yes, I have noticed this also.

[mgh 89]

I understand that a turn coordinator senses both roll and yaw."A turn coordinator operates on precession, the same as the turn indicator, but its gimbal frame is angled upward about 30

[Guest Patrick_Waugh]

Remember, there is a difference between yawing the aircraft about it's axis (to say hold a slip), and yawing relative to the world. =)The variable gives the rate of turn, meaning relative to the world, not the aircraft's yaw about it's own axis. Yaw all ya want, as long as it is not changing.Therefore, you could hold a steady slip and see no rate of turn using my gauges.

[Guest jcomm]

>Also the equations:>>Omega = g * TAN(Bank Angle) / TAS for a value in Radians, or>>Omega = 180 * g * TAN(Bank Angle) / (pi * TAS) for degrees> >assume the aircraft is in a coordinated turn which will not>always be the case. For example, if an aircraft is making a>wing-down approach in a cross-wind with opposite rudder the>aircraft would be flying straight but the formulas would show>a rate of turn.That's true, of course, but if you follow the first formula suggestion, correcting the token variable "DELTA HEADING RATE" or "TURN INDICATOR RATE" for the bank angle, then even the Goose will perform standard rate turns...I don't know if Patrick's turn coordinators allow him to perform a standard rate turn in 2 minutes when flying the Goose, for instance, but most of the instruments I used don't...Just to show my point here, I attach the part of the text for the turn coordinator in the Goose (FSX) that will allow you to get indications based on the first of the formulas I suggested and, at the same time, displays OM and TR, the first a digital reading of the turn rate with the COS correction and the second the actual "TURN INDICATOR RATE". You can enable the display by clicking over the gauge area. OM is in green, TR in red. I know I shouldn't allow -0.0 to appear, but my point here is not to be perfect...Test this gauge with the Goose. Use the digital readings to help you mantaining a coordinated or uncoordinated standard rate turn and you'll see how close you will get to 2'On the attached picture you can also see how far appart both values are during a standard turn, to the right in this case - that's why your standard rate turns, based on the MSFS token variable, give you 360 degrees in nearly 1' 25''...

[mgh 89]

I wasn't criticising your gauges. I was pointing out that equations that use only Bank Angle and TAS cannot give the correct rate of turn in all circumstances. Correcting this for Bank Aangle will not overcome the initial error. Also, remember yaw is an angle whereas the turn coordinator is measuring the rate of change of angle.

[Guest Patrick_Waugh]

>I wasn't criticising your gauges. I was pointing out that>equations that use only Bank Angle and TAS cannot give the>correct rate of turn in all circumstances. Correcting this for>Bank Aangle will not overcome the initial error.I wasn't feeling you did either.I'm just trying to point out the assumption you "model" of the behavior assumes, that is all.And indeed, it may be correct for the DELTA var.>Also, remember yaw is an angle whereas the turn coordinator is>measuring the rate of change of angle.Yes exactly my point above. You yaw in a slip, but your yaw rate is not changing. Both variable proport to give us a rate, rather than a yaw angle.We all agree on the theory and the math, I was only trying to point out that, as my TC gives me correct turns, if you use the other variable, you need not compute anything.But, perhaps my gauge is not taking pitch into account correctly. Maybe later when I have more time, I'll experiment with this variable as well.If my gauge was stand alone, I would send one to you for testing purposes, but right now it is part of a multi-gauge.In the end, all I care about right now is that it gives me a 2 min turn as advertised. :DI am glad you guys posted this as I was lost with the DELTA var.

[Guest Patrick_Waugh]

Later I'll try to get a stand alone gauge you can try.Patrick

[Guest jcomm]

Thx a LOT Patrick!;-)I see we also share an interest - Rotary Wing...Visited (and bookmarked) your site. I didn't know about it.I look forward for the release of that Bell206 :-)The first two things I did when I got my hands on FSX were to restore some sort of auto-rotation in the R-22, and invest a little bit in the Bell FM, namely in the torque effects area - one of the major limitations in the MSFS helo model...BTW: I use [Helicopter]low_realism_stability_scale = 0.8, 0.5, 0.01 in the default Bell206. Also my Gyroscopic Effects slider is set at 1/4 (set to the LEFT) in the Airplane Realism Menu because somehow the main rotor gyro effects got increased in FSX - more than they should, IMHO...One of the items in my list has been the use of the new "canted" engines to simulate the effects of torque not simulated, or exagerately damped by the MSFS helicopter FM. Basicaly I added a 90 deg. canted engine on the same axis as the tail rotor..

[Guest Patrick_Waugh]

>Thx a LOT Patrick!>>;-)>>I see we also share an interest - Rotary Wing...>>Visited (and bookmarked) your site. I didn't know about it.>>I look forward for the release of that Bell206 :-)>>The first two things I did when I got my hands on FSX were to>restore some sort of auto-rotation in the R-22, and invest a>little bit in the Bell FM, namely in the torque effects area ->one of the major limitations in the MSFS helo model...Interesting, but not sure what you mean. I find that the yawing tendency in FSX is not much much better.>BTW: I use >>[Helicopter]>low_realism_stability_scale = 0.8, 0.5, 0.01You are a mashochist. =) >in the default Bell206. Also my Gyroscopic Effects slider is>set at 1/4 (set to the LEFT) in the Airplane Realism Menu>because somehow the main rotor gyro effects got increased in>FSX - more than they should, IMHO...Are you speaking of the left yawing tendency? It was increased because it was not enough in FS9. There is considerable torque to overcome on lift off. If not, what are you addressing here?>One of the items in my list has been the use of the new>"canted" engines to simulate the effects of torque not>simulated, or exagerately damped by the MSFS helicopter FM.>Basicaly I added a 90 deg. canted engine on the same axis as>the tail rotor..Interesting idea, but does it have an effect you can notice in FSX? It did not seem to matter much in FS9, but perhaps things have changed.

[Guest jcomm]

>>[Helicopter]>>low_realism_stability_scale = 0.8, 0.5, 0.01>>You are a mashochist. =)> :-) Actually, I always found the MSFS Helicopters way too stable and dampened - things are not that way in real life...>>in the default Bell206. Also my Gyroscopic Effects slider is>>set at 1/4 (set to the LEFT) in the Airplane Realism Menu>>because somehow the main rotor gyro effects got increased in>>FSX - more than they should, IMHO...>>Are you speaking of the left yawing tendency? It was>increased because it was not enough in FS9. There is>considerable torque to overcome on lift off. If not, what are>you addressing here?>No - actually, and that's why I introduced the next paragraph, MSFS has an incredably low yaw effect (yaw due to torque, due to collective changes) in their helicopter FMs. FSX instead of bringing it up to more realistic effects, brought it way down (maybe because you're now supposed to control your aircraft with a Gamepad...).OTOH they they increased Gyroscopic effects exhagerately, in such a way that now when you give cyclic inputs (pitch/bank) the corresponding (bank/pitch) gyro effects are huuuuge.>>>One of the items in my list has been the use of the new>>"canted" engines to simulate the effects of torque not>>simulated, or exagerately damped by the MSFS helicopter FM.>>Basicaly I added a 90 deg. canted engine on the same axis as>>the tail rotor..>>Interesting idea, but does it have an effect you can notice in>FSX? It did not seem to matter much in FS9, but perhaps>things have changed.>This didn't actualy exist on previous versions of MSFS - the ability to define engine axis canted, say, 90 degrees to the aircraft z axis (the long axis in MSFS..., since they follow a left hand rule...). So, using an engine canted 90 deg. and positioned in the tail, programmed to respond to collective and many other parameters, of course, might bring much more sensible yawing tendencies, specialy when hovering, takeoff, etc...

[Guest jcomm]

The cant subject I am referring to is...ThrustAnglesPitchHeading.0 = 0,0 //Thrust pitch and heading angles in degrees (+pitch down, +heading right)a new Engine parameter one can use to align the thrust axis in directions other than the usual long axis of the aircraft.If you make the 2nd parameter equal, say 90.0, you're defining a thrust axis perpendicular to the aircraft longitudinal (z in MSFS) axis.We could use a bit of XML, or even better, "C" programming to make the engine interact with collective setting in the helicopters, for better torque yaw effects. Of course speed, etc.. should alo be taken into consideration...When I refer in my other post the huuge gyroscopic effects, I must point out that the problem is particularly evident in the R-22-based helis. In order to make these "stones" autorotate we have to tweak the FM. I use a combination of parameters, but usualy setting collective_on_rotor_torque_scalar = 0.8torque_scalar = 8.0drag_force_cf = 1.15side_drag_force_cf = 2.5pitch_damp_cf = -2.0roll_damp_cf = -2.0yaw_damp_cf = -2.0yaw_stability_cf = 0.15Weight_to_moi_factor = 0.80inflow_vel_reference = 38.0idle_rpm_friction_scalar= 0.7will do the job...You can play with the (inflow_vel_reference / Weight_to_moi_factor) "binary" to seek the characteristics that suite you better, but there will be no Rotor load in the R-22 model :-( BTW, rotor load is somehow modelled in the B206, and auto-rotation more acceptable than in previous versions...

[Guest Ron Freimuth]

>>Also the equations:>>>>Omega = g * TAN(Bank Angle) / TAS for a value in Radians, or>>>>Omega = 180 * g * TAN(Bank Angle) / (pi * TAS) for degrees>> >>assume the aircraft is in a coordinated turn which will not>>always be the case. For example, if an aircraft is making a>>wing-down approach in a cross-wind with opposite rudder the>>aircraft would be flying straight but the formulas would>show a rate of turn.>That's true, of course, but if you follow the first formula>suggestion, correcting the token variable "DELTA HEADING>RATE" or "TURN INDICATOR RATE" for the bank angle, then even>the Goose will perform standard rate turns... One can time a turn against the clock. The only sure approach. I noted the C172 in FlightGear displays less Yaw in turns. Further, the 'Ball' appears to work as I remember: it goes to one side in a slip. MS' Ball tends to center. One might take a look at the FlightGear source code to see what equations they use. I think elements of it can be found at the sourceforge site, meaning one wouldn't have to DL the FG source code. FG might have an accurate 'Ball' algorithm. I still don't understand why there is Yaw in a constant turn. I did find that reducing 'Dihedral Effect', Cl_beta, so an AC will stay in a banked turn isn't good. Reducing it a large amount in my C172N resulted in no Roll with Yaw. IOW, it acted as if there were no Dihedral. I did note that there is a Prop effect on the rudder in FS9, but not in FSX. Adding throttle yaws an AC more (in FS9), especially at low speeds. However, the Prop effects should also affect WeatherVane stability and Yaw Damping. Also, horiz tail components. I don't see any of these in FS9 (or FSX). FS2K2 was the last FS version with them all intact. Further, I see no effect of moving the Wing vertically(in aircraft.cfg). I had some idea that was true before. Seems the only safe way to get an accurate flight model (CoL and CG appropriate) is to set the Datum so it's at 1/4 MAC, 0, 0. Reference everything from that point, and change the empty CG as appropriate. Vertical CG has some effect on 'wing leveling'. A higher CG reduces the effect. I moved the Empty CG of my Cessna up by 1 ft to increase the tendency to stay in a bank (and, set Cl_beta back to the official value). Ron