FSM-GA knob response times

[tiberius]

I also tried to configure them as Encoders with 4/4 pulses in Physical buttons page, but that would make them not emitting Logical button pushes.

From the timing logged it looks like as the encoder signal is buffered by FSM-GA ... ?

[moewillie]

I've got my FSM HDG knob bound to Increase Heading Bug and it responds instantly 1 degree for each click of the knob. Also FSM ALT SEL knob is bound to Increase Autopilot Reference Altitude and it responds instantly 100 ft */- for each click. Very satisfied with this performance. See my setup in attachments.

[Aplato]

I get instant responses for small rotations (1-2 clicks), but if I twist the knob a lot it very quickly falls behind. Is this not the case for you?

[Aplato]

Was pointing to a possible resolve for a question of yours

Do you have any additional ideas? Nothing I've tried with any encoder settings has resulted in any meaningful improvement and to have this much delay makes this pretty much unusable for any turns more than 20 degrees or so. Here is another video using a different VKB testing application (VKB_JoyTester.exe) to demonstrate the slow response time.

https://youtu.be/P-2bLa_qS9k

[Capecop1]

I have this issue as well, exactly as described by the op. I use the encoder on the fsm in elite dangerous for FSS signal tuning. For those unaware, tuning the FSS requires progressing from very low frequency signals up to very high frequency signals while searching a star system for stellar bodies. Using the encoders on the fsm to rapidly change frequencies will result in me stopping spinning the encoders and the frequency will continue to change (as if I were still spinning the encoder). Length of time for registering additional button presses after I have stopped spinning the dial seems to be directly related to how fast I spun it. Faster spin usually means more "ghost" presses. I've seen upwards of 5 seconds of continued input after I stopped turning the dial in particularly bad cases.

[Aplato]

Thanks for posting this! I'm glad to hear I'm not totally crazy on this one. Hopefully there's a software solution to this.

[tiberius]

flash the latest firmware, configure the buttons as virtual encoder by following:

• in Profile -> Buttons, find the two buttons corresponding with the encoder
• click the lower-numbered one, configure it as Encoder, Virt, type Discrete
• in Global -> Common, reduce T_Enc but no lower than about 15 (need experimentation)

don't forget to Set into the controller.

This will reduce the interval between encoder outputs but now you probably will find that encoder pulse count are not enough ...

I wanted to use the encoders to control MSFS heading, altitude and vertical speed (as marked on FSM) but still haven't come up with a satisfactory config. MSFS just don't like the encoder input and the value is always changing too slow. I've already given up and configure them to joystick hat pushes, which MSFS treats push and hold as quick change that is easy to operate.

[Aplato]

Thanks -- this actually helped a little bit. I've been using X-Plane lately with the same issues, but setting this along with a virtual encoder with a T_Enc value of 35 seems to give the best results. It still takes way too long to make heading adjustments, but it at least reduces the amount of time that the values continue to change after I stop twisting the knob. Sadly with lower values, a lot of the movements aren't picked up in X-Plane. It's too bad because with a value of 20 it looks pretty good in VKB Button Tester. I'm still hoping there's a better solution though.

[rtrski]

I have this issue as well, exactly as described by the op. I use the encoder on the fsm in elite dangerous for FSS signal tuning. For those unaware, tuning the FSS requires progressing from very low frequency signals up to very high frequency signals while searching a star system for stellar bodies. Using the encoders on the fsm to rapidly change frequencies will result in me stopping spinning the encoders and the frequency will continue to change (as if I were still spinning the encoder). Length of time for registering additional button presses after I have stopped spinning the dial seems to be directly related to how fast I spun it. Faster spin usually means more "ghost" presses. I've seen upwards of 5 seconds of continued input after I stopped turning the dial in particularly bad cases.

I'm not associated with VKB aside from as a customer, and I don't have the FSM, but have also tried a homemade differential clicky encoder for Elite FSS and it just doesn't work satisfyingly. I don't think a standard differential encoder's function is good for an analog axis; I went back to using one of the axes on a thumbstick (Kosomosima Premium LH) instead. As you noted its really only registering 'presses' as you turn it. An analog axis can be 'jumped' to a position, while a stepper has to....step...its way there.

Even this giant chunky beast has a limit:
(I confess, when I built this it was totally in the intent of using that big dial for FSS!! But I had to abandon that idea, it just doesn't work as well as a thumbstick.)

There's two types of encoders, absolute and differential. One only 'know' it turned clockwise or counterclockwise by a click, and subsequent clicks if done fast enough to exceed the polling rate of the two signals that tell whether it stepped clockwise or counterclockwise can confuse it. Depending on whether its a half step or quarter step (how many channels it actually has that it's comparing) it might handle a faster rate, but there's ALWAYS a max rate these can be physically turned and digitally keep up.

