Drakoz

Wow, that is weird. I can explain some of what might be happening. I assume your Windows machine is connected to your Theater Receiver as a sound device, correct? Meaning, you can play sound through your receiver from your computer, right? If so, then turning it off is effectively the same as removing an audio device. This causes DirectX to re-allocate all devices, which causes DCS to do a re-init. This is the same issue I mentioned where having a faulty front panel headphone or mic connector can cause your audio card driver to think that a new device was just plugged in, or unplugged. Each time that happens, DirectX treats it as if a new device has just been created or removed. Even though this is an audio device, not a game controller, it doesn't matter. DirectX causes a DirectX re-init, which causes DCS to re-init all devices. The part I can't explain is why the TrackIR doesn't work at all when the receiver is off, but only works when it is on. I would expect TrackIR to go away momentarily and come back when the receiver is turned off and turned on, but not go away as long as it is off period. Very odd. I would suggest removing all drivers or connections to your receiver and completely uninstall TrackIR also. Then re-install each separately. Pay attention to the installation order (TrackIR first, then receiver, or vise versa) and see if the installation order makes a difference. It seems some how, your TrackIR driver is being affected by whether the receiver is active. Makes no sense, but who knows. I've seen weirder. A similar issue is to recognize that display monitors connected with HDMI are often audio devices as well, even if the display doesn't have speakers. So I have seem some oddness occur with DirectX because of turning off a display, or the display going to sleep - because it may be removing the HDMI audio device from the DirectX audio device list. Though I have not seen this cause problems with DCS, because obviously when I'm flying, all monitors are active and don't go to sleep (I run triple monitors).

I am only advocating that ED rethink how they acquire and initialize game controllers, not remove the hot swap feature. The issue was created when ED added the hot swap feature, though. The hot swap feature is critically important I believe. But there is a way to acquire and initialize game controllers that should not cause the game to lock up. Getting a TrackIR disconnect/reconnect message isn't what bother's me because my TrackIR seems to continue working fine. But having DCS lock up for 2-4 seconds is a disaster. I can't play multiplayer with my mates because I become a liability for example. I've done DirectInput (DirectX) game controller programming, and I know it is possible to do hot swapping without bringing the came to it's knees. Most other games allow hot swapping, but don't come to a halt for a few seconds when they see a change in the controller list (caused by the Windows problem). As for overloading USB ports - yes that is one of the many proven causes of this issue. I have an 8 port USB hub, for example, that I have overloaded, and it would sporadically reset because the power demand exceeded the hub's capacity. But I have also proven that the issue I have in DCS occurs even when I unplugged all USB hubs and devices, and only had a keyboard and mouse plugged into the motherboard's main (non-hub) USB ports. I think I even ran DCS with just the keyboard, no mouse. Yet, I still got lockups in DCS.

This issue is much bigger than just TrackIR and it is not TrackIR's fault. For some, it affects many other USB devices - gaming devices used in DCS, but also affects USB hard disks, and other non-gaming devices for non-gamers. For many, it causes DCS to lock up or pause for several seconds when the USB devices reinitialize. It is both a Windows problem introduced in the summer of 2016 with the major update that summer from Microsoft, as well as a DCS problem because that same summer, ED introduced the ability to hot-plug USB devices while DCS is still running (a useful feature, but....). The lockups in DCS occur because DCS sees that a DirectX reset has occurred for one of a variety of reasons and DCS halts operation momentarily while it re-discovers and initializes all USB game controllers. It is a _very_ serious problem for those that have it. I have stopped playing DCS because of it. For a more clear discovery of all the possible causes and solutions, see this thread: https://forums.eagle.ru/showthread.php?t=170322 I suggest reading from the last post backward or start around the 5th or 6th page and go forward where the better information starts, but read all of it before jumping to conclusions. So far no reliable solution has been found short of wiping and reinstalling your OS and drivers (and that isn't 100% proven yet). That is my next step. It can also be caused by a hardware problem, like your front panel headphone or mic jacks having faulty wiring, or bad switches, which cause jack insert/removal events which causes a DirectX reinit. I have 100% reproduced the issue with DCS locking up and devices re-initializing by using DxDiag or other gaming device software (like simFFB) to cause a DirectX re-init. The windows power down issue causes it because the USB device goes into power save mode and that causes DirectX to re-init, or DCS to re-init because it noticed a change in the USB device list. This is a direct result of ED adding the ability to hot swap game controllers, so it is completely within their ability to solve this issue. It is possible to support hot swapping of game controllers without the lockups we see in DCS. It is as if DCS halts all interrupts, or goes into a loop that does not handle game sim updates while it re-inits the controllers. USBLogView by Nirsoft has been useful for investigating the problem. As yet, though, no one solution has solved the problem for everyone. ED needs to make a change to DCS at minimum because although this was introduced by Microsoft's power down feature, the problem in DCS is that DCS reacts poorly to the situation. I.E. There are many causes of the issue, but for DCS users there is one result - disconnect/reconnects cause the TrackIR issue, and/or it causes DCS to momentarily lock up. I have even seen DCS re-inits reinitialize FFB joysticks which is a huge problem as it resets force trim in helicopters, for example. I've seen Windows causes re-inits on my gaming devices while in other games which use game controllers, but no other game I use has the issue like DCS has.

