Jump to content
The simFlight Network Forums

PMDG 737 MSFS 2020: Climb rate reduced when FSUIPC7 running


GuyNeild

Recommended Posts

6 hours ago, John Dowson said:

Ok - Unused is an option in axes assignment when assigning direct to FSUIPC calibration. I guess this is used when there is no assignment to the axes itself, but when you have button control assignments to axes ranges. So this is nothing to worry about.

And this is exactly my case (e.g. the landing gear lever, with the DOWN, OFF and UP positions), but thanks for the confirmation.

One other thing I noticed about the spoiler axis calibration: I moved the lever full range back and forth, to set the bottom and top values. But when I operate it (in flight), I can see it traveling only between the "UP" and the "FLIGHT DETENT" position ... although there is still a portion to go ...

Link to comment
Share on other sites

1 minute ago, Eugenio Remus said:

One other thing I noticed about the spoiler axis calibration: I moved the lever full range back and forth, to set the bottom and top values. But when I operate it (in flight), I can see it traveling only between the "UP" and the "FLIGHT DETENT" position ... although there is still a portion to go ...

You need to use logging to see what is happening (i.e. controls being sent)... Best to do this in real-time with the logging console window open. But I suspect that this is becaue you are using the standard spoiler control. I don't think this is 100% reliable for the PMDG 737. Looking on HubHop, there is a potentiometer preset for the spoilers: PMDG B737 Spoiler Lever Set

image.thumb.png.d684673c822c0100853cd333761aae0d.png

As indicated in the comments, this is for an axis range of 20 to 1023. You should copy this preset definition, change to your axis range, and add the preset to your myevents.txt file and use/assign to this instead of the standard spoilers control. Also please remove/reset any calibration on the spoilers you have in the FSUIPC calibration panel.

If the spoilers aren't properly stowed, could this be the cause of the lack of airspeed?

Link to comment
Share on other sites

11 minutes ago, John Dowson said:

As indicated in the comments, this is for an axis range of 20 to 1023. You should copy this preset definition, change to your axis range, and add the preset to your myevents.txt

To be clear, if you have a standard axis range of -16383/4 -to +16383, then the preset would be:

My PMDG B737 Spoiler Lever Set#@ 16383 + 32.768 / near 0 max 100 min s0 l0 5 < if{ 679101 (>K:ROTOR_BRAKE) quit } l0 10 < if{ 679201 (>K:ROTOR_BRAKE) quit} l0 50 < if{ quit } l0 70 < if{ 679301 (>K:ROTOR_BRAKE) quit } l0 95 < if{ 679401 (>K:ROTOR_BRAKE) quit } 679501 (>K:ROTOR_BRAKE)

Adjust as needed.

Link to comment
Share on other sites

It's a sophisticated way, but I am not that kind of tech guy. I pasted the line you wrote into the myevents.txt file, then I removed the ordinary axis assignment, and opted for the "Send to FS as a preset" option for such axis (and I could select my brand new preset ....), also removed the previous axis calibration as per your suggestion. But that setting could not move the spoiler lever at all ... 

So I went for something less refined, but that could be enough for my needs and - above all - to overcome the climb/accelerate issues ,,, so I set the spoiler axis as "unused" and programmed five button ranges for the PMDG presets "DOWN, ARMED, 50 %, FLIGHT DETENT, UP" and so I could finally see the lever moving along its full range of motion, along with the physical joystick lever.

I will tell you if this will work and keep me away from trouble. 

I will leave it to other (and more tech-proficient) simmers to implement your suggestion, but thanks anyways. 

Link to comment
Share on other sites

16 hours ago, Eugenio Remus said:

But that setting could not move the spoiler lever at all ... 

Sorry, there is a mistake in that preset - you need to divide by 327.68 and not 32.768. Try:

