Elevators/gload offset and newest versions

[jeehell]

Hi,

I just upgraded to the new FSUIPC versions (4.60a to 4.70b and 3.98 to 3.99).

As you maybe know/remember, I developed a FBW software. Since upgrading, my soft does not want to work correctly under FSX, but it still works correctly in FS9.

So I was wondering if you had introduced any change in the handling of any of the following offsets, that might differ under FS9 and FSX:

- Elevators $0BB2

- Elevator trim $0BC0

- g-load $11BA

(by the way, I just noticed you were off until the 9th, enjoy your holiday!)

Regards,

Jean Luc

[Pete Dowson]

So I was wondering if you had introduced any change in the handling of any of the following offsets, that might differ under FS9 and FSX:

- Elevators $0BB2

- Elevator trim $0BC0

- g-load $11BA

No, they are still exactly as they were. In FSUIPC4 offset 0BB2 is derived directly from the SimConnect variable "ELEVATOR POSITION", 0BC0 is "ELEVATOR TRIM PCT", and 11BA is "G FORCE". Use FSUIPC4 logging -- or better, monitoring, to see. If you Monitor those to the normal log it will also show the SimConnect values explicitly.

Regards

Pete

[flugerpel]

Hi Pete,

thank you very much for FSUIPC. It makes developing for MSFS a lot easier.

I am also working on a project which includes a A320 FBW. As we only recently switched from FS9 to FSX, I encountered the same problems as jeehell described them. We also calculated the g-force via the vertical acceleration. There is definitely a difference between FS9 and FSX in regard to that. In an older thread I found your hint to use the logging function of FSUIPC as it also shows the original SimConnect value.

I analysed the original value and found out that the resolution is better than the value supplied through the offset 11BA. I suggest to supply the original SimConnect value through the offset 30D0 as FLT64. It contained the g-force as FLT64 for FS2000 and is since then no longer used.

I would be glad to read your opinion.

Regards,

Steffen.

[Pete Dowson]

As we only recently switched from FS9 to FSX, I encountered the same problems as jeehell described them.

Er, which were, exactly? He never explained even after I told him there were no changes on my side. I find it quite frustrating when folks complain about something, with no details, then just disappear. How can things ever be fixed or improved like that?

He also said the changes were on both FS9 and FSX, just between different versions of FSUIPC despite me not changing anything in regard to those offsets.

We also calculated the g-force via the vertical acceleration There is definitely a difference between FS9 and FSX in regard to that.

No one has ever documented what units offset 11BA was in. I tried to make the FSX one compatible to those preceding it. If you know more about this I'd be grateful if you could reveal the secret. I only arrived at the value to place in 11BA by experimentation and comparisons with FS9. You are saying i made a mistake? If so, what, please?

I analysed the original value and found out that the resolution is better than the value supplied through the offset 11BA. I suggest to supply the original SimConnect value through the offset 30D0 as FLT64. It contained the g-force as FLT64 for FS2000 and is since then no longer used.

No, 30D0 should be the vertical acceleration. That surely is not the same as G-force -- the largest G-forces in most flying are those in tight curved flights with steep back. G-forces may be in any direction, not just vertical.

If you need the raw value from SimConnect I'll find a different offset for it. But I'd like you to explain the difference between FS9 and FSX with respect to 11BA, because I tried to make it compatible and you have me concerned now.

Regards

Pete

[flugerpel]

Hi Pete,

Er, which were, exactly? He never explained even after I told him there were no changes on my side. I find it quite frustrating when folks complain about something, with no details, then just disappear. How can things ever be fixed or improved like that?

No complain from my side. I just observed the same behaviour as he described in another thread. My post may have been better placed at the original thread by jeehell to this topic.

He also said the changes were on both FS9 and FSX, just between different versions of FSUIPC despite me not changing anything in regard to those offsets.

