CaptCrash

@danhenri The discrepancy you note is due to compression heating and the limited recovery coefficient of the temperature probe on the actual MU2. Based on the POH values I have identified the recovery coefficient of the temperature probe to be about 0.6. This is important for the following equation: T_static = T_total * (1 + 1 / (0.2 * C_recovery * Mach^2)) Where T_static is the static outside air temp, T_Total is the indicated outside air temperature, C_recovery is the energy recovery coefficient of the probe. Modern probes are 1 but those are aspirated types on jets, on stuff like the MU it would be between 0.6 or 0.8 depending on type. Regarding your performance issues, you may want to try out my FM modification, it gets the plane to within 1% of cruise POH values. I haven't evaluated takeoff or landing distances yet.

Just and update regarding simbrief. I did submit a request for an MU2 profile based on the POH and AFM. They said they'll add it but no idea on time frame

OEM and GNS versions exhibit the same behavior, the course can be set but the obs knob and the CDI card on the HSI do not rotate to reflect the new course. GNS version shows the behavior when in GPS mode according to another user

It appears the RMI needle will flip the long way around if the navaid switches from the left to right side of the nose due to the circular singularity at 360/000

Currently undergoing V2.0.2 compatibility testing The patch is compatible with 2.0.2

8/9/2022 Change log added flight model ventral strakes added tip tank fins and strakes added 85% ram inlet recovery pressure reduced total power to 1113shp to account for ram inlet recovery cruise values are now consistently below 2% delta from POH values at all altitudes Changed trim time response and increased elevator trim in response to POH values and autopilot sensitivities uploaded weight and balance spreadsheet

Hey there @mjrhealth I'm not sure what you are trying to say. If you are trying to be helpful might I suggest instead of saying "payd (sic) to read other posts" providing a link to the other posts as an alternative? Something along the lines of the following: Lets try to avoid basically telling people to read the forum and have a bit more understanding that people miss things. Thanks, Crash

Hmm. I believe @amyinorbit has openGPWS functioning on her M1 in the Q400 so maybe she can shed some light on her voodoo that she do, I don't own a mac. the weather API for XP12 is going to be totally different hopefully rendering the need for openWXR redundant. But for users that will not upgrade to XP12 it may be worth integrating it. I would have done so already but I'd need to modify the obj and insert the screen object to replace the mesh where the INOP sticker is

When the auto-stop throttle feature is toggled engine 1 reverts to reverse and all control is lost of engine 2.

OpenWXR is a free plugin which relies on OpenGPWS and emulates a functional radar. This would be very useful for the OEM version of the panel which currently has an INOP weather radar. The system is customizable to the exact color and radar beam configuration using proper radar signal generation, filtering, signal processing and integration. It works as a standalone plugin once it is compiled and only requires space on the panel.png for the screen drawing https://github.com/skiselkov/OpenWXR/

LibRadio is a plugin that properly computes signal propagation and handling of LOC/GS signals. Libradio relies on OpenGPWS to compile but acts as a standalone plugin. It greatly enhances the realism of radio signals by properly computing the signal masking and signal strength. It overrides the default radios but requires some updates in the MU2 to properly be integrated. I have it compiled on my system and the AP loses APPR functionality. One major draw back to using the default handling of nav signals is the downwind ILS case. If flying downwind with the ILS tuned but on the departure end of the ILS Xplane will provide a guidance signal for the opposite runway effectively rendering BC approaches impossible. https://github.com/skiselkov/libradio https://github.com/skiselkov/opengpws

There is a fuel limitation in the MU-2 based on the ZFW cg of the aircraft, if it is nose heavy then you can only put fuel in the mains or mains and outers. You can find this information in section 7 of the manual i posted in this forum. If there is no fueling limitation applied then you should fill the mains first, then the outers, then the tips. There can be several reasons for this here are a couple major one. 1) if a fuel transfer system failure occurs the resulting imbalance roll moment is greatly increased if all the fuel is out on the tips. 2) In the event of a bleed system failure or leak in the tip tanks you may not be able to transfer fuel from the tip tank(s) Proceed to 1. If you use the manual and go through the flight planning for section, you can get proper fuel numbers. I put a request into simbrief(Navigraph) to add the MU-2. Below is an image of my weight and balance form for the MU2. For Flight planning I plan an average climb TAS of about 185knots and 670pph for climb (this is based on the book values, the TOGA MU-2 fuel burn is about 14% too low). for cruise the flight planning tables lay it out quite nicely, and if you are using my mod, your speeds will be spot on but the fuel flows are still 14% too low.

http://web.archive.org/web/20211123225103/http://givdemo.com/images/N360RA POM & AFM.pdfThe AFM and POM are at the link above. This would be a good datapoint to use for reporting performance discrepancies

http://web.archive.org/web/20211123225103/http://givdemo.com/images/N360RA POM & AFM.pdf Enjoy!

The mod is compatible with V2.0.1