MSFS & Altitude issue on STD barometer

[John Dowson]

On 9/20/2024 at 5:09 AM, Capt. PERO said:

This is my code but the value of Altitude in VATSIM stays untouched...

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

Maybe try converting the double from offset 0x6020 to an int before writing it to 0x0574:

-- Loop till flag 0 is set
while ipc.testflag(0) == false do
    ipc.writeStruct(0x0024, "1UW",  0x0574, "1UW", 4, "1SD", math.floor(ipc.readDBL("6020")))

    -- Sleep for 50 mSecs so the update gets done roughly 20 times per second
    ipc.sleep(50)
end

-- Now undo the overrides (otherwise they'll take about 12 seconds to die, with frozen values provided!)
ipc.writeStruct(0x0024, "1UW", 0x0574, "1UW", 0)

Also try logging offset 0x0570 as an SIF64, and also 6020 as a FLT64 in FSUIPC. Aren't these values more or less the same anyway (especially the integer component? Note the original value will be logged, not the spoofed value. Are you sure VATSIM is reading the altitude from 0x0570/0x0574 (i,e, does that match what VATSIM shows)?

Edited September 21 by John Dowson
corrected

[John Dowson]

Please also see this (long) thread on this issue: https://forums.flightsimulator.com/t/vatsim-ivao-pilotedge-users-be-aware-of-an-important-bug/426142/398

An important comment is this one (quite old now):

Quote

Please read the previous messages. 3rd party apps like VATSPY use “plane altitude,” regardless of airplane altitude. This will not match your indicated altitude. except for below the transition altitude when you have the baro set per the sim’s QNH and the pressure gradient is the ISA standard pressure gradient.

Below the transition altitude, the controller will see you at the same altitude indicated by VATSPY, which will likely be different than your indicated altitude. (Below the transition altitude, VATSIM also uses the simulation variable “plane altitude.” ) Above the transition altitude, VATSIM uses the simulation variable “pressure altitude,” and in that case, the altitude they see you at should agree with your indicated altitude (assuming you set STD/29.92/1013.2 on your baro). Your airplane’s true altitude compared to airplanes from other sims will be different, however, for the same flight level.

VATSIM will be changing the way they do the altitudes as described in a post above. However, that work is on hold until a bug in how altitudes are reported through SimConnect is fixed.

and also one of the last comments on that thread:

Quote

I think the core issue here is a misunderstanding of what the problem is. It sounds like there’s an assumption that some kind of data is faulty or being forwarded incorrectly to VATSIM, and thus there is something erroneous inside the sim itself that needs repair or is broken. However, neither of those things is true. I understand you’re not particularly interested in hearing why that isn’t the case, but I think it’s worth attempting to understand, as it does have real world pilot impact, which is why the atmosphere model was updated. I would like to also stress that the exact same set of issues laid out below also hold true of the XP12 atmospheric and altimetry model.

I’ll try and take you through the whole situation, to better explain what is happening here.

Historically, all ATC clients read a value called PLANE ALTITUDE. This value was the exact geometric altitude above the earth. This previously was safe to use, as in an exactly ISA atmosphere (which all simulators could only model to this point) the geometric altitude and the indicated altitude are identical if the altimeter is correctly calibrated.

However, in reality, temperature and pressure effects cause errors in altimetry. These are especially relevant to pilots in cold weather conditions on approach where you can see in some charts that you may have increased minimums, as cold weather can make the altimeter read higher above the ground than you actually are, which can be disastrous if not accounted for properly. These effects were missing from the sim prior to the altimetry model update.

As a result of this, the PLANE ALTITUDE value (which was never the indicated altitude, as a reminder, but reasonably safe to use before) does now usually not match the altimeter indication. I cannot stress enough, this is not a bug, but a feature. Real altimeters act in exactly the same way.

To allow third party developers to read the correct data depending on their use case, there are a few values which can be used instead:

• INDICATED ALTITUDE: The altitude currently shown on the cockpit altimeter
• CALIBRATED ALTITUDE: The altitude that would be shown on the cockpit altimeter if the altimeter was always perfectly calibrated
• PRESSURE ALTITUDE: The altitude that would be shown on the cockpit altimeter if the altimeter was set to 29.92inHg.

In a real ATC environment, there is no equivalent of PLANE ALTITUDE (pure geometric altitude). The fact that this worked OK before is merely because the sim’s atmosphere model was incorrect and simplified. Instead, in real life ATC receives the pressure altitude from the plane’s transponder unit, and corrects that using the local QNH, showing the corrected value on the scope if under the transition alt, or the pure pressure alt if above it. It is 100% possible for third party clients to accurately do this by reading the PRESSURE ALTITUDE data value and it has been possible since the altimetry and atmosphere model update.

However, there is a wrinkle here, and it isn’t caused by MSFS. VATSIM, IVAO, PilotEdge and the like also have to support mixed simulations, which include mixed atmosphere simulations: in other words clients with totally different environmental and altimetry sims need to coexist under the same ATC. There are now two classes:

• Sims that are only capable of simulating an ISA atmosphere, for which the geometric alt is safe to use (FSX, P3D, XP11, XP10)
• Sims that can simulate non-ISA atmospheres, for which the geometric alt is very much not safe to use (MSFS, XP12)

Things get even more complicated when you realize this additional wrinkle: the ability to use non-ISA atmospheres means that if two people are not using the same weather, their altimeters may be reporting the same value for two entirely different places in space. I’ve actually talked at great length with the developer of vPilot and the PilotEdge client about this tricky issue, and as you can imagine, there’s no one single perfect technical solution to this issue from the client side. I’ll demonstrate why:

Let’s pretend there are two planes from different simulators both coming in to KTEX RNAV 9Z at 13000 feet. The OAT is -5F/-20C (it got that cold last year). You’ll notice the warning here in the chart regarding the required temperature correction:

image1894×512 120 KB

 

Let’s assume both simulators have calibrated their altimeters to local QNH. One simulator can only do ISA atmospheres, so one client’s plane reports PLANE ALTITUDE at exactly 13000. The other simulator can do non-ISA atmospheres, so reports PLANE ALTITUDE at 12335ft. They both have the same INDICATED ALTITUDE value of 13000 feet. Where do you place each plane? There are three locations to consider:

• Where does the non-ISA plane appear in the ISA sim?
• Where does the ISA plane appear in the non-ISA sim?
• Where do either plane appear on the ATC client?

There are a lot of unhappy options. You can place both planes at their geometric altitudes in all three locations, but this has some problems:

• If the ATC client scope is doing the proper QNH correction, then the ISA plane appears to be ~700 feet high. If it isn’t doing that, then the non-ISA plane appears to be ~700 feet low.
• The expectation of both pilots in each simulator who locally have correct QNH is that they would have 0 feet of vertical separation, but instead they have ~700 feet.

You could just stick each plane at their INDICATED ALTITUDE. But wait, this also has some issues:

• If the pilots have the wrong QNH they still appear as if they’re at the right altitude on the ATC client scope, because they’re both at 13000 feet indicated.
• If the pilots have the wrong QNH then they should have some vertical separation but would show visually in each respective simulator that they do not

Furthermore, the non-ISA plane is actually closer to the ground and is experiencing the effects that require altitude correction. If the ISA plane attempts to do that altitude correction, it will be flying at too high an altitude. So, there isn’t a totally straightforward answer as to how to support totally incompatible atmospheres or weather settings from the third party developer side. One plane is almost 1000 feet closer to the ground in these conditions, which can’t just be ignored or waved away.

VATSIM and PilotEdge have done the best possible compromise they can here, which is using an algorithm that weights the separation between planes highly on the simulator client side, so should show planes at roughly the correct vertical separations to each other’s clients as they get closer to each other. If third party ATC decided to drop support for ISA-only sims and also force everyone to somehow download the exact same weather, then these differences between clients would nearly vanish, but that’s not really a practical answer.

Therefore, you end up with the situation that exists today: old ISA-only sims must be catered to and worked around with these types of algorithms, and different weather settings in non-ISA capable sims can still wreak havoc with no clear and perfect solution for placing the aircraft in space in the ATC client.

 

So this looks more to be an issue with the clients that use this data, and I am not sure a fix for this in FSUIPC is appropriate as it may break other things/clients- should probably be fixed in the clients themselves, e,g. VATSIM.

I will talk to Pete as he may have some ideas as to anything that can be done in FSUIPC.

John

[John Dowson]

Maybe also check-out/log the value of offset 0x0590 (INDICATED ALTITUDE CALIBRATED), but note that this is in feet and not metres. Is that correct, both below and above transition level?

I am thinking I could maybe add a new ini parameter than when set would switch the value held in 0x0570/0x0574 to use either INDICATED ALTITUDE CALIBRATED (currently held in 0x0590 in feet) or INDICATED ALTITUDE (held in 0x3324 in either feet or metres, depending in the value held in offset 0x0C18) instead (in same units and format) of the current PLANE ALTITUDE. I don't think I should be using an AP/GPS altitude for this though...what are your thoughts on this?
e,g, either

   PlaneAltitudeSwitch=Indicated  -- this would switch the simvars held in offsets 0x0570 and 0x3324, preserving the current format of both offsets
or
   PlaneAltirudeSwitch=Calibrated -- this would switch the simvars held in offsets 0x0570 and 0x0590, preserving the current format of both offsets

(maybe also PlaneAltirudeSwitch=GPS to use - but maybe not switch with - GPS POSITION ALT currently held in offset 0x6020)

I can look into adding this parameter for you to try over the weekend, if you think that would help - check those offsets and let me know.

John

 

[John Dowson]

On 9/20/2024 at 5:46 PM, John Dowson said:

I don't think I should be using an AP/GPS altitude for this though...what are your thoughts on this?

I can also allow for:
     PlaneAltitudeSwitch=GPS
to switch 0x0570/0x0574 with the GPS altitude in offset 0x6020. In fact, this is probably the only sensible option.

And rather than switching the offsets, i think I will just change the simvar used for offset 0x0570/0x0574 and leave the other offset as-is.

[John Dowson]

On 9/20/2024 at 11:14 AM, John Dowson said:

Maybe try converting the double from offset 0x6020 to an int before writing it to 0x0574:

-- Loop till flag 0 is set
while ipc.testflag(0) == false do
    ipc.writeStruct(0x0024, "1UW",  0x0574, "1UW", 4, "1SD", math.floor(ipc.readDBL("6020")))

    -- Sleep for 50 mSecs so the update gets done roughly 20 times per second
    ipc.sleep(50)
end

-- Now undo the overrides (otherwise they'll take about 12 seconds to die, with frozen values provided!)
ipc.writeStruct(0x0024, "1UW", 0x0574, "1UW", 0)

Could you try spoofing from 0x0570 instead of just 0x0574, i.e.

-- Loop till flag 0 is set
while ipc.testflag(0) == false do
    gpsAlt = ipc.readDBL(0x6020)
    ipc.writeStruct(0x0024, "1UW",  0x0570, "1UW", 8, "1UD", math.floor((gpsAlt - math.floor(gpsAlt))*65636*65636), "1SD", math.floor(gpsAlt))

    -- Sleep for 50 mSecs so the update gets done roughly 20 times per second
    ipc.sleep(50)
end

-- Now undo the overrides (otherwise they'll take about 12 seconds to die, with frozen values provided!)
ipc.writeStruct(0x0024, "1UW", 0x0570, "1UW", 0)