MrGreen

No I do not. However, the ASUS version of the Realtek drivers comes with a software called ASUS Sonic Studios and ASUS Sonic Radar. These seem (after some googling) to be quite similar to MSI Nahimic. In fact, just looking now, a thread on another forum mentioned that Sonic Studio uses .DLL:s from Nahimic. I guess we found our culprit. I installed some "generic" or non-ASUS-specific Realtek drivers yesterday, and got fs2crew to pic up my mic, but I'll try to install the ASUS ones today, but uninstall everything related to Sonic, hopefully that will make fs2crew work, but without lower audio quality.

Okay so I have an update to my issue: I read a thread here that suggested that ASUS realtek drivers might cause issues, so I uninstalled them and I actually got the fs2crew to pick up my voice when running Microsofts default audio drivers. I thought that the reason I had an issue was that I never updated my realtek drivers to Windows 10 (I checked and they were for Win 7) and so downloaded and installed the new Windows 10 64bit realtek drivers. The problem reappeared. The culprit is definitely the interaction between fs2crew and the ASUS realtek audio drivers (or simply realtek audio drivers). As a temporary solution I might run the microsoft drivers but the sound definitely isn't as great. Any way to solve this issue without having to uninstall realtek?

Hi, I've been away from FSX for a while and the last time I used the NGX and fs2crew reboot was in 2016 with windows 7. After that I updated my system to Windows 10 (no clean install) and I've had no issues because of this with other programs or games. Coming back to FSX I updated NGX and subsequently did a clean reinstall of both NGX and fs2crew (with the latest update). I have however not gotten my voice to be recognized by fs2crew. No green text, no response from the FO. The last time I was (successfully) using fs2crew was with a headset but being a bit of an audiophile I've since been using a pair of HD598 headphones together with clip-on mic (Antlion modmic 4.0). I've been communicating via voice just a few weeks ago but I checked that my mic was working both by checking that sound was being picked up and by enabling listen. I also made sure to follow the voice recognition instructions from the fs2crew manual and I did a voice training and configured the mic to pick up my voice. Googling the issue I came across a post by Bryan York that recommended to click "use this audio input device" in the advanced voice recognition settings, which I followed. Nothing has resolved the issue. On the fs2crew audio panel inside FSX I've switched between different audio devices (realtek hd audio and even my displayport monitor lol) without success. Clicking reset audio system makes FSX freeze. I've also tried reinstalling Fs2crew and reverting to the version I used last year, no luck. Any suggestions? I would really like to avoid having to do a clean FSX reinstall or, even worse, a OS reinstall. EDIT: My signature system is outdated. Current hardware: Win 10 64bit, i7 7700K, GTX 1070, no sound card.

So would you recommend me not to bind F1 to the reverser detent then? I like it as an insurance in case the hardware-throttles happen to stay at a >0% level, hitting F1 will make it go 0 so autobrakes etc applies. But I don't want to break the simulation. I did a flight yesterday with cost index 50 (descent speed 296/.792, if I remember correctly) and I never had to use drag (until touchdown ). I did however do the F1 "trick" during the descent to shave off a few % of N1. I'm not sure if the F1 thing actually had any effect, and I feel it is harder for the aircraft to keep a low ECON SPD in descent compared to 280+. Maybe I have unrealistic expectations, but it feels like I shouldn't have to use drag during long parts of the descent (5000-10000ft) if my planning is correct and there are no unexpected changes during the descent (new speeds, different routing, sudden changes in weather). Am I wrong?

Very interesting information. How come 260/.76 requires a lot of drag? Shouldn't the VNAV simply calculate a more shallow descent path? Also since low descent speed is used to save fuel, if you have to use the speedbrakes more to make it work, doesn't that counteract the benefits? EDIT: The descent speed was selected quite a distance before the TOD. Is there anyway to get around the idle limitation? I thought I could solve it by binding the reverser detent to F1 but for some reason I have to hit F1 twice.

