Drakoz

I think most the people experiencing this issue do not get the "bling - blong" disconnect/reconnect sound. That's a different issue and your solution sounds like a good one for power issues. In my case, for sure that's not the case. It only occurs in DCS, not in any other game and not in Windows. I eventually reduced my config down to a single joystick and keyboard (not even a mouse) and moved those devices around to every USB port I had (on motherboard, on motherboard through a on motherboard hub as not all motherboard ports come directly off the main chip set, and various external hubs, powered or unpowered). It had no effect on the issue. I also proved this using USBLogView which would show if devices were actually disconnecting/reconnecting due to a power issue, or bad or loose USB connector. If it's a power or faulty cable issue, the problem would occur in all games or even in Windows watching the "game devices" dialog even with no games loaded (again this is where USBLogView is helpful). But the issue most people are reporting here is specific to DCS. DirectX reinitialization by DCS causing the problem??? I wonder if it is related to a DirectX command issued by DCS as a result of some Windows event or just in general. Maybe when DCS added the ability to hot swap USB devices, they implemented it in a way that they issue a command that causes a USB or DirectX reset, and that causes all devices to be reacquired by DCS. If so, this is probably not the correct way to do it as DCS locks up for 1-3 seconds due to this event and it resets some (or all) USB devices. I will look at the DXDiag logs next to see what I can find. Maybe I can even find a way to create the event myself by writing some code that will cause a DirextX initialization. simFFB has the ability to do a DirectX Initialization (it's part of how you must use simFFB with DCS). I think I saw the problem happen once or twice when I used simFFB to reinit DirectX, but my tests are not conclusive. To be clear, though, I have this problem even when I am not using simFFB.

