JRBarrett

MSFS upper winds are derived from the Meteoblue NEMS30 model. Most upper winds forecasts (no matter what the model) are updated every 6 hours. I use Foreflight linked to MSFS, and compare the upper winds in Foreflight (which come from the NOAA GFS model) to the winds in MSFS, and they are normally very close at any given altitude and time. Differing models will always have a slight difference of opinion as to what the winds will be. You can see this in the MeteoBlue app which can display the animated winds at any flight level from several different models, including the NEMS model, the GFS, the ECMWF, the ICON and others. They are usually close at high altitudes - less so near the ground. The NEMS30 model (based on a 30 KM grid), will usually show pretty constant surface winds north and west of Palm Springs in Southern California, while the much higher-resolution HRRR model (3 KM grid) will show the increased wind speed in the Banning Pass caused by the temperature differential between the coast and desert.

In all my testing during the beta, never encounter this particular problem. Not sure what would cause it. When you press the left APU master button, (which is not lighted), you should see the APU RPM and EGT gauges appear on the #3 display and the APU inlet door move to “OPEN”. Is that happening? Possibly another control binding is interfering?

That NDB no longer exists. If it shows in LNM, I assume you are using an old database for LNM. I don’t know how old the default LNM database is. MSFS uses current nav data, so that NDB will have been (correctly) removed within MSFS. If you have a Navigraph subscription, you can update LNM to use the latest nav data. This is probably the issue with many of the NDBs that do not show up in MSFS. A large number of NDBs have been permanently decommissioned throughout the world in the last few years.

Which specific NDBs? (Identifier and location).

Another thing to do during preflight: On the pilot’s FMS keypad push the “MFD MENU” key. This allows you to select the overlay of advisory VNAV data at the top of the MFD display. For the pilot’s (L) display select “VNAV” and for the copilot’s (R) display select “ON”. This is the standard setup that r/w crews use. It will display the distance to TOD, and the time to go, as well as the predicted vertical speed at the beginning of your descent. The right display will show the time to the next three waypoints and the estimated fuel remaining at each. I’ve seen a few review YT videos and the reviewers often overlook enabling these displays. For climbs, I always use SPD mode, and for descents I always use vertical speed. You CAN use speed mode for descent, (if maintaining a particular speed is of paramount importance), but V/S works much better in most cases if following a STAR with altitude constraints, in which case you would control speed with engine thrust. I normally aim to descend at 280 knots IAS, as that is what many US STARS expect. In this case, you will find yourself slowly reducing power more and more as you descend.

Here is how I do it in the sim. It is first of all important to have a button assigned to the TOGA command. On some aircraft (with autothrotles) this will advance the power levers to takeoff power. In the real (and simulated) CRJ this will set the flight director command bars to the pitch required to hold V2 + 10 after takeoff. It will also set TO TO in the PFD FMA window. During preflight on the EFB Performance page, you should have selected your takeoff flap setting (8 or 20 degrees) and used the “SET ALL” button to set your V speeds on the PFD. This will also set the speed bug to the calculated V2 + 10 speed. I normally takeoff with flaps 8. I do not use vertical speed for climbs, but SPD mode only. It is also important to insure your heading bug is set to runway heading before takeoff. On takeoff, I advance the power levers to the TOGA detent and release brakes. As the aircraft accelerates through VR, I rotate, and pitch up to hold the flight director pitch command bar. Retract gear with positive VS. At 400 feet AGL, I select SPD and HDG on the autopilot control panel and engage the AP. If your runway heading takes you close to a direct path to your first waypoint you can select NAV before engaging the AP instead of HDG. The aircraft in the current version does a nice job of holding pitch to maintain the V2 + 10 speed bug when using SPD mode. I then start increasing the speed bug setting. Initially to 200 knots. As you do this the aircraft will start pitching down to accelerate but it will still maintain a positive climb rate. Passing 1000 feet AGL, I pull the power levers back to the CLB detent. Once above about 180 knots, I retract the flaps but leave the slats deployed. I then wind the speed bug up to 230 knots. Passing 210 knots IAS, I retract the slats and set the speed bug to 250 knots. The aircraft does a very good job of tracking the speed bug with pitch, and vertical speed will be typically between 2000 and 4000 FPM. At 10,000 feet I set the speed bug to 290 knots for the rest of the climb up to cruise.

No, it’s definitely not. There are some additional significant improvements coming (relating to the flight model) which I’m not at liberty to discuss. Although this initial V2 release does work in 2024, it was compiled using the 2020 SDK. Hans’ next step is to create a 2024-specific version.

That change log indicates all the changes made since last October, not just in the last seven days.

You only need to install VS if you want to compile the program yourself. The folder contains a pre-built executable that you can run directly. When you install the SDK, you need to install the optional “Samples” folders. The simvar watch program is in there.

It works with both 2020 and 2024

Here in the US, if you visit a craft brewery and want to sample several different beers the brewery produces, they will pour small glasses of the product (usually 4) lined up on a board, and it is referred to as a “flight”. Only other place where I have encountered the term.

Right now it just displays a text message: “Oops The software powering this discussion forum has encountered an unexpected problem…

You have to use current real-world charts or a database for something like Plan G that is up-to-date. Navigraph can supply both.

It is your Windows time setting that needs to be changed. You can set the actual time of day to local time with no problem. It is your time zone that is not set correctly. A new Windows installation is set by default to the Pacific time zone, and that will not change unless you go into the system settings to change it to your actual time zone. Both MSFS 2020 and 2024 use the Windows system time zone and UTC time (from the MSFS server) to determine what your local time is. If you change the time zone setting in Windows, you will have to reset the correct local time as well.

Not yet