MartyReynolds

Hi John, The range of delay in transfer of control of about the times you saw were probably consistent with what I observed as well. Sometimes it has taken over half a minute but in most cases it seems five to ten seconds and half the time and one to two seconds at other times. If using your older Method 1 of dual unlinked controls is not possible (per Thomas), I could switch from Sim-Avionics to ProSim737 (I own it as well and it has the joystick flight control interface and calibration built into the program) but I have a Flight Deck Solutions throttle quadrant and the interface for it is only available with Sim-Avionics. So I am surmising that my only option left if to write my own USB joystick driver for the flight controls and then forward the axes values to Prepar3D via FSUIPC offsets or SimConnect. Do you have any recommendation on one versus the other for a project like this? Marty

HI Thomas, I'm sorry I wasn't clear. The issue is not with the FO yoke per se. The issue is with either yoke when one has been used, then that yoke is left to neutral and the other yoke is then being used. What occurs when one pilot is flying and then there is a transfer of control to the other person. When this occurs, it can sometimes take up to 20 seconds before the the other yoke starts functioning. I.e. this occurs from FO yoke to CA yoke as well as from CA yoke to FO yoke. I am surmising that it works with P3D is paused because when I view the axis calibration tab in the FSUIPC interface, not for the purposes of calibration, but just to see the joystick IN and OUT values for any control I select. When I do this for elevator, I see no delay irregardless of how many times I switch over from moving one yoke or the other. It is instantaneous, just like it is for the other control axes (aileron, rudder, etc). But when I close the FSUIPC interface and look at the aircraft elevator OR actively log axes with FSUIPC to a console window, I observe the issue where I can't get the other (not currently used yoke) from working until a period of time. The log file has no errors in the values you see. The issue is when the output values go to zero, this means that I have stopped using that yoke and it is now resting in the neutral position within the null zone. Then you start seeing values again, it means that the other yoke has now finally started working and once it does, it works without error. You really can't see anything in this log file unless you could time stamp each value and I moved the yoke not randomly but for a fixed period of time ... then at the moment stopped and switched to the other yoke ... But I think this would only show what I am observing and not be helpful. I could also show you this perhaps more clearly with a video clip so you could see the live log file to console, or the Prepar3D view of the aircraft control surfaces. But there is a MB upload limit here that is too small for a brief video clip. Marty

Hi Thomas, I'm attaching the FSUIPC6.1.log. I only pressed New Log one time after I went through the steps you asked me to do. What is extremely frustrating to me regarding this is that the same USB joystick devices works perfectly fine for the aileron axis, always - but it never works for the elevator axis. If I switch assignments (swap ailerons for elevators in both control yokes), it still is the elevator axis that does not properly work (even though it is now assigned to the X axis on the joystick and controlled by turning the yoke left and right) - and - moving the yoke forward and back (assigned to ailerons) works perfectly. This seems to me to rule out it being a problem with the yoke, or USB connection, or port power management, etc. It seems that something must be occurring that is interfering with the elevator axis when read by DirectInput. The only additional clue I have is that this only occurs when FSUIPC window is closed and Prepar3D is running. When I open the FSUIPC dialog and Prepar3D pauses, both elevator axes work perfectly (as seen in the axis calibration tab of FSUIPC). Computers have become so complex and have so many interdependencies, Windows registry is a cobweb, there are different versions of Prepar3D, different versions of Windows 10 updates ... I can see how somethings things like this occur that are near impossible to resolve. If I can't get this working with Method 2, do you think it would be possible to assign the elevators of my two control yokes using the older Method 1? If so, could you please help me with this as the manual is a little ambiguous regarding this. My only other option is to write an interface program myself in C++ to read the joysticks with either raw input or DirectInput, then push that to Prepar3D via an FSUIPC offset or with SimConnect. That project would be a huge endeavor for me because I have limited experience with the C++ language and low-level hardware interfacing. But I'm determined to get this working so I didn't buy a $2,000 paperweight that I have to keep turned off (not assigned) in order for my sim to be functional. Thanks for your help. Sorry this is frustrating. Marty FSUIPC6.1.log

Hi Thomas. I did exactly what you asked. When I tested the controls, I'd move the CA yoke a couple of times about half way forward and halfway back a couple of times. Then I'd leave the CA yoke in neutral position and move the FO yoke in the same way. I watched the aircraft elevators visually. Rarely immediately, usually after 5 - 20 seconds, the elevators would leave the neutral position and start moving normally. I then left the FO yoke in neutral position and repeated the movements on the CA yoke. I did repeated going from CA yoke to FO yoke then back to CA yoke about half a dozen times. Marty FSUIPC6.ini FSUIPC6.log