Other than making sure all the buttons and axis work, you should make sure, the joystick does not twist. This is a weak point if someone abuses the stick, but it takes serious abuse to break it. It isn't so much a wear issue. Also, make sure the throttle levers have good friction when you adjust the friction wheel. If the stick has been heavily used, the throttle friction rubber might have worn down. But I mean _heavy_ use. But if the stick is barely used, as you say, there is little to nothing really to worry about as long as the stick works, and the buttons and axis feel good. Just hook it up to your laptop and open the Windows game controller screen and make sure all the buttons and axis work.

Glad to hear it, and yes as you say, it is a tricky problem. I have a lot of older software on my machine - Win7 to Win10 upgrade, so my OS dates back probably 4-5 years now. I intend to wipe the hard disk and re-install to see if that makes it go away. Just waiting for the right time because my PC will be down for several days when I do it.

Yes in summer of 2016, two things happened (as best I have determined) that caused this issue. 1) Windows released an update that created some problems for many Windows users (mostly related to power saving features for USB devices), and 2) DCS released an update that allows for game controller hot swap. It seems the combination of the two has resulted in the problem most of us are reporting here. But the real issue for DCS users is not the Windows issue as the Windows issue mostly does not cause any direct harm. I mean, I see my Saitek flight panels flash every 30 minutes or so all day long which is the Windows issue, but it doesn't prevent them from working 100% of the time when I am actually using them in games like X-Plane. Since they are actively being used in X-Plane, they never reset there. Same would be true for DCS if DCS didn't re-init things as a result of the Windows issue. So It is how DCS reacts to the Windows issue, or any other circumstance that may cause DCS to perform a DirextX re-init and re-discover of all devices that is the problem - at least the problem which ED can solve regardless of the Windows issue. It is the re-init and rediscovery that is the problem. I haven't tried it, but I am not surprised that an Alt-Enter would cause it as this is in general a major reset of the game (reset of all graphics and it probably executes the game controller re-init and re-discover code). There should be a way for DCS to discover hot swapped game controllers without having to issue a DirextX reset, and causing a 3-5 second delay. Both are detrimental and they are two separate actions. If ED disabled the hot-swap re-discovery, I'm sure this problem would go away. But that is not a solution - hot swap is very important for a flight sim given the complexity of the game controllers we used. There is a solution that should be possible to allow hot swap, and not cause the 3-5 second delay or re-init all game controlles. The re-init is a big deal too, not just the game lockup. The re-init causes came controllers to reset. This doesn't affect most devices, but it does affect some. For example, it causes the Logitech G940 FFB stick driver to re-init and reset all current FFB settings which results in the helicopter trim being screwed released. It causes some custom built cockpit game controller boards to re-init and reset all their logical toggle switches (switches whose toggle state is stored in memory to simulate a real toggle switch). Hopefully ED can at least look at this and give some idea of if they can even repeat it, much the less solve it. BTW, blast, this could still affect your non-USB laptop keyboard because the driver that makes your keyboard work still follows the same power shut down features of USB devices even though it is not a USB device. Meaning, the driver doesn't know it isn't a USB device. That is how drivers in Windows work - they are virtualized to assume that all HID devices are separate devices (like a USB device) and generically implement all common features, including power shut down.

Coug4r's experience is generally the case for all people. But it doesn't affect other games because other games don't then issue a DirextX reset and stop all actions while they re-allocate all the game controllers due to the disconnect event. That is the DCS problem. I run many other games with all my gear connected (some games using the gear like X-Plane, and other games not). Only DCS pauses for 3-5 seconds. USB Logger continues to show the disconnect even when playing other games, and even when I am just at the desktop. But I don't have issues with any other software, or issues with any devices actually having trouble. As for the laptop keyboard, it may actually still be USB. It depends on how they made the laptop. For example, laptop cameras are often USB devices connected to an internal hard wired USB hub. You are probably right, though, the keyboard is probably not USB. But the driver that runs it may still treat it like a USB HID device which means it is potentially affected by the issue. My point is, it is more appropriate to think of it as a user I/O device issue (which includes mice, keyboards, USB devices and game controllers, audio cards, etc.). There is a sub-system component of windows that manages all these devices, even if they aren't USB, and the Windows issue originates from there. I haven't figured out all the possible ways the issue can be triggered, but I think for most of us, the most common way is for a USB device, or an audio jack switch used to detect insertion/removal of a connector to trigger it.

The issue is a Windows problem, yes, but how DCS reacts to it (locking up for several seconds as well as causing a DirectX reset to all gaming devices while it rediscovers them) is unique to DCS. What ever the Windows issue is (and there are several possible things that will trigger it, but one ultimate issue), Microsoft isn't going to fix it any time soon, and having to disable power management, or edit the registry for every single USB device isn't a solution (even if it worked, which it does not). I've stopped playing DCS and buying DLC because of this issue. Not retribution - just there is no fun in it. I can't play multiplayer with my group because I'm a hazard when I lock up. My only hope now is to wipe my hard disk and re-install. My biggest fear is it is related to certain motherboards and even a reinstall won't make it go away. I can buy a new MB, but what if that one has the same problem. A very unpleasant situation.

