MSFS & Altitude issue on STD barometer

[chanchu81]

Hello John,

Have you received any bug of MSFS2020 about altitude on 29.92 / 1013 or when the altimeters is in STD?

We use the offset 0574 that reads well the altimeters in any FS old version or Prepare3d but in MSFS2020 it doe shows a difference +-1500 fts.

look at the attachment:

Microsoft Flight Simulator 2020
Airbus A320 NEO
The SUR Acars windows is the app developed by my team using the 0574 offset to record the altitud. but as you see when the Sim is in FL400, the SUR Acars is reading FL410.

Do you know how can we resolve it?

[John Dowson]

15 hours ago, chanchu81 said:

Have you received any bug of MSFS2020 about altitude on 29.92 / 1013 or when the altimeters is in STD?

For MSFS bugs, you should check the Asobo forums. There have been many issues with incorrect altitude over the past year, and I am not sure of the current status of these. For example, here are a few (older ones): 
     https://forums.flightsimulator.com/t/altimeter-problems-altitude-hold-and-atc-altitude/433209
     https://forums.flightsimulator.com/t/help-with-incorrect-high-altitude-altimeter-setting/429439/4

Your image is also showing a setting of 30.16 inhg, and not 29.92...interesting, I have not seen that altitude config panel before, I will take a look...

15 hours ago, chanchu81 said:

We use the offset 0574 that reads well the altimeters in any FS old version or Prepare3d but in MSFS2020 it doe shows a difference +-1500 fts.

Offset 0x0574 just holds the value if the PLANE ALTITITUDE simvar received from MSFS. The altimeter reading (indicated altitude) is held in offset 0x3324, so you could try that offset.

John

 

[chanchu81]

Thank you John, 
I just wanted to bring it here to check if someone had similiar issues.
I will use 0x3324 then

Santiago

[John Dowson]

1 minute ago, chanchu81 said:

I just wanted to bring it here to check if someone had similiar issues.

Sure, no problem. This does seem strange - I will look into this further when time allows...maybe someone else has noticed this and can respond?

John

[NaMcO]

Might be a bit late to the party, but currently flying at FL360, STD in the altimeter and reported altitude by my ACARS (through FSUIPC7) is 37440ft. Same altitude on the IVAO map which is reported by the IVAO client, presumably using SimConnect.

Latest version of MSFS obviously.

[mtjoeng]

Isn't this how it should be (almost)?
MSFS shows the STD altitude
while actual pressure is 30.16 and actual altitude is 41232
So before your ACARS recorded from P3D/FSX an adjusted output that transmitted (ATC) FL
Now you either need to find a new output from MSFS that transmits FL
or you have to calculate the FL from the true pressure altitude
I'd say?

On 2/14/2022 at 8:13 PM, chanchu81 said:

The SUR Acars windows is the app developed by my team using the 0574 offset to record the altitud. but as you see when the Sim is in FL400, the SUR Acars is reading FL410.

 

[NaMcO]

@John Dowson I opened a new topic because this one seemed kind of "abandoned" and it was not my own question. But i do agree it is related, so...

Question from the other topic:

Hello,

Is it possible, with the current values provided by MSFS, to calculate the actual altitude the aircraft is flying in? I am currently flying at FL360 and the reported altitude through the regular offsets is way off (37342ft at the moment). Sometimes it's even bigger.

I understand that MSFS has a whole different (better) model of the atmosphere, so is there a way to read all the required data to calculate the "correct" altitude we're flying at? I am sorry but this is a very grey area for me, altitude calculations with pressure, temperature and the such make me "dizzy", so any help is appreciated.

Thank you!

[John Dowson]

This has not been "abandoned"...

There is Plane Altitude, held in offset 0x0570:

Quote

Altitude, in metres and fractional metres. The units are in the high 32-bit integer (at 0574) and the fractional part is in the low 32-bit integer (at 0570). [Can be written to move aircraft] (Read offset 6020 for easier conversion!)

and also Indicated Altitude held in offset 0x3324:

Quote

This is the altimeter reading in feet (or metres, if the user is running with the preference for altitudes in metres), as a 32-bit signed integer. Please check offset 0C18 to determine when metres are used (0C18 contains ‘2’). The same value can be calculated from the actual altitude and the difference between the QNH and the altimeter “Kollsman” pressure setting, but this value ensures agreement.

These offsets just hold the values as received from the FS. If the altitude reported in the offsets is 'way off', then this is an issue for Asobo - FSUIPC just reports/stores this data as received from MSFS.