My PMDG B737 Spoiler Lever Set#@ 16383 + 327.68 / near 0 max 100 min s0 l0 5 < if{ 679101 (>K:ROTOR_BRAKE) quit } l0 10 < if{ 679201 (>K:ROTOR_BRAKE) quit} l0 50 < if{ quit } l0 70 < if{ 679301 (>K:ROTOR_BRAKE) quit } l0 95 < if{ 679401 (>K:ROTOR_BRAKE) quit } 679501 (>K:ROTOR_BRAKE)

I have actually looked into this before, and that preset should allow movement between the 4/5 notched positions. For complete smooth axis control, you need to assign with 'Send to FS as normal axis' using the Axis Spoiler Set control, and remove any calibration on the spoilers. See 

Otherwise, you can keep using the button controls on the axis range if that works ok for you.

Did you get any further on the loss of airspeed issue? Did you try the logging I suggested?

Link to comment
Share on other sites

yes, I kept the button controls on the axis range, since those positions will satisfy most needs during flight.

Unfortunately that seems to get in my way again.

With the spoiler controlled via buttons preset along an "unused" axis, I still have my climb choked.

It is enough for me to close FSUIPC as soon as I see the darn "STAB OUT OF TRIM" light blinking, and to re-launch it a few seconds after, and then it's all right ... it's definetely weird.

What should I now include in the log ?

 

Link to comment
Share on other sites

On 1/14/2024 at 1:11 AM, Eugenio Remus said:

What should I now include in the log ?

Add logging for offsets 0BB4 (ELEVATOR DEFLECTION PCT) and 0BC0 (ELEVATOR TRIM PCT) as S16 using the Log->Offsets facility, and maybe also 0BC2 (ELEVATOR TRIM INDICATOR) also as S16. Also activate logging for Axes Controls. When you get the issue and restart FSUIPC7 and everything is working as expected, zip up your FSUIPC7_prev.log and FSUIPC7.log files and show them to me.

John

Later: maybe also the spoiler positions, offsets 0BD4 and 0BD8 as U32. You can only log 4 offsets at a time, so maybe drop 0BB4.

Edited by John Dowson
Later added
Link to comment
Share on other sites

And what I can tell you after a few more flights, is that I mustn't switch FSUIPC back on too fast, or the problem will persist.

The aircraft needs a firm grip on the "free" climb before FSUIPC can be run again harmlessly.

Hope it makes sense according to your findings ... 

Link to comment
Share on other sites

Your logs show the elevator trim decreasing in your prev log file, down to -4208, and when you restart it gradually increase slightly to -2788. I would guess its the AP controlling this, and there is not much difference between the values after the restart so I don't think this can be causing the issue. The spoiler offsets remain at 0, so this looks ok, although maybe PMDG aircraft don't use these offsets - I will check the PMDG SDK/offsets to see if there is anything there to log which could be useful. For now, drop those (0BD4 and 0BD8) and add 0BB4.

Looks like you didn't set logging for Events and Axis Controls. Can you set logging for these please

15 hours ago, Eugenio Remus said:

And what I can tell you after a few more flights, is that I mustn't switch FSUIPC back on too fast, or the problem will persist.

The aircraft needs a firm grip on the "free" climb before FSUIPC can be run again harmlessly.

Were those logs attached when the problem persists or went away? Seems it was restarted quite soon - after 10 seconds or so....

Link to comment
Share on other sites

I am not sure what the stabilizer is or what controls this, but I think this is not related to the elevator trim. Can you log the following offsets, both as U8, to see if these change:
    6600 - MAIN_annunSTAB_OUT_OF_TRIM
    6C3C - TRIM_StabTrimMainElecSw_NORMAL
    6C3D - TRIM_StabTrimAutoPilotSw_NORMAL
    6C68 - TRIM_StabTrimSw_NORMAL

These are the PMDG controls relating to the stabilizer:

Quote

 

