Orion2: Heading and Course Bug Rotation Speed

[Arecibo]

Hi all,

I have a real issue with the speed that the heading and course bugs rotate on the Orion2 base, specifically in the F-4E. I end up having to spin it wildly to get it moving at a decent speed. Then it overshoots and I have to wait for it to finish before I can roll it back. I get so frustrated that I end up having to dial it in onscreen using the scroll wheel, which works fine. Is there a way to fix this or is this a firmware/Winwing support question? I have the speed dialled up to max (5) in SimApp Pro, but it needs to go higher.

Cheers,

Tim

P.S. Do Winwing monitor this forum?

Edited 1 hour ago by Arecibo

[speed-of-heat]

I don't think they do, in simapp pro is there an option to configure them as axis, there usually is an option to set them as 'button', 'axis' or 'both'... (At least on other win wing devices)

[Dragon1-1]

This is actually a problem with how encoders work. Since they send individual presses and not continuous input, this results in weird behavior. The mouse wheel seems to have special handling on Windows level that means it doesn't have those problems, but encoders on the Orion 2 are seen by the input system as rapidly tapping a button.

My recommendation is to bind those encoders to radio channel knobs, not to heading and course. Rotating a control that moves in steps is a far better use of them.

[Arecibo]

6 hours ago, Dragon1-1 said:

This is actually a problem with how encoders work. Since they send individual presses and not continuous input, this results in weird behavior.

You'd think Winwing would have tested this. I wonder if it's something that could be fixed on a module level. For example, detecting different speeds of inputs would move the dial x10° / x50° / x100°

6 hours ago, Dragon1-1 said:

My recommendation is to bind those encoders to radio channel knobs, not to heading and course. Rotating a control that moves in steps is a far better use of them.

That's a really solid suggestion actually. Thanks for that!

[Dragon1-1]

27 minutes ago, Arecibo said:

You'd think Winwing would have tested this.

They're probably aware, but it's not just Winwing. It seems to be an issue with how Windows handles rapid DirectInput inputs. For Winwing to fix it, they'd have to code some sort of solution when turning an encoder quickly enough registers as a continuous press instead, but this would have to be on the device side, before the input is sent. I don't know if other encoders from other brands act the same, but IIRC my Arduino-based control panel had to handle a similar problem.