Force VS Airpseed Profile ( Flaw)

[cmbaviator]

I noticed that the cls2sim software takes into account only the true airpseed instead of the IAS ( indicated Air Speed).

That shouldn’t be the case because it’s quite unrealistic, flaps, landing gear, airframe speed limit is given in IAS ( indepednant of the altitude)

Because if you climb for example at a constant speed, lets say 150kts IAS From 3000 ft to FL250, the force scale factor shouldn’t changed, that is the case currently because the software takes onto account the TAS, from 3000 to FL250, the IAS will remain the same but TAS will increase like 155 kt to 0.48M but the force applied on control surface should remain the same.

Is it possible to have in the futur an option to choose between IAS or TAS ?

[Diego Bürgin]

Hello folks

Diego here.

This problem has been on my issue list for a longer time and I’ve been asked about it from multiple people.
I’ve had a try at it multiple times unsuccessfully, so I’m reaching out to the community now.

What is the problem exactly?

CLS2Sim can read true and indicated airspeed from X-Plane.
(In fact, it can read any value that is in this List.)
Airspeed is used for force calculations, which affect the “Force Scalefactor”, a scaling value for the deflection force.

Indicated Airspeed:
+ It will scale according to air pressure, so dynamic loading using indicated airspeed would be correct.
– When failing the pitot tube, or any indicated airspeed related system in X-Plane, the indicated airspeed will fail also and controls will loose forces.

True Airspeed:
– It will not scale according to air pressure, so the further up you go, the more it will diverge from indicated airspeed.
+ it will continue to give reliable data, regardless of system failure in X-Plane.

So we have two factions of people. The faction wanting realistic dynamic forces, and the faction wanting to be able to simulate failures.
The easy solution would be to let people choose between TAS and IAS, we can have that in the next update, no problem.
But I’m sure we all agree that it would be nicer to have the correct behavior, even if it has to be somewhat simplified,
Or maybe a choice between IAS, TAS, and self calculated IAS?

Now I’ve tried to calculate indicated airspeed myself, but I just don’t arrive at the same or even similar values as I see in X-Plane.
So my question is to you people from the community:

Can you give me the concrete formula to get to indicated airspeed using the available data?
A simplified version that holds up to standard?
I am willing to experiment. I can upload different versions to try out.

The constraint is, that all variables in that formula would have to be available from Datarefs:
http://www.xsquawkbox.net/xpsdk/docs/DataRefs.txt

For example I have the barometric pressure at the point the current flight is at:
sim/weather/barometer_current_inhg

I have the true airspeed in m/s:
sim/flightmodel/position/true_airspeed

I can read the density of the air in kg/cubic meters:
sim/weather/rho

Here’s one of the formulas I tried to implement:
https://aviation.stackexchange.com/questions/25801/how-do-you-convert-true-airspeed-to-indicated-airspeed
(In the first link got stuck on the correction variable “Ki” as I didn’t find it in the Datarefs.
As a last measure, we could give you an expert option, where you enter that variable yourself. But meh. Not happy with that.)

And here’s another one:
https://aviation.stackexchange.com/questions/42793/why-does-indicated-airspeed-change-with-altitude

Want to see the datarefs live in X-Plane, their actual values during flight?
Use this plugin: http://www.xsquawkbox.net/xpsdk/mediawiki/File:DataRefEditor_12-11.zip

So here are my cards. What do you think?

EDIT:
Proposals to test:

Gradual change from IAS to TAS on failure using LP filter.

Regards
Diego

[cmbaviator]

Diego

For me the software uses only the TAS speed for force scaling which is wrong in my opinion.

If you climb/descent at a given Speed (IAS) the force on the yoke should remain the same, it is not the case currently.

Try climbing at the constant speed (IAS), you will see that the force scaling number will increase instead of remaining the same (because as it climbs, the TAS increases even though the IAS remain constant.

A simple fix is just to get the current IAS of the aircraft instead of the TAS of the aircraft.

Edit
Brunner told me by mail that it will be fixed in the next update. ( I just noticed that it was you Diego that replied to me.

I think the software should read this : sim/aircraft/view/acf_Vso float y kias Various speed maxes for the aircraft.

KIAS is for calibrated IAS I think, if that’s correct, that’s what the software should read instead of TAS. I dont think you need to convert, couldn’t Xplane nor P3D give you already the data for the IAS or KIAS ?

[cmbaviator]

or maybe this one : sim/aircraft/view/acf_asi_kts int y enum air speed indicator knots calibration I think this data is the KIAS

EDIT:

I didn’t read carefully enough Diego. As suggested in my mail, just give the option to the users and maybe put a text about pros an con of either choice

[Diego Bürgin]

Testing sim/aircraft/view/acf_asi_kts now.
EDIT: sim/aircraft/view/acf_asi_kts stays at 1 for all planes. Seems to be an enum from the description. Will look further into it.

As for the change, I had changed to indicated airspeed, but have held back the release because the change introduced a new bug.
Namely that failures on the pitot tube will kill the forces on the yoke.
So I am trying to get a better solution from the community,
before I allow choosing between TAS and IAS as a last solution.

[cmbaviator]

I see.

Maybe a compromise could be that if a pitot tube failure is detected, the software reverts back to TAS ?

[Diego Bürgin]

Failure detection is possible, but switching from IAS to TAS during flight will result in a step response in forces, the yoke would kick at the pilot.
A short detection delay would mean a short twitch where the yoke becomes weightless, ideally there would be none.
A low-pass filter to disallow sudden changes, would smooth over the change.

The final result of force change would be the red line in the attachment.

I added it to the experimental test release list.

Attachments:

You must be logged in to view attached files.

[cmbaviator]

looks like a nice compromise, any ETA when the update will be available ?

[hamsammich]

Interesting behind-the-scenes info.

As to pitot failure, how you arrive at your calculations is less important to me than having the yoke behave identically before and after said failure. And, for the record, I do understand it’s far easier to be a user than a programmer. Your work is appreciated!

[Diego Bürgin]

I can’t give you an ETA at this time.
We will first see how many proposals we gather.
Then we’ll have to internally discuss the feasibility and implementation time of each.

[cmbaviator]

it will behave differently as after the pitot failure it will take into account the TAS instead of IAS

[hamsammich]

So why, with 4.14, did I experience what I experienced? e.g. pitot failure killing yoke forces? Apologies. Now I’m a little confused. And, yeah, I will be taking a written exam on all this at some point. 🙂

[Diego Bürgin]

I just checked in the sources, and downloaded and tested the released CLS2Sim 4.14 from our website.
It is using true airspeed and is not affected by pitot failure.
You’re on the newest X-Plane?

@hamsammich: Did I give you a prerelease/beta using indicated airspeed? (The version number would have a b at the end.)
I’ll contact you and we’ll have a look at it.

[cmbaviator]

ther’e is a beta version of the update ?

[Diego Bürgin]

It’s simply a version using indicated airspeed instead of true airspeed.
But as described, it will completely kill any forces on the yoke on pitot failure.
I have implemented it simply to internally test behavior of force when changing altitude and to observe the difference between TAS and IAS.
It was never intended to be released in its current form.

This was more like “oh ****, did I accidentally give that version out to someone?” because his description matched the behavior of this test version.
But luckily nothing of that sort happened, (I checked with him), So I’m not only being paranoid but also going senile 😉

There IS a beta out, but not about this feature.
It’s a beta that allows the newest version of Zibo mod to support the Autopilot feature of Brunner devices.
See here:

Yoke won't move when autopilot is engaged in the Zibo mod in XP11

[Author]

Posts