martinboehme

According to the manual, the only other item that could be causing this is that the autopilot and yaw damper need to be off. Maybe the autopilot is still on from checking it as part of one of the checklists?

That's understood. See my post above where I converted the TAT of 25 degrees at FL 150 to an SAT of 9 degrees (assuming a standard 737 climb speed of 280 KIAS). That's ISA+24, which is still plausible.

Thanks! That's less consistent then with the value that @ThomseN_inc observed... but then that observation is likely from at least a day ago. Certainly, the value is in the range of what is plausible.

I think the reason may be that this is a customization that's specific to the M500. Some aircraft that use the G1000 aren't pressurized. Others have pressurization controls that are separate from the G1000. WT does provide some extension points for the G1000, but obviously not yet for this particular aircraft-specific behavior. By the sound of it, it's being worked on though.

Thanks for that data -- hadn't thought to check ForeFlight (and I'm not sure if my subscription covers Africa). That temperature agrees almost exactly with what I had computed earlier from the TAT. This isn't far off from the ISA + 24 that I computed for FL 150 above. Could you check ForeFlight for the current temperature at FL 150 by any chance?

It can be misleading to compare TATs. I'd suggest looking at SAT instead -- I believe on the 737 NG you can find that in the FMC on the PERF (or PROG?) page.What speed were you doing at FL 150? Assuming you were doing a standard 737 NG climb profile, you'd be doing 280 KIAS. As the formula for ram rise is expressed in terms of TAS, we need to convert IAS to TAS. At FL 150, 280 KIAS corresponds to about 350 KTAS. Plugging that into the formula, we get:SAT = TAT - (TAS / 87)^2 = 25 - (350 / 87)^2 = 9I agree that this seems pretty warm for FL 150 (it's ISA+24), but I wouldn't discount it without checking against a real-world source. (I haven't unfortunately been able to find vertical profiles for HAAB.) Are you saying you're running with real-world weather and nevertheless you're observing the same temperatures every day? That would indeed seem strange, and it's not something I've observed so far.

No, because that northern European airport is likely close to sea level, so a SAT of 16 degrees is just ISA + 1. Climb from that airport to 7500 feet (the elevation of HAAB) and you'd expect to see only +1 degree SAT, assuming the standard ISA lapse rate of 2 degrees per 1000 feet. Put differently, 16 degrees at an elevation of 7500 feet corresponds to 31 degrees at sea level. Those are the equivalent conditions to think about if you're used to flying from sea level airports. The warm temperature relative to ISA explains why you're seeing bad climb performance.

I don't think there's anything wrong here. All of these values look plausible.It's important in this context that TAT (total air temperature) is not the same as the temperature of the free air outside the aircraft -- that would be SAT (static air temperature). When the aircraft is in flight, TAT is higher than SAT; the difference between the two is called ram rise, and it increases with speed. This Wikipedia article contains more details:https://en.wikipedia.org/wiki/Total_air_temperatureHere are two rules of thumb for calculating TAT for a given SAT and speed (either in knots or Mach number):TAT = SAT + (TAS / 87)^2TAT = SAT * (1 + .2 M^2)(For the second formula, the temperatures need to be in Kelvin.)For your first scenario, in the initial climb, let's assume SAT is still the same as it was on the ground, and that you have a speed of 250 knots. This gives us:TAT = 16 C + (250/87)^2 = 24 CThis is in pretty good agreement with your observation.For the second scenario, let's work backwards from your observed TAT to work out what the SAT is. A TAT of 0 C is 273 K, and I'll assume that you're cruising at Mach 0.8. We getSAT = TAT / (1 + .2 M^2) = 273 K / (1 + .2 * .8^2) = 242 K = -31 CThe ISA (international standard atmosphere) temperature at FL 300 is -44 C. So this would be 13 degrees warmer than ISA ("ISA + 13") -- pretty plausible at these latitudes. It also corresponds well with the temperature on the ground: At the field elevation of 7500 feet, ISA temperature is 0 degrees, so the observed temperature of 16 degrees is ISA + 16".If your aircraft indicates SAT (often labeled OAT) in addition to TAT, you can take a look at the two values and compare them.

We will leave no stone unturned. MSFS 2024 will rock your world!

Can you post a screenshot of this situation? In particular, it would be useful to look at the modes of the flight director and autothrust displayed on the PFD. Also, what is your physical throttle set to?

Funnily enough, when I started reading your post, I thought you'd say it would make sense to put these options in the EFB rather than the FMS. The FMS has pretty limited screen space, requiring the options to be spread across many pages. The EFB has more screen space, and more options in terms of UI widgets. Doesn't mean all the options should go on one page, but there would be more choice for the UI designers in terms of how to group the options on different pages. I don't see how putting these options in the EFB would lead to clutter - they could be tidied away behind a single "options" item in the EFB interface (in the same way they are in the FMS today). Not saying this should be a priority - as you point out, these options are accessed pretty rarely - but I can't help but think the EFB would be able to improve the presentation of these options.

Just a guess, but maybe you accidentally turned on the "copilot" assistance option? It seems like the kind of thing that could cause this behavior.

I think you're misinterpreting what he said. When he says the X-Plane 172 felt familiar, I think he means coming from the MSFS 172, not the real 172. Note how he explicitly says that both the X-Plane 172 and the MSFS 172 do not match the stall/spin characteristics of the actual aircraft: (Emphasis mine) And then he specifically points out the wing drop as one aspect of the two simulated aircraft that does not match the real aircraft. So I'd encourage you to continue reading -- I think it's a well-written piece.

The MD-80 has a two-person cockpit. Maybe you're thinking of the DC-10? Appreciate if this isn't your thing - it's certainly different. However, the workload in flight is very manageable - most of the additional button pushing and switch flipping happens on the ground.

Here's an example of a real A320 in the situation we're discussing here (speed selected, descent managed), watch from 3:33: Some points to note: We can tell the speed is selected because the speed is displayed in blue. We can tell the descent is managed because the vertical mode is "DES". The aircraft is high on profile (and continues to become ever higher). Nevertheless, the autoflight system prioritizes achieving the selected speed over maintaining the vertical profile.

It's recalculating the vertical path, but it may not be able to achieve it. The vertical path is computed based on the assumption of an idle descent at 250 knots below 10,000 feet (in the absence of other constraints). If you select a lower speed, you'll get closer to green dot speed (the best glide speed). You're therefore gliding more efficiently, your glide angle will therefore become shallower and you'll deviate above the vertical path. The FMGS can't do anything about this as the vertical path already assumes an idle descent - and it obviously can't reduce the thrust below idle. What you as the pilot therefore need to do is to extend the spoilers (which the autopilot has no control over). In the opposite scenario, if you increased the speed above 250 knots, the FMGS would be able to maintain the vertical path by adding power (which it does have control over).

If both battery switches are off, the lights won't show "OFF". You'll only see "OFF" if the other battery is switched on. Did you turn the APU on? It's required to start the engines.

Consider also: The premium edition aircraft were originally encrypted, making it hard to mod them. At some point, the encryption was removed (in response to community requests). Why would they do that if they didn't want people to mod the default aircraft?

Bear in mind though that size on disk doesn't have a lot to do with VRAM requirements. If a scenery uses LODs well, it can have a lot of detail up close and still be VRAM friendly. All other things being equal, it's true of course that more complex sceneries will require more VRAM. But I'd wait for a verdict from others before giving up on this.

Fascinating - I never knew that! Apparently, Little Navmap even has an option that lets you switch between whether to apply the current magnetic variation or the one the VOR is actually calibrated to: https://www.littlenavmap.org/manuals/littlenavmap/release/latest/en/MAGVAR.html @masconti This might be an option worth trying out. I assume on your system the option is set to use the current variation.

From @LtCdrDruid 's post though it appears that's what it is.

I don't think this is an accurate analogy. You wouldn't do the ingest / data conversion every time someone requested a certain date and time; you'd do it once, when a new model run becomes available, and then you'd store the data on your own servers in the format required by MSFS. How much data are we talking about? You say the US GFS model is tens of gigabytes in size. Which time window does that cover -- 24 hours? Let's assume it does, and let's assume NEMS30 is in the same ballpark -- let's say 30 gigabytes for a dataset covering 24 hours. The data for an entire year would then be just over 10 terabytes. That's not a lot of data to store and serve. Someone else mentioned that the global scenery that gets streamed is in the petabyte range -- 2.5 petabytes IIRC. Compared to that, the weather data for a whole year would be just a blip. Another point of comparison: On Google Drive, the free tier gives each user 15 gigabytes of data. 10 terabytes is therefore equivalent to the amount of storage consumed by about 700 users on the free tier. And Google Drive has about a billion active users. Technically, I think historical weather is eminently doable. The question is whether MS / Asobo will choose to make it a priority.

Interesting -- hadn't seen that yet! I found this part of the interview very revealing. It seems to me that Jörg has heard of the request for historical weather but truly believed it meant weather from 1947 (for example) and, from his statement quoted above, wasn't aware that meteoblue even has data going back 80 years. As you say, it's disappointing that this information still hasn't gotten through despite the efforts of the community, but maybe he's now finally understood that what people are asking for is really just weather going back 24 hours... which should be significantly more feasible than, say, recreating the weather conditions of Lindbergh's transatlantic flight (which is maybe what he understood). Not holding my breath... but we'll see.

Maybe what they meant is that it's common to be given a lineup clearance at Heathrow and other busy places because it's more efficient. You can only give a takeoff clearance once the departing aircraft has lifted off, but you can give a lineup clearance while the preceding aircraft is still on its takeoff roll. This keeps traffic flowing better, which is vital at a place like Heathrow that's trying to squeeze as many movements as possible out of two runways.

The fork is real: https://github.com/tcantenot/Atmosphere-Rendering-Parameter-Calculator And the person who forked the repo is apparently a Senior Engine Programmer at Asobo: https://theorg.com/org/asobo-studio/org-chart/thierry-cantenot Of course, this doesn't mean that the modified coefficients will in fact end up in MSFS. But at least we now know that this has come to the attention of a developer at Asobo, and they're interested enough to be looking at @Biology's code.