Dual Unlinked Flight Controls

[MartyReynolds]

I have two PFC yoke flight controls that emulate B737 airliner yokes. Each yoke has a USB interface card that Windows 10 sees as a game controller card. I have set up calibrated and set up the axes with FSUIPC 6 via Method 1 as documented in the FSUIPC for Advanced Users manual (page 45). I am using P3D v4.5.

The aileron works perfectly in transfer of control from one yoke to the other. The rudder works perfectly as well. However, the elevators do not consistently work properly. At times, transfer of elevator control from one yoke to the other will occur, even when the second yoke was in neutral (yes, I did create a wider than normal null zone when calibrating). Sometimes when  trying to transfer from one yoke to the other, the elevator control will not transfer despite moving the elevator control up and down to extremes of travel. If one is persistent, it usually will eventually transfer control but can take some time before it does occur.

I have enabled control axes logging to get clear readouts of this, and can clearly see that transfer occurs correctly and immediately will the aileron and rudder axes. However something appears glitchy in the elevator axis that makes it work sometimes, then not other times.

Pete, I was thinking of writing a C++ utility program that would read game controller inputs and allow to see is something odd was happening with Windows 10 and reading the game controllers. I also thought about removing game controller assignments in FSUIPC, then using this utility to read the flight controls and then write the elevator/rudder/aileron positions to FSUIPC offsets for aircraft control. First, though, I'd like to just test how Windows 10 is reading the elevator axes to see if that is the problem. Can you tell me if FSUIPC reads game controller input through DirectX or another API interface, so I can emulate how FSUIPC is seeing the game controller data.

Thanks,

Marty

[Thomas Richter]

Hi,

Quote

Can you tell me if FSUIPC reads game controller input through DirectX or another API interface, so I can emulate how FSUIPC is seeing the game controller data.

FSUIPC uses DirectInput and doesn't see controllers different than Windows does, as it is using the same library.

Quote

I have enabled control axes logging to get clear readouts of this, and can clearly see that transfer occurs correctly and immediately will the aileron and rudder axes. However something appears glitchy in the elevator axis that makes it work sometimes, then not other times.

FSUIPC doesn't switch/transfer controllers but it uses the last highest value of an "Axis". Your problem will be a bad elevator poti of the controller that is not in use when you face the problem. It means the elevator axis of that controller is sending constant changing values in neutral position. If the value it sends is opposite of your current input the that value is greater and accepted/used.

The easiest way to identify this is by checking that controller in Windows -> "Game controller settings"

Thomas

[MartyReynolds]

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.

[Pete Dowson]

14 minutes ago, MartyReynolds said:

I might still need to write a short utility that would allow me to increase the polling frequency to a high level

You can change the polling interval in FSUIPC.  It's controlled by the PollInterval parameter in your FSUIPC INI file's main [Axes] section. The number in that parameter is the number of milliseconds between polling.

Pete

 

[MartyReynolds]

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). 

[Pete Dowson]

9 hours ago, MartyReynolds said:

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). 

I really can't see what would be different with your code reading values to the way Windows and FSUIPC does it. In the axis assignment window in FUIPC the "IN" value IS the input value, unmolested.

If you have one of your devices apparently misbehaving but only in the Sim, not when it is checked and scanned, it is much more likely to be an additional assignment in the Sim. Have you made sure controllers are disabled in the Sim?

We haven't seen your FSUIPC settings (the INI file) yet, either. Best to check through that to see if there are any rogue settings.

Pete

 

 

[MartyReynolds]

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

[Pete Dowson]

18 hours ago, MartyReynolds said:

Here is the FSUIPC.INI file.

You only have one Elevator, one Aileron, one Rudder and one set of toe brakes actually assigned. The only thing you have two of is Steering Tiller:

[Axes]
PollInterval=10
RangeRepeatRate=10
0=0X,256,D,1,0,0,0    -{ DIRECT: Aileron }-
1=0Y,256,D,2,0,0,0    -{ DIRECT: Elevator }-
2=1X,256,D,3,0,0,0    -{ DIRECT: Rudder }-
3=1R,256,D,8,0,0,0    -{ DIRECT: RightBrake }-
4=1U,256,D,7,0,0,0    -{ DIRECT: LeftBrake }-
5=2X,256,D,36,0,0,0    -{ DIRECT: SteeringTiller }-
6=4X,256,D,36,0,0,0    -{ DIRECT: SteeringTiller }-

The yoke is on one device, the rudder pedals on the other, and the two Steering Tillers on two other devices,  one of which (device 2) no longer exists (maybe you only have one tiller and the ID has changed? You should use Joy Letters so devices will be tracked.

Without assignment in FSUIPC or in P3D, your other yoke cannot possibly be used or interfere.

Pete

 

[MartyReynolds]

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

[John Dowson]

@MartyReynolds If you are unplugging and re-connecting USB devices, you should really use the 'JoyLetters' facility (see User guide if you don't know what this is), which will prevent problems if/when Windows assigns a different id to your device(s).

[Pete Dowson]

1 hour ago, MartyReynolds said:

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.

Rather a waste of time showing me the INI file then! 😞

1 hour ago, MartyReynolds said:

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).

That's rather poor! Thomas recently converted my PFC yoke to hall effect sensors via Bodnar boards, and I get the full range I'd expect. I think you must have used the wrong impedance values. My yoke was an original PFC serial port one, via its controller board -- my complete cockpit was originally supplied by PFC.

1 hour ago, MartyReynolds said:

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?

No. The delta value in FSUIPC assignments for axes causes any change less than a certain value to be ignored. The normal delta is 256, which works well. You don't appear to have changed that (it's the 256 in the INI assignment lines).

