MSFS 1.15.8.0 wrong climb to altitude with Live weather

[vonmar 121]

I do not know about other tests.

My first post showed the runway altitude that I see in the Baron when the baro is set to 29.92 at KSEA.

Anyone doing the same test (Baron , no tweeks, I am not using LittleNavMap / nothing in Community folder) should see the same reference altitude (given near same conditions).

Now if 5 people are testing 5 planes (or different planes) they should see the same. But do they? Is the problem with all planes or just some planes?

And,  if they climb to a test altitude like in my post they should see the same error as I indicated.

My test was just an example test which would be easy to do and verify.

 

Have you tried the test in my first post just to verify the numbers and climb to altitude error?

 

Note:

Your post that you edited/removed is still present in the post I quoted from you for reference if you need to look back.

 

Edit : Here is a copy of my first post so you do not have to return to the first post several pages back.

MSFS 1.15.8.0 wrong climb to altitude with Live weather

 

Example test:

KSEA with MSFS ATIS reporting 30.12 
with altimeter set to 29.92 at runway altimeter reads 230’
with altimeter set to 30.12 at runway altimeter reads 420’
Note: The difference is 190 feet


Baron or Citation Longitude Baro set 30.12
Autopilot armed altitude 3000 feet 
e.g., set V/S to 800 feet per minute
Aircraft does not stop at 3000 feet continues to 3190 feet

190 feet too high.

 

 

 

 

Edited April 18, 2021 by vonmar
added my original post for a quick reference here

[marsman2020 1,310]

I'm satisfied at this point and not going to spend any more time on this, having spent over an hour already. 

For all the Garmin aircraft I tested, the altimeter adjusts correctly with the baro knob and the AP stops leveling off based on the altimeter, for all reasonable conditions with Live Weather on. 

I'd suggest reviewing some real world documentation on how altimeters work.

 

Edited April 19, 2021 by marsman2020

[JRBarrett 3,034]

3 hours ago, vonmar said:

KSEA with MSFS ATIS reporting 30.12 with altimeter set to 29.92 at runway altimeter reads 230’ with altimeter set to 30.12 at runway altimeter reads 420’ Note: The difference is 190 feet Baron or Citation Longitude Baro set 30.12 Autopilot armed altitude 3000 feet e.g., set V/S to 800 feet per minute Aircraft does not stop at 3000 feet continues to 3190 feet 190 feet too high.

I understand exactly what you are saying. For you, the altitude capture function is acting as if it was (internally) always referenced to 29.92, despite what the actual ambient pressure (as injected by Live Weather) might be.

If ambient pressure is higher than standard, the aircraft would level off too high. If ambient pressure was lower than standard - the aircraft would level off too low.

Unfortunately, like others here in the thread, I cannot duplicate this. I just spawned at KSEA 16L in the default Baron with the default G-1000. I set pressure to ambient (which at the moment is 30.07), set a preselected altitude of 3000 feet, and took off on runway heading, with a vertical speed of 900 FPM, and the aircraft leveled off at 3000 feet indicated exactly.

I do believe you are seeing exactly what you report - and you are not the first person to report this - but I have no idea why your specific installation would do this.

From my work on the CRJ project, as well as a r/w avionics tech, I do know that the default Asobo autopilot G1000 altitude hold function is linked directly to the indicated altitude on the PFD (as is the altitude hold in a real Garmin G1000). If you select 3000 feet, the aircraft will level at 3000 feet indicated altitude no matter what the actual pressure altitude might be.

Your true altitude of course depends on having the correct current barometric pressure set - if you did not (in a real airplane), ATC would notice the discrepancy.

Your installation acts as if the altitude hold is linked to the transponder’s mode C encoder, which is indeed set to a fixed reference pressure of 29.92 at all times. If this happened in a real aircraft, I’d suspect that something was mis-wired.

Are you using the stock Asobo Baron, with the stock G-1000? 

Did you try syncing the altimeter to current pressure by pressing the “B” key, rather than manually adjusting the baro set knob?

Do you have any other add-on aircraft installed, or any of the Working Title Garmin mods? In the CRJ project, there was at least one customer whose CRJ had some instrument malfunctions because of the presence of the WR CJ-4 in the community folder, but the problem disappeared after reinstalling both aircraft.
 

 

 

 

Edited April 19, 2021 by JRBarrett

[vonmar 121]

6 hours ago, JRBarrett said:

I understand exactly what you are saying. For you, the altitude capture function is acting as if it was (internally) always referenced to 29.92, despite what the actual ambient pressure (as injected by Live Weather) might be.

If ambient pressure is higher than standard, the aircraft would level off too high. If ambient pressure was lower than standard - the aircraft would level off too low.

Unfortunately, like others here in the thread, I cannot duplicate this. I just spawned at KSEA 16L in the default Baron with the default G-1000. I set pressure to ambient (which at the moment is 30.07), set a preselected altitude of 3000 feet, and took off on runway heading, with a vertical speed of 900 FPM, and the aircraft leveled off at 3000 feet indicated exactly.