The absolute encoder knows where it is from zero, (it outputs a multi-bit value that tells its location, bit count related to how many increments around the axis it can resolve) but even then might manage to output a couple intermediary positions. But those are much more expensive components; the sale page for the FSM only says "rotary encoder" that I can see, if it was an absolute I suspect they'd have said so, and I suspect we'd see a zero mark on both the knob and on the housing. Using a differential as an absolute can be done in software but assumes ability to count exactly how many steps have been made, which means you can't exceed the sampling rate. (A buffer might try to cache steps if some other output reporting process e.g. looping thru all the buttons goes a bit slower.)

Basically what you're seeing is the same thing as a stepper motor in a 3d printer 'losing' a step. It zeros, then every position thereafter is a number of X,Y,Z increments from there for the whole printing path, and if the motor gets blocked or insufficient current driving it so a step here or there isn't made you get layer shifts. The continuous output after turning might mean there's a software buffer in the microcontroller driver that's trying to preserve all the steps it saw, but even that logic gets confused if the steps exceeded the polling rate in coming in.

I suspect you're asking too much of this part perhaps (you and the OP both) expecting it to have unlimited actuation speed range, and keep up always (even aside from adding an extra software layer). Links below no direct association to the encoders used by FSM to my knowledge, just good general tutorial info on how encoders work and are specced for function.

http://cdn.automationdirect.com/static/ ... derfaq.pdf
https://www.quantumdev.com/calculating- ... -encoders/

Curious how far off base I am though; I'm definitely a dweeb at this stuff myself, at best.

[rtrski]

I don't have any experience with the software you're using, but I got lots on VKB's native software and technical issues and I can tell you this is the first time when I encounter a delayed action coming from a VKB device. Not saying it's not there, but there are too many layers of software covering your hardware and too many variables we can't control - third party controller software build for a different brand, unofficial plane module.
If you'll find the same sort of control on an official plane, try binding the device without any thirds and you'd still get delays please let us know.

Emphasis added above.

