martinboehme

If it's at the quality level we've be outen led to expect, that seems like a good deal to me.

I've finally managed to look into this some more. And yes, it involved intercepting an airliner. In a Hawk. And then landing at whatever the closest airfield on the VFR map was. Which turned out to be LOGM Mariazell, a glider field with an entirely unsuitable 1700 foot runway. But I'm not going around on short final to a glider strip. Glider pilots laugh at people who go around. And hey, at least the runway was paved, and I did get the Hawk stopped in time. So that alone was worth my time. And in the process, I found out why we see AI traffic flying at those strange "in between" altitudes. The short version is: AI aircraft fly according to true altitude instead of indicated altitude. And then they try to cover it up. I'm not sure if this is a known bug or not, but I'll try to find out and will report it to Asobo if it's not yet known. The detailed version is... well, quite a bit more detailed, but I hope it will be interesting to some. Background Let's first recap some relevant background. This will allow us to compare what we expect to see against what the simulator actually does. Three different types of altitude are relevant to us: Indicated altitude: This is, as the name implies, the altitude indicated on the altimeter. Pressure altitude: This is the altitude the altimeter would indicate when set to the standard setting of 1013.25 hPa. True altitude (also called geometric altitude): This is the vertical distance between the aircraft and mean sea level. These three altitudes are the same if international standard atmosphere (ISA) conditions prevail (1013.25 hPa and 15 degrees C at sea level). Most weather presets use ISA conditions. Otherwise – in particular when flying with real weather – these altitudes are generally different. They are related as follows: For every 1 hPa that the altimeter setting is greater than standard, the indicated altitude is 30 feet greater than the pressure altitude. Assuming that the altimeter is set to the local QNH: For every 1 degree that the temperature is warmer than ISA and every 1000 feet above the elevation of the airport that issued the QNH, the indicated altitude is 4 feet less than the true altitude. (The actual relationship is nonlinear, but this is a good approximation.) TCAS works by detecting the transponder signals of other aircraft. A mode C transponder signal encodes the pressure altitude of the aircraft. To display a correct indicated altitude to the controller, radar equipment on the ground adjusts the received pressure altitude using the current QNH. TCAS, on the other hand, does not need to know the current QNH as it is only interested in the relative altitude of another aircraft compared to the own aircraft. This relative altitude is computed by subtracting the pressure altitude of the own aircraft from the pressure altitude of the other aircraft. Experiment 1: User aircraft I wrote a program that uses the SimConnect API to query indicated altitude, pressure altitude and true altitude for the user aircraft as well as AI aircraft. Let’s first look at some data for the user aircraft. I did a test flight from EDDM Munich (elevation around 1500 feet) with real weather enabled. Temperature was 8 degrees (4 degrees below the ISA standard temperature of 12 degrees at 1500 feet), QNH was 1017 hPa. Here is a measurement taken while the aircraft was sitting on the runway: 1 Hawk XX266 -- indicated: 1482 ft pressure: 1379 ft true: 1482 ft The leading “1” is the so-called object ID, which is always 1 for the user aircraft. Indicated altitude and true altitude are the same, as they should be when on the ground at the airport that issued the QNH. As the QNH is 4 hPa higher than standard, we would expect indicated altitude to be 4 * 30 ft = 120 ft greater than pressure altitude; the actual difference is 103 ft, so pretty close. I then took off and climbed to an indicated altitude of 10000 ft. Transition altitude is 5000 ft, so I should normally have set my altimeter to the standard pressure setting, but I left it set to QNH because I wanted to observe the difference between indicated altitude and pressure altitude again. Here is the measurement: 1 Hawk XX266 -- indicated: 10003 ft pressure: 9908 ft true: 9836 ft The difference between Indicated altitude and pressure altitude has reduced slightly and is now just 95 ft. This seems correct: The factor of 30 ft per hPa is only valid close to sea level and becomes smaller with altitude. Indicated altitude and true altitude are now different. Assuming the ISA temperature deviation is the same -4 degrees from the ground to 10000 ft, we would expect indicated altitude to be approximately 4 * 4 * 8500 / 1000 ft = 136 ft greater than true altitude. The actual difference is 167 ft, slightly more, but MSFS may actually be modelling this more accurately than our linear approximation. In all, MSFS models the altimetry effects well for the user aircraft. Experiment 2: AI aircraft Now lets look at some measurements for AI aircraft. I took off again from EDDM in the Hawk and climbed to altitude, looking for an aircraft to intercept. I performed this experiment on a different day, again with real weather, so the temperature and QNH were different: 3 degrees C (ISA - 9) and 1025 hPa. Here are measurements for some selected AI aircraft in the vicinity that were in level flight, i.e. had a vertical speed close to zero: 597 A20N D-AHVX -- indicated: 30662 ft pressure: 30998 ft true: 30997 ft 609 A20N F-CTSU -- indicated: 28664 ft pressure: 29000 ft true: 28999 ft 612 TBM9 F-CKHA -- indicated: 30662 ft pressure: 31000 ft true: 30997 ft 614 A20N D-ACHN -- indicated: 25662 ft pressure: 25998 ft true: 25997 ft 657 A320 4X-BJL -- indicated: 40662 ft pressure: 40994 ft true: 40997 ft 17843 A20N HB-NCE -- indicated: 30662 ft pressure: 30998 ft true: 30997 ft 28796 Skyhawk HA-QLB -- indicated: 10998 ft pressure: 10998 ft true: 10998 ft 47373 Skyhawk OE-WZS -- indicated: 6999 ft pressure: 7000 ft true: 6999 ft There are several points here that are unexpected: For high-flying jets and turboprops, indicated altitude and pressure altitude are different, even though we would expect these aircraft to set their altimeter to standard pressure. The difference is about 340 feet for all aircraft. Conversely, for the lower-flying Skyhawks, indicated altitude is within a few feet of pressure altitude. Pressure altitude and true altitude are always within a few feet of each other. We would expect a significant difference here because the temperature is significantly colder than ISA. Here’s my speculation on what is going on. The relationship between indicated altitude and pressure altitude looks like a “double bug”: It looks as if MSFS is applying the US transition altitude of 18000 feet everywhere in the world. Above the transition altitude, indicated altitude and pressure altitude should be the same; below the transition altitude, they should be different. It appears that MSFS has this exactly flipped. The difference of 340 feet corresponds to about 11 hPa. Because indicated altitude is lower than pressure altitude, the corresponding altimeter setting is 1013 hPa - 11 hPa = 1002 hPa. This isn’t even close to the local QNH. However, if indicated altitude was 340 feet greater than pressure altitude, we would obtain an altimeter setting of 1024 hPa, which is close to the QNH. So it appears that MSFS also has a sign error here. The fact that pressure altitude and true altitude are almost the same is even more puzzling. Based on the temperature deviation from ISA, we would expect a significant difference, and indeed I was observing such a difference on the user aircraft. Either the pressure altitude or the true altitude must be wrong – but which one? To find out, I intercepted the aircraft with ID 597 (D-AHVX) so that I would be able to compare the measurements from the user aircraft and the AI aircraft. Here are the measurements in comparison when I was flying directly behind the AI aircraft: 1 Hawk XX266 -- indicated: 32300 ft pressure: 32306 ft true: 31036 ft 597 A20N D-AHVX -- indicated: 30662 ft pressure: 30998 ft true: 30997 ft I had the altimeter set to standard, so as expected, the indicated and pressure altitudes are almost the same. On the user aircraft, true altitude is significantly lower than indicated, again as expected given the temperature deviation from ISA. Comparing the user and the AI aircraft, the true altitudes are within 40 feet of each other, and that difference is down to my sloppy formation flying. So the true altitude reported for the AI aircraft is correct, and the pressure altitude is erroneous. Unfortunately, this means that AI aircraft can fly at grossly incorrect altitudes. It seems obvious in this case that the AI aircraft was supposed to fly at FL 310, but in fact, it is flying at FL 323. Conclusions MSFS appears to do the following: AI aircraft fly according to true altitude instead of indicated.altitude. Indicated altitude for AI aircraft is wrong in two ways: The AI aircraft’s altimeter should be set to QNH below transition altitude and standard setting above, but MSFS flips this. The difference between indicated altitude and pressure altitude has the correct magnitude but the wrong sign. Pressure altitude is erroneously reported as being the same (within a few feet) as true altitude. Why does MSFS incorrectly report pressure altitude as being the equal to true altitude for AI aircraft when it can obviously model the temperature effects on altimetry accurately for the user aircraft? I can only speculate, but I remember there used to be a bug where ATC was continuously admonishing AI aircraft to climb or descend because their altitude was off. I suspect that, at the time, AI aircraft were reporting their correct pressure altitude to ATC but, as today, flying according to true altitude. This bug may have been “fixed” by reporting an erroneous pressure altitude that is equal to true altitude. Finally: How should an addon developer compute altitude differences when they implement TCAS? Unfortunately, there is no good solution. A real TCAS computes altitude difference from the difference of the two pressure altitudes. But in MSFS, this can lead to wildly incorrect results. In my intercept example above, TCAS would have displayed the other aircraft as being a safe 1300 feet below me when in fact we were at the same altitude (and very close!). A better compromise is to compute the difference of the true altitudes. In my example, TCAS would have correctly shown the other aircraft as being at the same altitude. However, this does have the effect of displaying strange “in-between” altitudes when the user aircraft is cruising at a normal flight level. Had I actually been cruising at FL 310, I would have seen the other aircraft as being 1300 feet above me -- an accurate display because it was, indeed, flying at an "in-between" altitude.

