MrGreen

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