What did we do. In FS2004 there was no g-Force value available which we could use to create the Airbus typical flight control which is, at least for the pitch, a load based control. So we used the vertical acceleration from the offset 3068 and calculated the vertical load (in g's) by our own. This worked very well in FS2004. Now we switched to FSX and the same code, without any changes, did not work anymore and the reactions of the plane were completely erratic. This seems to be related to the value FSX now provides through offset 3068 (vertical acceleration in ft/sec/sec relative to the body axes).

No one has ever documented what units offset 11BA was in. I tried to make the FSX one compatible to those preceding it. If you know more about this I'd be grateful if you could reveal the secret. I only arrived at the value to place in 11BA by experimentation and comparisons with FS9. You are saying i made a mistake? If so, what, please?

I do not think that you made a mistake. If my post suggested that I apologize. I think that the value FSX provides through offset 3068 is slightly different even though it still is the vertical acceleration relative to the body axes. This leads to a situation where the derived g-Force is decreasing even though one is pulling at the stick which should lead to an increase. As our solution worked in FS2004 I never tested the value provided through offset 11BA. I started testing it in FSX due to our problems.

No, 30D0 should be the vertical acceleration. That surely is not the same as G-force -- the largest G-forces in most flying are those in tight curved flights with steep back. G-forces may be in any direction, not just vertical.

As we always used the acceleration values in reference to the body axes for our flight control solution, we only had to use the vertical one. The programmers manual in regard to the offset 30D0 does not state if it is referencing world or body axes. It was just a suggestion, any offset is okay.

If you need the raw value from SimConnect I'll find a different offset for it. But I'd like you to explain the difference between FS9 and FSX with respect to 11BA, because I tried to make it compatible and you have me concerned now.

I am sorry Pete. I cannot explain the difference of this offset. All I can tell is, that, when using the value from the offset 11BA in FSX, my flight control reacts almost in the same way as it did in FS2004 using the g-Force derived from the offset 3068. Almost, because du to the rounding the resolution of the value is not high enough to be used by a flight control software. That's why I suggested to provide the original SimConnect value through another offset.

I will do some analysis on the offset 11BA in FS2004 and FSX to see if it behaves similar and report back to you.

Thanks for your response and best regards,

Steffen.

[Pete Dowson]

What did we do. In FS2004 there was no g-Force value available which we could use to create the Airbus typical flight control which is, at least for the pitch, a load based control. So we used the vertical acceleration from the offset 3068 and calculated the vertical load (in g's) by our own. This worked very well in FS2004. Now we switched to FSX and the same code, without any changes, did not work anymore and the reactions of the plane were completely erratic. This seems to be related to the value FSX now provides through offset 3068 (vertical acceleration in ft/sec/sec relative to the body axes).

So, is the value in 3068 the wrong value? Have you determined what the differences are? (Sorry, I thought it was a difference in 11BA which concerned you).

I think that the value FSX provides through offset 3068 is slightly different even though it still is the vertical acceleration relative to the body axes.

Only "slightly" different? But enough to result in completely erratic behaviour? I don't understand how that could be classified as 'slight'. ;-)

This leads to a situation where the derived g-Force is decreasing even though one is pulling at the stick which should lead to an increase.

So, is the "slight" difference a matter of sign? Does the sign need reversing?

As we always used the acceleration values in reference to the body axes for our flight control solution, we only had to use the vertical one. The programmers manual in regard to the offset 30D0 does not state if it is referencing world or body axes. It was just a suggestion, any offset is okay.

Okay. I'll find one. But I'd like to know if we had the wrong mapping for 3068 in FS9 and before, or SimConnect is providing the wrong value for this in FSX. Can you tell? Most of the values in FS9 and before were discovered or confirmed by Hervé Sors, and I've always relied on him for things like this which are all beyond my understanding of FS.

Regards

Pete

[Pete Dowson]

Okay. I'll find one.

Not on general release yet, but try FSUIPC 4.749g

Offset 0x1140, double, G-Force direct from SimConnect.

Regards

Pete

[flugerpel]

So, is the value in 3068 the wrong value? Have you determined what the differences are? (Sorry, I thought it was a difference in 11BA which concerned you).

Only "slightly" different? But enough to result in completely erratic behaviour? I don't understand how that could be classified as 'slight'. ;-)

I did some testing and visualized it. Sorry for the quality but 20k upload is not enough.

The red line is the altitude (in feet).

The blue line is the load in g from offset 11BA.

The green line is the load in g derived from the offset 31C8 (sorry I mixed them up, we did in fact use the vertical acceleration relative to world axes).

After visualizing it I have to admit that the difference is not so slight. The diagrams above are very clear. While in FS9 the value from 11BA correlates almost exactly with the value derived from 31C8, in FSX this is no longer the case. So you can imagine that a controller depending on the g-force as control value behaves completely different.

I did a further analysis and also visualized the value from offset 3068. This value seems to be identical in FS9 and FSX. But the value from 31C8 in FSX is different than the value in FS9. How the value is calculated in FS9 I cannot tell but in FSX the value from 31C8 is a mirror from the value in 3068.

So, is the "slight" difference a matter of sign? Does the sign need reversing?

If you reverse the value from 31C8, it would be nearly identical to the value from 3068.

Okay. I'll find one. But I'd like to know if we had the wrong mapping for 3068 in FS9 and before, or SimConnect is providing the wrong value for this in FSX. Can you tell? Most of the values in FS9 and before were discovered or confirmed by Hervé Sors, and I've always relied on him for things like this which are all beyond my understanding of FS.

In my opinion the value from FS9 is correct. At least it provides a value which is plausible. I have no idea why the value 31C8 from FSX is different from the one in FS9 as it should be the same thing. As a cross-check I also derived the vertical acceleration from the vertical speed and the result was the same. So I think that FSX/SimConnect itself is the source of the problem and not a wrong mapping in FSUIPC.

I also already tested the new version you provided. Thank you very much! The value is ok. The only thing is, that it changes only once a second while at the same time the derived value 11BA changes approximately 20 times a second. Do you have an idea why?

To summarize: I think the offset 3068 is ok in both sims. The offset 11BA is ok in both sims. The offset 31C8 is ok in FS9 but different in FSX.

Thanks for your effort and best regards,

Steffen.

[Pete Dowson]

The diagrams above are very clear. While in FS9 the value from 11BA correlates almost exactly with the value derived from 31C8, in FSX this is no longer the case.

Hmm. You are better at understanding them and correlating them visually that I, then, as there seems only more detail in FSX, not much difference in where things go up or down. But i bow to your knowledge in this over mine.

I also already tested the new version you provided. Thank you very much! The value is ok. The only thing is, that it changes only once a second while at the same time the derived value 11BA changes approximately 20 times a second. Do you have an idea why?

I'll check. I might have put it with the wrong data group. I have different update rates for different things.

To summarize: I think the offset 3068 is ok in both sims. The offset 11BA is ok in both sims. The offset 31C8 is ok in FS9 but different in FSX.

Hmm. Shame. Maybe i could have done something about that if it had been pointed out a few years ago. Maybe applications have become dependent on the 'wrong' value now.

Regards

Pete

[flugerpel]

Hi Pete,

I am still thinking about the offset 31C8. There is definitely an error in the FSX value SimConnect provides. For comparison I calculated the vertical acceleration from the vertical speed. This calculated value is different from the FSX value SimConnect provides through 31C8, but it is equal to the one FS9 provides through 31C8.

I have an idea I want to test. Maybe there is a way to correct that. I am looking into it. If I find a solution I let you know.

Regards,

Steffen.

Edited December 13, 2011 by flugerpel

[flugerpel]

Hi Pete,

I suspect the following. Microsoft made an error in SimConnect with the vertical acceleration relative to world axes. In FS9 they provided the vertical acceleration in ft/sec/sec available through the FSUIPC offset 31C8. In FSX they provide a value which can be best described as the acceleration of the vertical acceleration. The unit would then be ft/sec/sec/sec. I corrected for that error and calculated the vertical acceleration based on the time interval provided by FSX. The result shows a curve which is similar to the vertical acceleration calculated from the vertical speed but is to much offset in some areas. The error seems to accumulate over time.

For FSUIPC 4 (I guess it is FSX only?) I suggest to derive the value for offset 31C8 from the vertical speed to remain compatible with FS9. I can't imagine that someone is using the wrong value as it is, in my opinion, of no use. On the other hand, I cannot be sure. I guess it is your call.

Best regards,

Steffen.

[Pete Dowson]

I am still thinking about the offset 31C8. There is definitely an error in the FSX value SimConnect provides

Herve Sors seems has been checking things and last I knew he believed 31C8 is correct, but thinks that the G-Force supplied by SimConnect (the one I use for 11BA and soon 1140) is suspect. I must admit they both look good to me!

For FSUIPC 4 (I guess it is FSX only?) I suggest to derive the value for offset 31C8 from the vertical speed to remain compatible with FS9. I can't imagine that someone is using the wrong value as it is, in my opinion, of no use. On the other hand, I cannot be sure. I guess it is your call.

I am getting conflicting advice at present. We'll see. I'll pass on your opinion to Herve.

I'm not really wanting to do any complex time-based conversions like the one you suggest in any case. Scaling and so on, yes, but nothing like what you ask.

Regards

Pete

[flugerpel]

Herve Sors seems has been checking things and last I knew he believed 31C8 is correct, but thinks that the G-Force supplied by SimConnect (the one I use for 11BA and soon 1140) is suspect. I must admit they both look good to me!

I am getting conflicting advice at present. We'll see. I'll pass on your opinion to Herve.

I am interested to hear Herve's opinion and how he came to the conclusion.

I will try to do a reproducable test, so it is easier to compare the results from the two sims. But currently the only value which does not add up for me is 31C8. When looking at the visualized values It is easy to see the difference. When I am successful, I can provide an excel file to you to pass on to Herve.

Did you have the chance to check on the update rate of 1140? Please, do not feal pushed. I would just like to test it's impact on my flight control application. I guess the value will be perfect as the results using 11BA are already very good.

I'm not really wanting to do any complex time-based conversions like the one you suggest in any case. Scaling and so on, yes, but nothing like what you ask.

Ok. Then I guess the value will have to remain that way, as I don't think that MS will update SimConnect. Except maybe with the next installment (MS Flight). The vertical acceleration value can still be calculated on the application side.

Just out of curiosity. In FSUIPC you are always passing through the original value? At max you are multiplying or dividing with a constant?

Regards,

Steffen.

[Pete Dowson]

I will try to do a reproducable test, so it is easier to compare the results from the two sims. But currently the only value which does not add up for me is 31C8. When looking at the visualized values It is easy to see the difference. When I am successful, I can provide an excel file to you to pass on to Herve.

He is doing similar, it will days a couple of days or so, he says.

Did you have the chance to check on the update rate of 1140?

FSUIPC 4.749i will be up later today. I am working on something else but I'll release that later in the week, probably as 4.751.

Just out of curiosity. In FSUIPC you are always passing through the original value? At max you are multiplying or dividing with a constant?

It's a straight copy of the 64-bit double which arrives from SimConnect as "ACCELERATION WORLD Y" in ft/sec^2 units. Same applies to 31C0 ("ACCELERATION WORLD X") and 31D0 ("ACCELERATION WORLD Z"). You can check that of course using the Monitor in FSUIPC. If you list the offset in the table on the right-hand side of the Logging tab, as FLT64, and check "normal log" below, FSUIPC not only logs changes to the offset but also the SimConnect input, including name, of the related variable(s). If you check "console log" too, and run FSX in Windowed mode, you can see it all in real time.

[LATER]

Okay, get FSUIPC 4.749i

Regards

Pete

[herve_sors]

Gentlemen,

It seems there could be a problem regarding values FSX reports regarding world based accelerations (and/or speeds but it seems it concerns mostly accelerations). Apparently, it is not due to the way FSUIPC report them as far as they are mapped from the ACCELERATION WORLD X, Y and Z Simconnect values and some users using a direct Simconnect access already reported similar problems..See here

http://www.fsdeveloper.com/forum/showthread.php?t=23526

Some tests I performed (see graphs) using a standardized flight protocol for calculating reported averaged FS accelerations (eI) versus calculated accelerations from speeds (aI) over 250 ms intervals from FSUIPC mapped offsets show that:

- There are major discrepancies between calculated vs reported world X, Y and Z accelerations

- It is not the case for FSX body accelerations (at least Iy that was the one I tested)

- It is also not observed for FS9 using the same protocol and FSUIPC offsets

The reason for such discrepancies is still unknown. It could be due to some changes MS implemented for world reference axes but probably not to the way accelerations are aerodynamically defined. As so, I don't think we could imagine FSX reports an "acceleration of acceleration" as far as, AFAIK, this concept is still unused and physically unknown

Whatever it may be, any relationship between Vertical world based acceleration (FSUIPC 0x31C8) and G-force/G-load cannot be easily interpreted, considering ACCELERATION WORLD Y may not have the same meaning in FS9 and FSX. Additionally, we do not know how FS calculates G-Force as reported by SimConnect and FSUIPC but it certainly doesn't depend only on the vertical world acceleration but also on other forces that apply on other axes (for ex, a steep turn, or a longitudinal acceleration will increase it while vertical acceleration will still be 0). Consequently any comparison between G-Force / Vertical world acceleration in FS9 and FSX is probably not possible by now.

Detailed numerical results can be provided on request (email me for that)

Hervé Sors

[flugerpel]

Okay, get FSUIPC 4.749i

Thank you very much. I will test it as soon as possible.

Best regards,

Steffen.

[flugerpel]

Hello Hervé,

The reason for such discrepancies is still unknown. It could be due to some changes MS implemented for world reference axes but probably not to the way accelerations are aerodynamically defined. As so, I don't think we could imagine FSX reports an "acceleration of acceleration" as far as, AFAIK, this concept is still unused and physically unknown

Don't get me wrong. I don't think that MS did that on purpose. Such a value does not make sense and, as you said, is unknown to physics. I just think they made an error and the value has been divided by the time span one time too often. This can be visualized when "playing with the numbers". The only thing is I had to change the sign. But this is only a hunch. Your analysis showed perfectly that there is a difference between FS9 and FSX, whatever the reason is.

Additionally, we do not know how FS calculates G-Force as reported by SimConnect and FSUIPC but it certainly doesn't depend only on the vertical world acceleration but also on other forces that apply on other axes (for ex, a steep turn, or a longitudinal acceleration will increase it while vertical acceleration will still be 0).

You are correct. In a steep turn you would still get 1g which is of course not correct, but It is sufficient for a FCTL system as an Airbus for example has attitude protections (bank, pitch) which would prevent steep turns and excessive pitch angles. The value we are looking for is the value of the quotient between the lift and the weight. The weight is easy, but to calculate the lift you have to know some factors, like air pressure, relative speed and some values which are depending on the wing geometry. I am not sure if MS really calculates it that way. I will do some tests. Maybe it is possible to deduce the value in some way, to see how MS did it.

Regards,

Steffen.

[herve_sors]

Agree Steffen..

The value we are looking for is the value of the quotient between the lift and the weight. The weight is easy, but to calculate the lift you have to know some factors, like air pressure, relative speed and some values which are depending on the wing geometry. I am not sure if MS really calculates it that way

yes indeed..but be sure it is feasible from the 3/6 DOF body plane vectors although it is mathematically complicated. From comparisons I performed between aerodynamical ( that is the result of speed/acceleration vectors on the 3 z,x, y axes and forces that apply on them that are weight, thrust and gravity) and modelized lift and drag data (from aircraft data and tables), I can tell you MS did it the right way. Probably a bit difficult to build a simple gauge for that unless you use what MS provides "as a final result"

Whatever it may be, we should probably continue investigating and reporting, although it is not really FSUIPC related

Hervé

[flugerpel]

Hi Hervé

I can tell you MS did it the right way. Probably a bit difficult to build a simple gauge for that unless you use what MS provides "as a final result"

It is currently not possible to read some required values from the aircraft.cfg via FSUIPC. At least I was not able to find one. So I will not follow that road for the time.

I also think that the g-force value MS provides is correct as all tests showed plausible results. From my point of view (Airbus Flight Control System) I will use this value in the future as reference. I just have to wait until Pete releases the version with the corrected interval for the new offset 1140.

Merry Christmas and a Happy New Year 2012,

Steffen.

[Pete Dowson]

I just have to wait until Pete releases the version with the corrected interval for the new offset 1140.

That was corrected several releases back and is certainly okay in the current interim version 4.754 released on the 21st December.

Regards

Pete

[flugerpel]

Thank you Pete,

I realised a few days later that you already uploaded a corrected version to the download section.

Regards,

Steffen.

That was corrected several releases back and is certainly okay in the current interim version 4.754 released on the 21st December.

Regards

Pete