Thanks guys. Much of this has been understood for years and discussed in other forums (about the MS FFB2 dead zone and the G940 issues), but seeing how it affects the Gazelle especially was the big reason I summarized it here in the Gazelle forum as opposed to positing in the Input and Output forum. I used to think the G940 was just a really bad FFB design, and with poorly designed gimbals - a week point for most FFB sticks. It is still inferior to the MS FFB2 gimbal and FFB design, but with the v1.42 firmware, now I see most the problem was the reversal bug. Again, with the reversal bug still affecting the G940 throttle and rudder pedals, these components are not appropriate for helicopter use. Only the G940 joystick with v1.42 firmware. The G940 still isn't perfect - it's gimbal and motor drive power are still lacking relative to the MS FFB2, but seeing just how bad the MS FFB2 dead zone was affecting my flying, the G940 is now a welcome relief. Alternatively, FragBurn's idea of an unsprung stick without center detents, but with friction hold is an excellent solution as well - something I have considered trying over the years.

The Microsoft FFB 2 has a small dead zone at the center and it causes this issue particularly with the Gazelle, though this issue exists with all aircraft in DCS or any other sim for that matter. Any joystick with a dead zone will have the same issue, and I now realized that perhaps many of the complaints about the Gazelle's flight characteristics are due to a joystick dead zone or because people incorrectly program a dead zone in the joystick axis settings. For a FFB stick in particular, you do not want a dead zone. Because this is a big topic, I have started a new thread (link below). I noticed the problem particularly with the MS FFB2. I also have a Logitech G940 which is even worse due to its hysteresis (what is commonly referred to as the G940 reversal bug). The HOTAS Warthog does not have this issue because it does not have a dead zone, but because non FFB joysticks have a center detent, it can create a similar result. It is all about the hesitation caused by moving past the dead zone, or having to overcome a center detent. There is no solution for the FFB2, but installing the G940 v1.42 firmware makes a _huge_ difference. I now fly using the G940 and have shelved my FFB2 sadly. New thread on this issue: https://forums.eagle.ru/showthread.php?p=3428457