I have noticed this as well. I have the Saitek Throttle Quadrant and have mapped the reverser-notch (after the bottom end of the throttle range) to F1. On touchdown, after I've put the throttles in the F1-notch during the flare, the throttles are usually 30-something% and I have to cycle the F1 again to get them to fully idle. Is this a problem with my throttle-setup or something inherent in the NGX or actually prototypical?

Thanks for all the quick answers. I suspected this might be the case before, because one time the throttles were stuck at 47% N1 in the descent. Since then I set my hardware throttles to 0 during cruise. However, I think I've always had the "A/T OVERRIDE = NEVER" since that is the default, afaik? I've been able to manage the "overspeeds" without many issues, the point of my question was more to try to identify if something in my descent planning was incorrect or if a sim/outside sim issue was the cause. If you look at my two screenshots you can see that the winds on the ND correspond almost exactly with what I put in the descent forecast for that altitude. The 260IAS descent speed I chose because I've been told that the two 737 carriers in Norway use 260 descent speed as SOP. Also a few of the Swedish airport STAR charts/AIP advise on keeping 260IAS or less after crossover altitude. However I might have misunderstood this, since I know Braathens company procedure were to fly 280 in the descent. Also I should add that I had this "issue" with ECON SPD. I guess what puzzles me is that if the wind speeds I put into the DES FORECAST page match the "real world" why would the VNAV path be too steep? Well, one thing to note is that the speed was increasing at this moment in time and would probably stabilize at 290. Indeed the aircraft was on profile, but the profile was too steep for the aircraft to keep its speed. If this happened once in a while I could put it down to winds being different, but I've never had it not happened since I picked up FSX again. Maybe I'm overthinking it but I want to know if I'm doing something wrong, so that I can fix it, or whether something is wrong with my simulation.

Hi. I've recently started using the NGX again after a 6 month hiatus and I'm running into problems. Every time I'm descending the aircraft picks up speed compared to the VNAV DES TGT SPD and I get the "DRAG REQUIRED" message on the FMC, usually when descending through FL250-150. I've tested not using the speed brakes and I'll hit 290IAS or more, compared to my target of 260IAS. I use PFPX for the flight planning and ASN as weather. I add the winds from the DESCENT column of the briefing to the DES FORECAST page and also ISA DEV and QNH, and they seem to reasonably match whats in the simulator at the time of the descent, still I'm always overspeeding. Here are two screenshots that might help in identifying the issue (they are quite large so I linked them instead of embedding): http://s2.postimg.org/fsmnx3hk9/DESFORECST.jpg http://s12.postimg.org/f1k6n7p71/DRAGREQ.jpg I have the FSUIPC dynamic friction mod installed but since it shuts off automatically above 30kts, and affects only ground friction, I can't imagine it would be the culprit. What am I doing wrong here? I realize that you might have to use the spoilers once in a while, especially if ATC is involved but to me this seems like the VNAV is calculating descent paths that are too steep for the aircraft to handle. STAR for this flight was RASMU 3F to Malmö Sturup Airport (ESMS), but since it happens on almost every flight I doubt it has anything to do with this specific STAR. Cost index is "6". Thanks in advance.