// Control Stand
#define EVT_CONTROL_STAND_STABTRIM_ELEC_SWITCH            (THIRD_PARTY_EVENT_ID_MIN + 709)    
#define EVT_CONTROL_STAND_STABTRIM_ELEC_SWITCH_GUARD    (THIRD_PARTY_EVENT_ID_MIN + 710)    
#define EVT_CONTROL_STAND_STABTRIM_AP_SWITCH            (THIRD_PARTY_EVENT_ID_MIN + 711)    
#define EVT_CONTROL_STAND_STABTRIM_AP_SWITCH_GUARD        (THIRD_PARTY_EVENT_ID_MIN + 712)    
...

// FLT  DK DOOR Panel
#define EVT_STAB_TRIM_OVRD_SWITCH                        (THIRD_PARTY_EVENT_ID_MIN + 830)
#define EVT_STAB_TRIM_OVRD_SWITCH_GUARD                    (THIRD_PARTY_EVENT_ID_MIN + 831)

 

Maybe also check the state of those stab trim switches in the VC. We can also check for those events that control the stab trim switches in your log, once logging for Events has been activated (they will be logged as ROTOR BRAKE controls with the parameter indicating the event).

Link to comment
Share on other sites

The offsets were monitored in the FSUIPC7.log file, but not in the FSUIPC7_prev.log file. And although these offsets were monitored in the 2nd log file, the values never changed from 0. This is because you have not activated the additional FSUIPC offsets for PMDG - can you do this please. Instructions are in the Offset Mapping for PMDG 737-700.pdf document.

The only suspicious event I can see in both log files is this:

Quote

    28562 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679101 (0x000a5cbd) ROTOR_BRAKE

This is a "Spoilers down" control. Do you know where this is coming from?

Can you repeat again with the PMDG offsets enabled, and also check the spoilers position as well as the state of the stab controls in the VC.

Link to comment
Share on other sites

On 1/20/2024 at 12:23 PM, John Dowson said:

The only suspicious event I can see in both log files is this:

This is a "Spoilers down" control. Do you know where this is coming from?

 

I might have moved on purpose the spoiler lever to make sure I left it in the "UP" range.

Okay I modified the PMDG .ini as requested and here you go with another couple logs, after I upgraded to the last FSUIPC version published. Events, Axes and Offsets (the four you asked for) were requested.

You will probably see the elevator trim value to descend from the takeoff setting (higher than 5) to almost below 1.

Then I switched FSUIPC off and could see the elevator trim getting back to a setting that's convenient for a climb, in fact the a/c that had almost leveled up started to climb again and reached the commanded speed of 250 kias.

I heard the noise and could also see the elevator trim wheels spinning to reflect that change of value.

I also moved the spoiler lever up (to the flight detent position) and back down, to make sure it wasn't interfering with the climb. 

In theory, it looked raised and stwowed ... in practice, I don't know ...

Maybe you can find what's the disturbing - yet temporary factor. 

Needless to say, when I re-launched FSUIPC,  this didn't prevent the normal climb to continue.

Looking forward to hear from you.

FSUIPC7_log (2).zip FSUIPC7_prev (2).zip

Link to comment
Share on other sites

First, can you add
   DontLogThese=67030,67038,67039,67040,67227
to the [Profile.B737PMDG] section of your FSUIPC7.ini - this will prevent the LIGHT_POTENTIOMETER_SET and LIGHT_POTENTIOMETER__*_SET events from being logged, which are of no interest and are filling your log files.

21 hours ago, Eugenio Remus said:

I might have moved on purpose the spoiler lever to make sure I left it in the "UP" range.

Okay, but this is strange as the controls logged are for spoilers down, not up...

The offset logging shows that both offsets 6C3C (TRIM_StabTrimMainElecSw_NORMAL) and 6C3D (TRIM_StabTrimAutoPilotSw_NORMAL) held a value of 1 both before and after the restart, and the other two offsets never changed value from 0. Did you not get the STAB OUT OF YTIM warning on this flight? It seems not, so this was another red herring...