Thomas, The INI file you are referencing was a temporary attempt to try to get the elevator axes working for my flight controls using the older Method 1. That was not fruitful so I went back to configuring everything as Method 2, including all of the steps you have outlined above. It works perfectly for all axes except for the elevator axis, as before. When I said "controller switching", I was attempting to understand why this wasn't working. If the code is simply using the device with the highest value, then it is probably more accurate to say that there is something occurring that is hiding or preventing FSUIPC from seeing the other device so it is not responding to the other device also assigned to that axis. This occurs even if the control is in motion and held and large amounts of travel and also if there is a sufficient null zone defined. Then, when FSUIPC eventually does see the device and starts utilizing those control values, something occurs that prevents it from then seeing the original device.

Thanks Pete. No problem. No rush. I think I'm in a minority of FSUIPC users as ProSim737 allows for assignment and calibration within it's program. Most people probably either have one yoke or a linked yoke setup. Using Sim-A and dual unlinked yokes is probably a small percentage of your clients. I wish I could put in dual linked controls, but my space for the sim is limited and if I did that I'd lose the capability of using NATVis in the future. Thanks for taking the time to evaluate. My C++ book arrived today! The really cool thing about this hobby is that is is a blend of aviation, computer programing, hardware ... and the sky is the limit.

Update: I ran a test with Raw Input selected instead of Direct Input for controllers in Prepar3D, rebooted the computer, relaunched Prepard3D, verified enable controllers was deselected, then checked the elevator output. No change - didn't make any difference. -- Until I can get this working, could you tell me if I could just use your older method 1 for just the elevator axis? In an earlier post I showed the entry I made to FSUIPC.INI to try to do this, but I didn't see it having any effect. Could you please clarify what to put in for ElevatorB= ? Also, can you verify it goes in the [JoystickCalibration] section. Thanks. Marty

Hi Pete, to try to isolate this, I only have my Prepar3D computer running and the only application running is Prepar3D v4.5 with FSUIPC 6 add-on and SODE add-on. Sim-A is on another computer and that computer is not even turned on. I was thinking, when I click on FSUIPC to open your interface and view the joystick calibration tab, I see immediate and expected elevator OUT from either control yoke. I can switch back and forth at will between the two control yokes and it functions perfectly. If this output on the joystick calibration tab is post-processing of the algorithm you use in FSUIPC for dual controls and deciding which joystick device is the "active" one, then to me, this would mean that your code is fine. If my assumption above is correct, then I wonder if the issue is a bug within Prepar3D because Prepar3D is paused when I open the FSUIPC interface, but then resumes when I close the FSUIPC interface. The little bit of reading I've researched on DirectInput indicates that when one creates an abstract class to represent an input device, you can specify if you want exclusive access to the device while you read the inputs. Also, I think the more common method is to refresh the device and read from it using polling. I wonder if Prepar3D has a bug that is causing it to still continue to poll the device to get input values, but then doesn't use the values as controllers are disabled. But the polling of the device is periodically blocking FSUIPC from getting values. But this doesn't make sense because I think the exclusive access to a device in DirectInput code applies to the entire device and cannot be restricted to a particular axis or button. There is an option in Prepar3D for controllers. You can select either Raw Input or DirectInput. I noticed my installation is on DirectInput. I didn't think this would matter because I have the checkbox for "enable controllers" deselected. I also have all default control assignments for the joystick removed as well to ensure this is no conflict. Later today, I'll change controller input from DirectInput to RawInput in Prepar3D, reboot and relaunch, then see if there is any effect in case my hypothesis above has any validity and turning off DirectInput might resolve this. Marty

Hi Pete, I switched aircraft to the Lockheed Martin "Piper Cub" that came with P3D. I see the same behavior. So it occurs both with the Sim-A 737 as well as a default aircraft. I did notice that I could rarely or perhaps never get the elevator control to transfer over to the other yoke by pulling back on the second yoke. I was more successful in transferring control if I pushed forward - or - moved the control just a little back and forth just outside of the neutral position. -- Completely different change of subject -- I did try to use your older Method 1 for just the elevator control. I assigned the FO Yoke elevator movement to the PropPitch1 axis. I then opened the FSUIPC.INI and saw the new entry under [Axes] for this assignment which was given an assignment number of 1. I then added an entry in the [JoystickCalibration] section: ElevatorB=1 However it did not have any effect on elevator movement. I am not sure if I needed to define ElevatorA for the CA yoke, in order for this to function properly. I am also not sure if the number "1" I am referencing was the correct number to use, or if I should have used "AY" or "1Y" since I am using joy letters as you suggested. I'll attached the INI file from the Method1 attempt. FSUIPC6_Method1.ini

ahh, here is the INI file I forgot to attach FSUIPC6.ini