After my old CH Rudder pedals deteriorated to the point where I would have uncommanded differential braking on one pedal and very unsmooth braking on the other I have finally made the switch to Saitek Combat Rudder Pedals. In Sweden, where I live, you can return the product within 14 days, if you are not satisfied, for a full refund. I would like to ask some questions to other Combat Rudder pedal users to see if I have received a good item or if I should return it. The first positive of the controller is that I can finally have functioning RTO braking on the PMDG aircrafts, which was an impossibility before because of the faulty CH pedals. 1. With the tension adjust wheel in the minimum setting the rudder axis stays about 500-600 units (in FSUIPC) to the left when the left rudder has been applied and then moved to center. If I move the rudder to the right the axis centers completely. 2. The rudder axis, with the axis added in FSX controls 60% sensitivity and 5% deadzone as per the install instructions, "stutters" slightly, about 20 units up or down. It goes all the way to max on both sides (16380). 3. Both brake pedals (axis added in FSUIPC as FSUIPC calibration) goes full min (-16384) and full max (16384) but every once in a while the axis might stay at -16200 if I let go of the brakes slowly). 4. With brake pedal axis added in FSX Controls, sensitivity at 80% and deadzone at 0% (as per Madcatz install instructions) the axis goes -135xx at release and 135xx at full application (around +-13550 on both extremes). My first question is whether the slight misalignment of the rudder pedal and the non-full range of the toe brakes, the minuscule flickering of the rudder axis in FSUIPC should worry me? Are these properties normal or do they tell of faulty potentiometers that might deteriorate in the future? I might sound paranoid but I want to make sure since I have the option of getting a new item. My other question is whether it would be better to skip the Saitek/Mad Catz instructions and assign the axis directly through FSUIPC calibration since I seem to get the full range (might not make a difference though) of the toe brake axis? Thanks in advance

Hi. Thank you and sorry for the late reply. If I understood your answer correctly the only available callouts after takeoff are: "Flaps 0 I A S 160/185/200/240 climb checklist to the line" I know that many European carriers use "high speed climb" or 210KIAS until FL150 and then either 5 knots less every 1000 feet or Pitch Hold 5 degrees. Flybe uses 210 KIAS, Tyrolean mostly 210 KIAS but also 185 (Intermediate climb) or 160 for terrain avoidance. Wideroe I think also use 210 commonly, but I'm awaiting confirmation from a pilot there. Of course it is not a big problem that "210 IAS" is unavailable during the climb checklist but if you ever get the chance to add that, I would appreciate it very much. Also thanks for considering the altimeter "issue".

Hi. I have 2 questions regarding the addon. 1: After acceleration height some operators would climb at IAS 210 knots, is it possible to call this during the after takeoff checklist (Flap 0 I A S 210)? Or do I have to independently call the speed after the checklist command? 2: I presume you would do the descent checklist when leaving cruise altitude (or thereabouts), but as the first item is "altimeters" this would prevent the FO from finishing the checklist until transition level. In Europe the transition level might be as low 5000 feet (probably lower in some countries) so the FO would not finish the other items until that time. Doesn't it seem more appropriate that the altimeter item should be lower on the checklist or "below the line" in Europe? Thanks in advance

I'm a bit late to the party, but I think I might have a good site that will help you get realistic routes in Europe. https://www.eurofpl.eu/ The website requires (free) registration. From what I've gathered it is linked to EUROCONTROL and CFMU, where all the IFR routes are validated, so there should be no unrealistic "simmy" routes. If you need charts and AIP, you can go to http://www.ead.eurocontrol.int/eadcms/eadsite/index.php.html and create a "EAD Basic" login and you will be able use documents from all countries within the Eurocontrol system. Hope that helps anyone in the future.