Anyone still having this problem? The problem I'm seeing... The USB devices seem to re-initialize every 5-15 minutes. When it occurs, (1) some of my USB devices get reset (like my Logitech G940 FFB stick recentering and losing it's force trim and (2) I get a 1-3 second lockup in DCS while it re-discovers the USB devices. I have to retrim my FFB stick and then all continues normally except that I have often crashed or been shot down because of the lockups. Not all USB devices are affected the same - my Microsoft FFB 2 stick, for example, does not reset it's trim - just as some of you found that some cockpit USB boards were resetting and losing button states, but other boards didn't have issues. This appears to be both a Windows 10 and DCS issue. It is a Windows 10 issue in that they changed something in the summer 2016 update that caused problems for USB devices like hard disks and WiFi devices as well as gaming devices. It is a DCS issue because DCS locks up momentarily when the USB devices reset. DCS needs to do something to prevent the lock up. No other game/sim I run has these issues, not even sims where I use the same USB devices. It seems DCS is seeing the change in USB state and stopping all operations while it reinitializes the USB devices. I use a TrackIR 5 with latest software. I have occasionally seen the messages in DCS saying TrackIR disconnected/TrackIR reconnected when the problem occurs, but not often. Details of my efforts to solve the problem: Note all of the devices I tested with used to work before this problem started. The windows 10 Update in 2016 and/or the DCS update around the same time started this issue, but I had never seen this issue before in Windows 10 or 7, or in any prior version of DCS. The issue has existed since it started - no update to DCS or Windows 10 has affected it. 1. Disconnected every USB device and hub on my computer except for one joystick and the keyboard (even disconnected my wireless mouse and it's wireless dongle). Problem continues. Moved that single joystick and keyboard around to various USB connectors to make sure it was not a bad connector, or to make sure I wasn't using an on board motherboard hub. No change. Occurs with USB 2.0 and 3.0 ports equally. Occurs using hubs or direct motherboard USB ports. 2. Turned of "USB Selective Suspend" in the Advanced Settings Dialog for Power Management. No change. 3. Turned off "Allow the computer to turn off this device to save power" on the Power Management tab (in the Device Manager) for all USB hubs, HID compliant mice and keyboards, and Human Interface Devices (which includes joysticks, and other USB controllers). No change. 4. I rebooted and then verified that #3 above was still true for all USB devices and hubs. Some devices re-enable this feature on reboot so you must uncheck the power off box again every boot. No change. Note, if some of you solved this issue by doing #3, check your power management settings after reboot. I bet several of them re-enabled the power management. If this is the solution, it is not a good one as you might have to disable power management every boot for multiple devices. 5. Verified that #3 above was still true for any virtual HID devices like the G940 key remapper or Thrustmaster TARGET (if I was using them). No change. 6. Deleted and updated as many USB device drivers as I cold find on my system and uninstalled a few pieces of software that might have had some connection to USB devices (just to be sure). No change. 7. Verified that I have the latest BIOS for my motherboard as well as latest motherboard chipset drivers (anything having anything to do with USB hardware). No changes. 8. Tried USBLogView to see if any USB devices are disconnecting and reconnecting. No. All USB devices are remaining connected throughout the problem occurring. This shows there is no hard disconnect of a USB device occurring. I'm to the point of trying to reinstall windows from scratch, but as that is days of effort, and no guarantee it will solve the issue, I am reluctant to try it just yet. Sadly, I have to curtail my DCS flying until I can solve it.

OK, I think I figured out what is going on with the G940 and it happens with the Gazelle and Huey (and I assume other helos). In the G940 software setup you can change the spring forces.. But this is conflicting with the DCS setup and under certain circumstances, you'll see really strong spring force, but in other circumstances, you'll see soft spring force as the two conflict with each other. This is not a DCS problem. It is a G940 software problem, maybe related to Windows 10. I will explain below. I have loaded the G940 software which includes the Logitech Profiler which allows setting custom key functions for the G940 buttons. But the menu we care about is the Options -> Global Device Settings. You can find this either from running the G940 Logitech Profiler and going to Options -> Global Device Settings or by going to the windows Game Controllers dialog, doubling clicking on the Logitech G940 in the controller list and clicking on Settings. The two dialogs are similar, not exact. But they both perform the function we care about. This dialog allows you to set the Overall Effects Strength, Spring Effect Strength and Damper Effect Strength. It also allows you to enable or disable the Centering Spring in Force Feedback Games and change the spring force. With this last item enabled, the spring force is very strong in DCS (too strong making it no fun to fly the Gazelle or any helo and making it seem like the cyclic brake is fighting you). So I disabled it. I also set Sprint Effect Strength to 50%, leave Overall Effect Strength and Damper Effect Strength to 100%. Then in the DCS FF Tune dialog, I set Trimmer Force to 100% (default) and leave the other settings at default (Shake 50%, Swap Axis, Invert X, Invert Y unckecked as it should be for the G940). With these settings the G940 feels pretty good and the cyclic brake function works pretty well also - the amount of force resistance with these settings is very similar to the forces I feel using an MS FFB2. But the problem is, certain events cause the G940 FFB driver to reset which enables the full spring strength or otherwise messes up the settings set in the G940 Profiler software. In my case, sometimes alt-tabbing out of DCS and back in would cause the forces to get messed up. Or, for some reason, I have a problem in Windows 10 that causes the USB ports or the game controllers to reset every 10 minutes or so and this resets the G940 driver and makes it all go back to full spring force. When it gets messed up, I found that pressing the Cyclic Brake button (T) or resetting the brake function (L-CTRL+T) would reset the G940 back to the correct force settings. But in some other testing, this did not work consistently. Sometimes I had to go back to the G940 Gloobal settings and click OK on the menu again to enable the proper settings. Play with it yourself to see what happens. Note, the every 10 minute reset I'm experiencing is not a DCS problem. I'm pretty sure it's something wrong with my Windows system or a bad USB device causing that problem. I've had this issue ever since the major Windows update last year. So I hope nobody else is having that issue. It causes DCS to hesitate badly twice in a few seconds as it reacquires the USB devices or something like that. Anyway, my point is, anything that causes the G940 Profiler or driver software to reset will make the G940 go back to full force. Hypnos, when you said that you could get your G940 tp work, but then when you restarted DCS (or reboot your computer or ???) later, it would not work again. I'm pretty sure the above explains why it works sometimes and not others. Because the Logitech driver is being reset and enabling the full spring force. Check it out and let me know.

Yes, this is normal, but not correct. When you release the cyclc brake button, the FFB stick should stay where you left it, and the virtual stick in sim should also stay where you left it. But in both 2.x and 1.5.x the virtual stick returns to center. I would call this a bug. But it should not affect your flight as the Gazelle follows the real stick, not the virtual stick. You can see what the Gazelle follows by bringing up the controls indicator (R-CTRL+ENTER). The indicator should match your FFB stick position. Yes, when you release the brake button, the stick should release it's force and remain still, not push back to center. If it pushes back to center (which is what I think you are saying), that is a problem. Are you sure you have the cyclic brake button mapped to your stick? Try using the keyboard command for Cycke Brake (press and hold T, move your stick, release T and your stick should remain where you left it). Then press L-CTRL+T and it should recenter your stick as this resets the brake to center. Also, you (or someone else) mentioned that when you press and hold the brake button, the stick does not go limp. Yes, this is a bug. As long as the brake button is pressed, the FFB stick should be limp (no force). The effects I describe above are true with the Gazelle using either a G940 or a MS FFB2, and on DCS 1.5.x and DCS 2.x. So it is not related to the particular FFB stick - assuming you have the invert axis setting set correctly of course. The G940 is not a very good FFB stick unfortunately. I think it's forces are too strong (not subtle enough) and lack precision (the motors, gearing and gimbal for the G940 were not well designed). Plus there is a very non-linear center force dead zone with the G940. I think this is what you are feeling. What you describe above is what I feel as well I believe. Regarding the force dead zone, this allows you to move the stick a small amount and feel little to no force, but then push it a little harder and the force is very strong, too strong. The dead zone isn't a control dead zone (the stick actively controls the helicopter in the force dead zone), but a force dead zone (the FFB does not push the stick hardly at all). Because the Gazelle has some odd flight characteristics due to it's stability control and how you have to use the stick to compensate for it, I believe that it creates more difficulty flying with a G940 and stability control on the Gazelle vs. other helicopters. But the problem is a G940 problem, not a Gazelle problem. It is so bad that I don't like using the G940. I have reduced the Trim Force in DCS to 30% and it improves things, but does not get rid of it. I tried less than 30%, but now the force dead zone gets so large that it won't hold the stick using the cycle brake. I used simFFB with the G940 and it improves things significantly, but that's because simFFB is mimicing things like friction and hydraulic feel as well as spring force. DCS does not mimic friction and hydraulic feel, though. DCS only mimics spring centering force and that is the worst effect to use on the G940 because it is too strong and too much like a light switch (no return force in the force dead zone and then hard force as you move outside the dead zone). Have you loaded up the G940 software? If so, go into the Logitech G940 software to the menu that lets you set amount of spring and effects forces (the "Global menu" that has 4 sliders to control the % of force for each type of force). Uncheck the "enable spring force" at the bottom of the menu. If this is enabled, then both DCS and the G940 software are implementing a centering spring force, but you need to turn it off so only DCS implements the spring force. It should still work with the G940 spring force enabled, but to me, it felt much better to turn this spring force off.

Hypnos, I compared the settings for the G940 vs. the MS FFB 2 in both DCS 1.5.7 and DCS 2.1.1 (all latest updates as of today), and all is working as it should be. Meaning, for the G940, in the FFB Tune menu you should have Swap Axis, Invert X, and Invert Y all unchecked. For the MS FFB2, all you should change is the Swap Axis (checked). These settings are the same for other aircraft in DCS. This also matches other sims and games I've used these sticks on. So, yes, Polychop fixed the FFB for the Gazelle to match the rest of the world. But it sounds like you are describing other issues. You may be having other software or hardware issues with your G940. I suggest you load simFFB and use that to test the G940 to see if the FFB effects work in the correct direction. simFFB has an "invert" check box. For the G940, leave it unchecked. For the MS FFB2, check it. simFFB will allow you to perform the equivalent of a cyclic brake and "hat" type trim function on your stick with no sim running. Hence a good way to test your stick. If you want, you can use simFFB in DCS. Load DCS and enter your mission. Once loaded, alt-tab to simFFB and click "Init DirectX Input" in the Options menu and now simFFB will control all your FFB functions. For helicopters this works better than in DCS, but for fixed wing, you will lose the effects of wind on the control surfaces (like in a stall). I prefer the feel of simFFB and it is completely compatible with DCS FFB, trim and cycle brake functions. Also, the G940 can be made to feel much better (better forces) using simFFB's settings. I wish all sims implemented this kind of FFB (damper, friction, spring) feel in game. Hope this helps.

Just to confirm, when you say that your G940 isn't working, do you mean that it moves incorrectly, or does not move at all? If it moves incorrectly, follow Pat01's comments in the forum topic you linked to. Hopefully that gives the right settings. But those settings are probably only right for the Microsoft FFB 2. They will cause the G940 to move incorrectly. So.... If those settings do not work, review my post earlier in this topic (https://forums.eagle.ru/showpost.php?p=2897668&postcount=5) for an explanation as to why your FFB 2 works, but your G940 is moving incorrectly. It all boils down to the settings for the "Swap Axis" and "Invert X" and "Invert Y" settings. Get these right and your G940 will work. Sadly, not all FFB sticks follow the common standard for which axis is X and Y (Swap axis) as well as which direction the FFB stick should move (Invert X and Invert Y). Hence why we have these options. When Polychop first developed FFB for the Gazelle, they tested with a MS FFB 2, so their default settings matched that stick. But the rest of the DCS aircraft have the default that normally works with sticks like the G940. Recently, I believe, Polychop fixed all this so that the Gazelle works like all other aircraft in DCS. Play around with Swap Axis and Invert X/Y and you'll get it. If you still have trouble, let me know and I'll confirm the settings for both sticks in v1.5 and v2.x as I have both a G940 and a MS FFB 2.

Ya, I've contemplated doing something like that. Thanks for the advice. I have the Saitek Combat Pro pedals (the round medal foot pedal is more like a helicopter anti-torque pedal vs. most other rudder pedals). I turned the spring force down to minimum, and the center detent doesn't seem to bother me any, but it could be better.

Not sure there's much I can say that you probably haven't already figured out. But I'll assume nothing and explain my setup. Axis Tuning for Cyclic and Rudder... For everything, I set Deadzone=0, Saturation X and Y = 100 (these are default). Deadzone will only make flying more difficult as the center of the stick will have a dead spot, and Saturation will remove max deflection which reduces the control available on the helicopter. For the Curvature, I started out (like you), with a curvature (about 15-20) while I was learning, but as you get more comfortable flying, you should reduce the curvature to less than 10, or even set it to 0. A real helicopter is _very_ sensitive which is more like curvature 10 or less in DCS depending on the length of your joystick. If you use any kind of stick extender, then your curvature should be 0 or close to 0. This is if you want the cyclic and rudders to mimic a real helicopter. If you don't care about that, then set these numbers to taste. It's a sim and this is meant for fun, so it doesn't really matter. In my case, however, setting DCS to a realistic sensitivity helped greatly in my ability to fly a real helicopter the first few times. While you are learning to fly, hold the stick with 3 fingers, not a full hand. Rest your arm on something and move the stick just with your fingers. This gives you better control over the very small movements required on the stick and reduces arm pump (muscle strain on your entire arm) because it is easier to relax. It's how I learned to fly an real R22 starting out as well. Learning to relax your arm (and yourself period) is critical to learning to fly a helicopter. Axis Tuning for Collective... Unless there is a special reason to do so this should be set to default. Deadzone = 0, Saturation X and Y = 100, Curvature = 0. There is generally no reason to change these unless you are trying to match or fix some kind of non-linear situation caused by your cockpit setup (which I gather is why you changed them). Button setup and other settings (I think this is what you really asked for) How you set up your buttons is entirely a matter of taste. I always look at the cyclic and collective buttons for the real helicopter (in the DCS manual) and try to match those buttons on my joystick and HOTAS Warthog throttle as much as possible. For example, the collective on a Huey has search light controls. I set those up as well on my collective, and I have flown some missions where using the search light makes for a fun experience. Then I add other functions as desired to make flying easier. But again, this is entirely a preference thing. Because the MS FFB2 stick doesn't have enough buttons to map everything on the Huey's real cyclic to the FFB2 stick, I mapped some of those to my Warthog HOTAS throttle instead. The point being, you want these controls accessible without having to touch a keyboard (remove your hands from the controls). Also, for the FFB Tune menu for the MS FFB2, I have played with the Trimmer Force some, but I've always kept the shake at the default 50. But since I use simFFB, the FF Tune menu in DCS is bypassed and simFFB sets all that. When you run simFFB, it takes complete control of the FFB functions away from DCS. DCS has done some improvements to the FFB functions since I last played with all this, so it's time I try DCS FFB (no simFFB) and see how it has changed. Also, FFB effects are slightly different from one aircraft to the other as they are controlled by the aircraft maker, not generically by DCS. Not sure that really said anything useful, but since you asked... Regards, Michael

I can't speak for the others, but I am still interested in this and I still plan to hook up the Teensy board I bought to an existing FFB stick I have as a test platform and do some work on the software from MetalGear. But it is about 5th on my list right now unfortunately. I am working on some other joystick/game controller related projects first.

Honestly, by now there should be plenty of TrackIR's on eBay to get one cheap and relatively speaking a new one isn't really that expensive either especially since it is an investment you will be using for a very long time (unless you go VR). For those that want to DIY something go for it, but if you want something now that works, you won't be disappointed with a TrackIR 4 or 5. Next to a proper joystick, it is the most important thing any sim pilot should have (yes, more important than rudder pedals - though rudder pedals are a very close 3rd). Once you own one, you'll wonder why you made yourself suffer to so long not having one. Also, if you want to save a little money, get the one with the clip that attaches to a hat - you don't need the LED clip. The hat clip works just fine. I've been using head tracking since 2000 (TrackIR 3, then TrackIR 5) and if it wasn't for head tracking I wouldn't be an avid sim pilot. So forget the cost Ya, money matters, but also ask yourself,what the value of your "fun time" is. Flying a sim without head tracking is like flying a sim without a joystick. You can do it, but it really isn't the same. I'm not putting down people that want to DIY their own head tracker and I'm not putting down hegykc's efforts either (he'll get there when he gets there), I'm just saying that consider your time is important too, and waiting for hegykc to make a head tracker is time lost when you could be enjoying a flight sim with a TrackIR, or your own DIY effort. Life is short, and the cost of a TrackIR isn't really that expensive in the scheme of things.

For those that haven't seen it yet, this issue has been fixed in DCS 1.5.4.57013 Update 6 (Sept. 23 2016) and DCS World 2.0.3.57442 Update 3, the just released update (Oct. 7, 2016). I was running 3 monitors in a left/middle/right configuration and had to place my UI (map, radio menu, main menu, etc.) on the left monitor using the monitor config file. But now with both the above updates, I can put my UI back on the center screen and everything including F10 Map clicking and scrolling works as you would expect. I hope the same is true for everyone.

Convoy escort mission with Black Shark Den.

If the USB timings are the main concern, then yes, export that to the interrupt routine and see if it works better. Also, if you are missing button push events, it might be a good idea to debounce them externally using a debounce circuit (something to make the key press a little longer as well as debounce it) so if you are in the USB interrupt routine, you don't have to catch every button press exactly on time. We haven't had to use hardware debounce circuits for a couple decades, just re-sampling in software. But in this case, a hardware debounce circuit might be a good idea. There may even be an I2C GPIO chip that does this for us. The goal is to off load stuff from the CPU - not because the CPU can't do it, but because the time you'll spend making the software do it well might not be worth the effort when a couple dollars in external parts might make things much easier. Alternatively maybe place the button detection circuit at the end of the USB routine in the Interrupt routine. Keep it simple to detect a button press, but do the debounce in software outside the interrupt routine in your main loop. As for analog sensing, I would hope it isn't so critical that it be sensed on a regular schedule. If there are long delays between sensing analog movement, you can probably average the analog signal and extrapolate (if that is even needed). Forgive me if I am suggesting stuff you have already thought of.

MetalGear, that's what I thought. I had considered all these issues a few years ago as well when speaking about the same issues with Grendel on the 3DPVert. I don't profess to have solutions to them, but that's just the point - the solution is to spend time massaging the code to work, and if you make any changes to the code later, it results in significantly messing up the timings again and lot's more time wasted trying to re-fix the timing. It's a never ending problem. The solution is to have a processor that is fast enough to put all timing related stuff in an interrupt, or timer driven loop, and all other work is done outside of that loop as time allows. On an 8-bit ATMega, that may be difficult, but with a modern 32bit processor, especially one with better built in USB support, it might significantly ease the process. Most my experience is with ARM7 architectures (Phillips, now NXP 2000 series). For timing, I've used a timer interrupt to make sure all timed events happen at a specific interval. For example, I was working on a system were serial busses like I2C were being bit banged (all done in software, no hardware assist) and the timing is critical. I guess that's what you are doing using an interrupt to count ms since start. Then all events occur on intervals of some number of ms in your primary loop. This has worked well for me in data acquisition tasks in the past, but I didn't do USB which is much faster than the I2C stuff I did - well, assuming USB 2.0 support perhaps. I bought another Teensy 2.0 so I can dive back into the adapt-ffb-joy projects and start where I left off a couple years ago. But I have always planned to move to a 32-bit processor with much better capabilities, RAM, and ROM, and better USB hardware support. They are so cheap these days. The only reason for me to stick with the Teensy 2.0 is because as I'm learning, I wanted to stick with what the Adapt-ffb-joy project started on. My next goal was to re-write my own code on a TI processor or similar (32 bit with good memory and good USB support).

Ah, understood. Need to optimize the code to keep the timing right so you don't lose the USB connection or other joystick events. I remember discussions with the 3DPvert guy (Grendel) about similar issues a few years ago. Are you using interrupts for anything to keep timing, or is it all round robin through the main loop? Are you using floating point, or integer floating point (shifting the integer back and forth to do floating point using integers), or look up tables? I mean, I assume there is some trig going on for sin/cos on angles of force so you have to use floating point or look up tables right? The ATMega is not very fast at floating point. Did you post the source code? I didn't see it. Only the HEX file. I just ordered another Teensy 2 from PJRC. I'm going to mock this part onto the Wingman Force stick I have as a test platform. So hopefully I can help with your code.

MetalGear, is the main thing you were having trouble with related to combining forces? You said something about having difficulty with timing previously.

Yes, that's what I meant by when I get the Wingman Force taken apart again, I will report back. I plan to sort out what signals I need to make it work, get a CPU (e.g. Arduino, Teensy) to run it and start playing with software.

RC Servos are inadequate for this at a price that is reasonable. Even if the servos had enough toque and low price, they would resist free movement too much. Take a servo and try to move it by hand. That's just too much resistance for a FFB stick. And once you get a servo spinning fast (like a fast stick movement from left to right), it has too much momentum. It over shoots unless the electronics stop it. One of the critical features of a FFB stick when the motors are disengaged, or driven at a very low current, is the stick is completely floppy. For perspective, the motors involved in a FFB stick are typically 1 inch dia. or larger DC motors often driven through a 30:1 to 80:1 gear ratio. I'm not sure how much of the ratcheting that I feel on my various FFB sticks is gearing vs. DC brushed motor cogging, but yes, I have been down on the idea of gearing for this reason and other reasons. The MS FFB2, with DC brushed motors, has the best feel in my experience regarding ratcheting and I think it is because of a very high motor gear ratio. But it also has noticeable backlash due to multiple gears. So as you say, backlash is a big problem, and making gears without backlash is difficult or expensive. Re: wire driven pulleys, I have felt this is likely best as you say. My only concern is if the wire breaks, it is not an easy fix for an inexperienced person. The wires are under tension, and have to be done just right. That being said, the Wingman Force I have to use for software development is a wire drive joystick, which is also part of why I'm using it. I want to see how well the wire stuff works. I looked at this a lot in other applications as well, and wire is in fact my favorite solution for many reasons, except for I just need to understand the reliability. The Wingman Force still has DC brushed motors, and a very low gear ratio (maybe 15:1??), so the brushed motor cogging will show through heavily to the stick. But the openness of the case and design, and the wire drive makes it much easier to mock in other non-brushed motors in order to learn. Except ground gears are very expensive to make. They can be as precise as you are willing to pay for. :) This was as much an economic choice on their part as anything else. As with everything FFB, there are many compromises. The belts smooth things out some and reduce stress and are probably much better than using plastic toothed gears for a FFB wheel due to the torque and size of parts. I'm talking about toothed belts here so they don't slip. Not sure how much the notchy feel I get on my FFB wheel is the belt, though, vs. the motor, but I think the motor is a 3 phase AC servo motor so the notchy feel I get is probably the cogs on the belts. Most CNC machines are run by rubber belts I'm sure you know - even the high end german 5 axis CNC I have. But it's a single 2:1 ratio and it allows the belts to be tensioned to get rid of backlash. This is another reason to use belts or wires. It's easier to remove backlash. On FFB products, though, the belts do break (I've read complaints about belts breaking in FFB wheels). The belts can be replaced as a bolt on item, though. Well, sort of. Doing it on a FFB wheel is a huge PITA. But doing it on a FFB stick maybe not so much. Again, with over design, this isn't a problem, but there's a point where the thickness/width of the belt causes resistance beyond what is acceptable.

Best way to get started on software testing with a real stick is to use an existing FFB stick. I grabbed an old Logitech stick for parts for exactly this purpose (a Logitech Wingman Force). It has a decent gimbal, large DC brushed motors, and an analog drive circuit to drive the motors. So I believe all I need is a DAC out and maybe an opamp to adjust the voltage range to match the existing analog circuit. And because the analog motor driver circuit is separate from the CPU board, it is possible to just remove the existing CPU Board and tap into the motor driver cable directly. I'll report what I find when I get a chance to figure it out. Then I can use this to start figuring out software.

I started working on a DIY FFB stick a couple years ago, but it was a slow burner project. Earlier this year I turned up the heat on it, diving deeper into the gimbal design, and motor/drive choice (more on that below). But I had to jump back into the software and electronics because yes, that is the biggest task. Anyone that tells you, however, that any part of a _good_ FFB stick is simple hasn't spent enough time understanding them yet. This isn't a trivial DIY project. It is my hope that my efforts can help other DIY'ers wanting to make a FFB stick. So maybe it's time I started collaborating with others. I'm an EE (I design digital and analog circuitry for embedded products), I write software, and I have a well setup CNC machine shop. But I can't do it all at once, and I really want to get a working prototype ASAP. I have investigated much into the USB PID spec and software and yes, it is a mess. Much of the spec is incomplete or incorrect. The 3DPvert project from the Descent forums (by Grendlel) and Adapt-FFB-Joy projects inspired me years ago as I am a long time Descent fan. I used these projects to get my old Microsoft 3DPro and Microsoft FFB Pro sticks working. The patent issues may be a problem as well, but I have no knowledge of what is patented or how. I fear, though, that Immersion's patents are the reason we don't have any commercially viable FFB sticks on the market, and won't for a long time. Even if the commercial market was willing to make FFB sticks (and there are many reasons beyond patents why they would not), what we get would likely be sub-standard, and weak in some way or the other. By weak, I mean, poor feedback feel (like most FFB sticks that were made), weak plastic parts needed for mass production, and poor long term reliability. I don't blame the FFB stick makers for this. A FFB stick is nothing but compromises. I'm still amazed that the MS FFB2 was only a $200 product, yet it is probably the best overall FFB stick made (best feel, best reliability), and amazingly all using plastic parts and no roller bearings. Even the G940 uses metal roller bearings in it's plastic parts. But the MS FFB2 isn't perfect. To make it better would have been prohibitively expensive for a consumer product. So for my own project, I started designing CNC machined aluminum gimbals with roller bearings. Because the motors can't be mounted to the gimbal axis directly, they must be mounted stationary, and transfer their torque into a gimbal that rotates in two directions without moving the motors. It's a trivial concept, but it's not like a normal joystick gimbal. Requires a lot more bearings and parts. This is just the prototype. It has to allow me to try different motor/gearing vs. stick weight setups (short stick, stick extension, heavy stick vs. light stick) so the first iteration will be over designed on purpose. The stick movement system (motors, gearing, and the PID loops to make it work without oscillating itself to pieces) is a big tuning project, and the tuning changes with every change to the stick (stick length, motor torque, weight of the stick). It is possible to come up with a specific formula for tuning that other DIY'ers could follow, but as people will want to customize the sticks for their simpits, making something that simplifies this process for people that don't understand PID loops is important. To be clear, this is a bigger deal for a FFB stick than it is for a FFB wheel. But I have to admit, I"m not speaking from experience with a FFB device. My experience is from tuning CNC machine PID feedback loops. More complicated than needed for a FFB stick but it taught me the reason why mass, speed, and motor drive strength matter - and probably why a couple of you commented on the difficulties of getting accurate movement in a FFB device. It is interesting that the plastic FFB sticks gain an advantage here. Plastic means less mass, weaker motors, and easier to tune. There is a reason why it takes two MS FFB2 mechanisms to drive a metal Thrustmaster Cougar or Warthog stick handle. Everything gets exponentially bigger with weight (bigger motors, gearing, gimbals, etc.). Regarding motors, and direct drive vs. geared Stepper motors - no. You need motors that spin freely, and stepper motors do not. Also steppers are "start/stop/start/stop" in their motion (hence the name stepper motor) and very noisy. A stepper would not provide a good FFB experience. It would be funny to see, though. If you've seen any videos of a CNC machine using stepper motors, you know what I mean. :-) DC brushed motors are the cheapest choice, and this is what all consumer FFB sticks have used as far as I know. But I think some of the newer consumer FFB wheels are using 3 phase AC servo motors. There is a difference in cost and quality. DC brushed motors will give a notchy feel in the movement as you pass the brushes over the gaps in the main shaft. DC Brushless, or AC Servo motors will not be notchy, but they are more expensive - possibly a LOT more expensive. For a quality FFB stick, I was planning to start with DC brushless. Honestly, though, because of the need to pick a proper motor for the application, I might have to just spec a motor and buy it from a vendor instead of trying to find any old motor on eBay. For DIY'ers, this may become a problem as motor, gearing, and torque are critical factors to figure out. You can easily waste a lot of money and time buying motors only to find out they don't offer a good feel or enough torque. It's not just a matter of if the motor is strong enough for the FFB effect. It's whether the motor is strong enough to drive a stick (of given length and weight) accurately without saturating. If the motor saturates (what happens when the motor is too weak), then it is more like a light switch banging from 0 to full torque as the output driver constantly bangs off the maximum output voltage trying to drive the motor. Again poor FFB feel, and a critical part of the PID tuning process. You can always just get an oversized motor, but trust me, one of the biggest compromises in a FFB stick is finding the smallest motor that will fit in the case and still provide good FFB feel. For simpit builders with floor mounted sticks, this doesn't matter. For someone trying to make something smallish in size for on a desktop, or a pedestal in front of an office chair, it does. As for attachment to the gimbal shafts, direct drive it out. Well, maybe if I used a nice AC servo motor, but those would be prohibitively expensive, and probably too large for a small desktop FFB joystick. Again, it might be OK for simpit builders. So the method of attachment is gears, or belts. Belts will wear out over time, but provide the smoothest operation. Belts and their gears should be commonly available off the shelf parts. Gears are the common choice for FFB sticks, but they are always plastic. That is actually probably better than using metal gears. Metal will have more stringent lubrication requirements (you'll have to re-grease them regularly or you'll get rapid metal grinding and wear). Plastic is more forgiving here. Getting rid of backlash so there is no mechanical dead zone is the reason why all this matters. That, and being able to buy such parts off the shelf because I don't want to waste my time custom machining such parts - especially the gears. Gear design and machining them is not trivial - not if you don't want any backlash. I might look into 3D printed parts, but this isn't something you can do on a common hobby 3D printer. The tolerance and strength isn't there. Hence 3D Printed means expensive. Another option is wire driven (like a gear, but you use piano wire wrapped around a shaft to spin the gear or motor). I don't like this idea, because I assume the wire will also wear out and break. So I would rather people have to replace a belt than have to replace a wire. But there are a few examples of DIY FFB controllers using wire drive. It might be possible to get creative with new concepts like linear magnetic drives. But this is probably highly custom and will take up more space than it is worth. I haven't looked deep into this yet. Software If there is a possibility to collaborate on an open source joystick FFB software project, than that would help give me more time to work on the mechanical stuff, and the electronics. Yes, there may be off the shelf electronics to make this work, but my plans go way beyond what any off the shelf stuff can offer. That's a topic for another day. The software has 3 components to it. 1) USB PID, 2) the actual FFB drive software on the stick which requires implementing the USB PID stuff as well as PID feedback looks for the FFB movement. Don't confuse USB PID (Physical Interface Device) with PID feedback loops which is about the equations used to tune an electro/mechanical moving device. 3) Software to allow DIY'ers to actually use all this stuff to build and tune their own DIY projects with any competence. I've left out some details, but my point is, it's not good enough to just make some source code. It needs to be refined enough to make it easier for DIY'ers to create their own custom variations of a stick. I.e. help with PID feedback tuning and adjusting parameters. All my comments above are assuming the use of the USB PID spec, which is the FFB that all our flight sims follow (DirectX to USB PID). Of course with custom software written directly for DCS, for example, the FFB can be made immensely better. But that's a project for another day and has to be done for each flight sim - a support nightmare. Maybe there is a chance for the Internet community to re-define FFB on the PC to provide something better than USB PID and do it in a way that the sim developers will jump on board. But if anyone is going to do that, it needs to be a dedicated team willing to make it work long term, providing SDK's to the sim developers, support, and hand holding (and maybe dealing with possible legal and patent issues). In other words, a well organized effort. Otherwise we would just be wasting the time of the sim developers. I'd like to see it happen (and would pledge my support to help), because the USB PID stuff is somewhat disappointing. But for now, I'm grinding my teeth on just getting a prototype working any way I can. So what is my point with all this For those that have read this far, my goals are to make a FFB stick for my own purposes, but if I'm going to do it for myself, I should help enable others to do it as well. That might mean working on open source software, but will also mean making parts (mechanical and electronics) which others can use to build their own custom FFB sticks. Unfortunately, none of this helps the average sim pilot that just wants a FFB stick and wants to go fly. But doing a complete FFB joystick product is a major business venture, and not likely a very profitable one. If it were, the major companies would still be doing it. So let's see where this goes.

hegykc, exactly my point (and the only reason I responded to the VR conversation in your thread about sim controls, as it is off topic). VR does not play well with sim controls like what you are building. But because VR will likely become a big deal for main stream gamers, it will further alienate flight simmers from the rest of the gaming world. Maybe, maybe not. But it will have some impact. Most people I've talked to who use VR love it. The realism that comes from 3D vision when flying a helicopter near the ground for example, is _very_ compelling. Perhaps less so for fixed wing unless you fly near the ground. So VR could take us away from nice simpit controls like what you are making, hegykc. For serious simpit builders, no. But maybe for the people who are half and half like me (I'm not going to build a complex simpit, but I do try to use multiple controls to enhance the experience), I have a choice to make. If I go VR, it means I will be using fewer real simpit controls, and more virtual controls in the sim instead (clickable cockpits). Take the A10 CDU you are building. That is an example of something I would probably buy if I don't use VR because it is a complex control that is a pain in the butt to do with a mouse. But with VR and the technology that uses a pair of IR cameras to see your real hands and put them in the sim, now all of a sudden I can do the CDU with my hands and fingers. No more pain using a mouse. I am talking about the Leap Motion product. Sims don't directly support it yet, but if they do, it will be a game changer for using VR instead of a simpit. In the mean time, Leap Motion provides basic support by turning your hands into a mouse in a creative way. All this works without special gloves or sensors on your hand. https://www.leapmotion.com So simmers will fall into two categories. VR simmers who have minimal to no simpit controls, and simpit people that can't use VR because they can't see their simpits. Well, the 3rd category are people that just fly around with a joystick and use the mouse for everything else. But those people aren't likely to buy VR or simput controls.

(and as others just commented) VR will be driven by a whole cadre of new companies (or all the old ones grabbing a pice of the pie) trying to dive into the first real transition to computers, gaming, and entertainment since the Smart Phone became a thing. This isn't the minor update of a 4K monitor (which will be the norm eventually too). It is a paradigm change which will be driven mostly by console game companies, not PC games. And that is what will drive the price down for the PC as well. Don't underestimate the feeding frenzy that will occur in the next 5 years. VR is a pivotal event in computer history that may very likely transform how people interact with their gaming devices. My concern isn't how soon and how cheap, but more that in the rush to out do each other, some companies might ruin VR by providing really cheap crap that just turns people off. I mean, the Samsung VR headset provides VR, but you don't hear anything about it. But if something like that became the norm, it could kill VR for the PC.

Be it 2 years, or 5 years, in a few years, the cost of a graphics card capable of driving VR will be cheap enough that it will be the norm (in 5 years, the $100 card will be equiv. to a GTX1080, and the $350 cards will put the GTX1080 to shame). That's not the issue. The cost of the VR headsets will be. That cost will likely drop rapidly over the next 5 years as well, to the point that in 5 years, people will probably be buying VR for the cost of Track IR (maybe $100 for the cheap version, or maybe the cheap version will be a cell phone in a VR headset, and $250+ for a high end version) and using it on their PC's that are already VR ready. VR will also likely be the norm on several major game consoles (no more TV for your xBox) which is what will drive the cost down and push the cheap version. Cheap VR is coming, faster than most people think, but not as fast we many would like. The bigger issue for flight simmers is being able to see your real world environment through the VR. People who invest in extra controls to make the flight sim easier (not having to use the mouse for everything) will be blind reaching out for stuff they can't see. Technology to place our hands in the sim exists now and for cheap. We just need the sims to adopt it natively. That helps and for many, may be good enough to drop using real simpit controls, but it will never be the same as having a real set of controls for some things. I hope a "bleed through" view capability will be added to VR to allow us to quickly see the real world without having to take the head set off momentarily. But I expect such a thing won't happen - it will be viewed as too complicated. Which means flight simmers with extensive real controls or simpits will be out of luck, having to choose between their nice simpit controls, or the wonderment of VR. Life is never perfect.

I was confused by this but now I understand what is wrong and how to make it work. Ramsay has it correct, but here is some detail as to what is going on. For the Microsoft Forcefeedback 2, in the Gazelle, you need to uncheck Swap Axis, and check Invert Y. For other sticks that normally don't need the axis swapped, you'll need to check Swap Axis, and then check or uncheck Invert X or Invert Y as needed to get things moving in the right direction. This will get trim working. But you may need to use Invert X to fix the Y movement, and Invert Y to fix the X movement. That is not normal, but it is what I found on the MS FFB 2. Unfortunately, this will not fix Magnetic Brake. The above changes will get Magnetic Brake working in the correct directions, but I think Polychop is applying both a FFB Magnetic Brake effect (hold the stick when the Brake button is pressed) while at the same time applying a non FFB axis center adjustment. The result is using Magnetic Brake causes the FFB stick to move _and_ the axis center point to move and it amplifies or doubles the joystick position as far as the Gazelle sees it. Hence Magnetic Brake on the Gazelle is non-functional at this time. If you still want Magnetic Brake functionality, you'll need to use simFFB (which implements both Trim and Magnetic Brake correctly) until Polychop can fix things. It's a WIP, so I'm just happy to see them working on it. Thanks guys! And this confusion isn't their fault. I did tests on several aircraft in DCS and realized this is a point of confusion for many developers getting the axis incorrect, or incorrectly applying a FFB force to the stick while at the same time moving the virtual stick point as if the stick is not a FFB stick. It's a serious problem in DCS and I hope everyone can get on the same page one day and make it consistent. I explain the reasons for all this below. As stated by others, the MS FFB 2 force feedback axis are reversed compared to many (most?) other FFB sticks. This is normally solved by clicking the Swap Axis check box on the FF Tune screen where you set up your control axis. This check box doesn't swap the X and Y axis controls. It swaps which axis the FFB effect is applied to. In most other sims, and also in simFFB, you must similarly swap the axis for a MS FFB 2. Normally in DCS (at least the last time I tested in detail), for the MS FFB 2, if Swap Axis is unchecked, when DCS applies a force to push the stick to the left or right, it will instead move the stick forward or back. So with a FFB 2, you must click Invert Axis. With other sticks, this is unnecessary. But in the Gazelle, you have to have it unchecked. The Gazelle developers started with a MS FFB 2 stick for their testing, so they made their software match that stick, and assumed the correct state is Swap Axis unchecked. That is incorrect. So for now, uncheck Swap Axis for an MS FFB 2, but check it for other sticks until Polychop fixes it. The second problem is the Invert X and Invert Y. These should invert the direction of force on the X and Y axis as seen by the aircraft (X and Y should refer to X and Y of the virtual stick in the aircraft, not the X and Y of the real FFB stick in your hand). These should not change because of checking or unchecking the Swap Axis. But in the Gazelle, Invert X and Invert Y are being applied to the axis from the stick's perspective. So with Swap Axis unchecked with the MS FFB 2, X and Y FFB effects are correct, but the X axis is moving in the wrong directly. You would think that you must click Invert X to fix this. But in fact, you must click Invert Y to fix the X axis. Similarly, you must click Invert X to fix the Y axis if needed. So you may have to play with these to get them right. As for the magnetic brake issue on the Gazelle, I think all that is needed there is that when the stick is a FFB stick, Magnetic brake should _only_ apply a FFB force to hold the stick. But if the stick is not a FFB stick (or FFB is disabled overall), then Magnetic Brake must move the virtual stick center to allow a person to relax their hand on a nonFFB (sprung) stick. This has also been a point of huge confusion dating back to the original Blackshark with it's trim/brake functions. I may be off on my assessment of this. I'm going mostly on what I thought I used to do in other DCS modules. I.e. click Swap Axis, and then if the X axis is moving in the wrong direction, I would click Invert X. But it seems FFB has gone back and forth from working and being broken several times in DCS, so it has gotten confused by many developers using different methods to implement FFB and the FFB Tune menus.

The new patch fixes this issue for me. The Alarm light now comes in any case where the throttle lever is not fully forward, and now gives positive feedback as to why Auto Hover or Auto Pilot functions aren't working. So this means, for those having trouble getting Auto Hover or Auto Pilot features to work, if it is due to the throttle not being pushed all the way forward, or due to a noisy pot on an analog axis which you are using to control the throttle lever, now the main Alarm light will come on when the throttle lever is not all the way forward, or flicker on/off rapidly due to a noisy pot, giving you positive feedback that something is wrong. Thanks Polychop!