Some values from A2A aircrafts are off

[Passero]

I'm trying to write an advanced logging system that monitors most values on an airplane.

For example, I'm currently working on the engine performance monitoring and I'm tracking things like prop RPM, oil pressure, temp, manifold pressure and so on. 

I notice that when I try an a2a plane like the cessna 182, some values are not correct. 
For example the engine RPM (0898 and 08C8). For the build in cessna and the carenado the RPM value is spot on however for the a2a cessna it's off.

I notice the same for oil temperature. Again, build in and carenado are spot on.

Does anybody if this is just not supported for a2a planes or is there another way to obtain the correct values.

I do notice that the values I get from FSUIPC are following the same trend so if I would plot the values, they trends would be accurate. Only the absolute values are not accurate.  

[Pete Dowson]

Perhaps those A2A aircraft implement their own subsystems rather than using FS's built in ones. A lot of add-on aircraft do that (PMDG, some Aerosoft ones, FSL), primarily because they cannot get the model accurate enough or realistic enough using FS's own code.

The values in the standard FSUIPC offsets are those provided by SimConnect and they are the ones FS knows about. If they disagree with whatever is shown on the add-ons gauges then either the relevant system is being simulated separately, or, in order to get the desired performance, they are being "fiddled" internally and the gauge values adjusted to show what the values should be rather than what they really are.

I guess the only way you'll find out which and why would be to ask A2A. They should know the answers!

Pete

 

[Gypsy Baron]

Pete is correct in that A2A Accu-Sim aircraft systems are coded outside the realm of FSX in a great many cases.  Some of the simulation uses the default FSX functions but anything to do with the physics of flight or engine performance is most likely done within the Accu-Sim code.

In those cases, use of the appropriate L:Vars (local variables) might be required to monitor items of interest.

 

 Paul

[Passero]

Paul,

Thanks for this, I did some research and found a PDF with the local vars published by A2A however I cannot seem to find any info how to obtain those values through FSUIPC. 

[Pete Dowson]

24 minutes ago, Passero said:

I cannot seem to find any info how to obtain those values through FSUIPC. 

If you know the names of the L:vars you need, with any recent version of FSUIPC you can read L:Var values through offsets -- see offset 0D70 in the Offsets Status List document.

If you first need to discover the names, there's a Lua plug-in provided which monitors L:Vars and logs/displays them as they change, and an assignable FSUIPC control which lists the names and values at any time you invoke it.

Pete

 

 

[Passero]

Great, thanks! So I first have to write the name of the value to 0D6C after which I have to read  0D70  to obtain the value. Any examples on doing this? I'm using the .net DLL version.

Also, for future reference. Here's a list for the a2a c182 I found on the a2a forum: https://www.dropbox.com/s/iiwpwa594k6zbhm/A2A C182 Skylane - Variable list.pdf?dl=0#
Might be useful for people who want to do a similar thing. 

[Pete Dowson]

2 hours ago, Passero said:

So I first have to write the name of the value to 0D6C after which I have to read  0D70  to obtain the value.

No, no! How are you reading that? The name of the L:Var is a string and could be quite long, so it will never fit into the 4-bye 0D6C location! As it says, it's the number of the user offset where the value is written from or read to which goes there -- the name goes into the 40 byte area at 0D70. Please read whht it says more carefully. it is explicit!

2 hours ago, Passero said:

Any examples on doing this? I'm using the .net DLL version.

It's just writing values and strings, as for any other FSUIPC interfacing task. I'm sorry, but i don't use the .Net DLL, my only languages are C and ASM>

Pete