Interesting. That sounds as if it's still a fundamental bug in the sim. I'll have to pay attention to this the next time I fly. I believe there are debugging tools that can be used to display various parameters for AI aircraft, and of course for the player aircraft. I'll see if I can find something that sheds some light on what's going on.

Do you see this only when flying particular aircraft, or does the same thing happen with all aircraft? Just a suspicion, but: I think the TCAS implementation may be using geometric altitude instead of barometric altitude to compute the altitude difference. Before Asobo implemented temperature effects on altimetry, this would not have made a difference, but now it does. I know this created some similar effects at the time - maybe you're flying an addon where this hasn't been corrected yet?

Hadn't heard about this yet - this sounds promising!

It depends. They might dictate when they want you to start descending, but if there isn't any conflicting traffic, they might also tell you "when ready descend" or "descend at pilot's discretion". This means they're leaving it up to you when to descend.

"Walked away from another one, Simon." I love this deadpan line that the captain delivers at the end. Classic video... don't know how many times I've watched it. And great to see the 737 Jurassic at work. Navigation is purely by VOR - none of that fancy RNAV or the modern RNP approaches into Queenstown.

What's wrong about a pilot who wants to practice beyond the level required by the law and their employer? To me, that's the mark of a true professional.

Just did a quick test flight, and it lands really nicely now -- a massive improvement over the previous version, which floated massively and required significant forward pressure to prevent it from ballooning. Sounds as if you had a lot to do with these improvements -- thank you!

