I had similar problem Gawick-Cork. In the 747X could get to FL380 easy, on this flight I noticed T/C & T/D were almost together & I only managed FL250 before descent. ASE weather engine with REX textures-Gatwick & Cork Extreme-ENB-Ezdok.With same set up, Dublin-Edinburgh, no issues. Edinburgh Extreme also.On another flight I got unable next altitude, only needed 8000ft climb with 56miles to go from FL260. Empty aircraft load & light fuel 10000lbs! Ground temp at departure 12c/54F, Gatwick 200above sea level. TST at FL260 -25. Tried de ice just in case but made no difference.Sim running very smooth with good frames 25-28 much better than 747x so it beats me!Also getting the same issue with mouse & after saving flight FSX crashes, every time. Not had that before ever.Intoduction read, Loaed all pop ups during install + added files to cfg. Sent cfg to be adjusted as per intro!Also had some serious trouble with contollers for some reason & I'm still working on that. Everything worked great on the 747x.

I exactly have the same issues as well. I followed every instruction in the intro document as well. PMDG 747-400X on the same system and on the same flight works great. I have no add-ons except for PMDG 747-400x, 737NGX and FSUIPC (unregistered)

Well I guess this means PFC hardware users are hosed. Are hardware goes from pfc.dll to fsx with I believe some interface with fsuipc. No simconnect though..... Dang.

What I said is if you decide to go outside FSX and native Windows/drivers utilities THEN make sure you know what you are doing....

Ok, I have confirmed this issue as well. I will be watching for a fix. I use FSUIPC for too many things to disconnect it.

I exactly have the same issues as well. I followed every instruction in the intro document as well. PMDG 747-400X on the same system and on the same flight works great. I have no add-ons except for PMDG 747-400x, 737NGX and FSUIPC (unregistered)

Sorry about above. I've sorted climb problems. The 747 was very simplified & automated when it came to CDU use & the FMC. So I looked closely on a flight with respect to my entries in the CDU & I could sees that I was missing certain inputs. I've since done six flights taking care to fill every line during the CDU inputs & the aircraft has performed as it should. With a combination of weights, fuel loads it was spot on. So, try for yourself, I'm sure that climb problems will improve for you too.

Well now with a clean install of FSUIPC, this thrust problem hasn't come back, and I can use LINDA to connect my VRInsight MCP to the NGX (super sweet). This is great for my enjoyment of the NGX, but bad for troubleshooting. One thing I also realized is that I was using too high of a Cost Index (90) which might account for some of the high altitude thrust problems: the CLB mach speed was probably set too high to get much climbing done. I think I remembered this CI value from the Airbus, which uses a totally different numbering scheme.

hi everyone, i just found out about the fsuipc issue, anyone found a way to fix it yet? i just bought the 737 a couple of days back. pls let me know. cheers henry

