#2022 Altitude gap between fg2017.3 and 2018.2 or 2018.3

[Christian Le Moigne]

Hi,

With exactly the same conditions (altitude,distance ...), there is an altitude gap of 500ft between the two versions of Fg for the same indicated altitude.

fg2017.3 :
Indicated altitude : 3350 ft
Altitude-agl-ft : 3229 ft
Altitude-ft : 3432 ft

fg2018.2 & 3
Indicated altitude : 3350 ft
Altitude-agl-ft : 3701 ft
Altitude-ft : 3906 ft

So, with the last fg versions, the aircraft position is higher the ILS slope with a standard approach in the flightplan while it's correct with the 2017.3 version, as you can see on these screenshots.

[Christian Le Moigne]

The weather conditions and barometric pressure were exactly the same in the two versions :
Detailed weather - fair weather and barometric pressure = 29.92.
I think it's not a problem of "indicated altitude" but a more complex one because the same flightplan approach doesn't give the same "position/altitude-agl-ft" in exactly the same conditions and distance. It's visible on the two PAR screen.

[James Turner]

Can you reporduce this with the UFO, or is it specific to some aircraft?

[Christian Le Moigne]

With the UFO:

Fg2017-3 - On ground :
"/instrumentation/altimeter"
indicated-altitude-ft = 250.95
mode-c-alt-ft = 300
pressure-alt-ft = 252.14
"/position"
altitude-agl-ft = 0.101
altitude-ft = 294.17