21 hours ago, Eugenio Remus said:

Then I switched FSUIPC off and could see the elevator trim getting back to a setting that's convenient for a climb, in fact the a/c that had almost leveled up started to climb again and reached the commanded speed of 250 kias.

Ok, so you think that it is the elevator trim that is causing this issue? We did monitor the elevator trim offsets in a previous test and the values, and therefore the elevator trim settings, were the same values just before you stopped FSUIPC and when you restarted, so it looked like the trim hadn't changed, so I am confused now...

21 hours ago, Eugenio Remus said:

You will probably see the elevator trim value to descend from the takeoff setting (higher than 5) to almost below 1.

I cannot tell the trim setting (not logged!), but these are the control stand trim wheel controls (678), and show a 'mouse move' (03) action:

Quote

   917922 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   917954 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   917985 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918016 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918063 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918094 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918125 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918172 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918282 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918313 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918532 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
   918563 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE

The controls being sent before the restart were these:
   984844 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE
These are also from the control stand wheel trim...also logged when you restart.

   985672 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 200703 (0x00030fff) ROTOR_BRAKE
This is a control to hide/show the captain's yoke. Not  sure why there are so many of these...

Spoiler/speed brake controls are here:

Quote

   943532 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679201 (0x000a5d21) ROTOR_BRAKE - SPEED_BRAKE_LEVER_ARM
   943844 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679301 (0x000a5d85) ROTOR_BRAKE - SPEED_BRAKE_LEVER_50PCT
   943860 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 6364 (0x000018dc), Param2= 0 (0x00000000) SPOILERS_SET
   943907 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 7928 (0x00001ef8), Param2= 0 (0x00000000) SPOILERS_SET
   943954 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 9492 (0x00002514), Param2= 0 (0x00000000) SPOILERS_SET
   944032 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 9688 (0x000025d8), Param2= 0 (0x00000000) SPOILERS_SET
   944047 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679401 (0x000a5de9) ROTOR_BRAKE - SPEED_BRAKE_LEVER_FLT_DET
   944079 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 11252 (0x00002bf4), Param2= 0 (0x00000000) SPOILERS_SET
   944125 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 12523 (0x000030eb), Param2= 0 (0x00000000) SPOILERS_SET
   944188 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679501 (0x000a5e4d) ROTOR_BRAKE - SPEED_BRAKE_LEVER_UP
   944594 Lvars received: 2065 L:vars & 0 H:vars now available
   945688 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679501 (0x000a5e4d) ROTOR_BRAKE - SPEED_BRAKE_LEVER_UP
   945891 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679401 (0x000a5de9) ROTOR_BRAKE - SPEED_BRAKE_LEVER_FLT_DET
   945954 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679301 (0x000a5d85) ROTOR_BRAKE  - SPEED_BRAKE_LEVER_50PCT
   945985 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 10926 (0x00002aae), Param2= 0 (0x00000000) SPOILERS_SET
   946047 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 9688 (0x000025d8), Param2= 0 (0x00000000) SPOILERS_SET
   946157 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679201 (0x000a5d21) ROTOR_BRAKE - SPEED_BRAKE_LEVER_ARM
   946204 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 8091 (0x00001f9b), Param2= 0 (0x00000000) SPOILERS_SET
   946282 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 6527 (0x0000197f), Param2= 0 (0x00000000) SPOILERS_SET
   946313 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 5620 (0x000015f4), Param2= 0 (0x00000000) SPOILERS_SET
   946344 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 679101 (0x000a5cbd) ROTOR_BRAKE - SPEED_BRAKE_LEVER_DOWN
   946375 ***  AXIS: Cntrl= 65786 (0x000100fa), Param1= 0 (0x00000000), Param2= 0 (0x00000000) SPOILERS_SET

So it looks like the speed brake is/was in the down position when you stopped FSUIPC....

