Jump to content
The simFlight Network Forums

Offset 31C8 FS9/FSX


jeehell
 Share

Recommended Posts

Hi Peter,

For my A320 FBW, I need to control the vertical flight path through the g-load.

Since the usual g force offset is not accurate enough (the documentation clearly states that the unit and all is unknow), I decided to go the physics' way and calculate myself the vertical G load from the Y-axis acceleration in the world axes (offset 31C8).

I then use the formula: yGload=1+Yaccel/32.2 to convert ft/s/s to relative g's.

This actually works really great under FS9 where I get good results (When I compare to the usual Gload offset, with bank angle=0, I get almost the same value).

However under FSX I have had no luck at all!!!

Any idea? My first thought was that either in FSX it gets data in another reference axes, or the unit of the data is different (It seems it's not m/s/s would it be the case)...

Thanks in advance,

JeeHell

Link to comment
Share on other sites

Since the usual g force offset is not accurate enough (the documentation clearly states that the unit and all is unknow)

It's unknown to me. I don't know about others. For nearly all of the technical stuff in offsets I've always been dependent upon what other folks tell me. Because in FS9 and before folks said that dividing the value in 11BA by 625 gave good results, that's what I documented.

In FSX and ESP SimConnect provides a variable called "G FORCE", and that is what I provide in offset 11BA, but to keep compatibility with FS9 and before, I multiply the value supplied by FSX by 625. So at least the FSX copy will be "accurate". If you can reproduce exactly the same G-force conditions in FS9 and FSX then comparing them should show how good the FS9 one is.

I decided to go the physics' way and calculate myself the vertical G load from the Y-axis acceleration in the world axes (offset 31C8).

I then use the formula: yGload=1+Yaccel/32.2 to convert ft/s/s to relative g's.

This actually works really great under FS9 where I get good results (When I compare to the usual Gload offset, with bank angle=0, I get almost the same value).

However under FSX I have had no luck at all!!!

Any idea? My first thought was that either in FSX it gets data in another reference axes, or the unit of the data is different (It seems it's not m/s/s would it be the case)...

It's ft/sec/sec, as documented, not m/sec/sec.

The value there is from the SimConnect variable "ACCELERATION WORLD Y". I've been advised by others that is compares correctly to the same thing in FS9, so I'm not sure what you're getting. The Simconnect SDK states this variable is: "Acceleration relative to earch, in vertical direction, Feet per second squared" (including the typo in Earth).

Regards

Pete

Link to comment
Share on other sites

In FSX and ESP SimConnect provides a variable called "G FORCE", and that is what I provide in offset 11BA, but to keep compatibility with FS9 and before, I multiply the value supplied by FSX by 625. So at least the FSX copy will be "accurate". If you can reproduce exactly the same G-force conditions in FS9 and FSX then comparing them should show how good the FS9 one is.

That's good to know, I will test it right away.

However I can assure you in FS9 it's not even near accurate during level flight coordinated turns, where the total G load would be 1/cos(phi) with phi being the bank angle.

It's ft/sec/sec, as documented, not m/sec/sec.

that I know, but since I had different results, I thought the unit could have changed and tried the first obvious unit after ft/s/s so the metric m/s/s...

The value there is from the SimConnect variable "ACCELERATION WORLD Y". I've been advised by others that is compares correctly to the same thing in FS9, so I'm not sure what you're getting. The Simconnect SDK states this variable is: "Acceleration relative to earch, in vertical direction, Feet per second squared" (including the typo in Earth).

Well in my case at least it does not compare...

I will do some tests and will try to give you figures to corroborate my experimentations...

regards,

Jean Luc

Link to comment
Share on other sites

I use FSX SP2

I had a thought. If I'm correct, FS9 uses a flat Earth model when FSX uses a spherical model, maybe that would be a cause for the little discrepancy?

I cannot get good figures because the errors seems to appear only when the actual g load is different from 1g, so on level flight it cannot be observed, and with elevator deflection it's hard to have the same experiment conditions in both simulators...

What is weird, is that the sign of the 31C8 offset seems to change (i.e. when it should be negative it becomes positive but stays positive when it should be negative, and sometimes it is however correctly signed??).

Regards,

JL

Link to comment
Share on other sites

Ok I can give you a protocol to see what's wrong with offset x31C8:

Keep the wings level and monitor the formula I gave you (G=1+Yaccel/32.2) along with the FS Gforce which you can show inside FS (shift+Z twice)

Under FS9, both values should be strictly the same (except for the rounding indeed), when in FSX they do differ a lot, especially when you pull/push the stick fully forward/backward.

Thanks for your help.

Link to comment
Share on other sites

Ok I can give you a protocol to see what's wrong with offset x31C8

It's no good to me, really. All I can do is provide what FSX gives me. If it is wrong, if it is a bug in FSX, then I would need some expert, maybe yourself, to give me the correction factor or formula.

In the past I've tried to check what I am providing against the values saved in the FS FLT files. i.e. these, in the [simVars.0] section:

PVelBodyAxis

BVelBodyAxis

HVelBodyAxis

XVelBodyAxis

YVelBodyAxis

ZVelBodyAxis

PAccBodyAxis

BAccBodyAxis

HAccBodyAxis

XAccBodyAxis

YAccBodyAxis

ZAccBodyAxis

PVelWorld

BVelWorld

HVelWorld

XVelWorld

YVelWorld

ZVelWorld

But FS doesn't appear to save instantaneous values for World-relative accelerations. I suppose with some spherical trig you could derive them from the saved values though and compare the result with the values SimConnect is providing me.

Regards

Pete

Link to comment
Share on other sites

It seems that in FSX, as you said, the 11BA offset is indeed accurate. So I decided to go that way, even if it's a little bit less accurate than my previous method.

I'm however quite sure that the FSX simconnect data concerning the world Y-axis is corrupted somewhere, it's a real shame.

Thanks for your help anyway.

JL

Link to comment
Share on other sites

It seems that in FSX, as you said, the 11BA offset is indeed accurate. So I decided to go that way, even if it's a little bit less accurate than my previous method.

I'm however quite sure that the FSX simconnect data concerning the world Y-axis is corrupted somewhere, it's a real shame.

Well if you have a way for me to correct it before mapping to the offset, let me know please. If it can be accurately derived from the other accelerations (which surely it must be?) then maybe that's what I should do? Though since it needs to be a frequently updated value I wouldn't want any resulting performance degradation.

Regards

Pete

Link to comment
Share on other sites

Actually I tried to get the world axes acceleration from the body axes acceleration, using rotation matrices, but to no avail...

Since my maths are pretty rusty now, I probably did it the wrong way though...

Another solution would be to actually derive the acceleration from the velocity (in the world axes), but I didn't try this one.

If I have time in the upcoming weeks, I will dig further down in my maths books, and if I'm successful, I'll let you know of course.

As for the performance issue, you only can tell what is acceptable or not...

Regards,

JL

Link to comment
Share on other sites

  • 6 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.