The Maddog team have just released an update: https://www.flythemaddog.com/forum/index.php?/topic/14525-fly-the-maddog-x-msfs2020-edition-new-installer/ The changelog is here: https://www.flythemaddog.com/forum/index.php?/topic/14523-new-msfs2020-version-next-week/ The update includes a number of enhancements to the EFB, the addition of a Turnaround Mode and Realistic Mode (which means that aircraft aging is tracked per airframe), and improvements to the flare behavior. I'm particularly interested in the latter, because previously the flare behavior has always been something that bugged me about this aircraft; you would need to push the yoke forward in the flare to prevent the aircraft from ballooning. I haven't tried out the update yet, but I plan to do so tonight.

It's safe because ATC will only clear you for the approach if they can guarantee separation from other traffic. Nowadays, this is typically done with radar. In the old days, before radar was widely available, this was done by only ever clearing a single aircraft for the approach at a time. Any other aircraft would be kept in the hold, above the approach, until the first aircraft had completed the approach. In some regions, this is still done today. Obviously, though, this doesn't allow very high arrival rates. Ultimately, all aircraft will be converging on the airport anyway -- so the only way to keep things safe is to have ATC enforce separation. Edit: It's certainly true though that an aircraft flying the teardrop will make ATC's job harder -- which is why, it it's busy, ATC will often be reluctant to clear you for the full procedure.

Maybe it's worth revisiting what the purpose of the initial approach segment is: It gets you from a fix on an airway, or from the endpoint of a STAR, to the final approach fix in a way that a) aligns you with the final approach course, and b) guarantees terrain and obstruction clearance. Simply going direct to the final approach fix would not necessarily achieve either of these objectives, and of course there are still aircraft that aren't RNAV capable and are therefore simply unable to go directly to the final approach fix. In practice, as others have pointed out, ATC will often give you vectors that get you onto the final approach more expeditiously. But the "full procedure" still needs to be available, at the very least, for the case of lost comms, when you obviously won't be able to get vectors. If you're flying without online or offline ATC, you can "self-vector" yourself onto the final approach using what you see on the ND, but unless you stay above the MSA, you can't really know that you're giving yourself terrain and obstruction clearance. Another thing that's pertinent in this context is that there are different "styles" in which approaches can be constructed. The approach at EGGD that we've been discussing is very "classical" in that it can be flown without RNAV -- it provides a "teardrop" course reversal that commences at a navaid located at the airport. Nowadays, many approaches define initial approach segments that can only be flown using RNAV. Often, these are in fact intended to be flown day-to-day, as the idea is to provide a way for ATC to get you onto the approach without needing to issue any vectors, thus reducing ATC workload.

