Dual Unlinked Flight Controls - elevator

[MartyReynolds]

Hi Pete,

I have dual unlinked PFC control yokes and rudder pedals (recently purchased) for my B737NG sim running Sim-Avionics. I have set up my second set of flight controls (for the FO side) as recommended in your Advanced Users Guide method 2 (same method as recommended the Peter & Steve Cos at Flight Deck Solutions). The issue I am seeing is regarding when FSUIPC decides to determine which flight control is controlling. I understand it does this by looking at which control was moved and is registering the largest deflection from neutral or zero.

When I test this with the ailerons and rudders, it works perfectly. When I test it with the elevators, I have noticed that it only works when the desired new active flight control is initially pushed forward (nose down). When the newly active control is initially pulled backward (nose up), it will never "take control", even if the control yoke is pulled back to maximum deflection.

To make this clear in case there is confusion, let me give a scenario. The CA yoke is active and is being used to fly the aircraft. If the CA yoke is slowly released to the neutral position so that the FO yoke can be used to fly the aircraft. If the initial control input to the FO yoke is nose up (pulling the yoke back), the elevators do not move and remain in neutral position irregardless if the yoke is pulled fully back. However at anytime the FO yoke is pushed nose down forward of neutral, FSUIPC then catches that yoke and activates it as the controlling yoke.

This issue does not exist if the initial control input to the FO yoke is a nose down (pushing the yoke forward). FSUIPC immediately makes the FO elevator control active and controlling in that case, and works as expected. Also, this issue does not occur with either aileron or rudder pedal input. They work normally as per your documentation.

I have attempted troubleshooting by verifying Windows calibration of the USB Game Controllers for the PFC yokes. It is fine. I also have only calibrated in FSUIPC the CA yoke per FDS instructions, but when I look at the raw and output values for each yoke, they are almost identical (both yokes purchase from PFC within the last year).

I am wondering if this might be a minor bug in the code that is looking at maximum deflection for the elevator axis. I can imagine that the code should be taking an absolute value of the axis value and comparing the absolute value of one control to the other. Perhaps this absolute value step was omitted?

I am using FSUIPC v5.153. Most recent version of Prepar3Dv4. I did NOT install PFChid64.dll as reading the documentation, it appears this is for more complex PFC hardware and would not apply to hardware that is essentially nothing more than a USB game controller joystick device. I have attached the FSUIPC5.Joyscan.csv, FSUIPC5.ini, and FSUIPC5.log.

Finally, every once and awhile I can get it to work normally with the elevators. I am thinking that this is dependent on when the neutral resting position of the yoke control changes slightly and ends up with a slightly negative raw value. This might also be consistent with the software code having a minor bug when comparing the positive and negative numbers.

Thanks,

Marty Reynolds

 

FSUIPC5.ini FSUIPC5.JoyScan.csv FSUIPC5.log

[Pete Dowson]

24 minutes ago, MartyReynolds said:

When I test this with the ailerons and rudders, it works perfectly. When I test it with the elevators, I have noticed that it only works when the desired new active flight control is initially pushed forward (nose down). When the newly active control is initially pulled backward (nose up), it will never "take control", even if the control yoke is pulled back to maximum deflection.

There's no difference whatsoever in how FSUIPC treats the elevator assignments and calibrations compared to those for the other flight controls. It's all the same code, only the name of the control is different.

So, there's something odd in the way the elevator is wired, or in your assignments and calibrations.

Looking at your assignments, in the INI file, I see:

0=0X,309,D,1,0,0,0    -{ DIRECT: Aileron }-
1=0Y,1,D,2,0,0,0    -{ DIRECT: Elevator }-
9=3X,356,D,1,0,0,0    -{ DIRECT: Aileron }-
10=3Y,185,D,2,0,0,0    -{ DIRECT: Elevator }-

Why those very odd Delta values? Those are the minimum changes before they are acted upon.  With a 1 it means every single minute change will cause FSUIPC to attempt to honour it. This is normally only used for digital controls where the specific values are needed -- e.g. setting a heading with an axis.

I strongly recommend you set them all back to 256, like the rest of the assignments.

The log would only have been of interest had you enabled axis logging first and the done a elevator test. It would have been a huge log with a delta of 1 of course, so I would have asked you to change that first in any case.

Pete

 

[MartyReynolds]

Thanks Pete. Changing the delta values back to default totally resolved the issue.

I had tried to widen the delta a bit and I think the process of doing this resulted in accidentally changing one of the elevators to a delta of 1.

Marty