I have flown DCS (and other flight sims) with a Microsoft FFB 2 joystick for years. But difficulties flying the Gazelle due to its stability systems finally brought to the fore front an issue with the FFB2 joystick that makes it less than ideal for helicopters - or at least specifically the Gazelle. The issue is the FFB2 has a dead zone at its center position. The Logitech G940 and its hysteresis "feature" (commonly referred to as the "reversal bug") make it even worse. The issue I am referring to exists with all joysticks with a built in dead zone, or to anyone that sets a dead zone using the joystick axis config. But it affects the Gazelle particularly. Many people have complained about the Gazelle being difficult to fly, or handling unnaturally. Having trouble holding it in a turn for example as it seems the Gazelle wants to turn in too hard, or not enough, and having to constantly adjust the joystick back and forth to keep it flying a level turn. Some of this is the Gazelle and the devs have done a lot of work to improve it but some of it is also the Gazelle doing what it is supposed to do, and the result being messed up by a joystick dead zone. To me, it was a little frustrating, but not difficult to overcome. I just had to be active on the controls. I did a video two summers ago to make this point showing an inset view of how I handled the controls and was able to keep the Gazelle stable (see below). But recently with all the Gazelle improvements related to this issue, I realized that the issue people are seeing may be just as much a matter of the joystick dead zone. I realized the problem after some testing with recent updates when I noticed that as long as I had the FFB2 stick off the center spot, the Gazelle was easy to fly. But as soon as I had to pass through the FFB2 center point (the dead zone), I would get a jump in movement or an overreaction in the control. The dead zone causes a moment of hesitation where you get no input control to the helicopter. You tend to move quicker to overcome the dead zone and when you come out the other side, the input you issue is too much. This results in overcompensation and oscillation. In a real helicopter, there may be a small amount of slop in the stick which creates an input dead zone, but that slop occurs exactly where you stop and reverse the stick. Not at a specific and unmoving center position like on the FFB2 where that dead zone has nothing to do with mechanical slop. It is wrong to use a dead zone period on a FFB stick as it defeats one of the benefits of using FFB. Microsoft really screwed up here by failing to understand the most fundamental benefit of their product! But people will have similar issues with non-FFB sticks as well. In fact, even if there is no dead zone on a non-FFB stick, the center detent position of the stick can cause similar issues. That is why FFB sticks are so popular for helicopter sim pilots. On the Logitech G940, the issue is worse due to its hysteresis feature. It is called the reversal bug because every time you reverse the direction of any G940 axis (stick, throttle, or rotators/trim knobs,) it waits a moment (like a dead zone) before issuing input to DCS. At first thought, you might think that sounds like the slop I just mentioned in a real helicopter. Well, no. Once you have cleared the "virtual" dead zone or slop, it issues a new coordinate that is as if there was no dead zone at all. Meaning, when you reverse the G940 axis, it always jumps approx 1% of the axis travel after a moment of hesitation. At least with a dead zone, when you get to the other side of the dead zone, the new coordinate issued by the FFB2 is only a single step away from the previous side of the dead zone. Here is a Youtube video that shows what I'm talking about. There is no way to solve this for the FFB2 short of adding a generic DirectX game controller board like a Bodnar or Teensy board acting as a new USB joystick, issuing the X/Y axis data to the sim while still preserving the original circuit board to handle the FFB. Several people have done this - there are forum topics on how to do it on the ED forums and elsewhere. The MS FFB2 has adjustable dead zone using the FFB2 software, but that software doesn't run under Windows Vista and beyond. I have loaded the software under Windows XP and tried to see if I could reduce the dead zone and have that reduction be permanent, but the FFB2 stick is by default already at the most reduced dead zone available. So even if the software worked under Win7/8/10, it would not help. Sadly, I have shelved my FFB2 stick because of this. The solution for the G940 is to install the latest firmware (v1.42) that significantly reduces the hysteresis for the Joystick axis. For firmware v1.41 and earlier, the hysteresis is about 1% or 1.5% of travel. For v1.42, it is now 0.3% and barely perceptible. Unfortunately, the v1.42 firmware is not available from Logitech's support website. The v1.41 firmware is the last official version. The v1.42 was only semi-officially released on the Logitech forums and then abandoned. Logitech revamped their forums and the original topic discussing the release of v1.42 and the link to the download are gone. But I found them on archive.org. https://web.archive.org/web/20120119090658/http:/forums.logitech.com/t5/PC-Gaming/G940-firmware-1-42-is-now-available/td-p/542496 And in the first post of that topic, you'll see you can download the v1.42 firmware from Logitech at this link: http://www.logitech.com/pub/techsupport/joystick/G940_Update_FW0142.zip Sadly, v1.42 does not fix the reversal bug for the throttle or the other analog axis. Meaning, using the G940 throttle for a helicopter collective is not a good idea. I now fly with the G940 joystick and Warthog Throttle. The G940 FFB is not as good as the MS FFB2, but the dead zone on the FFB disqualifies it for helicopter duties - at least for the Gazelle. It isn't all bad - the G940 is a very nice HOTAS. It feels nice in the hand and has a good array of buttons. Finally, some of you may say, but I like having a dead zone on my joystick because I can let go of the stick and the aircraft stays where I put it. Again, for A FFB stick, this is wrong thinking. If you want a dead zone on a FFB stick, it should be at the current position of the stick (as held by the FFB motors), not at the center of axis travel. The G940 sort of creates this with its hysteresis, but when the stick reaches the end of its slop, it issues a 1% jump in axis position, which is even worse than the dead zone issue. The v1.42 firmware solves this. As for dead zone on a non-FFB stick, having a dead zone is a personal preference thing. Since you are already dealing with a stick that doesn't work like the real thing (because it self centers - and that's not how helicopter sticks work), the center detent is the bigger problem, and adding a dead zone might actually be an improvement to compensate for the unrealistic centering.

I had the same issue today in DCS 2.2 and confirmed that DCS 2.5 has the problem. I solved it by changing my graphics settings. DCS 1.5.7 does not show the problem. I found that changing MSAA to 4x or 8x would prevent the TV screen from showing a camera image. I would get the cross hair, but no image. But MSAA 2x or less works fine. I run an nVidia GTX 1080. I noticed there is a new update to the nVidia drivers and after installing it, now I can use MSAA 4X or 8X and the TV camera works.

I finally got around to looking at the AC97/HD connector on my motherboard. Mine is a dual AC97/HD capable connector. Most motherboards from the last 15 years and most computer cases also support HD audio for the front panel connectors. But the way to configure it one way or the other (AC97 mode vs. HD mode) is to simply turn off the jack insertion auto-detection feature in the Reaktek Audio driver (the little Realtek speak icon in the lower right corner in Windows). This isn't a new idea as we all discussed this previously, and how disabling this feature (basically enabling AC97 mode) does not conclusively fix the problem in DCS unless it is a case that your front panel audio jacks are screwed up. I.e. if your headphone hack has a broken "insertion detection" switch, that could absolutely result in a DirectX reset which causes the pause in DCS. But that's caused by a mechanical problem. You can solve it by turning off the auto insert detection feature in the Realtek driver which effectively turns your audio connector in to an AC97 connector, or fix your bad connector. Anyway, the question was, if you plug an AC97 connector into the AC97/HD connector configured in HD mode, would it cause problems? Maybe, but again, many of us already discussed and tested the solution to this problem. Disable auto-detect. But that does not solve the problem for all people or all cases.