I do believe you are seeing exactly what you report - and you are not the first person to report this - but I have no idea why your specific installation would do this.

From my work on the CRJ project, as well as a r/w avionics tech, I do know that the default Asobo autopilot G1000 altitude hold function is linked directly to the indicated altitude on the PFD (as is the altitude hold in a real Garmin G1000). If you select 3000 feet, the aircraft will level at 3000 feet indicated altitude no matter what the actual pressure altitude might be.

Your true altitude of course depends on having the correct current barometric pressure set - if you did not (in a real airplane), ATC would notice the discrepancy.

Your installation acts as if the altitude hold is linked to the transponder’s mode C encoder, which is indeed set to a fixed reference pressure of 29.92 at all times. If this happened in a real aircraft, I’d suspect that something was mis-wired.

Are you using the stock Asobo Baron, with the stock G-1000? 

Did you try syncing the altimeter to current pressure by pressing the “B” key, rather than manually adjusting the baro set knob?

Do you have any other add-on aircraft installed, or any of the Working Title Garmin mods? In the CRJ project, there was at least one customer whose CRJ had some instrument malfunctions because of the presence of the WR CJ-4 in the community folder, but the problem disappeared after reinstalling both aircraft.
 

 

 

 

Hello,

I did a short KSEA departure / climb to 3000 feet video for your review.

I will paste the link to the video into this post.

https://youtu.be/OlU9RIGqrpI

 

 

 

[JRBarrett 3,034]

8 hours ago, vonmar said:

Hello,

I did a short KSEA departure / climb to 3000 feet video for your review.

I will paste the link to the video into this post.

https://youtu.be/OlU9RIGqrpI

 

 

 

No question that you are having the issue that you report, but I have no idea why this happens on your installation. My default Baron under the identical scenario levels at exactly 3000 feet indicated -  and will do so no matter what pressure is set in the altimeter setting.

This is really a question for the MSFS official forums, or Zendesk. For some reason your altitude hold function is locked to 29.92 as a reference pressure - which I can only theorize indicates something is corrupt in your MSFS installation - or it is an unwanted/unexpected interaction with another add-on. The latter possibility could be eliminated by insuring that all add-ons (either commercial or freeware) are fully uninstalled. Especially any aircraft with custom autopilots or any weather-related add-ons like Rex or unreal weather. Also, you would want to insure that developer mode is not active.

[vonmar 121]

43 minutes ago, JRBarrett said:

No question that you are having the issue that you report, but I have no idea why this happens on your installation. My default Baron under the identical scenario levels at exactly 3000 feet indicated -  and will do so no matter what pressure is set in the altimeter setting.

This is really a question for the MSFS official forums, or Zendesk. For some reason your altitude hold function is locked to 29.92 as a reference pressure - which I can only theorize indicates something is corrupt in your MSFS installation - or it is an unwanted/unexpected interaction with another add-on. The latter possibility could be eliminated by insuring that all add-ons (either commercial or freeware) are fully uninstalled. Especially any aircraft with custom autopilots or any weather-related add-ons like Rex or unreal weather. Also, you would want to insure that developer mode is not active.

When you are MSFS KSEA, default Runway, MSFS Live weather with standard pressure setting (29.92) when the flight first loads [before any changes] what is the altitude reading?

Which version of MSFS are you using?

Edited April 19, 2021 by vonmar
additional question.

[JRBarrett 3,034]

6 hours ago, vonmar said:

When you are MSFS KSEA, default Runway, MSFS Live weather with standard pressure setting (29.92) when the flight first loads [before any changes] what is the altitude reading?

Which version of MSFS are you using?

Version 1.5.0.8

I didn’t pay exact attention to the altitude before I synced the altimeter, but it was around 200 feet. This is not a generic MSFS problem but something specific to your installation. Do you have any add-on aircraft or other utility programs? This is critical, because it is the only thing I can think of that might cause this issue.

Nobody here at Avsim is going to be able to solve this issue, because nobody else is seeing this problem with the Baron at KSEA. This is really a question for the official MSFS forums or Zendesk, though I fully understand that you really do not get much in the way of support there.

[Av8ing1 46]

No idea what's going on but thought I'd mention this just in case. At one point awhile back and not in the Baron, my aircraft autopilot would hold above or below the altitude selected. I realized that I had not set the standby altimeter to the correct local setting, it was at standard 29.92, so I adjusted it. The autopilot then held the correct altitude as displayed on the PFD. The autopilot was using the standby/secondary altimeter setting and thus the error. Now I set both instruments, like you are supposed to and have not had a problem. No idea if this is the case on the G1000 in the Baron. I think I was flying the A320. Obviously this condition is not normal. Must have been a bug, I have not tested it of late. 

