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.