Ah, I just realized why the AC97 vs. HD audio BIOS setting may have fixed it for Olmba, and yet another reason why audio in general may cause this problem, but it is not necessarily the solution. Dutch Baron, not all motherboards have the AC97/HD audio setting in the BIOS because not all motherboards have both HD and AC97 support. This setting tells the motherboard which type of audio connector you have used to connect the PC case front panel audio jacks to the motherboard (exactly as you suggest). I believe I've seen that the same connector is used for both AC97 and HD, but the pinouts are are changed by the BIOS setting. Or there are two connectors, and the AC97/HD setting tells the motherboard which connector you have enabled. Regardless, if you have an AC97 cable connected to the audio connector set in HD mode, or vice versa, signals will be crossed and might cause confusion for the on board audio. That confusion can cause a DirectX event (like thinking you inserted or removed a mic or headphone), which causes DCS to pause and do a re-init. Again, this is just one of many possible things that can cause a DirectX event, but the problem is still that DCS is reacting poorly to them by pausing and re-initializing all USB devices. I would have thought that completely disabling the on board audio would stop this regardless of HD or AC97 mode and crossed wires. In my case, disabling the onboard Realtek audio in the BIOS did not affect the problem at all. But I will check the AC97/HD settings on my PC and see what I find. Thanks for this great info!

Sorry if I wasn't clear. Yes, the sim calculates aerodynamic stuff like the control surfaces going light when you are about to stall. The way these are implemented is the sim just commands a reduction in the effect of the spring force. I only mean that translating such sim generated force commands into something that is "correct" for the stick has to be done by the software on the FFB stick, and "correct" for the stick is kind of up the person designing the FFB stick. Similarly, SinusoidDelta comments about a way to implement actual correct force is kind of a neat idea. So I guess there are many ways you could tackle this. But just remember that the force numbers coming from the sim are really just guesses. FFB sticks are not a calibrated device. Hence why DCS has a "spring force" and "effects force" percentage adjustment in the controls menu. Got it. Yes, cost is a function of size of components. A bigger motor needs bigger silicon (bigger FETs), heat sinks, and power supplies. Power electronics is like that - cost goes up exponentially as the power requirements increase. But the fundamental circuits used to drive motors are still common and typical. For example, H-bridge circuits for a DC motor. It gets more complicated for AC motors, though, as they need to sense communication as the motor rotates. Luckily, we can buy motor driver circuits off the shelf for any kind of motor. Unfortunately, cost gets expensive fast as you move to bigger motors.

Yes, the most basic FFB command is (I believe, others will have to check me on this) a force and a vector, but that information is generic. Not something you can just give to a motor driver. You have to recalculate the input to the motor controller to match the motor strength, gearing, stick length and weight in order to implement the force and vector commanded by the FFB protocol. This type of force could be used to implement friction or hydraulic feel like the way simFFB does it, or other effects. But it is probably not so often used in flight sims. The other important FFB command would be the position of the spring center and the spring force. Unlike the vector/amplitude force described above, the spring center is positional. If the stick is moved away from the commanded spring center, the CPU inside the FFB stick must calculate and apply a force based on a simple spring force to return to the 0 position. Hence the spring center command would be used for cyclic brake on a helicopter. Or by changing the intensity of the spring force to approach 0 force, you could mimic the reduction of wind force on a WWII war bird as it slows and stalls. So in fact, spring center and force is probably the one we (DCS pilots) care about most. The FFB protocol has other commands as well, like saw tooth or square wave movements which are intended to mimic different effects (gun fire, vibration, etc.). In those cases, too, you get a command (e.g. square wave at a given amplitude and frequency) and you must interpret that command to the motor driver to get the correct feel. This is why ever FFB stick/motor combo needs to be tuned. Most of these effects are not important to us for DCS, they are more gimmicks. And if it isn't clear - the FFB protocol issues a simple command, and the CPU (e.g. the Arduino) must interpret that and give inputs to the motor controller to create the desired effect. The Windows PC has no knowledge about how the motor is driven except for seeing how the stick actually moves. So that gets to the feedback part of the loop. The stick is moved by the human, or by the motor controller, the position is fed back to the flight sim, and it may then issue a new FFB command based on the movement. More likely, though, the sim will issue a command (like spring force and spring 0 position due to a helicopter cyclic brake command) and then do nothing further until the cyclic brake button is pressed again. But the FFB stick's CPU (the Arduino for example), must also constantly monitor the position of the stick and implement the previous FFB commands by adjusting the motor driver's input as needed. This is a constant activity. So that is the second feedback loop - the Arduino monitors the stick's position and drives the motor controller. When I talked about PID feedback loops previously, those are implemented on the Arduino and can be as simple or as complicated as you want to make them. Heck, some FFB sticks (most of them???) probably didn't even use PID loops, and if there is no resistance to stick movement, the stick will slam back and forth trying to reach the commanded position, beating themselves to death as they oscillate to pieces. That is why most FFB sticks have a sensor to see if a human is holding the stick. When I do my own FFB stick, though, I plan to implement PID feedback looks to prevent this, and so I can make a safe FFB stick that doesn't require a "hand sensor". Yes, which is why you need to know the power draw of the motor at 0 RPM while being commanded to the maximum amount of force you want to create. For example, if the stick is capable of pushing 10 ft-lbs of force on the stick while the pilot is holding it stationary. That state draws the most current. You need to make sure that the motor, the motor controller, and the power supply can all supply the required current without burning up. Also, you need to be wary of the heat that builds up inside the FFB stick's enclosure. So fans and heat sinking may be needed. Most of the better FFB steering wheels have fans and heat sinks on the motors, for example. Not beyond us. The motor controller is responsible for managing which poles to drive how and when. Whether it's a single phase DC or AC motor, or a multi-phase motor (like a 3 phase AC motor), we are isolated from that by the motor controller. All we do is provide an input to the motor controller in the form of an analog input (e.g. -10 to +10V) or a digital input like a PWM signal, or with actual commands through an I2C, SPI, or other serial bus.

