Alex_rcpilot Posted May 10, 2010 Posted May 10, 2010 (edited) Hi guys, have you noticed that rotaries only work well with the mouse wheel? Well let's say probably most people haven't tested them with keyboard or joystick buttons, but here's a chance to try it. And you'll find out that they not only respond to keystrokes, but are also overwhelmingly sensitive to the duration of the input. That means as long as you hold the key/button down, the rotary keeps turning. It's quite difficult to control how many detents it turns with each keystroke you make. At first I thought it might have something to do with axis, that ED might have had considerations on rotary usage with joystick potentiometers. But as I tried assigning an axis to a rotary, I failed. It makes sense that you can't turn a rotary with an axis because rotaries are normally meant for infinite rotation, while axises aren't. This is exactly what's puzzling me: A. Why are they built to be sensitive to the duration of corresponding inputs? I tried using precise electronics to generate stable repeating keystrokes with adjustable duration, but the rotaries either misses a couple of inputs, or turns too much. It's quite difficult for me to find a perfect duration for the button to be held down. I'd like to consider this a bug in my test rig. B. On the contrary, why is the mouse wheel so reliable? Is it because DirectInput sees mouse wheel input as an undividable directional "notch" event, rather than a "button down" event followed by a "button up" event which happens to buttons? I think it'd be much better if a rotary responds to a "button down" event by turning exactly one notch in the pre-defined direction. Then it ignores the following "button up" event, and stays there till next "button down" event. I hate to bring additional workload for the ED crew who are already working around the clock, but I'd appreciate any response from you guys. Perhaps you may consider my suggestions with the next DCS update. Thanks! :thumbup: Alex Young Edited May 11, 2010 by Alex_rcpilot
PanelBuilder Posted May 21, 2010 Posted May 21, 2010 Hey Alex, I feel your pain :-) It's difficult even to figure out how many keystrokse one of these knobs needs, for one rotation. It would be very frustrating trying to use a keystroke encoder for these. It's nice that we don't have to. On the question of infinite rotation or not, some are and some aren't. One example: Abris cursor is, Abris brightnesss is not. Normally, the "infinite" ones want an incremental encoder and the "finite" want a pot. Right now I'm experimenting with an incremental encoder, a Gray code encoder, and a pot. Main thing with the pot is to throttle down the number of messages that get sent, stop to stop. I'm finding about 40 is enough so you get a message if you just nudge the knob. ymmv. Cheers, Colin
CAT_101st Posted May 22, 2010 Posted May 22, 2010 You might try using roterys that have a longer throw betwean detents. 45* or so. That may help. Roterys with the small detents were realy ment as volum control and don't realy matter if you miss a few detents when rapidly spinning the dile. Home built PC Win 10 Pro 64bit, MB ASUS Z170 WS, 6700K, EVGA 1080Ti Hybrid, 32GB DDR4 3200, Thermaltake 120x360 RAD, Custom built A-10C sim pit, TM WARTHOG HOTAS, Cougar MFD's, 3D printed UFC and Saitek rudders. HTC VIVE VR. https://digitalcombatmercenaries.enjin.com/
Alex_rcpilot Posted May 24, 2010 Author Posted May 24, 2010 Hey Alex, I feel your pain :-) It's difficult even to figure out how many keystrokse one of these knobs needs, for one rotation. It would be very frustrating trying to use a keystroke encoder for these. It's nice that we don't have to. On the question of infinite rotation or not, some are and some aren't. One example: Abris cursor is, Abris brightnesss is not. Normally, the "infinite" ones want an incremental encoder and the "finite" want a pot. Right now I'm experimenting with an incremental encoder, a Gray code encoder, and a pot. Main thing with the pot is to throttle down the number of messages that get sent, stop to stop. I'm finding about 40 is enough so you get a message if you just nudge the knob. ymmv. Cheers, Colin Thanks for the reply, PanelBuilder. May I ask what type of message did you send to DCS? :music_whistling: I'm still immitating two standard joystick buttons with each incremental encoder. So my "message" is simply a standard joystick report handled by DirectX. As you said "it's nice that we don't have to", I presume you've found a workaround for this problem? As you've pointed out, knobs like ABRIS brightness adjustment are finite, I thought about it for a while, but still couldn't figure how finite knobs could take advantage of this timing-sensitive input style. Although there might be various workarounds, I still think it'd be better to optimize this slight detail in future releases if there's no obvious advantage with keeping it this way.
Alex_rcpilot Posted May 24, 2010 Author Posted May 24, 2010 You might try using roterys that have a longer throw betwean detents. 45* or so. That may help. Roterys with the small detents were realy ment as volum control and don't realy matter if you miss a few detents when rapidly spinning the dile. Sure, Cat. I can try that. But what it does is no different from changing parameters in my firmware. I've already tested my 'denser' rotaries notch by notch with an oscilloscope, not being able to spot any lack of positional response. The point is the design concept of these rotaries aren't compatible with keystroke inputs. I searched for articles talking about mice, and it turned out that the mouse wheels generate a "scroll n lines" message which doesn't contain any timing information. This's is unlike the button down - button up process reflected with buttons or keys. And that's why those rotaries work so well with mice.
PanelBuilder Posted May 27, 2010 Posted May 27, 2010 Thanks for the reply, PanelBuilder. May I ask what type of message did you send to DCS? :music_whistling: Hi, The messages are text messages sent to lua socket in the usual way. I've got an interface board that does this. Whenever the value on the pot pin changes, it sends a message. So at 8 bits, 255 messages can get sent stop to stop, which I find is way too many. I can cut the number of messages in two ways: first is to reduce the resolution to say 7 or 6 or 5 bits. Second is to set a number by which the value has to change before a message is sent, like 2, 3, or 4 etc. With the second method, the range stays the same. Cheers, Colin
Alex_rcpilot Posted May 27, 2010 Author Posted May 27, 2010 Hi, The messages are text messages sent to lua socket in the usual way. I've got an interface board that does this. Whenever the value on the pot pin changes, it sends a message. So at 8 bits, 255 messages can get sent stop to stop, which I find is way too many. I can cut the number of messages in two ways: first is to reduce the resolution to say 7 or 6 or 5 bits. Second is to set a number by which the value has to change before a message is sent, like 2, 3, or 4 etc. With the second method, the range stays the same. Cheers, Colin Thanks for the info:thumbup:. Now before ED (doubtfully) optimizes this rotary function, the only way to handle it properly with a physical component is through LUA socket. I'm not sure if your interface board has its own ethernet driver, if it does, things are certainly straight forward; otherwise, you've presumably built a socket server/client software on the PC to bridge other types of communication to the LUA socket? Here's an interesting question: is it preferable to build the cockpit with ethernet port only or USB port only, or both? If someone with a computer whose motherboard carries only one RJ-45 connector runs into an ethernet-based cockpit, how does he manage to connect to the internet as well as the cockpit with the same port? Is a router gonna help? And if this pit was built with a high speed USB port instead, which relies on some sort of bridging software on the PC, will this software reduce PC performance by too much?
obotNapalm Posted May 27, 2010 Posted May 27, 2010 (edited) ... If someone with a computer whose motherboard carries only one RJ-45 connector runs into an ethernet-based cockpit, how does he manage to connect to the internet as well as the cockpit with the same port? Is a router gonna help?... A lot of broadband routers have an ethernet switch built in (the one provided by my broadband supplier has a 4 port from memory as well as the wireless function). Otherwise you can buy a cheap switch, or a 2nd PCI/PCI-e ethernet card should do the trick. Edited May 27, 2010 by obotNapalm
Alex_rcpilot Posted May 27, 2010 Author Posted May 27, 2010 A lot of broadband routers have an ethernet switch built in (the one provided by my broadband supplier has a 4 port from memory as well as the wireless function). Otherwise you can buy a cheap switch, or a 2nd PCI/PCI-e ethernet card should do the trick. Hi Napalm, thanks for the tips. I'm not quite sure what this switch looks like in the setup page, but maybe many people can work it out with their own routers. That question was kind of generic because I thought it might be the case for the majority of pit users. Personally, I'm lucky enough not to have go through so much trouble because my motherboard actually carries two gigabit ethernet ports. But I'll try n' mess with the router later anyway, just for fun...lol
y2kiah Posted May 27, 2010 Posted May 27, 2010 Hi Napalm, thanks for the tips. I'm not quite sure what this switch looks like in the setup page, but maybe many people can work it out with their own routers. Hi Alex, he means this kind of switch You simply need to add your pit components to your home network, no need for more than one ethernet port on your computer. Since you have two ports on your PC, your pit network could be completely separate, and your Windows machine could belong to both networks simultaneously.
Total Posted May 27, 2010 Posted May 27, 2010 There are two types of rotary switches out there. "Make before break" and "break before make" Make before break has become the most common. For the rotary switche sin your pit simulators, you are going to want a break before make rotary. Simply put, it breaks the connection before making another. In a make before break, it keeps the connection between the poles as you rotate it. When searching, you will want to find a "Non-shorting" rotary switch. Your other option is to use an encoder.
Alex_rcpilot Posted May 27, 2010 Author Posted May 27, 2010 Hi Alex, he means this kind of switch You simply need to add your pit components to your home network, no need for more than one ethernet port on your computer. Since you have two ports on your PC, your pit network could be completely separate, and your Windows machine could belong to both networks simultaneously. Oh thank you y2kiah for the reference material. Now I get the point. That's a pretty handy device, though I don't really need one for obvious reasons. lol.:)
Alex_rcpilot Posted May 27, 2010 Author Posted May 27, 2010 (edited) There are two types of rotary switches out there. "Make before break" and "break before make" Make before break has become the most common. For the rotary switche sin your pit simulators, you are going to want a break before make rotary. Simply put, it breaks the connection before making another. In a make before break, it keeps the connection between the poles as you rotate it. When searching, you will want to find a "Non-shorting" rotary switch. Your other option is to use an encoder. Hi Total, thanks for the tips, that's something I hadn't noticed before, I will keep an eye on them later. However, I don't think the type of physical component has any contribution to the problem under discussion here. Because: A. It's a timing sensitivity issue in the software which is made worse by the fact that Windows is not an RTOS (Real-Time OS); B. My hardware & firmware is custom-made which accepts inputs from literally any type of component, or no component at all (software signal generator). It generates a standard DirectX button input which is directly recognizable by DCS software despite the component being used. And no matter how precisely this input is generated, DCS fails to percieve it 100% properly, presumably due to the none-real-time nature of the OS. Accurate timing can't be achieved easily on systems like Windows, a virtual object like rotaries works better with an event-based response logic, rather than a time-span based one. Edited May 27, 2010 by Alex_rcpilot
Nasty Posted May 27, 2010 Posted May 27, 2010 when i make cockpit i put playmachine and cockpit machine 1gb lan card and crossover cable so i dont get extra trafic in my router , so thats way i m sure i get good pings when i play online.trust me if you read everyframe cockpit data home router possible go slooooow motion mode cos there is too much traffic
Alex_rcpilot Posted May 27, 2010 Author Posted May 27, 2010 when i make cockpit i put playmachine and cockpit machine 1gb lan card and crossover cable so i dont get extra trafic in my router , so thats way i m sure i get good pings when i play online.trust me if you read everyframe cockpit data home router possible go slooooow motion mode cos there is too much traffic That sounds like a good reason for me to feel lucky about my dual-gigabit motherboard. lol
PanelBuilder Posted May 30, 2010 Posted May 30, 2010 There are two types of rotary switches out there. "Make before break" and "break before make" . Hi, I don't think Alex is actually talking about the rotary switches in the cockpit; by rotaries I think he means the pots and encoders. Cheers, Colin
Alex_rcpilot Posted November 1, 2010 Author Posted November 1, 2010 Guys, now that Warthog Beta versions are available, has it inherited this issue? I have yet to wait for a couple of weeks before I get the money for pre-purchase. I'd like to bring this problem to ED's attention because it's going to dramatically affect the way peripherals are built and their performance. Hope someone will look into this matter if it's not too much trouble. Thanks!
y2kiah Posted November 1, 2010 Posted November 1, 2010 (edited) I haven't been able to test anything because Export.lua does not seem to be working yet in Beta 1. I've enabled it in Config.lua but that still did not get it working. I haven't read about anyone else getting it to work yet either... hopefully in Beta 2. edit: my bad, you're probably talking about mousewheel vs. keyboard for rotaries within the sim? Edited November 1, 2010 by y2kiah
Alex_rcpilot Posted November 1, 2010 Author Posted November 1, 2010 I haven't been able to test anything because Export.lua does not seem to be working yet in Beta 1. I've enabled it in Config.lua but that still did not get it working. I haven't read about anyone else getting it to work yet either... hopefully in Beta 2. edit: my bad, you're probably talking about mousewheel vs. keyboard for rotaries within the sim? lol, yup, but no problem. Have you tested any of those rotaries with the default config on your keyboard? :)
Feed Posted November 1, 2010 Posted November 1, 2010 Has this keystroke issue been reported in the DCS beta forums? It's something I'm sure they'd address, because not everyone is going to be using their mouse wheel to control cockpit dials. The only other option would be lua scripting, and AFAIK, lua is disabled while in multiplayer.
Alex_rcpilot Posted November 2, 2010 Author Posted November 2, 2010 Has this keystroke issue been reported in the DCS beta forums? It's something I'm sure they'd address, because not everyone is going to be using their mouse wheel to control cockpit dials. The only other option would be lua scripting, and AFAIK, lua is disabled while in multiplayer. In order to report this issue I have yet to confirm it because I don't have access to the beta release for now. If someone with the software may spare some time and do a few tests, please either post your results here, or directly report this issue to ED. You might wanna also put up the link to this thread to save a lot of elaboration.:)
Alex_rcpilot Posted November 8, 2010 Author Posted November 8, 2010 Has this problem been confirmed positive with A-10C? Anyone?
Alex_rcpilot Posted December 9, 2010 Author Posted December 9, 2010 Seems like nobody is willing to test it. I think I gotta purchase a beta version and confirm this issue. And then report it as a bug to ED. Damn I like the DVD version instead.....
Recommended Posts