Fix the FSUIPC problem? Easy: don't calibrate your controllers through FSUIPC. I'm not being glib or disrespectful. This aircraft does not need FSUIPC for controller calibration. (If you find that your other aircraft do work better with FSUIPC, fine, there's a checkbox in FSUIPC that allows you to set up an individual aircraft the way you want it.)

Fix the FSUIPC problem? Easy: don't calibrate your controllers through FSUIPC.

I was having these thrust problems without doing any calibration through FSUIPC, only axis assignment. There was some other bad juju between the NGX and FSUIPC that was not related to calibration.

When I got the first wide beta build, I performed my usual FSUIPC calibration routine. I had problems with my rudder pedals and throttle quadrant similar to what others are reporting now. The first step in troubleshooting was to remove the offending controller. Problems disappeared. The next step was to delete my FSUIPC settings specific to the NGX and reconnect the controllers. I then experienced the kind of problems I've always had, and why I was using FSUIPC for controller calibration in the first place. I then installed the latest CH drivers. Problem solved. No jittery throttle, no jittery rudder, significantly reduced jitter in the toe brakes, which I solved by increasing the toe brake null zone in FSX. Bottom line, there should be no path for controller information through FSUIPC for the NGX. Period. Axis assignment? No. Joystick Calibration? No. You cannot "disable" FSUIPC for just one aircraft, but you can avoid enabling it. In other words, if you have your FSUIPC set up so that your controller information goes through it for all aircraft, then you're going to have problems with the NGX. The solution, when you have aircraft that apparently "need" FSUIPC (not saying they do, but it's a common enough solution), then you must enable the joystick settings for each of those aircraft individually. No one is suggesting that you get rid of FSUIPC, which serves a good many highly useful functions. A number of high quality add-ons require it, and at least one high quality add-on requires you to run your throttle axes through FSUIPC with excellent results. What I'm suggesting, based on what I learned while testing the NGX and from some very clear conversations with EV and others, is that FSUIPC must be used judiciously. The NGX has been coded so that FSUIPC is not needed for controller calibration, so you just need to configure FSUIPC so that your controller data doesn't pass through FSUIPC while you are using the NGX.

When I got the first wide beta build, I performed my usual FSUIPC calibration routine. I had problems with my rudder pedals and throttle quadrant similar to what others are reporting now. The first step in troubleshooting was to remove the offending controller. Problems disappeared. The next step was to delete my FSUIPC settings specific to the NGX and reconnect the controllers. I then experienced the kind of problems I've always had, and why I was using FSUIPC for controller calibration in the first place. I then installed the latest CH drivers. Problem solved. No jittery throttle, no jittery rudder, significantly reduced jitter in the toe brakes, which I solved by increasing the toe brake null zone in FSX. Bottom line, there should be no path for controller information through FSUIPC for the NGX. Period. Axis assignment? No. Joystick Calibration? No. You cannot "disable" FSUIPC for just one aircraft, but you can avoid enabling it. In other words, if you have your FSUIPC set up so that your controller information goes through it for all aircraft, then you're going to have problems with the NGX. The solution, when you have aircraft that apparently "need" FSUIPC (not saying they do, but it's a common enough solution), then you must enable the joystick settings for each of those aircraft individually. No one is suggesting that you get rid of FSUIPC, which serves a good many highly useful functions. A number of high quality add-ons require it, and at least one high quality add-on requires you to run your throttle axes through FSUIPC with excellent results. What I'm suggesting, based on what I learned while testing the NGX and from some very clear conversations with EV and others, is that FSUIPC must be used judiciously. The NGX has been coded so that FSUIPC is not needed for controller calibration, so you just need to configure FSUIPC so that your controller data doesn't pass through FSUIPC while you are using the NGX.

PFC hardware requires fsuipc to communicate with FSX. Thus without fsuipc the PFC hardware which mind you costs a lot of money cannot work. FSX does not otherwise recognize the hardware. This is I guess the reason vnav was completely hosed up and did not work, throttles did not ever go below 42%, plane took a few hundred miles to get to cruise, gear and spoilers dont work etc..... Without being able to use fsuipc with this plane, its basically a waste of 70 bucks for users of certain hardware.

Without being able to use fsuipc with this plane, its basically a waste of 70 bucks for users of certain hardware.

Sure, for many of us, disabling FSUIPC is simply not an option. However, completely disabling it is not necessarily required. I am currently using FSUIPC just fine with the NGX after doing a clean install and generating a new default fsuipc.ini file. I am using FSUIPC with LINDA to map the knobs and switches of my VRInsight MCP and it's working beautifully. I am also continuing the process of trying to figure out exactly which FSUIPC features/settings are the ones that are tripping up the NGX thrust management. Once we can isolate the exact cause, then nobody will have to use the "big stick" approach of completely diasabling FSUIPC to get the NGX to behave.

Eric, In that case, I recommend submitting a support ticket.

Eric, In that case, I recommend submitting a support ticket.

Yes, I suppose I will when I get a chance tomorrow. There is a fair share of people having issues with the ngx and fsuipc interaction including apparently some beta testers yet the issues tracking thread mentions nothing. If the interaction (or lack thereof) with fsuipc was made public prior to release that would have helped in at least my purchase desicion. I think It is not right that they dont share the fact that the ngx will not run properly if your hardware is dependent on fsuipc to interact with fsx.

\I think It is not right that they dont share the fact that the ngx will not run properly if your hardware is dependent on fsuipc to interact with fsx.

This is not completely true. Sure, PMDG can -- and should -- mention that there are *possible* issues with the NGX and some configurations of FSUIPC. But me (and at least 3 other virtual pilots I know) have the NGX working just fine with FSUIPC and our add-on hardware. So it's unfair to make a blanket statement that NGX is always incompatible with FSUIPC or that your add-on hardware won't work. Hopefully we'll be able to isolate the specific problem soon.