I've flown the DA62 a fair bit, and this doesn't mirror my experiences at all. Among other things, I recreated a factory ferry flight across the North Atlantic, and the DA62 was more than up to the job -- a joy to handfly, good altitude capability, and definitely not underpowered. Here are some thoughts: My suspicion is that something else in your community folder may be interfering with the DA62. Have you tried disabling all the addons in the community folder and seeing if the problem persists? My next suspicion would be that a rogue control assignment, maybe to a mixture axis, is causing the DA62 to develop less than full engine power. Failing that, can you post a video showing the problems you're having? That might help pinpoint what the issue is. By the way, are you using the excellent DA62X improvement mod? If you are, make sure you have the latest version. If not, go out and get it -- it's a must have. Hang on in there -- once you've overcome whatever the problem is, you'll find the DA62 is an absolute blast. It's a great go-places airplane and just beautiful to look at, both inside and out.

Note however that even if you switch to kilograms, the fuel quantity display on the EIS still reads in pounds. This is not a bug - the real aircraft does this too. See also here:

Agree - I don't think the animation itself is the hard part. I think the bit that takes the most effort may be regaining access to the airframes from which they built the original models. And they may have decided it's not worth the effort to them. Again, not saying I wouldn't welcome opening doors - just speculating as to why they didn't do it.

Pure speculation, but here's what I think may be behind this. As I understand, the original model for the TBM already included the doors as separately modeled parts, including those areas that are only visible when the door is ooen. The only thing that needed to be done was to make them animatable. I suspect that this wasn't the case for the CJ4 and Longitude and that the doors were simply modeled as part of the fuselage - meaning that the parts of the door that are only visible when it is open was not modeled at all. Enabling the doors to open would therefore require more work - some 3D modeling, maybe also requiring someone to get access to the airframes from which the original models were scanned. Not saying it wouldn't be great to have opening doors - but this could be the reason it didn't happen in AAU1.

Thanks - don't know how I missed that!

I hadn't seen that guide yet. Is it included in the standard AAU1 installation (where?) or do I need to download it from somewhere else?

Thanks for that info - makes sense!

Exactly what I said, 2 posts above.. Thanks. Didn't realize that information came from WT - it sounded as if it was just a conclusion you had drawn from your own knowledge of the aircraft.

So what did they say about it? I'm on the WT Discord, but there's more discussion there than I can keep up with on a regular basis.

Thanks -- that was quick and definitive! I guess I'll file a bug report with Cessna then. 😉 On a more serious note, I can see how this inconsistency might come about given where I suspect the boundaries of the various software systems lie. I think in this case, I'll fly the Longitude in pounds -- seems less confusing than to work with a mixture of pounds and kilograms. While you're here, can you comment also on the standby instrument -- is that inHg exclusively, or is there some way to switch it to hPa? By the way, thank you for the quality of support you provide in these forums, which isn't even your official venue for support. I see you posting detailed replies on seemingly every WT-related question -- much appreciated!

Another question: I used the settings on the GTC (hope I'm using the correct term here?) to change the units for fuel quantity from pounds to kilograms. Other GTC menus, e.g. for landing performance, are now showing kilograms as expected, but the fuel display on the "big center screen" (sorry, don't know the correct Garmin terminology for this) still shows the fuel in pounds. Is this a bug or is it accurate to the behavior of the real unit, and if so, is there a different settings option where I can change the units used for the fuel display on the "big center screen"? On a related note, I've changed my baro units from inHg to hPa to fly in Europe, but the integrated standby instrument still uses inHg. This makes sense, as I wouldn't expect it to be talking to the rest of the avionics, but is there any way that I can change the units used by the standby instrument? Or is it a limitation of the real aircraft that the standby instrument always uses inHg?

Thanks for the heads up. Let's hope the affected airports get fixed quickly!

There's another fix in this update that will be very welcome this time of year in the northern hemisphere: Runways and taxiways will no longer be covered in snow. (Previously, runways even at big airports could be almost entirely blanketed in snow, making them almost impossible to see.)