Check the Asobo forums - there are many reports on altitude issues, for example, see the following:

    https://forums.flightsimulator.com/t/incorrect-altimeter-readout/479399
    https://forums.flightsimulator.com/t/if-qnh-is-lower-than-983-altitude-is-shown-incorrectly/470898
    https://forums.flightsimulator.com/t/temperature-and-altitude-reporting-are-not-fixed-with-the-patch/431354

Note there are also two additional altitude simvars which are not held in FSUIPC offsets:

PLANE ALT ABOVE GROUND

Altitude above the surface

PLANE ALT ABOVE GROUND MINUS CG

Altitude above the surface minus CG

If those are of interest, they can also be added to FSUIPC offsets - see the Advance User guide.

John

[NaMcO]

7 hours ago, John Dowson said:

These offsets just hold the values as received from the FS. If the altitude reported in the offsets is 'way off', then this is an issue for Asobo - FSUIPC just reports/stores this data as received from MSFS.

Check the Asobo forums - there are many reports on altitude issues, for example, see the following:

Thanks, just wanted to make sure this was something that had to be addressed (or not) on the Asobo side. Since it is, i'll just wait until they fix it.

[NaMcO]

I read that the Vpilot client developer solved the issue in some way, but i cannot find any information about what he did in order to get the proper altitude from MSFS. I can read the aircraft corrected altitude which usually translates to 35000 38000 or 32000 depending at which altitude you're flying, but this is still not the actual altitude the aircraft is flying at.

Is there really no other way except to "do the math" and get the altitude? Does FSUIPC even have all the required offsets for these calculations? I'm sorry, but i'm a complete newbie regarding altitude calculations with pressure and temperature on the mix, so this is why i'm asking.

Thanks!

 

[John Dowson]

Have you tried using the Pressure Altitude simvar (offset 0x34B0) instead of the Plane Altitude (offset 0x0570)? There is a long discussion on this problem here: https://forums.flightsimulator.com/t/vatsim-ivao-pilotedge-users-be-aware-of-an-important-bug/426142/451 (as well as those other links I preciously posted), the last comment being:

Quote

You should find out from the developer of Smartcars just what altitude variable they are accessing. They are probably using “plane altitude,” which is the airplane’s true altitude. Post-SU5, when using live weather, the airplane’s true altitude will be a function of the pressure lapse rate. At least for cruise altitudes above the transition altitude, they should consider using pressure altitude (same as flight level) since that is what the airplane should be flying. There may still be some issues with MSFS-reported pressure altitude (due to pressure spikes and some small errors in the pressure vs altitude relationship), but it should work okay for determining if the cruise flight level has been reached.

Or they can just use indicated altitude throughout and just depend on the pilot to be using the right baro setting. This would then agree with what the pilot sees.

I don't think you should be doing your own calculations to determine the correct altitude... With vPilot 3.3, they recommend using indicated altitude with the altimeter set correctly - see https://forums.vatsim.net/topic/31832-altitude/page/2/.

John

[John Dowson]