Fg2018-2 & 3 - On ground :
"/instrumentation/altimeter"
indicated-altitude-ft = -266.68 (it's negative !)
mode-c-alt-ft = -300
pressure-alt-ft = -265.48
"/position"
altitude-agl-ft = 0.0998
altitude-ft = 294.17

Fg2017-3 - 2500 ft
"/instrumentation/altimeter"
indicated-altitude-ft = 2500.31
mode-c-alt-ft = 2500
pressure-alt-ft = 2501.51
"/position"
altitude-agl-ft = 2281.19
altitude-ft = 2582.80

Fg2018-2 & 3 - 2500 ft
"/instrumentation/altimeter"
indicated-altitude-ft = 2500.11
mode-c-alt-ft = 2500
pressure-alt-ft = 2501.30
"/position"
altitude-agl-ft = 3089.34
altitude-ft = 3089.33

For all :
setting-hpa = 1013
setting-inhg = 299.92

[i4dnf]

Repeating what I've already mentioned on the mailing list:
AFAIKS as long as the altimeter setting matches the environment/pressure-sea-level-inhg value the indicated altitude is correct.
However, I noticed that Detailed weather on first run sets some random sea level pressure that doesn't match the one in Environment->Weather->METAR Data .
This happens regardless if Detailed weather is enabled via the launcher (thus auto-run) or enabled later via the Environment->Weather dialog.
Further resets of Detailed weather apply the same sea level pressure as in the METAR string.

Please show some screenshots showing the following properties:

environment/pressure-sea-level-inhg
environment/pressure-inhg
instrumentation/altimeter/setting-inhg
instrumentation/altimeter/indicated-altitude-ft
position/altitude-ft
position/altitude-agl-ft

NOTE: you can put the property on-screen by shift-clicking it in the property tree

IIRC prior to 2018.x, Detailed weather could only be started from the in-sim dialog, so this behaviour was not so visible, or maybe even not triggered.

[Christian Le Moigne]

2017.3 Detailled weather loaded at startup :

2017.3 Same values when changing to Basic weather

2017.3 Changing Basic weather to Detailled weather:

2018.3 Detailled weather loaded at startup :

2018.3 Changing to Basic weather :

2018.3 Changing back to Detailled weather :

[i4dnf]

This isn't FDM related.
It's weather engine related.
(It's a [user] failure to set the barometer setting to the correct value (most likely due to discrepancies between METAR reported value and weather engine actual value))

[Benedikt Hallinger]

This also occurs on 2020.4 (currently next); see Ticket: #2842

Just again tested at East Midlands / EGNX / RWY 27 threshold:

• Started with live weather / advanced weather. METAR says Q0993 (parsed to 29.32 inHgG)
• /environment/pressure-inhg = 29.026
• /environment/pressure-sea-level-inhg = 29.32
• /position/altitude-ft = 282
  Calibrated altimeter to 29.32 gives reading of ~265 ft

=> That looked good and not off.
Looks like its not always off...

[Benedikt Hallinger]

Retested with "fair weather" with startup (same position at at EGNX / RWY27 Threshold):

• METAR/weather string says Q1015 (parsed to 29.97 inHg)
• /environment/pressure-inhg = 30.143
• /environment/pressure-sea-level-inhg = 30.476

• /position/altitude-ft = 282 (same position as before!!)
  Calibrated altimeter to 29.97 gives reading of -180ft (~460ft off!)

• Changing to "Basic Weather" fixed the altimeter reading without further action

• Changing back to "Detailed Weather" made it off again, but this time its showing -80ft
• Changing the "tile selection mode" to METAR again fixed it with "Detailed weather".

---

• Completely restarting with the same conditions again failed.
• Completely restarting with the same conditions, but supplying --prop:/local-weather/tmp/tile-management=METAR in my launcher instantly worked without further intervention (Altimeter calibrated to 29.97 showed the expected 280 ft).

So my reasoning would be at this point, that the weather presets initialization need to be revisited when not using live weather.

[Gijs]

I think I found the problem. In Nasal/local_weather/local_weather.nas we have:

if (type == "High-pressure-core")
    {weather_tiles.set_high_pressure_core_tile();}
....
else if (type == "Fair weather")
    {setprop(lw~"tiles/code","cumulus_sky");weather_tiles.set_fair_weather_tile();}

However, in Environment/environment.xml the local weather tile type for the "Fair weather" scenario is set to "High-pressure-core" instead of "Fair weather":

    <scenario>
        <id type="string">fair-weather</id>
      <name type="string">Fair weather</name>
      <metar type="string">XXXX 012345Z 15003KT 12SM SCT041 FEW200 20/08 Q1015 NOSIG</metar>
      <description type="string">A lovely day for trip to your favorite 100$ hamburger airfield</description>
      <local-weather>
        <tile-type>High-pressure-core</tile-type>
        <tile-management>realistic weather</tile-management>        
      </local-weather>
    </scenario>

This effectively loads the High pressure core scenario (1028 hPa), which explains why the pressure is way of from the shown METAR (1015 hPa).

Unfortunately, changing the tile type to "Fair weather" gives a Nasal runtime error: No such member: set_fair_weather_tile error, because weather_tiles.set_fair_weather_tile() does not exist!

@trenk, is there a reason for not having a fair weather tile type in local weather? According to your comment in https://forum.flightgear.org/viewtopic.php?p=285024#p285024 it is on purpose. I understand that, as long as the tile mode is not set to METAR we'll get an approximation, since AW adds some randomization to the pressure (up to 6 or 10 hPa, depending on the scenario). However, for all the other scenarios this is still relatively close to the METAR pressure, with a maximum difference of 0.09 - 0.15 inHg, because they have a properly defined local weather tile type. It's only for fair weather and thunderstorms that there is a considerably larger difference of up to 0.44-0.47 inHg (see attached graph).

• The fair weather pressure range in local weather is (equal to high pressure core) 1025 - 1031 hPa, while the METAR reports 1015.
• The thunderstorm pressure range in local weather is 1000 - 1010 hPa, while the METAR reports 995.

I think we need to do two things, to ensure that basic and advanced weather use identical scenario presets that more or less match the shown METAR:

1. Add a fair weather tile type to local weather with the proper pressure minimum.
2. Change the local weather thunderstorm minimum pressure from 1000 to 990 hPa.

[Gijs]

I've pushed the aforementioned fixes per [a9bce8] and [096aad]. It was easiest to set the fair weather scenario to METAR mode, rather than crafting a dedicated fair weather tile type.

[Christian Le Moigne]

Thanks to Benedikt for bringing this old topic back to light and thanks to Gijs for resolving it.

[Benedikt Hallinger]

Thank you very much :)