Ainuke

OK, thanks. At least I'm not alone, I guess? I'll monitor that thread to see if anyone has opinions there as well. Doesn't sound like the type of thing that the devs would get hot and bothered about, though. Talk about a niche within a niche within a niche...

Just updated to 2.5.6.49798 on Windows 10.0.19041 I just acquired this joystick to explore a more robust FF flight stick. It gets recognized by Windows and is visible in the GamePad utility and appears to work OK. I plugged it in to see if it was supported in DCS, but DCS wouldn't progress past the splash screen. Tried several iterations of repairing the install, which generated no errors, either on the fast or slow iterations. Anyway... I unplugged the joystick and DCS fired right up, no issues. Verified again that plugging in would recreate crash: check. Is this a known issue with this joystick? Thanks in advance, Erik dcs.20210123-221209.crash dcs.log

please take my money...

Perfect, thanks! I didn't expect to get an answer, much less such a complete one, and so quickly. -Erik

Oh, I think I see... J2 and J3 are the remaining toe axes, and J1 is the absent rudder? _Erik

Wow, thanks!! Is that the only card in the box? Nothing for USB interface? The connections look like they're going to be VERY helpful. _Erik

39:30

Thanks for the response, Home Fries. That's about what I gathered. I wonder how informative it would be to take some resistance readings from the pinouts. If it's a straight line to the pots, the meter would show it. I didn't find any specific documentation online, so I wondered if any of the control builders in the audience had any experience with these... Thanks! -Erik

Hello All, Does anyone out there have the TFRP rudder pedals, or knows what kind of output the RJ-12 jack puts out? I have the T.16000M FCS HOTAS on its way from eBay. I want to hack the throttle quadrant to make a dedicated heli collective (replacing the grip with tubular aluminum and replacing the buttons with better, etc.). There's an RJ-12 input where the rudder pedals can interface, and TM says that it'll incorporate the 3 axes from the pedals into the throttle. What I'd like to do is substitute 3 pots to use for trim wheels when I'm flying fixed wing aircraft, but don't know (short of buying and hacking) whether the RJ-12 signal is just a straight reading from the rudder axes or if it's run through the board on the pedals and communicated via serial or some such? I know that there's a separate USB output from the pedals, so maybe what comes across the RJ-12 line is linked in with that some way. I could use a Bodnar board, I realize, for the trim controls, and more buttons to boot, but the FCS throttle has plenty of buttons to choose from, and keeping everything compatible with TARGET would increase cross-sim utility. (I don't usually use TARGET for sims, but it did allow me to use the Warthog HOTAS for Ghost Recon: Wildlands heli flight somewhat successfully). Tell me, O Wise Ones, does anyone have the answers I seek? Thanks in advance -Erik

Ok, here's a different perspective that resolves many of the issues that have been discussed here, and addresses limitations in the motor/gear design, namely gear ratio, cogging, sensitivity, motor inertia/speed/torque, etc. I propose a different route, that builds on the existing roller/cam design of current high-end joystick gimbals. The roller/cam design approximates increased stick pressure (centering) as deflection from 0 increases. The problem with this is it's static. You have to choose one cam profile that is the best compromise for all aircraft. BUT, if you could dynamically reshape that cam profile in real time, based on feedback from the FFB protocol, you would not only be able to adjust the feel based on airspeed/stall, but you could have different profiles for different types of aircraft (little-to-no cyclic centering for rotary aircraft, for instance). If you were to break that cam yoke into two halves, you could alter their slopes to be steeper with higher airspeed, to flat for a stall. There could either be separate motors for each half (if differential forces were needed for each direction), or a single motor that operated both in a scissor-type motion. The advantage to this is that small, cheap, low-torque motors could be employed (brushed, brushless, stepper, servo, whatever), because altering the slope of the cam can be done with a worm drive mechanism. The rolling action of the gimbal is no longer limited by steps, play in the gears, backlash, or any of the other concerns inherent to directly acting on the axis. This design also scales well to accommodate longer/shorter stick lengths, as the only difference need be the shape of the cam, not the strength of the motors. The downside is that the available effects are those related to airspeed and forces on the control surfaces. I would argue, however, that this provides a more accurate simulation. Why would you wish to introduce effects from cannon fire, landing bumps, etc. into your control axis, anyway (especially since hall sensors will pick up such events as control inputs)? Doing so makes sense in driving simulations, since the wheel has a more direct and stronger contact with the driving surface. In Aircraft simulations, however, such effects (vibrations and shocks to the airframe) are probably better executed through a tactile transducer mounted to the enclosure, and directed there via software. Keep the stick forces related to the control surfaces (turbulence forces can probably be accurately transferred to the stick via "warbling" the cam profile). I realize this represents a big departure from the current designs being talked about, but I think the benefits, in terms of complexity, cost, and fidelity make it worthy of consideration. I haven't had time to mock-up anything in SketchUp as yet to give a visual of what my idea is (my 3D modelling skills are very amateurish), but I'll try to put something together. -Erik

Not to distract you, but did you see this cyclic build (https://forums.eagle.ru/showthread.php?t=188055)? It handles force trim mechanically, much the same way as the Huey. -Erik

If I may... The difference between the rift display and 4K is a factor of 4, so for every one rift pixel, the 4K monitor displays 4. It can’t go the other way, though; the rift can’t display 1/4 of a pixel. But the game is calling for a pixel in that frame at that spot to represent the new object (missile), so a pixel is generated. A whole pixel, since a portion of one can’t be generated.

I have to disagree with this, based on my observations. With AA off, regardless of PD setting, I get horrendous “shimmering” along any straight edges (buildings, power lines, etc. It doesn’t even seem to matter if I go all the way up to PD 2.5, it’s still there, and it completely breaks immersion. It happens at some distance as well; looking at Vegas, for instance, from the Helipad at Nellis, it almost looks like the landscape between is crawling with ants. At 2xAA, it’s greatly reduced, and at 4xAA, it’s gone entirely. The cost (aside from the added graphics card workload), is less distinct text on gauges, etc. which increasing the PD corrects, in addition to providing more depth to things like the gauge bezels and the gunsight glass on the P-51. So I would argue that each setting addresses the weaknesses of the other, and using moderate amounts of both yields better graphical fidelity. -Erik

Ahem... My man! Thank you for confirming my thoughts about the CPU bottlenecking me. Using EVGA Precision I haven't been getting full capacity out of my video card with either DCS 1.5 or 2.0. Neither was the bus saturated. But Precision wasn't measuring my CPU, so I only suspected that it was the weak link. So you're telling me I should be running maxed visual settings if I can clock the CPU to 4.7? At what pixel density? The readability and presence of the guages goes up dramatically on CV1 with increase of pixel density; which is a plus for me... Sorry to hijack the thread. Would appreciate a PM if the answers get cumbersome for the mods... -Erik

Wow, very exciting build! I’m glad my meandering brought me here. My own plans are for a force feedback stick (for fixed wing and rotary), but this has given me some food for thought. Molevitch, I’m curious about your experience with overclocking your 6700 and it’s impact on framerate with CV1, but since it’s OT, I’ll PM you, if that’s Ok?