Pete

 

[MartyReynolds]

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

 

 

 

 

 

[MartyReynolds]

ahh, here is the INI file I forgot to attach

FSUIPC6.ini

[Pete Dowson]

18 minutes ago, MartyReynolds said:

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?

Well, this is certainly what your reported results suggest. But the strange thing then is that the code is the same.  In fact the code which decides which of the inputs 'wins' is the same for the elevator, aileron, rudders and both toe brakes. It's table driven -- there's no specific code for any one of those.

So I'm finding it very puzzling.  We will investigate. First, please confirm this occurs with ALL aircraft (all those you've tried), including at least one default.

Pete

 

[MartyReynolds]

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

[Pete Dowson]

11 hours ago, MartyReynolds said:

So it occurs both with the Sim-A 737 as well as a default aircraft.

Are you using Sim-Avionics? If so is that software running whilst you've been doing these tests?

Pete

 

[MartyReynolds]

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

 

[MartyReynolds]

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

[Pete Dowson]

3 hours ago, MartyReynolds said:

Until I can get this working, could you tell me if I could just use your older method 1 for just the elevator axis?

Thomas is looking into that. I think he's determined that the problem may be identical that way too. But tomorrow we shall move further on this. Sorry, it's been a busy weekend for other reasons, not related to FSUIPC.

Sorry, please be patient. We'll get to the bottom of this. I'm sure there's a logical reason, it is just trying to understand what could affect Elevator but not the other controls when they appear to be treated identically.

Pete

 

[MartyReynolds]

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. 

 

[Thomas Richter]

Hi,

just going back to your initial post.

Quote

I have two PFC yoke flight controls that emulate B737 airliner yokes. Each yoke has a USB interface card that Windows 10 sees as a game controller card. I have set up calibrated and set up the axes with FSUIPC 6 via Method 1 as documented in the FSUIPC for Advanced Users manual (page 45). I am using P3D v4.5.

The aileron works perfectly in transfer of control from one yoke to the other. The rudder works perfectly as well. However, the elevators do not consistently work properly. At times, transfer of elevator control from one yoke to the other will occur, even when the second yoke was in neutral (yes, I did create a wider than normal null zone when calibrating). Sometimes when  trying to transfer from one yoke to the other, the elevator control will not transfer despite moving the elevator control up and down to extremes of travel. If one is persistent, it usually will eventually transfer control but can take some time before it does occur.

I have enabled control axes logging to get clear readouts of this, and can clearly see that transfer occurs correctly and immediately will the aileron and rudder axes. However something appears glitchy in the elevator axis that makes it work sometimes, then not other times.

The test's I did here with two controllers and each assigned to AIL and ELEV, From FSUIPC Advanced manual page 46 Method 2:, don't use the older described Method 1.

Please delete the assignments you did for your CPT and FO yokes and remove the added i.e. ElevatorB= line from the FSUIPC6.ini file. Then please check after closing P3D that really the assignments for the Yoke's are removed and restart P3D.

- Assign both Yoke with AIL and ELEV via Direct to FSUIPC Calibration to Aileron and Elevator axes.

- go to Calibration and define the deadzone but you have to assign this for the axis of the controller that needs the higher value, the most jerky axis.

By doing so I don't have any trouble that ONLY the axis of each controller with the highest value is used and has control as long the other controller axis is not higher.

Just to clarify as I said in the beginning, there is NO controller switching. It is the axis with the highest value used but independent of which controller it comes from. If CPT AIL is greater than FO AIL and FO ELEV is greater than CPT ELEV, then CPT Aileron and FO Elevator axes are send to P3D.

Thomas

[MartyReynolds]

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.

 

[Thomas Richter]

Hi, 

in my test's here I have a jerky controller and a good one, both assigned to AIL and ELEV axes and the deadzones defined to cover the jerky controller. With this it all works correct as designed.

Can you please with the correct definition/setup in FSUIPC of both Yokes with Method 2, no other software running at all other than P3D do a test of the controller's where the elevator axis doesn't work. For this test please select in FSUIPC logging tab the Axis to log, nothing else. After a short session where the problem has been occurred please close P3D and after fully closed please send FSUIPC6.ini file and FSUIPC6.log file as they are, unaltered in fully (zipped or attached to your message.

Thomas.

[MartyReynolds]

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 Richter]

Hi,

so nothing went wrong in that test session, at the logging looks correct. It means FSUIPC is working correct but when you normally have a problem then it looks like something might interfere the controls.

What I'm missing is the beginning of the log file as you clicked on New Log, that would have been of interest as well.

When it takes normally 5 to 20 seconds before the other controller reacts points more to a sleeping USB port, Windows power management.

Would be nice if you still have the first Log file before you pressed New Log and you could send that as well. It's normally named FSUIPC6.x, the x depends on how often you pressed New Log.

Thomas