I reconnected my FO yoke and rudder pedals. Changed the FSUIPC INI so it will auto-assign letters to the joystick devices. Recalibrated everything in Windows 10. Verified controller assignments were globally disabled in Prepar3D. Went to FSUIPC and got all button and axis assignments perfect. When I go to the Joystick Calibration tab in FSUIPC, I can move either control yoke, or press on either rudder pedal, and the output for all axes are immediately correct and follow the logic in your user manual for dual unlinked joysticks. I am looking at the IN and OUT values on the calibration page. I can move from CA controls to FO controls and back .... over and over ... and immediately the IN and OUT values reflect control movement. However, when I look at the flight control surface movement in Prepar3D, or look at live FSUIPC logging for axes, all the controls transfer back and forth immediately and reliably except for the elevator axes. Whatever flight control is being currently used by FSUIPC for the elevator axis, movement of that control is fine and the logged axis values are immediate. However, if I then move to the other flight control and move the elevator, it doesn't transfer control consistently. Every once and while the control is transferred immediately, but more often than not, I have to keep moving the control over a period of time of up to 10 to 30 seconds before it "catches" and elevator axis values start showing up when that control is moved. To try to see if this was an issue with hardware, I reassigned my CA yoke roll movement to elevator and pitch movement to aileron. I did the same for the FO yoke. Then when I manipulated the yokes, I found moving the control yoke forward and backward would show up immediately on the aileron axis (as expected by my test assignment). I could switch to the other yoke and logged axis values would immediately reflect the other control taking over and outputting aileron axis changes. Then tested moving the control yoke left and right, I would see this show up on the elevator axis in the FSUIPC logged outputs (as expected by my test assignment). But when I then moved to the other control yoke left or right, I would have no logged axis outputs for a period of time. After 10 to 30 seconds, finally control would be transferred, and I'd start seeing elevator outputs. Each time I switched control yokes, there would be inconsistency and a significant lag before control was transferred. When I have left things like this, I have also been in the middle of the flight and without any movement of the second control, it would become controlling and my first control would then be unresponsive for a period of time until I regained control by moving it back and forth. So this test re-assignment seems to indicate that there is an issue in the code that determines which joystick device to use for the elevator axis. Do you agree? -- For now, I am going to try to see if I can just assign the elevator axis using your older Method 1 as documented in the FSUIPC for Advanced Users document. I think that all I need to do is find some unused axis that has a neutral center and assign the FO elevator axis to this. Then go in the FSUIPC.INI and add the line: ElevatorB=# I am guessing the # should be what is in the FSUIPC.INI file under the [Axes] section that reflects the name of the axis assignment I choose. Even if this works, I'd still like to get the elevator control functioning consistently with the other control that use the new Method 2 if that is possible. -- Note: I have attached my INI file after I reattached all joysticks and made the correct assignments. This INI file is prior to when I temporarily made test changes with the aileron/elevator axis. I don't see anything in it that stands out as an issue. Oh, I know. The resolution of the Hall effect sensor in my PFC yoke is not that great. I can't do anything about it without major surgery on the hardware. I think before that I'd get linked controls like yours. : ) Thanks, Marty

To make my sim functional, I have to unplug and/or unassign the FO control yoke. In this case, I did both, that is why you don't see it on the INI file. The second steering tiller assignment is just due to a Windows reshuffling of USB assignments in the past .. I just need to verify in FSUIPC while running that device 4 is the correct one and then delete the INI assignment for device 2. However, I don't think this has anything to do with the dual elevator controls and the issue of when control is transferred from one to another. When I do a Windows joystick calibration and check the box to see the raw values, I see that both PFC flight controls have a raw value from approximately 580 to 1480 from the Hall effect sensor when the elevator is moved from one extreme position to another. This gives a delta of only about 900 (just under 10 bits of resolution). The windows calibration then extends this so the calibrated output value is moving from approximately -16,383 to 16,383 by magnifying the raw output by a factor of 36.4. Due to the limited resolution of Hall effect sensor on the yoke USB interface, anytime the Hall effect sensor changes its raw output by only 1, application of the Windows calibration will cause the adjust output to change by 36.4. Would this have any possibility of causing the issue I see with transfer control from one device to the other, for the same axis? I am thinking later today I will do an experiment and assign the aileron to the elevator axis, and vice versa for both control yokes. The reason for this is that the ailerons sensors are pots and the elevators are Hall effect sensors. Then I will use FSUIPC to log live axis outputs to a window so I can watch and see how control is transferred. This will hopefully let me isolate the issue to see if this is an issue with the Hall effect sensor or not. Marty

