Ranma13

It's not, the throttle hardware and software already support it. My suspicion is that Virpil is waiting for orders to die down before introducing a refreshed version with analog stick. It's not like they don't know about it either, we've been asking for one ever since the throttle was announced, but was told that they wanted to get this initial version out first before investigating variants.

In a real aircraft, adjusting trim will move the stick. You can see this effect in the sim if you change the trim with the keyboard and look at the stick in the cockpit. With a spring-based joystick, what you typically do is keep the joystick centered, then adjust the trim until the aircraft is flying level. In the real aircraft, what you'd do instead is move the stick to the position that keeps the aircraft flying level, then adjust the trim until you feel the centering force on the joystick disappear.

The pinky button on the Warthog stick is pretty stiff and not really suitable for trim usage. The center push of the CMS hat also feels "crunchy" and not easy to press both quickly and reliably, so I use CMS hat forward instead, which works fairly well. As an aside, on the VKB MCG Pro I use the "pinky" button. It's conveniently placed right where my ring finger is and is easy to press by just squeezing my hand together a bit, but is also stiff enough to avoid accidental activation.

Never mind about how we personally feel about Reddit, I brought it up to compare and contrast the number of sim racers vs the number of combat flight simmers. The GA market doesn't care about FFB as it's implemented in DCS and other sims that use the DirectInput FFB API. X-Plane 11 doesn't even have native support for it, and from what I gather, Prepar3D has poor support. This is why pretty much every GA FFB device has a separate plugin to handle FFB. Immersion Corporation holds a large number of patents related to haptic feedback. If one doesn't cover racing wheels, another is surely to cover it; I just happened to link the first one I found. I'm not going to hunt down every relevant patent, as that'd be just a waste of time since none of us are going to read them in detail. People have different skill levels, but I think we can agree that the attempts up to this point at DIY force feedback devices is well outside the realm of what an average person can accomplish. Just because someone can do it doesn't mean that it's "it's perfectly easy to do". Also, DirectInput doesn't have crippled haptics? As someone who's studied the DirectInput FFB API and is currently writing a FFB-related app, I have no idea what you're referring to. For force feedback, you can't use stepper motors, you need servo motors. This article has a good explanation differentiating the two: https://www.machinedesign.com/motion-control/what-s-difference-between-servo-and-stepper-motors In particular, the chart shows why stepper motors can't be used: once they're in motion, the torque significantly drops off. Stepper motors are great if you need to hold a certain position and don't care that much about precision (compared to servo motors), but are not great at generating forces. Yes, people are willing to pay $500, $1000, or even $2000, but it's not a matter of if there are customers or not, but rather the number of customers. At $500, that price point alone restricts it to only hardcore enthusiasts. At $1000, you're only looking at the top of the hardcore enthusiasts. My Slaw Device pedals at $700 has serial number 190, and my RealSimulator FSSB R3 at around the same price has serial number 51, though it's #51 of its respective batch. By comparison, my Virpil T-50 stick at $200 is serial number 1160. Though this isn't a perfect comparison since all 3 are different devices, I think it's a good way to show that as the price of a product increases, the number of customers drops off exponentially. I mentioned the Logitech G940 because it specifically states that it uses Immersion's technology. There seems to be this belief that Immersion is a patent troll company and that they're the only thing holding back FFB devices, but even doing just a modicum of research into the company shows that this doesn't hold water. Not only does the company exist for the sole purpose of licensing its patents (as opposed to using its patents to shut out competitors), but they also appear to actively pursue licensing rights. Basically, if you have an idea and are serious about licensing with them, they'll work with you. Aside from the usual ideas like haptic feedback in phones and vehicles, some of the stranger things they've licensed out are haptic feedback for an animated sticker app, haptic feedback ads, a wearable backpack that translates music into vibrations, and iFeelPixel, an app that adds haptic feedback to various devices, some no longer in production. The G940 itself was only $250, which should give you an idea of just how much the licensing fee is. In any case, this has really strayed from the original discussion and I think I've said all that really needs to be said. Enough has been communicated that people can make their own judgement about who has better points, but I will end with this: I encourage you to do your own research and challenge your own assumptions. Take a serious look into the components and skills you would need to build your own FFB device from scratch. Research Immersion Corporation, their patents, business model, and portfolio. Study the DirectInput FFB protocol, what it's capable of, how games implement it, how joysticks handle FFB commands, and the PID protocol. Examine the currently-available FFB devices, the price point they sell at and what features they have, then compare them to the discontinued FFB devices. Evaluate the possible market size for FFB devices, how well it's implemented in games, which features are must-haves and what the customer needs are, and come up with a realistic price point given the amount of work involved to bring it to market. I've done all of the above and this is the position from which I'm basing my claims on. When I say I've done extensive research, I'm not talking about a 5-minute Google search; this is months of accumulated knowledge. I could be wrong and I'm totally willing to accept that (and I'd be happy to be wrong if a company released a good but affordable FFB device), but so far I've not seen anything remotely close to convincing me otherwise.

