[Elevators/gload offset and newest versions]

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

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

Okay, get FSUIPC 4.749i

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

Best regards,

Steffen.

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

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.

[Elevators/gload offset and newest versions]

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.