flugerpel

Thank you Pete, I realised a few days later that you already uploaded a corrected version to the download section. Regards, Steffen.

Hi Hervé 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.

Hello Hervé, 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. 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.

Thank you very much. I will test it as soon as possible. Best regards, Steffen.

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. 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.

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.

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.

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. If you reverse the value from 31C8, it would be nearly identical to the value from 3068. 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.

Hi Pete, 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. 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). 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. 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. 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.

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.