There are many more sim racers than there are combat flight simmers. The simracing subreddit alone has almost 3 times the number of subscribers than the hoggit subreddit. You can also see it in market support; our sims are limited to IL:2, DCS, and BMS, while in the sim racing world you have your choice between Forza, Gran Turismo, rFactor 2, Project Cars, Assetto Corsa, iRacing, Automobilista, and DiRT. For primary controls, sim racers can choose between Thrustmaster, Logitech, Fanatec, Ecci, Heusinkveld, ProtoSimTech, Ricmotech, SimXperience, and the various OSW manufacturers. On our side, it's Thrustmaster, Logitech, Virpil, VKB, MFG, Slaw, and RealSimulator, though it should be noted that Virpil and VKB still have ongoing supply issues and Slaw is a special order that takes 6 months to fulfill. For sim rigs, just off the top of my head I can name Next Level Racing, Obutto, GT Omega, Wheel Stand Pro, Vesaro, and Ricmotech. On our side, the only two that I know of that are purpose-built for flight sims is Volair Sim and MonsterTech. There are also several sim racing blogs, such as Inside Sim Racing, Sim Racing Paddock, bsimracing, and The Simpit, whereas on the combat flight side, I only know of Stormbirds.blog. On the DIY side, for BFF Simulation, when you get to the point that you're designing and manufacturing circuit boards, writing custom software for it, and putting them up for commercial sale, it's way beyond easy or amateur level. Similar to Brunner and other FFB devices intended for the GA market, it only supports the big 3 (FSX, Prepar3D, X-Plane), and you only get the board and software, but not the motors, belts, mounts, or enclosure. Simprojects.nl, aside from documenting the resistor mod for the MS FFB2, is a collection of random info related to FFB rather than any kind of really useful guide. It's really just a blog, hasn't been updated in ages, and seems like it's just a lot of WIP stuff that didn't go anywhere. The open source FFB thread on this forum has been going on for years now, with almost nothing to show for it. I haven't heard of Granite Devices before, but it looks like they only sell controller boards, making it one step behind BFF Simulation since you'd need to write the software yourself to interface with the sim. Their business model also seems like it's focused on providing controller boards for industrial devices, not home simulation use. The "Open Source Control loading using an Arduino Mega" link is literally just a high-level conceptual diagram and an invitation to discuss. So I still stand by my statement that I've yet to come across anyone who didn't start with a MS FFB2, or has done it at a level that can still be considered amateur or at least reproducible with off-the-shelf components. Racing wheels are part of Immersion Corporation's patents: https://patents.google.com/patent/US8487873?oq=racing+wheel+haptic On the software side, driver support is the easiest problem to solve. The PID protocol is well-documented and is easy to implement in most microcontrollers. Other issues such as gimbal design, power distribution, motor selection, and firmware implementation are much harder problems to solve because, unlike a common protocol, they have to be individually tailored depending on the parts used. A large manufacturer could put out a product in the $500 range, but whether it'd be profitable is another matter. The Logitech G940, released in 2009, was $250 for a stick, throttle, and pedals, and this is with a patent license from Immersion, but it had some major issues that Logitech tried and failed to fix in firmware. That was 10 years ago though, and people's expectations have changed a lot since then. Plastic gimbals and potentiometers are no longer accepted in higher-end products. We need more than just one or two hats with 4-6 buttons. We want stronger motors with no cogging or dead zones so that we can use extensions, which means that gears can't be used and we need direct drive servo motors. These cost around $300 per motor for a cheap 100W model only capable of generating 0.3 Nm sustained, which is only marginally better than the MS FFB2 at 0.2 Nm. Coupled with the fairly small market of people who'd actually buy one, and exacerbated by the rather poor in-game support, means that any company who'd do it is likely doing it as a passion project and not looking to turn a profit.