Re: Servo motors Yes, any motor that is designed with feedback and a control circuit to move to a commanded position, speed, etc. is a servo motor. RC servos have all this built into a single unit, but are completely inappropriate for a FFB stick because the gearing is so high, the RC servo will not free spin easily enough when no force is desired. A motor is very capable of moving at slow speed or at 0 speed (holding a force). They just draw more current at slow or 0 speed - which is why motors used on a FFB stick may need cooling. The motors you choose must be capable of handling this operation state without burning up. It's just a matter of seeking the right specs on the chosen motor. As Berniyh says, there are thousands and thousands of choices for FFB motors. Look at the 0 RPM specs for the motor - force output as well as power consumption at 0 RPM. That is the important spec for a FFB stick. Re: FFB stick gearing Most the FFB sticks I've looked at (or at least the good consumer ones) have between 1:60 and 1:80 gearing ratio if I remember correctly. RC Servos have much higher gearing. That's how they get away with such a small motor, but also why they do not free spin easily. To tell the motor position, you need to use a sensor (a rotary encoder, a hall effect sensor, a pot, etc.). Some motors come with encoders on them, but for a FFB stick, best to use a hall effect sensor that measures the stick movement regardless of the motor (no backlash). As for driving the motor, the controller logic (the CPU) has a position in mind that it wants to hold the stick at (center position, or off center due to a Cyclic brake function in a flight sim). If the stick is pulled away from that position then the CPU drives the motor to cause a known force to pull it back to position. For a FFB stick, that is how movement is applied - you must calculate the power required to apply a given force to the stick. How strong that force is depends on how strong the sim commands the force to be (spring force, or movement force). You cannot tell the motor a "force". You have to drive the motor with a given voltage/current and watch the hall effect sensor as the stick moves back into the commanded position. So it is a feedback loop. A well designed FFB stick will use PID loops (not to be confused with the USB PID spec) to prevent the stick from oscillating back and forth. PID feedback loops are a series of equations that make sure the stick moves quickly and effectively to it's commanded position, but without over shooting, under shooting, or bouncing back and forth. It may not be necessary to use PID loops, but again, a well designed FFB stick, or one with a lot of power should use PID loops if you want it to work better. The USB FFB spec, if I understand correctly, usually moves the stick to a given position using a force, not an X/Y position and speed. So FFB must have the ability to see that you are not at the commanded position, and calculate the power to be driven to the motor to apply the commanded force to reach the commanded position. So the software needs to understand both - position and force - for a FFB stick. This is actually the same in all servo systems - for example a CNC machine built using DC or AC Servo motors (not stepper motors) will work to both position the axis as well as do so at a given speed or force. A CNC machine is more focused on the speed thing whereas a FFB stick is more focused on the force thing, but the equations are similar, and still use PID Servo feedback methods. None of this applies to a stepper motor because stepper motors are not positioned using a feedback loop. You count the number of steps and just know where you are. Similarly, a stepper motor would not work well for a force to be applied to move a stick because the force of a stepper motor is always a discrete element - a step, with the same force. You can step it forward or back, but not really control the force required to do so. Finally, stepper motors, like RC Servos, do not free spin easily - so they are entirely inappropriate for a FFB stick. I think Berniyh is referring to the motor drive controller - the analog circuit that specifically drives the motor (e.g. an H Bridge circuit). The motor driver is controlled by a +/-10V input, or a digital input from a CPU. For example, for the +/-10V motor driver, the larger the voltage applied, the faster the motor will spin, or the more force it will apply. For a digital interface, there are several ways that might work, but one example (as in MetalGear's software I think) is to use a PWM (pulse width modulated) signal. As the pulse width changes, the motor spins faster or slower, or in reverse. Of if not spinning, it applies a larger or smaller force. As discussed in this thread, there are several off the shelf aftermarket drivers to drive motors, but as the motors get larger (i.e. direct drive vs. gearing), the motor controller gets bigger as well. More current, larger components, higher cost all around. And then you also start having to add cooling fans and maybe cooling fins on the motors.

Yes, the Cougar stick's gimbals are crap - I said that. The Cougar throttle, though, is mostly pretty nice - some button and knob issues that are well documented, and sadly, still having to deal with the Cougar Control Panel (CCP) is a bit of a pain. The Warthog is a huge leap forward in quality vs. the Cougar, yes. and the Warthog throttle is excellent. But in all of that, the reason I buy Thrustmaster is because of the programability (using Foxy originally, and now TARGET). Most popular game controllers offer some programmability, but none of them hold a candle to using the TARGET scripting language. Sadly, though, it is not for everyone. For that, they have the TARGET GUI, which is about as good as the programmability provided by most Saitek products. Why would you want to program the HOTAS? Because the default HOTAS setup you find in sims like DCS don't take advantage of the stick's full capability. By using TARGET, I can double triple, or quadruple, many functions onto the same buttons. I can swap from pilot to weapons officer in the Gazelle for example and make all the buttons work differently. Or I can use a press and hold button to recenter my TrackIR while still allowing that button to be used for a normal purpose with a quick press. But the biggest reason why I program the HOTAS functions using TARGET is because it means I can control the way the stick works regardless of the sim. I always keep the sim setup at it's default. Aside from assigning the analog axis in the sim, I program all other functions to use the default keyboard combos. Now when a new aircraft comes out, or if DCS does something to clobber the configs in the sim (which has happened!), instead of having to re-assign all the buttons in DCS for the new aircraft, I copy the TARGET profile, make a few changes to fix the minor differences, and in short order, I have the same complex configuration working for the new aircraft. Also, with programming, I can program functions for Teamspeak, TrackIR, etc. that are not part of the sim. It's not for everyone - you can plug in a Cougar or Warthog and use the built in DCS profile and it will work. But you are limiting the real power of a programmable HOTAS setup. Hence my comment, the best part of a Thurstmaster HOTAS is the software programability - for those that are interested in using it.

You don't have to get rid of your onboard Realtek Audio because doing so will not solve the problem. Try it - disable the onboard audio through the BIOS and try DCS. See if you continue to get the problem. In my case, I saw no effect. But if your audio jack is faulty and causing your mic or headphone to connect/disconnect randomly, then yes, of course, disabling your Realtek audio will reduce the number of times this issue occurs, but not get rid of it. Disconnecting or reconnecting a mic or headphone will cause the Realtek driver to re-init the audio devices because that is what it does. This is a normal feature of the Realtek driver (and probably every other audio card) to auto detect changing inputs and outputs and add/subtract them from the available audio devices. But there are many other things on our computers that will do the same thing, and any one of them can cause DCS to pause and re-init. Reread my post, #60 (https://forums.eagle.ru/showpost.php?p=3288227&postcount=60) where I explain all the ways it is possible to recreate this issue with DCS. It is normal for many different sources to cause a change in available devices on the system. And any such change causes DCS to pause and re-init DirectX. Obviously, while in DCS, you would want to minimize this occurring by not inserting or removing any such devices, but it seems (in my case at least), there is something in Windows that still causes DCS to re-init ever 1 to 15 minutes. My point being this is a normal part of Windows, and it is unavoidable to prevent it. No amount of turning off power saving modes, or the other fixes people have suggested consistently solve the issue. What I believe is going on with DCS is that in reaction to these common and regular Windows events, DCS is issuing a DirectX reset or re-init which will reset some devices (like some FFB sticks, or certain USB I/O boards), and then doing so causes DCS to have to reacquire all USB input devices which takes 1-3 seconds, causing a complete lockup of DCS. I've been discussing this verbally with friends that fly DCS and explaining the symptoms. More and more I am discovering that many people have this issue but have just been ignoring it because it doesn't mess up their USB devices, or it doesn't happen as often to them. It causes momentary lockups in DCS, but like me, they thought it was just a graphics glitch, or that DCS was just being glitchy period, and they just accepted that it is a fact of life. But now I think there is a pretty clear explanation of what is going on and possibly how to solve it.

An even higher point is the Cougar is fully supported by TARGET, the programming software for the Warthog. I'm not putting down Foxy - I used it for years and for those that like it, it does everything you need. But TARGET is easier to use for many (the TARGET GUI), or for people who like programming in a text file and a scripted language, the TARGET Script language is more powerful than Foxy (or rather, easier to achieve the same result). The point is, whether you want to use TARGET or Foxy, you give up nothing with a Cougar. In fact, using TARGET, you can combine your Cougar with any other supported Thrustmaster product (even another Warthog or Cougar) and share the shifted and mode states across all such devices (the Foxy IO and UMD states). Hence, if you get a HOTAS Warthog later, or just the Warthog Throttle, you can make it work transparently with your Cougar. As for the stick and throttle itself, the biggest problem is with the stick's gimbals. They suck. I stopped using my Cougar because there is about 1mm of play in the gimbal due to wear. That's a 1mm deadzone in the center of the stick's movement. Looks like with the Shapeways gimbal setup, there is a cheap alternative to fix that. The 3D printed parts are following the concept of the Uber 2 NXT gimbal set that was hugely popular a decade ago (using pull-pull springs). It gives a better feel than even a HOTAS Warthog stick in that there is no center detent at all, and it completely eliminates what made the Cougar so awful (it's original gimbals). So I would not hesitate to make that upgrade right away. But do the version where you retain the original Cougar PCB. Get the hall effect sensor boards that are analog output and hence compatible with the original Cougar PCB. That way you retain the use of Foxy and TARGET. Because the real reason why the Thrustmaster products are great is the programmability through TARGET.

USBDView is made by Nirsoft, the same people that make USBLogView. Here's the link for USBLogView. There is a link on that page for USBDView as well. http://www.nirsoft.net/utils/usb_log_view.html To those that don't know, USBLogView will show all USB device events (plug in, unplug, etc.). So it will show if a USB device is connecting and disconnecting due to, say, a bad cable or USB port. I don't think it shows devices being put to sleep, though. Or at least I never saw that happen. USBDView is more of a device list display. It shows all USB devices currently pluged in, or which were plugged in in the past, but are currently unplugged, along with all kinds of system information including details about the drivers for each device and as Catseye says, registry info. Catseye, thanks for the note - I hate to dive into the registry to solve this, but I'll check it out.

My motherboard does have Realtek audio. When I disconnect or reconnect my microphone, most the time, it causes the problem. I confirmed that the Realtek driver is causing a re-init of the audio devices and this causes the problem in DCS. I did not try it with the lineout/headphone jack, but I have every reason to believe it will do the same. But the bad news is, disabling the onboard Audio from the BIOS did not stop the problem. I also reconfirmed that hitting the "Init DirectInput" in simFFB's will cause the problem consistently as well (something I wasn't sure of before). This isn't about simFFB, but more the point is that simFFB is just performing a DirextX initialization, and that causes the issue in DCS. And of course, manually disconnecting or reconnecting a USB game controller causes the problem consistently. So having a faulty USB connector, a USB power issue (which may cause USB devices to reset), or an audio jack that is loose may cause the problem randomly, but sadly, after removing all those possible causes, I'm still having the issue in DCS from a source I cannot find. It is important to note, the issue with resetting the FFB stick only occurs in DCS. For example, if I use another program (simFFB or another sim like X-Plane) to control the FFB stick (without DCS running of course), and then I disconnect or reconnect USB devices or my microphone, the FFB stick does not reset, and the game does not lock up momentarily. I believe that when DCS added the ability to hot swap a controller, they added a DirectX init command. This may have been a bad idea. Fixing that would solve the FFB devices resetting. But would it also fix the issue of DCS momentarily locking up? It might. If DCS issues a DirextX reset, it causes all USB game controllers to reset and DCS must now reacquire them. If, instead, they only re-acquired the device that is hot plugged, it might not cause a momentary lockup. This is a serious problem that I believe a lot of people are just putting up with. I originally thought it was a graphics issue - because a lot of video games hesitate momentarily. I just assumed nVidia would release a new driver to fix it some day. But a year later, no fix, and now I realize (because of my FFB stick resetting), this is an issue caused by DCS doing something with DirextX, not a graphics driver issue. I hope we can find a solution soon.

Understood. Though aluminum is cheap. Time is the cost factor, which is why I'm offering to help. It's not a big deal to prototype something in aluminum as a test. Once I have the CAM work done, I can spit out a new part in probably 30 minutes for most pieces, and it's not a big deal to make minor changes to parts. Shipping to you (USA to UK) might be the expensive part. But regardless, let me know how I can help. Of course my goal is to play with your design coincidently, offer another perspective maybe, and then report back to this forum to help others if that is OK with you. I'm planning a shorter, stool mounted stick, but since your design is so close to what I was drawing up, I'm hoping to try yours out as a learning platform and use what I learn to reduce the size. I use Solidworks for CAD, but for the CAM work, I just need a STEP or IGES file. Regards, Michael

VR, I'm in San Jose, CA, USA, but maybe I can still help with making parts. Your design is similar to a design I've been working on, so maybe if I make parts for you, I can also copy your parts to test out my own plans (and hence help each other out). I own/run a professional CNC shop, so this isn't hobby equipment. I can easily make and remake parts with changes as needed to get things right. But I"m here as a hobbyist like the rest of you and I would like to help out. I'm also an engineer (I design digital and analog electronics for a living), so I hope to do the motor drive circuits, custom hall effect sensor arrangement, and software for my own FFB stick eventually, but for now making a working gimbal/gearing/motor mount design is the thing I am focused on, and passing what I learn onto everyone else. I've done a lot of tuning in PID loops for my CNC equipment, and a FFB stick is similar. Each stick (given it's motors, gearing, stick weight and length, etc.) requires custom tuning and everyone will eventually need some help with that too. BTW, you are totally right about thinking of torque vs. cost. This is why I am focused on the mechanical/motor design first. The software and electronics is a big deal, but figuring out the cost vs. torque to handle a stick and move it correctly is the bigger deal to me right now. I was going to start by mocking up the software and electronics to an existing FFB stick (an old Logitech Wingman wire driven FFB stick that has big motors) to learn how to get it all working, but I think I want to do all that with a stick that is fairly close to my final stick rather than going through all the FFB tuning parameter effort twice. So building something and testing it to find that sweet spot of cheaper motors and gearing that still achieve a quality FFB stick is my focus. Let me know if I can help.