Encoder setup to adjust heading/course etc.

[Viking]

I would like to use the encoders of my STECS to adjust the heading bug and omnibearing or course selectors in DCS.

Currently the encoders are set up as discrete buttons. However, the output is much too slow. I already adjusted the T_EN value to 2, but still the output is lagging heavily behind the input.

I would like to achieve a behavior that resembles that one of a mouse scroll wheel.

How can I do that? In DCS there is the option to use an axis for those knobs, but I do not know how to setup the encoder as a virtual axis for that. Would that work?

Any help would be greatly appreciated!

[fallout9]

Check out this guide.

[Viking]

Great, thx a lot!

I managed to setup the two Axis which are linked to the Encoder and are toggled with a Modal Switch. That works so far.

However, Axis 8 won't go beyond 25087 (see screenshot). Axis 7 works fine. Might that be a bug? All settings are equal between Axis 7 and 8.

One more question: is it possible to start the Axis again from 0 after exeeding 35017 (and vice versa)? That would be perfect for a HDG dial.

[Alex Oz]

Since you haven't posted your profile in accordance with the forum requirements, I'll give you some general recommendations.
Please update fw & configurator.
If you have any issues, let me know.

[jukelo]

Great, thx a lot!

I managed to setup the two Axis which are linked to the Encoder and are toggled with a Modal Switch. That works so far.

The attachment Encoder.png is no longer available

The attachment Profile_Axes.png is no longer available

However, Axis 8 won't go beyond 25087 (see screenshot). Axis 7 works fine. Might that be a bug? All settings are equal between Axis 7 and 8.

One more question: is it possible to start the Axis again from 0 after exeeding 35017 (and vice versa)? That would be perfect for a HDG dial.

This is symptomatic of a trimmer that is shifting the value of an axis bound to a physical sensor. Trimmers set up like that can't shift the axis value more than 50% either direction: if the sensor is centered, the encoder can give you the full range of values. Otherwise you'll be limited by the position of the sensor +/- 32767 (that's expected, you don't want your trimmer to overshoot). In your case that's most likely the Up-Dn lever on STEM that is the underlying sensor. It is not calibrated, so probably sending some value outside the expected range and limiting how far the trimmer can go.

Your options are to either:

• change the Trimmer options for physical axis 8 to Input instead of +, and change MPL to 5 and make sure kdhi and kdlo are set to 255. This makes the trimmer the 'virtual sensor' - my preferred method.
• or disable whatever sensor is bound to axis 8 in Global > External Devices so only the trimmer acts on that axis.
• or assign the encoder to trim a different (unused) physical axis.

[jukelo]

As for making the axis loop around, there is no built-in option for that (it would be a nice feature).
It's possible to scrounge something like it together with some heavy boolean use, but it's kind of janky and I have instead found that simply playing with the additional encoder options is usually good enough to avoid having to turn your encoder into an axis:

Mode defines the way encoder 'ticks' are processed:
* Standard produces pulses of length equal to the T value. ALL 'ticks' of the encoder are accounted for and queued internally. Turning the encoder fast can produce a very long queue since the T pulse duration is strictly enforced.
* G1 produces pulses of length equal to T. There is no queuing: if pulses are coming in faster than T, they are merged together and stop when you stop turning the encoder.
* GT+: pulses are merged AND queued into a single long pulse if they come in faster than T. Min pulse length = T, max = T * number of ticks.

The default T value is equal to T_Enc defined in Global > Common. The default T_Enc value is 50ms, which is fairly high. It's a conservative value to ensure Windows doesn't get confused when button pulses come in too fast (they'd be seen as one pulse).

For the Course and Heading knobs in BMS I use T_Enc = 20ms and Standard mode as a better compromise: the number of missed pulses is reduced. G1 due to no queuing would be ideal, but BMS treats each pulse as a singular event.
I believe DCS can interpret a single long pulse as several ticks of the knob/bug so G1 should work well.