Hi Pete, Yes, I reverified that controllers are disabled in the Sim. I have the checkbox deselected for "Enable Controllers" Here is the FSUIPC.INI file. When I'm not troubleshooting to try to fix this, I currently unplug the FO control yoke in order to fly in the sim in order to prevent loss of control when elevator control sometimes randomly switches from the CA control yoke to the FO control yoke. Marty FSUIPC6.ini

I went to Windows USB game controller looked at the output for both the CA control yoke and the FO control yoke. All outputs were calibrated and stable. There were no jitters or periodic spikes in what Windows was seeing. I then went into FSUIPC axes assignment page and looked at the raw outputs for each control. Again, both were very stable unless the yoke was moved, then each yoke would output raw output numbers consistent and immediately with the degree of yoke deflection. I then when back to logging axes with FSUIPC with a window on top so I could immediately see each addition to the log file. When moving the CA yoke aileron there was a stream of output values as the control was moved. Stopping movement, and the output values would cease. Then when switching to the FO yoke aileron any slight movement immediately transferred control to the FO side for that axis. There was immediately the same stream of output values being assigned to the aileron axis. I could go back and forth at random between the CA and FO aileron and the it was always transfer control back and forth without any perceptible delay. However, then I would move the CA yoke elevator, I'd see the same stream of output values just like I did with the aileron control manipulation. However, when I'd switch to the FO yoke, it would sometimes immediately transfer but more often that not it would take a few seconds, sometimes up to half a minutes, before the FO yoke would become responsive on the elevator axis. Once the FO yoke elevator was working, it would typically continue to stream values with movement indicating normal function. But then when I would try to transfer back to the CA yoke, the same phenomenon would occurs. Sometimes control would transfer immediately, but usually it took several tries of moving the elevator control to almost full up and down deflection before it would finally become responsive and I'd see elevator outputs start streaming to the log file. This testing indicates to me that the it appears that I do not have any hardware issue with my PFC control yokes with their output. I do know that they use Hall effect sensors for the elevator axis, but I am presuming the electronic device used for the signal to the USB interface card would be transparent to Windows, as both potentiometers or Hall effect sensors are simply going to be represented as a digital value for the respective analog axis. So I am thinking that this has to be either one or two things. One would be some quirk in Windows 10 that is providing incorrect DirectInput API values, perhaps due to confusion over both control yokes having the same IO interface card (no unique serial number, however Windows does assign a unique GUID and it seems to be consistent as long as I don't move around the USB port connections). I could test this by writing a DirectInput utility to directly read the outputs from each control yoke in real time to see if there is something odd occurring, but I doubt I will find anything because I see normal correct output behavior on the Windows USB game controllers interface used for calibration or just observing control inputs. In looking over C++ examples for the DirectInput API. The other theory would be that FSUIPC might be have some code that has difficulty with the behavior of switching from one control to the other on the elevator axis only. In this case, I could possible overcome this by using a utility to read all the joystick inputs, then just directly pass them programmatically to the corresponding offsets exposed by FSUIPC (and not make any axis assignments in FSUIPC). Pete - I did see my polling frequency was every 10 ms. I tried lower and higher variations on this, but did not find any effect. I also verified that my axes were all at the default delta value of 256, which they were. I also tried selecting "block elevator spikes" in case the PFC yoke was outputting super brief spikes in values that I wasn't seeing on the log files, that might be picked up by the code in FSUIPC for transfer of control from one joystick to another -- but this didn't have any effect either. I am presuming I'd see an elevator axis control value logged for any value that the FSUIPC code would use for making the decision on control transfer. Do you have any suggestion on which way to go next on what might be more likely to be fruitful? The C++ code for DirectInput is going to take me a bit of time to write as the examples I've seen of it look like the complexity of opening a window with MFC, so will require a bit of study. But once I have direct access to the card in a dedicated utility, I could probably easily determine if there was an issue with periodic output values that were erroneous (although I don't see any evidence of this on the Windows game controller calibration utility nor in FSUIPC logging).

Hi Thomas - what you posted makes perfect sense. I had looked at the flight control movements inside of Sim-Avionics and it appeared smooth and correct, but I think Sim-Avionics does some blending and smoothing of the FSUIPC offsets that are written to for flight control movement. I'll look in Windows game controller and see if I can see periodic jitters of the elevator on one of the control yokes. I think PFC uses Hall effect sensors instead of a pot, but a loose wire or bad sensor could certainly cause a periodic spike that would cause FSUIPC transfer of control to the FO side. What I read regarding DirectInput is that it is dependent upon polling for retrieving values, so I might still need to write a short utility that would allow me to increase the polling frequency to a high level just for testing, so I will see any periodic spikes from sensor failure. Or better yet, now I have an excuse to finally buy an oscilloscope so I can just directly see the output in real time. : ) (wonder if wife will accept this argument). I'll repost what I find - in case it could be helpful for someone else down the road.