Yeah, I think I will do that as well. I just had another, identical ctd, but this time in cruise trying to finish the flight that failed before :( (Actions done at the time of the fatal error was the descent checklist)

I was going to make a new thread but as we seem to have similar problems I'll write here.This is the error I'm getting while on climbout from ENVA (Trondheim Vaernes X from Aerosoft)Problem signature: Problem Event Name: BEX Application Name: fsx.exe Application Version: 10.0.61472.0 Application Timestamp: 475e17d3 Fault Module Name: StackHash_0a9e Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: 00000000 Exception Code: c0000005 Exception Data: 00000008 OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 1053 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789The CTD was quick, not the usual freeze "not responding" symptoms and then a Fatal Error pop-up but immediate.The error happened just after I told the FO to "Set Altitude Two Six Thousand" at maybe 6000 feet so away from the airport.First time I've had this CTD happen but I did do a reinstall of FS2Crew and the SP1C patches for 738/900NGX and 737/600 just before the flight.EDIT: To clarify I reinstalled the SP1C patch for NGX & 700/600 and uninstalled FS2Crew NGX vanilla and installed the new SP1 following the order in the change log.

Hi.I just had a FSX Fatal error:Problem signature: Problem Event Name: BEX Application Name: fsx.exe Application Version: 10.0.61472.0 Application Timestamp: 475e17d3 Fault Module Name: StackHash_0a9e Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: 00000000 Exception Code: c0000005 Exception Data: 00000008 OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 1053 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 The CTD was quick, not the usual freeze "not responding" symptoms and then a Fatal Error pop-up but immediate.The error happened in climb just after telling the FS2Crew FO to "Set altitude two six thousand". I've made a thread in the FS2Crew forums as well but as I followed their instructions to reinstall the SP1C patch for 738/9 and 737/6 it feels like it could be a NGX related problem.

I wanted to make sure it wasn't my hardware that was causing the problems so i turned off my OC and turned my memory down to a lower value (1866, they are stock rated at 2133: 9-11-10-28-2t). I fired up the sim and did a circuit with both the default 738 and NGX: No stutters!One thing was different in the sim compared to my previous tests though, it was spring now instead of winter. I wanted to be 100% sure it wasn't a software/sim issue so I changed the season to winter and did another circuit: The stutters/freezes were back.Can something in the scenery winter textures cause these problems?I wanted to make sure it wasn't my hardware that was causing the problems so i turned off my OC and turned my memory down to a lower value (1866, they are stock rated at 2133: 9-11-10-28-2t). I fired up the sim and did a circuit with both the default 738 and NGX: No stutters!One thing was different in the sim compared to my previous tests though, it was spring now instead of winter. I wanted to be 100% sure it wasn't a software/sim issue so I changed the season to winter and did another circuit: The stutters/freezes were back.Can something in the scenery winter textures cause these problems?

Ben: I have the OS/FSX running on a SSD, so no defragging :)Ryan: I'm running AA 8xS in nvidiainspector and when i checked the transparency settings Transparency Multisampling is disabled, and Transparency Supersampling is off/multisampling.Also when encountering these jerks I'm usually not 100% on the GPU and not even close to full VRAM usage in GPU-Z (500-600MB or so), but on the task manager CPU usage is hitting 100%, is this normal or can it be a CPU problem?

Hi.I read a thread a while ago where someone had problems with hard stutters (freeze for half a second - 1 second or so) on approach. I have had very good performance from the NGX after some initial tweaks but there is one airport that is still causing problems: Trondheim Vaernes X.I realize that this is the PMDG forum and not Aerosoft but I've already posted a thread on the Aerosoft forums a long time ago received no successful help, plus there are a lot of very competent individuals roaming around these forums so I usually like to go here for help :)Anyway, I'd just like to rule out whether this problem is on my side only or if others have similar issues on ENVA.To test I'd like if someone that owns the airport could do a LH circuit with the NGX on runway 09, for me the stutters are felt when turning and especially if i turn my viewpoint by 90+ degrees.Some extra information:I'm running autogen at very dense and water at 2xLow. Tweaks are the normal bojote ones with Texture_Max_Load at 4096. But even with a clean cfg and different nvidia inspector settings I still encounter the stuttering.Also fsuipc autosave is disabled.Thanks in advance

I read though that newer more powerful cards like the GTX 480 etc gained more from using Rejectthreshold. Isn't this true?