[vonmar 121]

7 hours ago, JRBarrett said:

Version 1.5.0.8

I didn’t pay exact attention to the altitude before I synced the altimeter, but it was around 200 feet. This is not a generic MSFS problem but something specific to your installation. Do you have any add-on aircraft or other utility programs? This is critical, because it is the only thing I can think of that might cause this issue.

Nobody here at Avsim is going to be able to solve this issue, because nobody else is seeing this problem with the Baron at KSEA. This is really a question for the official MSFS forums or Zendesk, though I fully understand that you really do not get much in the way of support there.

Jim,

Thanks for providing your test results and additional technical information on the possible causes of my reported problem.
Thanks also to all forum members providing their test results and technical information.
Much appreciated.

To answer your questions:
I have a default MSFS install.
As previously mentioned, nothing in the Community folder.
Long time ago I tested FSUIPC and Navigraph. Not currently using either.
No add-on aircraft or other utility programs.

Anything specific I could check in MSFS to see if anything strange is floating around in my setup?
If so I will have a look see.
So far all seems very normal on my test flight. No odd errors or CTD.


Additional follow up:

On April 13, 2010 (a week prior to posting in this forum) I posted the problem in MSFS forum.

So far I could not draw a positive conclusion from one forum member’s replies. But he basically said he was not having the same problem.

A second members reply was : 
“Done your test and can confirm I experienced the same issue.
I believe it’s caused by manually adjusting the Baro instead of using the B key.”

A third members reply was:
“Verify this happened on my machine–been this way since Store purchase.
Very annoying.
Later: Input latest Working Title G-1000 and retested–yep still fails to follow armed level.”


Replies form two members in this topic :

Ryan (ryanbatcund) reported:
“This has been happening since alpha.
Plane will climb to whatever it thinks is the pressure altitude not what is set on the AP ALT SEL.  This is incorrect.  IRL plane will climb to selcted altitude and if the pilot entered altimeter incorrectly it would show on air traffic radar.
Asobo might have done this as a clue that a user's altimeter setting is wrong.  But it's still weird.”


(marsman2020)
Note : this is from the post he took down (edited) but still part of his reply that I quoted.
“The Baron seems to be broken and does not behave the same as the other 3 aircraft. “
“ Set AP altitude to 10,000ft.  Takeoff and engage AP.
AP levels of when the indicated altitude = 12080 ft. 
I'd file a ZenDeck ticket but you'll need a really clear explanation to get anyone to do anything.”


So, now I am trying to gather specific information that would satisfy ZenDesk.

I will try using the Baro keyboard key [as you mentioned and another member suggested] instead of dialing the the current ATIS baro on my next test.
Note: I have always dial in my baro in all flight sims .... 

I will need to test other MSFS aircraft to see if there is any pattern to this problem.

[vonmar 121]

Results so far testing with MSFS version 1.15.8.0 using MSFS Live weather.

These are the aircraft that fly to and capture the armed altitude with the ATIS Baro dialed in at the departure runway.

CJ4 
screenshot linked

 

These are the aircraft that fail to fly to and capture the armed altitude with the ATIS Baro dialed in at the departure runway.

Baron
Cessna Longitude
Beech36


Link to my video testing the Baron:

https://youtu.be/OlU9RIGqrpI 

[img][/img]

 

[vonmar 121]

Today I tested 
MSFS v 1.15.8.0
Default MSFS Beechcraft 350i
KDFW RWY 18R FAA Airport Plate elevation 607 feet
MSFS and real world ATIS Baro 30.13
Baro 29.92 rwy 410 feet
Dialed baro 30.13 (baro above autopilot and PDF)
Baro 30.13 rwy 620 feet

Armed altitude 3000 feet
Autopilot stopped at 3000 feet 
All ok (took screenshot)

 

 

Edited April 22, 2021 by vonmar
Screenshot did not show up

[pstrub 997]

Have you tried setting the barometric pressure using the b key? Does it make any difference?

 

[vonmar 121]

3 hours ago, pstrub said:

Have you tried setting the barometric pressure using the b key? Does it make any difference?

 

Have you had the posted problem with the default MSFS Baron G58, Longitude or the Beechcraft Bonanza G36 ?
Do you normally dial the Baro or do you use the keyboard key?

All of my first series of tests have been done by dialing the ATIS Baro.

[vonmar 121]

MSFS TBM 930
UAAA ATIS 30.50
29.92 RWY 05R 1650 feet
Dialed baro 30.50 RWY 05R 2230 feet

Armed and captured 6000 feet OK

Edited April 23, 2021 by vonmar
insert screenshot

[vonmar 121]

MSFS Baron (retesting with the keyboard B key)
UAAA ATIS 129.8
RWY 05R 29.92 1650 feet
ATIS baro 30.50 selected with the keyboard B key RWY 05R 2230 feet

Armed altitude 5500 feet captured OK in this test