The racing community is huge compared to the combat flight sim community. There are many companies making wheels, pedals, and sim rigs for racing, compared to just a handful for combat flight sims. Sim rigs in particular are almost universally built for sim racing first, with sim flight support tacked on as an afterthought. A FFB wheel is practically necessary for sim racing, whereas it's mostly just a nice to have for sim flight. Whereas every car will have first-class support for a FFB wheel, most aircraft in DCS have poor FFB support, so poor that it's barely any better than a spring-based joystick. Logitech hasn't made a joystick since 2009, and their current portfolio of flight sim gear solely consists of the products that they acquired when Mad Catz went under. Thrustmaster hasn't shown much interest in the flight sim community; in the past 7 years, they've released 3 budget offerings (T.16000M joystick, TWCS throttle, TFRP pedals) and only one high-end offering, the TPR pedals. It's arguable that the T.16000M joystick doesn't even count because it's targeted towards space sims, and not so much flight sims. A Virpil or VKB base already costs $200-300. Add in two servo motors, electronics, a power source, and special firmware, and it's easy to see why force feedback devices in the GA market are not only rare, but start at $1,000. This is a price point that would drive away all but the most fervent of enthusiasts, even in the GA market. Hence why there are only 2-3 companies out there that sell force feedback yokes. If you have any proof of amateurs easily building a working FFB yoke or stick base that doesn't cannibalize a MS FFB2, I'd love to see it. In my fairly extensive research into FFB and my attempts to build one myself, I've not come across anyone who has done it without using the MS FFB2 as a starting point, or has done it at a level that can still be considered amateur.

Not sideways movement, forward and back movement: There seems to be excessive play when moving them forwards and backwards when they're linked together, and it's more noticeable in the right lever than in the left. This is because the rod that links the two arms together has quite a bit of play in it within its own housing, which translates to play in the levers when they're linked.

I've looked into this before, but the patent is the least of the issues that's holding back FFB development:

Do you have excessive play between the two throttle arms on the Virpil throttle? As in, if you wiggle one throttle arm back and forth, do you feel a lot of play in it before the other throttle arm starts to move? I've found as well that the Warthog is a bit sticky, particularly when trying to make small movements, but I was able to fix that issue by applying some Nyogel 767A to the gimbal.

It removes all force on the stick, like the springs have magically disappeared. The stick becomes very loose with no tension on it, and you can easily make over-corrections because there's nothing to push against. It also makes it harder to tell how far you're moving the stick because the force doesn't get stronger as you move away from the last-trimmed position. I've deliberately avoided mentioning the center trimmer modes because it's a separate topic that warrants its own section. The center trimmer modes are a workaround for spring-based joysticks and are a kludge, though a necessary one. They add a layer of complexity that doesn't exist in the real aircraft, if you're using a FFB stick, or if you have a joystick without springs but has friction locks that will hold the joystick in a single position.

