Cabin Climb Gauge

[James Curry]

I'm trying to iron out a couple of minor issues, one of them being the jittery cabin climb gauge that basically swings from max high to max low whilst taxiing on the ground. (known issue). It seems to be an issue of the SDK that we probably wont fix in the life of FS2020.

My crude work around is to try and implement "conditions" to the gauge script to disable the gauge at say below a defined IAS 120 kts so that it wont function at all and avoid the jittery wild swings we see when taxiing.
I think it would at least make the simulation a bit more bearable and realistic in the mean time.

I think I'm nearly there but could do with a few script sioc experts to lend a helping eye.
The script at the moment doesn't work and limit the gauge, but I don't feel that I'm a million miles off, quite close.

From the details below you will see what I'm trying to achieve so if we can collectively help each other for a solution..........

[James Curry]

I did also try this script after all the control script and it also didn't work,
I feel I'm not that far off working it out but will have to keep trying.

[biggstuff]

I have the same issue. Did you ever get this to work?

[James Curry]

unfortunately i didnt, in theory it should be a simple one but somewhere along the line there is input creating noise that makes the fluctuations and i haven't found a solution yet. I hate defeat!

[NobbyC_B738]

I haven’t installed a cabin climb gauge yet, but I will do soon and I have started preparation.
Today I watched Var 1536 (g_VSI) on IOCPConsole whilst taxiing and whilst accelerating on runway and recognized fluctuating positive and negative figures during taxiing that may be responsible for the jittery cabin climb gauge. As I haven’t connected any device 37 servos yet, I haven’t selected device 37 in the aircraft configuration. That means that there is no electronic noise from wiring or OC cards. It also seems not to be a script issue or a driver issue because device 37 is not activated on my side. Conclusion: these fluctuating figures seem to be a PMDG issue.

When PMDG does not solve the cause, we have to minimize the effect. James' idea of implementing “conditions” sounds good. But &IAS <= 120 will not work as a condition, because the IAS-variable (= Var 0324 in script ver. 7.0) is not the real speed indicated in PFD but the display speed that you adjust on MCP.

I haven’t found a variable that indicates real speed (especially between 0 and 120 knots) so we have to search for another variable that indicates that airplane is on ground or in low height. Up to now my only idea is to use gear down condition (if &gear_dn = 1). When someone else knows a more suitable variable that can be used for airplane-on-ground-condition, please share.
When the condition is met we want cabin climb gauge needle in 0-position what means “&SERVO_VSI = 430” (PosC is James’ case) or “&g_VSI = 0” -> not “&SERVO_VSI = 0”
Additionally I think a call-command or a subroutine is necessary to check the condition. I will try this later after installing gauge in autumn or winter.
I only shared my ideas in case someone else wants to try them before I get to it. Any better idea is appreciated.

[idj4]

Hi

Not been on the sim for a few months so I’m working from vague memory here.

Opencockpits recommend closing any unused outputs with a jumper, to reduce fluctuations. Put a jumper across pins 1&2. Maybe try that.

Regards
Ian

[NobbyC_B738]

Ian,
thx for input. Reading the OC servo card manual you can see that they recommend "closing any unused intputs with a jumper, to reduce fluctuations" (not OUTPUTS!). That's what I have already done. (blue jumpers on the potentiometer inputs J3 - J6)

servo.jpg (99.63 KiB) Viewed 47904 times

Actually I have connected 3 servos and everything is working fine without jittery needles. The cabin climb gauge is not connected yet and deactivated in the script, but nevertheless fluctuating values can be recognized on the IOCPConsole for variable 1536 (g_VSI). That seems to be an PMDG issue.

I will open a support ticket, via PMDG operations Center after I have updated to PMDG OC3. When they can eliminate these fluctuating values, everything would be fine. When they don't want to update the Boeing 737 for FS 2020, we have to live with a script mod with conditions.

[mvr1918]

I don't have the FS2020 installed now so can't check this in detail. Will look into this issue further when PMDG releases the 737 for FS2024.

What CabinVSNeedle (Var1536 using IOCPConsole) values do you see during ground, climbing, cruise and descend flight phases?
Var1536 values are raw data, ft/min, coming from the PMDG 737 airplane simulation.

Typical CabinVSNeedle Values
• On the ground: Should be close to 0 ft/min, since the cabin isn't pressurizing or depressurizing.
• During climb or descent:
• Climb: Around 300 to 500 ft/min as the cabin altitude increases.
• Descent: Negative values like -300 to -500 ft/min as the cabin altitude decreases.
• Cruise: Stabilizes near 0 ft/min, indicating a steady cabin altitude.

[NobbyC_B738]

Roar;
thx for offering support. I made a short flight and can report Var 1536 values as listed below:

1) on the ground, waiting at gate, engines started, everything in runway configuration:
Var 1536 in IOCPConsole = 0
virtual cabin climb gauge: needle at 0

vsi_gate.jpg (61.65 KiB) Viewed 47510 times

2) on the ground, pushback:
Var 1536 in IOCPConsole = 0 with very few sudden high values above + or -1000 within fractions of a second
virtual cabin climb gauge: needle at 0 (does not follow the fast and short changes)
no sreenshot possible, changing too fast

3) on the ground, taxiing to runway:
Var 1536 in IOCPConsole = 0 with lots of sudden different values, mainly changing between +2900 and -2900 , a few peaks up to +4000 and -4000 within fractions of a second
virtual cabin climb gauge: needle at 0 (does not follow the fast and short changes)
no sreenshot possible, changing too fast

4) on the ground, accelerating on runway:
same as 3) but calming down to lower figures at higher speed

5) climbing to 30.000 feet; vertical speed above 2500 feet/min:
Var 1536 in IOCPConsole = slowly increasing to and stabilizing at 500;
virtual cabin climb gauge: following exactly the Var 1536 value

vsi_climb.jpg (57.66 KiB) Viewed 47510 times

6) cruising:
Var 1536 in IOCPConsole = stabilizing at 0
virtual cabin climb gauge: following exactly the Var 1536 value
screenshot similar to 1)

7) descending from 30.000 to 10.000 feet; vertical speed appr. -2500 feet/min:
Var 1536 in IOCPConsole = -350 to –400 slowly changing and stabilizing;
virtual cabin climb gauge: following exactly the Var 1536 value

vsi_descent.jpg (58.84 KiB) Viewed 47510 times

8) landing, after touch-down:
Var 1536 in IOCPConsole = 0 with lots of sudden different changing values between +4000 and -4000 within fractions of a second
virtual cabin climb gauge: needle at 0 (does not follow the fast and short changes)

Conclusion: everything is fine in the air, but severe fluctuations on ground especially during taxiing and directly after touch-down. Virtual cabin climb gauge doesn’t follow the short fluctuating figures but servo motor of OC cabin climb gauge may try to follow, what ends up in the jittery behavior as other users describe.

[mvr1918]

Fine, now I have the info I needed. I will look into the driver code to see if I can suppress the major spikes when airplay is on ground.

In the meantime these spikes could be suppressed in the script as Var1819 should be reporting radioaltimeter.


the line &SERVO_VSI = L1 at the end of the
Var 1536, name g_VSI, static, Value 0

could be changed to
IF Var 1809 > 1000
{
&SERVO_VSI = L1
}
ELSE
{
&SERVO_VSI = the value that sets the needle to 0, normally 0, but is could be needed to use another value to set needle correctly at 0
}

This is sure is a PMDG bug. I don't remember this to be an issue with the PMDG 737 in Prepar3D.