So it looks like we are back to it being either the elevator trim or the spoilers/speed brake that is causing a decreased climb rate. Can you monito/check those settings both before you exit FSUIPC and again when you restart. Maybe also add offset logging back for these:
    0BC0 as S16 (Elevator Trim Pct)
    2EA0 as FLT64 (Elevator Trim Position)
    0BD0 as U32 (Spoilers Handle Position)

I will also ask Pete about this to see if he has any ideas...

John



    

Link to comment
Share on other sites

It would also be useful if the first log showed the reduced climb rate, as is usual, the aircraft recovers the climb rate when FSUIPC is stopped, and the second log shows the climb rate reducing again. Try not to touch the controls after the restart. The second log would then show the elevator trim and spoiler positions on start-up, and if these change as the climb rate reduces, and we can then see the controls that are causing this and hopefully determine where they are coming from....

John

Link to comment
Share on other sites

2 hours ago, John Dowson said:

It would also be useful if the first log showed the reduced climb rate, as is usual, the aircraft recovers the climb rate when FSUIPC is stopped, and the second log shows the climb rate reducing again. Try not to touch the controls after the restart. The second log would then show the elevator trim and spoiler positions on start-up, and if these change as the climb rate reduces, and we can then see the controls that are causing this and hopefully determine where they are coming from....

John

Mind you, when I re-start FSUIPC the a/c flies under autopilot (LNAV and VINAV) so I needn't touch any control. As a matter of fact, I switch on the A/P short after passing 1,000 ft AGL, as per good common practices. Everything that happens - the handicaped climb that sees the a/c leveling off and the elevator trim descending from the T/O value to below 1 - happens under autopilot and autothrottle. You saw changes in the spoiler settings because I actioned the lever from DOWN to UP going thru the other positions, just to make sure that I was to take off with the spoiler down ...

As for the elevator trim, I may be in need to adjust it after takeoff if I want to engage the A/P, because if you set the PMDG parameter "realistic A/P engagment" the A/C must be properly trimmed, and this means you must not apply significant actions on the yoke (on the elevator, especially), if you want to engage the A/P

Hope this helps, and of course I will go on testing.

I think I should also totally clear any hardware assignment to the spoiler: after all, I don't need it for take-off ... do I ?

So if I can take-off and climb "normally" then we know that it's the way I am controlling the spoiler axis that gets in my way.

This can be done without any particular offset logging ... so it's worth trying, and maybe it will be the very first test I take.

Link to comment
Share on other sites

15 hours ago, Eugenio Remus said:

I think I should also totally clear any hardware assignment to the spoiler: after all, I don't need it for take-off ... do I ?

So if I can take-off and climb "normally" then we know that it's the way I am controlling the spoiler axis that gets in my way.

Yes, sounds like a good idea. The A/P, once engaged, should be controlling the trim, so I don't think its this that can be causing your issue.

15 hours ago, Eugenio Remus said:

This can be done without any particular offset logging ... so it's worth trying, and maybe it will be the very first test I take.

Logging is always useful - sometimes the visuals in the VC can be different from the actual setting in the a/c, so worth monitoring, and it costs nothing.

John

Link to comment
Share on other sites

On 1/23/2024 at 6:29 PM, John Dowson said:

It would also be useful if the first log showed the reduced climb rate, as is usual, the aircraft recovers the climb rate when FSUIPC is stopped, and the second log shows the climb rate reducing again. Try not to touch the controls after the restart. The second log would then show the elevator trim and spoiler positions on start-up, and if these change as the climb rate reduces, and we can then see the controls that are causing this and hopefully determine where they are coming from....

John