You should always keep the 3 autopilot channels on at all times. It has 2 functions, a stability augmentation system that smooths out the pilot's inputs, and the hold channel that tries to hold the helicopter at the last-trimmed attitude. Some people recommend turning off the channel that's giving you trouble (for example, turn off heading hold if you want to change your heading), but this is not good practice because it will also turn off the SAS for that channel. When the trimmer button is pressed down, it will do 2 things: 1. Disable the "hold this attitude" part of the auto-pilot, but keep the SAS portion engaged (in fact, SAS is always engaged as long as the autopilot channels are solidly lit and not flashing). 2. Disengage the magnetic brake on the cyclic. When the trimmer button is released, it will do 2 things: 1. Program the autopilot to hold the aircraft's current attitude. 2. Re-engage the magnetic brake on the cyclic. In real life and with a force feedback joystick, you'll want to tap the trimmer, because holding it down will disable the magnetic brake and make the cyclic go limp, which is undesirable. With a spring-based joystick, it doesn't matter because the springs will always act on the joystick. The Flight Director button only does one thing. When it's on, it will disable the "hold this attitude" part of the auto-pilot, but aside from adding some symbology to the HUD, it does nothing else. For a FFB stick, this means that it will fly as if you're holding down the trimmer, but the magnetic brake will stay engaged. For a spring-based joystick, this will have the exact same effect as holding down the trimmer, since the magnetic brake has no effect on a spring-based stick. Personally, I find it odd that people don't recommend Flight Director more, since it essentially gives direct control to the player without the auto-pilot interfering, but still keeps the SAS engaged. If you want the most "authentic" experience, you should fly with a FFB stick and repeatedly tap the trimmer. If you only have, or prefer to use a spring-based joystick, then either tapping or holding will be fine since the end result is the same. Just don't ever disable the autopilot channels.

As an update, I've been putting some time into the Stream Deck plugin and have gotten pretty far with it. Here are some screenshots of the current development progress: The main window only has a Configure button, which opens a separate window for the actual button settings. It's more complex to do it this way, but Elgato really doesn't give you a whole lot of space on the main window. In the new window, you pick a control from a list, then configure what you want the button to do when the either the control changes or the Stream Deck button is pressed. For the majority of controls, you'll only need to select one control, but there are some like the LED buttons that actually consist of two controls, one for the LED, and one for the button itself. You'll have to provide your own images, and you'll also have to provide the logic for each control instead of just selecting which control you want and have it automagically work. There's not much I can do about that; there's thousands of controls and I can't feasibly go through all of them and write the logic for everything. On the upside though, profiles can be exported and they will contain all the data needed (including images), so if someone out there writes a profile, you should be able to import it and use it automagically. That said, I might add some convenience settings to make it easier to bind to things like toggle switches, analog dials, and LED buttons, though arguably it's not exactly hard to do right now. In any case, I'm getting close to an initial release. I just need to clean up some of the logic and do an art pass on the UI, and it should be ready for a 0.0.1 release. I don't want to give any timelines because I'm doing this on my free time and lately there has been some stuff that's been eating into that, but it should be soon.

I e-mailed Brunner asking if they could provide a discount or a lease program, but I didn't get a response, so it sounds like I'll have to get one at full price.

The fixed deadzone for the spring effect is probably to prevent oscillation, where the motors will kick the stick to one side but overshoots, then the motors kick the stick back but overshoots again, and this continues on indefinitely until the motors burn themselves out from the constant and quick changes in polarity. I'd be careful lowering the deadzone and go slowly from its current stock value going down.