Note also that there is a new(ish) MSFS simvar INDICATED ALTITUDE CALIBRATED, documented as Indicated altitude with the altimeter calibrated to current sea level pressure. You could add that simvar to a free FSUIPC offset and see if that holds the value you need. If so, you can then spoof the value of any other altitude offset using that value (using FSUIPC's spoofing facility at offset 0x0024) for 3rd party programs that need that value in a specific offset.

John

 

[NaMcO]

On 8/3/2022 at 11:57 AM, John Dowson said:

Note also that there is a new(ish) MSFS simvar INDICATED ALTITUDE CALIBRATED, documented as Indicated altitude with the altimeter calibrated to current sea level pressure. You could add that simvar to a free FSUIPC offset and see if that holds the value you need. If so, you can then spoof the value of any other altitude offset using that value (using FSUIPC's spoofing facility at offset 0x0024) for 3rd party programs that need that value in a specific offset.

John

 

I guess this is the solution. I will look into this, and report back for anyone interested. Thanks a lot for your input John.

[John Dowson]

3 hours ago, NaMcO said:

guess this is the solution. I will look into this, and report back for anyone interested. Thanks a lot for your input

No problem. I think that simvar would be useful for many people, so I will add it to a fixed offset in the next release.
Let me know how it goes.

John

[NaMcO]

Hello again,

This is definitely the SIMVAR to read as it holds the calculated altitude based on pressure (or so it seems). I am reading it to 0x2544 and obtained the presumably correct values for a test of FL300 350 and then 380 with PMDG's 737.

0x2544, 4, INDICATED ALTITUDE CALIBRATED,I32, Feet, w (although i don't think it is writable, nor do i need it - just copied for a test)

So, thanks a lot for adding it to a fixed offset, it will be very useful indeed!

Nuno

 

[John Dowson]

19 hours ago, NaMcO said:

although i don't think it is writable

No, it isn't. FYI, I will add this simvar to offset 0x0590 (4 bytes). If you update to use that offset, you can just remove the line that adds that once I have released.
If you like, you can test this already in the attached version (which I haven't tested yet!):

FSUIPC7.exe

John

[NaMcO]

Thanks a lot John. I have tested it and 0x0590 is returning the desired values. Awesome!

Meanwhile i have tested this simvar some more in longer flights and the altitude is indeed correct. Now if only all other developers start using it for IVAO and so on, everyone will once again be synchronized 😊

[Wim Soldaat]

Dear John and Nuno,

I have the same msfs altitude problem when on IVAO and have read this topic with interest.  How can I use this simvar/code in FSUIPC?  I have FSUIPC7 and WIDEFS.  I appreciate all your efforts!

Edited September 28, 2022 by Wim Soldaat

[John Dowson]

If you cannot change the offset that the IVAO client is using to read (0x0574) the altitude, you can spoof the offset to the value of this new offset (0x0590) using FSUIPC's spoofing facility at offset 0024.. To do this, you need an auto-running lua script. I have attached a similar spoofing lua script that some folks use for the FBW A320 parking break - you should be able to adapt this to your needs. You need to adapt to read the offset value (as opposed to the lvar value that he script currently uses)  of the new offset, update the spoofOffset and adjust the type/size of the value being spoofed from 1UW to 1UD

John

A320ParkBrake.lua

[Wim Soldaat]

John, thank you for your quick response. But, I am sorry to say, this all goes far beyond my capabilities as a simple user.

Today I flew the PMDG 737 at FL380 on STD QNH. Reported ALT via IVAO Webeye was 36850 ft. Local QNH was 1005 HPA, climbed to FL380 in cockpit,  but IVAO still reported me too low. To get to the correct FL on IVAO I had to lower the QNH to 980 HPA (and climb again).   So until a simple sollution is found I am stuck checking my altitude via IVAO and adjust accordingly. Or fly an incorrect FL on STD. Or go back to X-plane.

Kind regards,

Wim

[John Dowson]

First you need to find out what IVAO is using to determine the altitude. I suggest you try monitoring offsets 0x0574 (as S32) which is the Plane Altitude in meters, and also offset 0x0590 (also as S32) which is the Indicated Altitude Calibrated in feet.  First, monitor those offsets using FSUIPCs offset monitoring facilities to see if the indicated altitude is the one that you need.

If the latter is holding the correct value, then you can spoof offset 0x0574 to the value of offset 0x0590 converted to meters. I have attached a script that does this for you - to use it, save it to your FSUIPC7 installation folder and auto-start it by adding it to your [Auto] (or profile specific [Auto.xxx] section) as follows:

Quote

[Auto]
1=Lua calibratedAltitude

If IVAO is not getting the altitude from that offset, maybe ask them how it is getting the altitude...I cannot support IVAO, sorry. Maybe also raise a bug/request with IVAO to ask them  to use this calibrated value.

John

calibratedAltitude.lua

 

[Wim Soldaat]

John, I will do this and test the results.

Thanks a lot,

Wim

[Capt. PERO]

@Wim Soldaat have you fixed this issue with this workarround? We are faceing the same with JeeHell FMGS in MSFS on VATSIM. Next step would be finding out, which variable VATSIM is using to determine the altitude.

[John Dowson]

10 hours ago, Capt. PERO said:

Next step would be finding out, which variable VATSIM is using to determine the altitude.

Or find out which offset it is using, if it is getting this value from an FSUIPC offset. You can then spoof the value of the offset it is reading to read the correct value from a different offset, using the facilities provided at offset 0x0024. There is a lua example plugin provided that shows you how to do this, called liar.lua.

John

[Capt. PERO]

Thanks John. I found out, that JeeHell FMGS shows the value of 0x6020 for Altitude Indicated.

But so far no luck by writing this into the sim to affect VATSIM. This is my code but the value of Altitude in VATSIM stays untouched...

ipc.writeStruct(0x0024, "1UW",  0x0574, "1UW", 4, "1SD", ipc.readDBL("6020"))