No this cannot happen like you described it ! The first log will show the reduced climb rate and the elevator trim getting down from T/O value to below 1 ... when the 737 has leveled off, and it can't climb anymore, so I am basically stuck ... it's then when I need to exit FSUIPC, and as soon as I do it (well let's say it takes a few seconds) the a/c goes back to regular climb rate (in fpm) and the elevator trim gets back to higher values, maybe not around 5, which is a common average given normal fuel and payload, but at least around 4.

That you can see by comparing the logs, because that's also what I witness.

What is set, or reset, by restarting FSUIPC  ... that I don't know.

What do you want me to monitor for the next tries ?

Unfortunately, having NO assignments whatsoever for the elevator trim and even NOTHING for the flaps has given me success.

 

Link to comment
Share on other sites

John, I got news.

I have been on a PMDG support forum where a guy last December started a S.O.S. thread and described a situation quite identical to mine, including the "STAB OUT OF TRIM" alert.

In the end he simply removed his FSUIPC.ini and went flying with a regenerated FSUIPC.ini and he said the a/c was behaving okay.

He wasn't able - that way - to tell what parameter, control, offset or else had gone wrong.

I have no problems with making the same experiment, but ... shall I then reprogram all the hardware assignments (axes and buttons) from scratch ?!?!

Link to comment
Share on other sites

I am aware that FSUIPC can reset all the settings to the default values; I guess this doesn't erase any user assignment ... does it ?

And if doesn't, and the assignments stays in place ... what if the culprit is among the assignments, that are not erased ?

The reset to defaults operation would be of no use.

Am I correct ?

Eu

Link to comment
Share on other sites

Looks like I fixed it.

I edited the "bugged" fsuipc.ini and came out with a "straighter" version of it.

And the aircraft made one normal flight. Tomorrow I will rehearse.

I enclose both .ini (in a zip) so that your supreme knowledge after comparing them will likely determine what wrong setting was "blocking" the climb, for me and other people to know and to stay away from ...

Thanks for your kindness and your dedication and your support.

Eu

FSUIPC7.zip

Link to comment
Share on other sites

On 1/28/2024 at 12:21 AM, Eugenio Remus said:

I edited the "bugged" fsuipc.ini and came out with a "straighter" version of it.

And the aircraft made one normal flight. Tomorrow I will rehearse.

I enclose both .ini (in a zip) so that your supreme knowledge after comparing them will likely determine what wrong setting was "blocking" the climb, for me and other people to know and to stay away from ...

The only differences between the two ini files that I can see that could affect your PMDG profile are:

1. Flaps calibration: in your old/bugged in you have flaps ranges calibrated:

Quote

FlapStarts=-16384,-14335,-9855,-5504,-2432,1561,5982,10012,15474
FlapEnds=-15103,-10623,-6272,-3200,780,4681,8972,14043,16384
Flaps=0,16380/16

2. In your old/bugged in you have the spike removal options set:

Quote

RudderSpikeRemoval=Yes
ElevatorSpikeRemoval=Yes
AileronSpikeRemoval=Yes

3. Elevator calibration in your old/bugged ini looks slightly off (mull zone looks off centre, but this should not be an issue), and not calibrated in the working ini :

Quote

Elevator=-16384,1280,1408,15359/8

Anyway, keep the ini as-is for a while to confirm the issue has gone. Then try adding them back one-by-one to see if any make the issue return.  You should calibrate your elevator axis so I would start with that.

John

Link to comment
Share on other sites

I think this may be due to the calibration of the elevator, or maybe the flaps. PMDG aircraft in P3D don't play well with FSUIPC calibration due to priority levels, so maybe this is also the issue with PMDG aircraft in MSFS. Try calibrating the elevator again and see id the problem returns. If so, switch to assigning with Send to FS as normal axis and remove/reset the calibration.

Link to comment
Share on other sites

Another user has reported a similar issue and has determined that it is the flaps calibration that is causing this issue. So maybe try with just the flaps calibration removed, and maybe re-assign your flaps differently if you cannot use them without calibration. See 

John

 

Link to comment
Share on other sites

  • John Dowson changed the title to PMDG 737 MSFS 2020: Climb rate reduced when FSUIPC7 running

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.