This Adafruit guide should get you started on how to wire a servo to an Arduino: https://learn.adafruit.com/adafruit-arduino-lesson-14-servo-motors/overview Any Arduino or AVR microcontroller like the Teensy will do. As for getting the G-force data from the sim, if you don't want to write an export lua, you can try using DCS BIOS to pull the G-force data from the cockpit gauge itself. This has the downside of the aircraft needing a G-force gauge in the first place to pull data from, and will need to be individually set for every plane (different gauges across different aircraft have different IDs in DCS BIOS). Otherwise, you can write an export lua that exposes the data somehow (most commonly through a UDP broadcast port) using LoGetAccelerationUnits(): https://wiki.hoggitworld.com/view/DCS_Export_Script This will work across all aircraft, but it returns an x, y, and z vector, which I don't know how to convert into a single G-force value. Keep in mind that some people choose to go with a "glass cockpit" (a monitor behind a wooden/plastic shield with cutouts that exposes the gauges) not only as a cost-saving measure, but also because they don't make noise. It doesn't matter so much for a single gauge, but if you have multiple running at the same time, they can get quite loud:

Here's a reality check. You're bitching about something being too expensive when you're looking at the price of an out-of-production, new in box item. It doesn't matter what the item is, if you want it new in box when it's been out of production for several years, you pay the price for that privilege. The price isn't dictated by what you originally paid for it or what you think it should be worth, it's dictated by supply and demand. You demand a copy, there's limited supply, guess what happens to the price? Also, anyone can sell anything at any price, but that doesn't mean there will be buyers. You looked at the two highest prices online and then posted an all caps, three question marks topic about how exasperated you are, and yet a quick 30-second search on eBay shows that they regularly sell new in box for $150-180, and there's an auction up right now for another NIB copy.

Is it really that hard to understand that if you want an out-of-production item that's new in box, then be prepared to pay a premium?

You can check Mouser and Digikey, which have a large selection of rotary switches: https://www.mouser.com/Electromechanical/Switches/Rotary-Switches/_/N-5g2i https://www.digikey.com/products/en/switches/rotary-switches/200 DigiKey's filters are better than Mouser's. Both usually have the same stuff in stock, though some companies are only sold on one or the other. For example, Mouser carries Otto and Alps switches, whereas DigiKey does not, so it's worth looking through both sites.

Wow, I didn't know someone else was working on a Stream Deck plugin for DCS BIOS. I'm the person who mentioned that the Stream Deck SDK isn't that great. I'm also developing my own version here: https://github.com/danieltian/dcs-bios-stream-deck-plugin The plugin is still in its early stages and I'm still working on getting the app infrastructure set up, so it'll be a while before it'll be ready for an initial release. Here are some screenshots of what it currently looks like: I'm using the popup window that Elgato lets you open, but it's not resizable. It was designed only for login authentication pages, but it's still better than the ~175px that they give you in the property inspector. My plugin will support bi-directional communication so that the Stream Deck can change the image displayed based on the state of the sim, as well as display an optional title overlaid on top of the image. But yeah, the API is a pain to work with and under-documented.

Based on this post by kingpinda, Brunner only plans to implement force changing with airspeed for now. I believe I can do much better. Centering is really the must-have FFB effect, especially for helicopters. I'm planning to implement damper and friction, and using SimShaker's lua export as inspiration, I want to also add in things like gun shake, ground rolling bumps, stick shaking near stall speeds, gear transition vibrations, etc.

A small update, I've made some progress on the FFB app and made it look nicer: Note that the app currently only shows the FFB effects, but does not send them over to the CLS-E, so don't get too excited just yet. I'm still drumming up the funds to purchase a CLS-E base, which will give me access to the CLS2Sim software. Here's a video of the app with the Ka-50. Note that "center position" means the centering position of the FFB motors, not the stick position: And here's a video of it with the Su-25T. I start by adjusting the trim, then perform some maneuvers to get the periodic effect to start playing. I pop off the cockpit to show the period getting longer, which changes the movements from fast and sharp to a more rhythmic movement: I've also discovered some interesting things. vJoy's implementation of FFB reporting is incomplete and doesn't cover several effect types. For example, vJoy won't send any FFB reports when the FFB axes is swapped in DCS, and likewise when changing the damper and friction settings in ForceTest and SimFFB. Also, swapping the FFB axes in DCS won't actually do anything to the FFB message in vJoy, and some aircraft will report their FFB axes the "right" way and others the swapped way. It seems like there's an intermediate layer that handles reversing/un-reversing the FFB axes that vJoy doesn't handle. Luckily, the axis swapping issue can be fixed by adding a manual checkbox for it, and it seems like neither DCS nor IL:2 BoX uses damper and friction, so we're good on that front. I'll add in manual settings for those 2 effects though since CLS2Sim supports them. It does feel like I'm stepping around a minefield; I haven't triggered any so far, and hopefully it stays that way, but I've had to add multiple workarounds for various issues, mostly stemming from vJoy. For now I'll have to pause work on this app until I get a CLS-E base. Although I can continue working on integrating DCS' telemetry data with my app, I feel that I should really get the centering and periodic effect nailed down first before working on anything else, since those 2 effects are the foundation of the app. Stay tuned for future updates.

