Can I use 2 yokes from Ch products

[Nightflyer]

I have a homebuild 737 cockpit. A couple of weeks ago I bought a second yoke from CH products for the Co-pilot side of the cockpit.

Unfortunatly both yokes together does not work. They interfere eachother. I asked the support of CH products and they told me it is not possible to run 2 yokes. Is there any possibility to control 2 yokes in FSUIPC. I have the latest version.

Thomas

[BAW019]

Funnily enough I've just been adding a second set of flight controls to my homebuild.

FSUIPC (or it's SDK) comes with a pdf document that contains a section on setting this up round about page 32 (can't remember the exact name but it's something like "FSUIPC for advanced users"). I didn't find it that intuitive but got it working in the end and now my yoke and pedals work really well together.

It works by monitoring the inputs and using the biggest one from either yoke. For example if one pilot starts a climb and the other pulls his yoke back a little harder he will get priorty. As soon as one pilot's input overtake the other's then his inputs are in command - it's all very smooth and works very well.

From memory once the hardware is plugged in and calibrated (so it matches the original yoke) there are just three simple steps:-

Step 1 - Fibbing to Flight Simulator

This is the bit that I found confusing - you're going to tell FS to expect inputs from your new Yoke but those inputs will never actually get there because FSUIPC will intercept them and re-direct them to the Aleron and Elevator axiis. I set mine up to the mixtures axiis but FSUIPC redirects them to the Ailerons and Elevators so the mixtures remain untouched. Open up the Options/Controls dialog and select the Axis tab. Make sure you select your new yoke (not your exisiting one!!) and assgn it's axiis to some controls that you won't be using, such as the mixures.

Step 2 - Confessing To FSUIPC

At this point, if you were to fire up Flight Sim you'd find that whenever you moved yoke #2 the mixtures would change (to continue my example).

This is because you've told FS to expect input on those axiis but you haven't told FSUIPC to intercept them yet. Open the FSUIPC.INI and add the AileronB= and ElevatorB= entries to the Joystick cailbration section(s). My cockpit is non-specific so I've put the entries against the Joystick sections for each aircraft, you may not need to if you use the same plane all the time.

The 5 digit number you need to put after those two entries is a code that uniquely identifies each and every input - switches and axiis alike. The "FSUIPC Controls pdf" document (exact name?) lists these codes so search for 'axis', I think they're all grouped together. From that list you need to use the codes assigned to the axiis you told FS about NOT the elevator and aileron axiis. To continue my example I found the codes for the mixture axiis and and put them after the = sign for AileronB and ElevatorB. You're effectively saying to FSUIPC "Whenever someone sends input to FS on control number xxxxx, or on control number xxxxx intercept the information and re-route it to the Alerons or Elevators".

Step 3 - Smoothing It All Over

I found that unless I calibrated my new yoke inside FSUIPC's dialog it seems to operate like an on-off switch. Normally I wouldn't need to use the Calibration tab in this dialog but to use dual controls you need to open up FSUIPC from the FS menu and go to the Cailbration tab. Use the black arrow controls to locate the Aileron and Elevator screen and use it to calibrate your new yoke. When you're done you should be able to open that dialog up again and use the same screen to confirm that inputs from both Yokes are being treated the same by FSUIPC.

That's all I remember doing. Like I said I found it a little un-obvious but I'm not that gifted brainally so you may not need all this waffle. Give the FSUIPC For Advanced Users document a read and see if that helps.

Good luck!

Ian

[Pete Dowson]

I have a homebuild 737 cockpit. A couple of weeks ago I bought a second yoke from CH products for the Co-pilot side of the cockpit.

Unfortunatly both yokes together does not work. They interfere eachother. I asked the support of CH products and they told me it is not possible to run 2 yokes. Is there any possibility to control 2 yokes in FSUIPC. I have the latest version.

Thomas

The process Ian describes is the "official" way of doing it through FSUIPC, because that enables it to provide arbitrations between the two axes fighting to control the same control surface -- it simply chooses the one with maximum deflection.

These days, since I added "axis assignments" to FSUIPC, there is an easier alternative which also works well, provided that you have stable (non-jittery) axes. With many of the more recent USB based joysticks and yokes this may be the case.

For this you'd simply allocate your yoke axes in FSUIPC's Axis Calibrations tab. FSUIPC doesn't care how many axes you assign to the same control surface, it simply takes the last one to change by more than the "delta" value to can set there -- if you have no jitter you can leave the delta to default, but it could be increased a bit to deal with minor jitter. You don't want to have to increase it too much as this will cause a loss in resolution on your control.

If you assign axes in FSUIPC you need to make sure they are not also assigned in FS.

Regards

Pete

Pete

[BAW019]

Hi Peter,

I've used the 'official' method for several planes but occasionally load an adventure or pick a plane I haven't set up yet and of course my Yoke becomes a binary switch!*

You mentioned the alternative approach is to simply calibrate both joysticks and assign their axiis in in FSUIPC. I may yet go down that route but I wanted to check something before I go undoinig all my previous hard work! Does the second method apply the 'biggest wins' logic or it a case of last change in input wins?

For example, if my F/O is banking hard and I move my Saitek yoke slightly (from centre) in the same direction will the bank immediately easy up or will he continue to have control until I exceed his control inputs?

Cheers

Ian

(* My Build is generic so I can fly any plane but that means the calibrations have to be done for each plane using the official method)

[Pete Dowson]

I've used the 'official' method for several planes but occasionally load an adventure or pick a plane I haven't set up yet and of course my Yoke becomes a binary switch!*

...

(* My Build is generic so I can fly any plane but that means the calibrations have to be done for each plane using the official method)

Don't the calibrations work for any plane? Surely once you have the min/max/centre and response slope sorted, the same applies to all -- well, all except helos possibly?

You mentioned the alternative approach is to simply calibrate both joysticks and assign their axiis in in FSUIPC. I may yet go down that route but I wanted to check something before I go undoinig all my previous hard work!

You don't have to "undo" anything -- just save a copy of your FSUIPC.INI file someplace. Everything you do is saved there, no where else.

Does the second method apply the 'biggest wins' logic or it a case of last change in input wins?

I thought I said? Last change. I'll repeat the relevant bit from my last message:

FSUIPC doesn't care how many axes you assign to the same control surface, it simply takes the last one to change by more than the "delta" value to can set there -- if you have no jitter you can leave the delta to default, but it could be increased a bit to deal with minor jitter. You don't want to have to increase it too much as this will cause a loss in resolution on your control.

For example, if my F/O is banking hard and I move my Saitek yoke slightly (from centre) in the same direction will the bank immediately easy up or will he continue to have control until I exceed his control inputs?

Depends how much you move it -- if more than the Delta, the bank will be affected immediately (until the next change from the one you are using). The innards don't know where the values are coming from -- they are simply thrown at it by the multiple axis assignment.

Pete

[Nightflyer]

Hi Ian, Pete,

sorry for late reply. I was on holiday.

Many thanks for your input. I am realy happy to hear it is working.

I'll try on the weekend and hope I have success.

Thomas

[BAW019]

Just a footnote - I've now converted to using the other method that Pete mentioned (nothing assigned in FSX, just using FSUIPC axis assigments tab to set up the asiis. It's much easier to set up and works very well.

Ian

[Pete Dowson]

Just a footnote - I've now converted to using the other method that Pete mentioned (nothing assigned in FSX, just using FSUIPC axis assigments tab to set up the asiis. It's much easier to set up and works very well.

For FSX there's an interim update now available for testing:

http://fsuipc.simflight.com/beta/FSUIPC4291.zip

This uses an improved method for axis assignments routed "direct to FSUIPC calibration", avoiding SimConnect altogether, and by reports so far (it's only been half a day though) it is fixing problems folks have been having with SimConnect data corruption causing FSX to eventually crash.

The change which might benefit those using multiple joystick axes for the same FS control surfaces is that this version does arbitrate for the maximum deflection when "direct to FS calibration" is being use. (It cannot do it for routing via FS controls because there's no way to add source data, differentiating inputs, that way).

I think this will make the old method, of assigning extra axes to otherwise unused FS controls, redundant, at least for FSX. I may look to see if I can apply the same change to FSUIPC3, but no guarantees on that.

Regards

Pete

[Nightflyer]

Hi Pete, Ian,

last weekend I did the setup and it works well.

I am so happy. I realy thought I made a wrong investment.

Many thanks

Cheers

Thomas

[BAW019]

Hi Pete,

I think I may have found a bug in the latest beta. I use dual controls (2 Saitek yokes + 2 CH Pro pedals). If I set them up for Direct To FSX there's no problem, if I set them up as direct to FSUIPC for calibration all seems to work until I do the brakes on the second set of controls. Once the second set of brakes is assigned I find that I can only apply left brake on the captains set and right brake on the f/o set. I've tried it again after a cold reboot and I get the same results.

All the best

Ian

[Pete Dowson]

if I set them up as direct to FSUIPC for calibration all seems to work until I do the brakes on the second set of controls. Once the second set of brakes is assigned I find that I can only apply left brake on the captains set and right brake on the f/o set. I've tried it again after a cold reboot and I get the same results.

There's no way something happening on one axis affects what happens on another (i.e. left and right) -- each axis is distinct, the could just as well be rudder and aileron.

The only arbitration going on is that the maximum value from the two inputs assigned to the same FSUIPC control wins. Of course your brakes probably give their maximum value when "off" (I assume you REVerse them in the calibration?). That may be the problem -- I suspect your left here and right there business is a red herring because there's no way there'd be a relationship between left and right, no way.

To check whether the reversal is the problem, depress the currently operational pedal, to make its value lower than the non-working one, then move the non-working one. I think you'll find that it will then operate. (You may need two people to do this! ;-) )

This is also likely to be a problem with FS-assigned axes using the old method or false axis assignment, if they are reversed in FSUIPC -- but there's the option of reversing them in FS itself instead, which gets around it.

I'm going to have to think about how to deal with this. The problem is that the part of FSUIPC which is detecting and assigning axes, and doing the arbitration, is not at all related to the part doing the calibration and therefore the Reversal. I may have to devise some sort of indication which the arbitrator can use.

Pete

[BAW019]

Hi Pete

Well, I tried what you suggested but no luck I'm afraid. Holding down the good pedal doesn't make it yield to the bad one and I've checked that all brakes are set to REV.

It works fine if I only assign one set of controls to DIRECT TO FSUIPC, the behaviour definietly only appears when I assign the second set but I'm mystified why the test you suggested doesn't work - all the other axiis work fine!

Stumped!

Ian

[Pete Dowson]

Well, I tried what you suggested but no luck I'm afraid. Holding down the good pedal doesn't make it yield to the bad one and I've checked that all brakes are set to REV.

Well, it just must be due to the REV setting. I've worked out a way of detecting that where I do the arbitration and will upload a test version for you to try, maybe later today -- otherwise tomorrow.

It works fine if I only assign one set of controls to DIRECT TO FSUIPC

Because there's no arbitration, so no inputs are discarded in favour of others.

the behaviour definietly only appears when I assign the second set but I'm mystified why the test you suggested doesn't work - all the other axiis work fine!

How many of the other axes, dual-assigned, are REVersed, though?

Regards

Pete

[Pete Dowson]

Well, I tried what you suggested but no luck I'm afraid. Holding down the good pedal doesn't make it yield to the bad one and I've checked that all brakes are set to REV.

Check FSUIPC 4.295 (or 3.814), now with REV axes treated appropriately. Seems okay here with two sets of toe brakes.

Note that the change-over between one set and another can only occur when a new value is received -- a change over the "delta" so that jitter doesn't play a part. So if one pilot is depressing the brakes and then the other one fully depresses them and then releases them, they are released -- even though the first guy still holds them depressed. He'd have to wiggle them a bit to take control.

I know this isn't realistic, but it is really about the best I can do without a lot more fiddling about in the code, and i really don't want to risk the inevitably unreliability this will cause in the short term.

Regards

Pete

[BAW019]

Hi Peter, the new build works fine!

Many thanks for doing that,

Ian