Something is not correct because today it happened 6 times
300ft up … lvl off 300 feet down … in 5 minutes
This happened 6 times. In 2 x 2.5 hour flights.
A sudden jump somewhere i cannunderstand
But not up and down in 5 mins
1 Like
Yeah, but you don’t jump from 30.86 straight to 29.92 in a second and the aircraft giving you warning. Then flips back to 30.86 within a few nm.
I would expect changes in barometric pressure like this to be within 1 hPa at any given time on approach. You know, like 1013, then 1014, then 1013 again. Or in inHg unit to be 30.86, then 30.85, then 30.86 again.
Sure, if you depart on one place at 30.17 and your destinatiuon at 29.86 is very common. But you would only change this barometric pressure once. And any discrepancies at one place is generally very small amount.
FIFY
Altimeter setting easily changes even over a 1 hour flight. I’ll take off from Nashua, and by the time I get north of Manchester it could easily be different. It could even be different between Manchester and Concord which is a 15 minute flight. That’s why every time you talk to a new controller they tell you the pressure, and one reason it’s so important to listen to ATIS before you arrive at your airport.
I’m not seeing much of anything different in MSFS that I see in real life, other than the suddeness of the change.
Yes, its the SUDDENESS of the pressure changes that seems is Unrealistic, and should be addressed.
2 Likes
When transitioning from the model weather to actual airport METAR on approach, it will depend on how recent the model forecast is. All this past weekend, the Live Weather was providing forecast data that was at least 72 hours old. Live Weather was giving a much colder airmass than actually existed. On approach to DTW yesterday, I saw the temperature between 3000 feet AGL and landing go from -12C to + 10C (The latter temperature was correct)
Today, the Live Weather system appears to be back in sync, and the same flight has a much smaller change on approach.
1 Like
I started a voting topic for this issue following the release of v1.15.7.0 in which the release notes say this issue was fixed. Consider upvoting that post to indicate you also have this issue and Asobo needs to fix it.
Did they say they fixed the sudden pressure changes? I didn’t hear them say that.
I heard them say they fixed something about the barometric pressure settings in the gauges, but I assumed that was along the lines of the three barometric pressure registers and how the B key affects all three, but the altimeter and autopilot aren’t linked in the default gauges, so that can cause issues with the autopilot getting out of synch with the altimeter setting. Though, I haven’t looked to see what they fixed, and I don’t necessarily trust they actually did… And then it wasn’t clear to me it was fixed in this version, it sounded more like they said they fixed it and the fix will be in the next Sim Update (as opposed to the next World Update).
I think you are correct. The issue that was fixed related to issues with the altimeter had to do with autopilot altitude hold not working properly when the pressure was other than 29.92.
The issue in this thread is specifically a Live Weather problem - where the external pressure in the MeteoBlue model will suddenly change when flying at a constant altitude - instantly dropping or rising by several millibars.
2 Likes
The reason why Altitude Hold did /does not work, in say the C172 Steam, is because the AP is using the Pressure Reference from the TRANSPONDER, and not from the AP.
ie Adjusting the AP Baro make NO Difference to the AP altitude.
If However, you press the B button, all 3 baros get set, and then AP Altitude appears to work, because the B button also set the Transponder Baro – which it really should not, as the Transponder Baro “should” be fixed and calibrated on the ground by the Aero techs… NOT the pilot.
ie The Transponder should always display FLIGHT LEVEL, not actual ALTITUDE above mean sea level
It would hep a lot if the SDK defined which Baro Index, the Kernals AP code used !!!
I know this has been a problem for many MSFS users, but the underlying reason is not clear. In my own experience with MSFS flying many different aircraft, it has never happened to me - for other users it, it seems to happen on every flight with Live Weather active. On a recent Avsim post, a user flying the default Baron always saw the aircraft level at the 29.92 pressure altitude corresponding to his altitude selection. I flew the same aircraft, at the same location, and it worked perfectly every time. It worked whether I synced the altimeter by manually dialing in the current altimeter setting - or whether I auto-set it with the B key.
Yet, for the other guy, same airplane, same airport, it was definitely not working correctly - he made a video showing the effect.
A definite mystery.
you weren’t cruising at 18,000ft were you, as pressing B when above 18k will set 29.92 and if the barometric pressure is 30.86 in that area it could easily change back to that when you drop again, which might happen just by setting 29.92, if you see what i mean?
I don’t cruise at 18,000ft now, because of this, so 17,000ft or 19,000ft, to be well away from the transition altitude.
I’ve seen rapid changes at much lower altitudes, 3000-8000ft, for instance.
Again, it’s not the fact it’s changing that’s in question, that is normal, like where it might change from 29.96 to 29.97, and you may or may not catch the altimeter change slightly. I’ve seen the altimeter adjust by over 500ft on many occasions, indicating a large change in QNH.
Next time I catch this happening I will try to remember what it is set to before, and after I hit the B key.
No. I always cruise at 38/39,000 feet. I only press B when I’m under the trans altitude. When I’m above 18,000 feet I always pull the altimeter knob in my A320 to set to STD altitude, I never press B.
The altimeter jumps when I’m under 18,000 feet on approach. I press B when I passed the trans alt. and it’ll reset to 30.86… So I fly in that altimeter for a while, before suddenly, the Altitude warning alarming, and the altitude indicator shifts by about 500 feet in a milisecond. So I press B and the altimeter suddenly changes to 29.92 on the same altitude which is under 18,000 feet. I’m already on approach so this is even under 10,000 feet. Then after a few minutes of going through the STAR, the Altitude warning alarm goes off again, and it’s still shifts by 500 feet. So I press B again and it switches from 29.92 back to 30.86.
This isn’t normal behaviour. Altimeter shifts from one area or the next tend not to jump that much, should be a gradual differences, like it goes up/down by 0.01 for every difference in barometric pressure that you fly into. You don’t fly at 30.86 in one spot then take a step into another spot and it suddenly becomes 29.92 in the same low altitude.
1 Like
Fair enough. It was worth checking.
EXACTLY – in real world its a “gradual” change.
In MSFS 2020 it can be in instantaneous abrupt change – which is obviously incorrect – and leads to undesirable effects in the Sim.
The thing is for me … that i am flying this sim since day one … multiple flights per week. NEVER had this issue
After last update bingo
yes my frind - me to…
It’s not using the Baro from the Transponder. There are three (kind of) independent local Barometric Pressure “Indicated Altitude” registers. The AP uses the Barometric pressure stored in the “Indicated Altitude:2” register. The transponder gets its barometric pressure from register “Indicated Altitude:3” (instead of “Pressure Altititude” like it should be), and the Altimeter from register “Indicated Altitude:1”. These registers are independent of all gauges. They are just memory storage locations.
I say kind of independent because they are all changed by the B key. The B key updates all three registers to the local barometric pressure. Changing the Altimeter Kollsman changes the “Indicated Altitude:1” register, but leaves the other two alone. Hence, they all can get out of sync. The KAP140 does have an option so you can independently of the Altimeter change the “Indicated Altitude:2” register if you turn/press the right combination of buttons. Changing the Altimeter Kohlsman value has no effect on either “Indicated Altitude:2” or “Indicated Altitude:3” registers.
I have a modified Transponder that ignores the local Barometric pressure and just reports Standard pressure, as all Transponders are supposed to, if anyone is interested.
I agree that local Barometric pressure should not change as if you flew through a wall. It can change very quickly, it could be quite different over a distance of a few miles, but, it won’t just suddenly jump.
I suppose the issue is, at what point do you start a change in Barometric pressure, since reporting is likely by points as opposed to being able to look at say, an infrared satellite area map? How do you figure out where the changes occur, and how do you approximate an appropriate ramp? A change could happen anywhere between two points. I suppose you could just come up with a standard distance over which to make changes, maybe as a percentage of the distance between 2 points, and place the inflection point halfway between reporting points.
Here is where the KT76c Transponder gets its altitude reading from (instead of PRESSURE ALTITUDE like it should be. So I just replaced “INDICATED ALTITUDE:3” with “PRESSURE ALTITUDE”, and the Transponder acts as it should).
getAltitude() {
return SimVar.GetSimVarValue(“INDICATED ALTITUDE:3”, “feet”);
This is where the KAP140 gets its altitude information from. Note that it is using Register :2, and that it references the fact the KAP140 has its own Kohlsman setting (:2) independent of the Kohlsman setting of the Altimeter.
getBaroHPa() {
return (fastToFixed(SimVar.GetSimVarValue("KOHLSMAN SETTING MB:2", "Millibars"), 0)).replace(/\d+(?=(\d{3}))/, '$&,');
}
getBaroInHg() {
return fastToFixed(SimVar.GetSimVarValue("KOHLSMAN SETTING HG:2", "inHg"), 3);
}
getAltitudeDifference() {
return Math.abs(SimVar.GetSimVarValue("INDICATED ALTITUDE:2", "feet") - SimVar.GetSimVarValue("AUTOPILOT ALTITUDE LOCK VAR", "feet"));
This is where the Altimeter gets its altitude information from. Note that it basically sets the index (from this.altimeterIndex) to 1 after initializing it to 0. I couldn’t find any code where it would increment beyond 1. This is from the CommonPFD_MFD.js code.
class PFD_Altimeter extends NavSystemElement {
constructor() {
super(…arguments);
this.lastAltitude = -10000;
this.lastPressure = -10000;
this.lastSelectedAltitude = -10000;
this.selectedAltWasCaptured = false;
this.blinkTime = 0;
this.alertState = 0;
this.altimeterIndex = 0;
this.readyToSet = false;
}
init(root) {
this.altimeterElement = this.gps.getChildById(“Altimeter”);
if (this.gps.instrumentXmlConfig) {
let altimeterIndexElems = this.gps.instrumentXmlConfig.getElementsByTagName(“AltimeterIndex”);
if (altimeterIndexElems.length > 0) {
this.altimeterIndex = parseInt(altimeterIndexElems[0].textContent) + 1;
}
}
}
onEnter() {
}
onUpdate(_deltaTime) {
var altitude = SimVar.GetSimVarValue(“INDICATED ALTITUDE:” + this.altimeterIndex, “feet”);
var selectedAltitude = SimVar.GetSimVarValue(“AUTOPILOT ALTITUDE LOCK VAR”, “feet”);
if (altitude != this.lastAltitude) {
this.altimeterElement.setAttribute(“Altitude”, altitude.toFixed(1));
this.lastAltitude = altitude;
}
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.