As a small update, I started working on the Stream Deck plugin, but it's a real pain. I gave it a college try once before when the SDK was first released, but it was obvious that it was an early first release and wasn't ready for prime time. That situation hasn't really changed much. The SDK documentation falls into the typical trap of being a good reference only if you know what you're doing and only need to look up very specific pieces of info, but otherwise is very bad in explaining how to get set up and running. It also relies way too heavily on example projects to explain its various functions, so you end up having to download all those example projects and understanding how they work before the documentation starts to makes sense. The example projects are also written by different people with different coding styles, so there's no uniformity in their design or an official "this is the way you should do it" sample. On the debugging side, it's a major pain and it's what's roadblocking me right now. The API will ignore all requests that it doesn't understand or is missing required data, without any error messages. This makes it incredibly difficult to figure out what you're doing wrong, especially when the documentation is so sparse. The debugger they provide is also really crappy. You can debug the settings panel for each button (they call it the Property Inspector), but whenever you click away from a button and back onto it, it creates a new instance of the Property Inspector and you have to reload the debugger, because the debugger is tied to the Property Inspector instance. This means that if you accidentally click on another button (or in the gray space between the buttons) or need to reload the settings panel, you also need to reload the debugger as well. I think I've spent more time reloading the debugger than I have actually coding. I'll keep hacking away at it, but unless I get some kind of breakthrough, progress will be slow.

Humble brag aside, changing your process affinity to real-time will only have minimal impact: https://superuser.com/a/752864 Ikarus has very low system usage because all it's doing is reading the exported UDP messages, then updating its UI. The MFDs are rendered as part of the main game's render area, and should be updating at the same rate as the main game. There shouldn't be "nearly no delay", there should be no delay at all. There are good reasons for wanting to export the viewports to something that's not tied to the main render area. If your main display is a G-Sync display with a high refresh rate but your secondary monitors are only standard 60 Hz monitors, it will lock your G-Sync monitor to 60 Hz. Perhaps you want to display a MFD on only part of a secondary monitor while leaving the rest uncovered so that you can, for example, look at Discord chat in-game. Maybe you want to be able to use a tablet to export the MFDs onto, of which the current "solutions" are essentially just screen sharing apps with a skin. Some people may want to export the data to a computer running a non-Windows OS for esoteric purposes, such as exporting the Ka-50 Shkval to a Linux box, applying some filters to it, and displaying it on a CRT monitor. The current "just make the render size larger and draw the MFDs at a certain position on it" is not really a good solution and really limits what can be done with it. You're perhaps unaware, but at one time DCS either had, or planned to support exporting render targets to shared memory, which is exactly what we need. This comment can be found in Scripts\Export.lua:

He already gave you permission: Send the file to me, I'll host it on my Google Drive.

Let's not do the whole "PM me for the file" thing. I can't begin to tell you how many times I've come across that, but the person hasn't been active on the forum for years, or they've long since deleted the file, etc. Just put it up on Google Drive/OneDrive/DropBox/any other file hosting service so any of us can download it whenever we want, even several years from now.