To be fair, the "TEMPO" is a good simple example of intentionally creating a reporting delay in the device. TEMPO lets a long press (of a specified time length or greater, say 300msec) be interpreted differently than a short press on the same button. When you quickly press-and-release, faster than the specification, the software sends the PC the logical button or function associated with it "immediately" (I scare quote that because there's got to be a max clock speed of the black box microprocessor, so it is not truly instantaneous) upon RELEASE. Because until you released it, it didn't know that "the button was not pressed longer than the specified long press interval". Without the TEMPO function a short press can be registered in the very first step that the voltage indicating the switch is closed is noticed, instead.

Then the long press signal is sent (as a very momentary logical press-then-release) in the first time step past the specified long press interval that the button is still held. And then nothing else can be sent until the long press is physically released to reset the functionality.

But the "response" time of the short AND long press are slower than if it was just a single simple physical button = logical button function.

[Aplato]

I suspect you're asking too much of this part perhaps (you and the OP both) expecting it to have unlimited actuation speed range, and keep up always (even aside from adding an extra software layer)

Thank you for the detailed and thoughtful response. It's entirely possible that you're correct and this is simply an unavoidable limitation, but with the way the HDG knob in particular is behaving I find it difficult to believe that anybody could be satisfied using it to control an aircraft's heading or that it would pass through any QA process. It would be helpful to know if everyone else has a similar experience with it or if my device is behaving differently, but I doubt that anyone trying to make a 90-degree turn for example is happy with twisting the knob a bunch of times and then waiting several seconds to see where it lands and then adjust again to compensate.

[rtrski]

Absolutely, understanding the limit helps you decide on the use! I hope I didn't come across as dismissive, definitely not my intent. I think an Encoder is expected to be rotated "thoughfully" through clicks, making a setting, perhaps even then confirming with a press or something, vs. "point it to a heading as fast as humanly possible". To me the latter sounds more like an absolute encoder, or a dial that is geared smoothly to an analog axis somehow.

Hopefully someone far more official than I will reply (Fallout counts as affiliated by as a distributor/superb support helper I think, but he's not doing the firmware or hardware design himself to my understanding.) And even if the 'intent' doesn't match what you're doing 100%, and there is a polling rate limitation, that doesn't rule out that a firmware fix might yet improve currently observed behavior, some.

(FYI and totally off topic, we have a counter top toaster oven that uses an encoder to 'roll' between the cooking "mode" selections, then separate dials for time and temp adjustments if appropriate...you know: Toast, Bagel (both variations on 'both top and bottom burners'), Air Fry (bottom plus convection fan plus inline air heater), Roast (bottom only), Broil (top only) etc. etc. If I roll that encoder too fast either way it only registers occasional clicks 'clockwise', but slower it registers my correct direction and picks up every click. Drives me NUTS. I'm in a hurry for toast, dammit! )

[Capecop1]

I have this issue as well, exactly as described by the op. I use the encoder on the fsm in elite dangerous for FSS signal tuning. For those unaware, tuning the FSS requires progressing from very low frequency signals up to very high frequency signals while searching a star system for stellar bodies. Using the encoders on the fsm to rapidly change frequencies will result in me stopping spinning the encoders and the frequency will continue to change (as if I were still spinning the encoder). Length of time for registering additional button presses after I have stopped spinning the dial seems to be directly related to how fast I spun it. Faster spin usually means more "ghost" presses. I've seen upwards of 5 seconds of continued input after I stopped turning the dial in particularly bad cases.

I'm not associated with VKB aside from as a customer, and I don't have the FSM, but have also tried a homemade differential clicky encoder for Elite FSS and it just doesn't work satisfyingly. I don't think a standard differential encoder's function is good for an analog axis; I went back to using one of the axes on a thumbstick (Kosomosima Premium LH) instead. As you noted its really only registering 'presses' as you turn it. An analog axis can be 'jumped' to a position, while a stepper has to....step...its way there.

Even this giant chunky beast has a limit:
(I confess, when I built this it was totally in the intent of using that big dial for FSS!! But I had to abandon that idea, it just doesn't work as well as a thumbstick.)

There's two types of encoders, absolute and differential. One only 'know' it turned clockwise or counterclockwise by a click, and subsequent clicks if done fast enough to exceed the polling rate of the two signals that tell whether it stepped clockwise or counterclockwise can confuse it. Depending on whether its a half step or quarter step (how many channels it actually has that it's comparing) it might handle a faster rate, but there's ALWAYS a max rate these can be physically turned and digitally keep up.

The absolute encoder knows where it is from zero, (it outputs a multi-bit value that tells its location, bit count related to how many increments around the axis it can resolve) but even then might manage to output a couple intermediary positions. But those are much more expensive components; the sale page for the FSM only says "rotary encoder" that I can see, if it was an absolute I suspect they'd have said so, and I suspect we'd see a zero mark on both the knob and on the housing. Using a differential as an absolute can be done in software but assumes ability to count exactly how many steps have been made, which means you can't exceed the sampling rate. (A buffer might try to cache steps if some other output reporting process e.g. looping thru all the buttons goes a bit slower.)

Basically what you're seeing is the same thing as a stepper motor in a 3d printer 'losing' a step. It zeros, then every position thereafter is a number of X,Y,Z increments from there for the whole printing path, and if the motor gets blocked or insufficient current driving it so a step here or there isn't made you get layer shifts. The continuous output after turning might mean there's a software buffer in the microcontroller driver that's trying to preserve all the steps it saw, but even that logic gets confused if the steps exceeded the polling rate in coming in.

I suspect you're asking too much of this part perhaps (you and the OP both) expecting it to have unlimited actuation speed range, and keep up always (even aside from adding an extra software layer). Links below no direct association to the encoders used by FSM to my knowledge, just good general tutorial info on how encoders work and are specced for function.

http://cdn.automationdirect.com/static/ ... derfaq.pdf
https://www.quantumdev.com/calculating- ... -encoders/

Curious how far off base I am though; I'm definitely a dweeb at this stuff myself, at best.

Wow thanks for the detailed response and suggestions! I think you may be right and I am asking to much of the hardware. That's one awesome button box you have there! I'm working on one as we speak for star citizen! It's the one that isn't finished in the pic lol. Howd you do the text and white lines on your box?? Thanks again for the detailed post. I think I may just use that potentiometer I installed in my box for the mining laser throttle in SC for the FSS in elite. I mean if it's there why not?

[rtrski]

Capecop1, I don't want to hijack this topic too much with panel details - come ping me on Reddit, same nick there. I'll fill you in on how I did mine (quick hint - throw money at the problem, not DIY for the face panel ;-D ).

[JPVann]

So after 4 months of screwing with this FSM-GA and SEM modules ($250), extensive questioning on the VKB discord I found that the modules are literally at the lowest common denominator for Windows USB.

There was literally ZERO thought on how these should work in real life - all the effort was spent on looks. Just like the awful GNX throttle. These are nothing but dumb usb boxes with zero added extra thought. If you need this for MSFS like I do time to move on.

It's what I was directly told in the VKB Discord.