Hi, I did a similar thread in the Monitor/GPU forum but as I know there are so many competent individuals on this forum I thought I'd make the thread here, I hope thats okay with the moderators.I have 2 questions:1. After having some initial problems with my RAM ive reinstalled FSX and am now in the process of applying tweaks. I've followed NickN's guide on nvidia inspector settings and also used bojotes fsx.cfg tweak (with some changes).Tweaks used:RejectThreshold=131072Highmemfix=1Texture_bandwidth_mult=40Texture_max_load=4096ForceVsyncfullscreen=1-||- windowed=0The rest is per the bojote tweak for a HT off 4.3ghz + CPU etc, but with affinitymask disabled.Frames in FSX are set to unlimited with anti_lag limiting FPS at 30When using the NGX at some test airports like UK2000 EGPH/ AS ENGM im never above 1400/1300MB VRAM but when at Aerosoft ESSA it goes up to 1522MB as maximum.Thats dangerously close to the max VRAM of my GTX 480, what can I do to get the usage down to a more "safe" level? I feel like if i continue running the settings as I have the right now I will run into OOM errors etc.FSX display settings are the recommended by NickN setup but with High 2x. Water and Autogen at Dense.Nvidia inspector settings are: 8xS AA, Transparency set to off/Multisampling, and AF 16x. I'd like to keep it like this because I don't like the tree shimmering on lower settings.2. In Ryans sticky it says to put transparency at 4xSupersampling, wouldn't this decrease performance?EDIT: I upped the Rejectthreshold to 256KB and also put Autogen back to VDense, but at ESSA the VRAM was now only about 1100MB, why is this?EDIT2: I have REX cumulus and cirrus clouds at 2048.Thanks in advance

Hi, I'm not sure whether this topic is in the right place, if not please moderators help me put it where it is supposed to be :)After having some initial problems with my RAM ive reinstalled FSX and am now in the process of applying tweaks. I've followed NickN's guide on nvidia inspector settings and also used bojotes fsx.cfg tweak (with some changes).Tweaks used:RejectThreshold=131072Highmemfix=1Texture_bandwidth_mult=40Texture_max_load=4096ForceVsyncfullscreen=1-||- windowed=0The rest is per the bojote tweak for a HT off 4.3ghz + CPU etc, but with affinitymask disabled.Frames in FSX are set to unlimited with anti_lag limiting FPS at 30When using the NGX at some test airports like UK2000 EGPH/ AS ENGM im never above 1400/1300MB VRAM but when at Aerosoft ESSA it goes up to 1522MB as maximum.Thats dangerously close to the max VRAM of my GTX 480, what can I do to get the usage down to a more "safe" level, I feel like if i continue running the settings as I have the right now I will run into OOM errors etc.FSX display settings are the recommended by NickN setup but with High 2x. Water and Autogen at Dense. Nvidia inspector settings are: 8xS AA, Transparency set to off/Multisampling, and AF 16x. I'd like to keep it like this because I don't like the tree shimmering on lower settings.Also one question: in the PMDG Forum sticky it says to put transparency at 4xSupersampling, wouldn't this decrease performance?Thanks in advance

I just did an 11 hour long prime95 blendtest with 0 warnings and 0 errors. Must've been the command rate that was wrong. That one single setting can make the whole computer so unstable, fascinating :)Anyway, thanks so much all for helping me sort out this problem!One last question: Seeing as my Ram couldn't take a single setting being tighter than its specifications, should I return the ram and get a kit with more "slack" or will these be fine and stable for a long time?

Thanks for helping Peter.My Ram is running per its specifications: Clock, timings and voltage. I was running it with a Command Rate of 1T instead of its default 2T because that was not stated anywhere I could find.I'm now running it at 2T as well and will do a prime95 overnight run to check if its stable at default.The Ram is factory overclocked to 2133Mhz and the reason why I chose this type of Ram is because I've read and heard that performance ram can make a difference with FSX performance, especially stutters. Regardless if that is true or not, the ram was still as cheap or close to lower performance ram, so why not go for it?

Yeah Dario, those are the RAMs I use, and they are set to 1T. I'll switch to 2T but wont that decrease the performance a lot?

The ram sticks are rated at 2133/9-11-10-28, the speed im running them at. If they can't handle that I will have to send them back.I just checked on my computer after an overnight prime95 blendtest and it had rebooted, minidump folder had one .dmp file; how do I read it?As the sticks don't fail memtest but prime95 could it be mobo-related? Maybe I need to increase a voltage somewhere?EDIT: I found a way to read the .DMP file and it said stop code 0x124. Isn't that low vcore?