Mouse rotary encoder for heading bug

[JackZ]

I too am an hardware fan.
As a pilot in real life, and using my sim for training, I always felt that rotating a dial with a mouse was anti natural and quickly tried to have at least some hardware dials.

I went first the LeoBodnar way, which I agree is the easiest way, BUT even if it can handle encoders, I feel it is not adapted for moving a heading bug or a course bug.
The problem once again is the lack of proper acceleration handling

On the real plane, mechanical bugs are made in such a way that a 180 degrees rotation of the heading bug requires less than 3 times a 180 degrees hardware button turn.
That means that you can order a 180degrees turn to the Autopilot within 3 seconds and with less than 3 moves of the hand on the dial. Time is of the essence, so a small amount of rotation allows you a large heading change while still allowing you to move the bug with one degree increment. This thanks to the mechanical link between the dial itself and the bug via a train of mechanical gears.

On the contrary, with an encoder hooked to whatever card that emulates a joystick, one click equates to one button press. That button press is in turn translated to a heading bug increment/decrement command in your favorite sim, using the config menus you described.

A typical encoder sends between 24 and 60 clics per complete (360 degrees) physical turn. So if you want to initiate a 180 degrees turn of the heading bug, you'll have to "physically" send 180 clics to the sim, which equates to between 3 to 6 full 360 degrees rotations of the hardware dial!

I remind you that you can hardly make more than a 180 degree turn with your fingers on a dial without actually releasing then grabbing again the dial. At the end you'll move your hand at best 6 to 12 times on the dial to get that 180 degrees bug rotation.
Waaay too long more than twice the time it takes with a mechanical device.

The same applies to touch dials, a software touch dial can need more than five or six seconds of continuous finger operation to get a 180 degrees rotation, unless you increase the step count. But in that case you will loose some accuracy, as you will no longer be able to set heading precisely up to one degree...

Hence the acceleration problem, which we discussed on another post on this forum. You have to get a way to get fast increments when turning fast the dial and still be able to do precise adjustments up to one degree when turning slowly. But this feature is not built-in so you have to do it programmatically, one way or another.

For a less critical function such as a GPS dial, where huge amounts of inputs are less needed this can be okay:
For a typical GPS dial where you have to select at most 35 possibilities (A-Z letters 0-9), that is not much of a problem, one full turn of the dial can handle that.
But changing radio frequencies without dial acceleration of some kind can really be a pain...

Jacques

[MarkH]

If you have FSX, this is the extent of your "Heading" commands.

Heading bug (select)
Heading indicator (reset)

Not much there to "program the heading bug, is there? In fact it's almost useless.

Okay, two things. That is not the whole story because when you have selected the heading bug (with the command shown) you can then manipulate it with the 'selection increase' and 'selection decrease' commands. Yes, it's still ham-fisted if you program it from the FSX user interface because you need three buttons instead of two. But that's not the same as 'almost useless'. In fact if you have a Leo Bodnar board and a rotary control with a central push switch (such as the CTS 288V encoders that you can source with the Bodnar boards) you can put the 'select' command on the push switch, with the 'selection increase' and 'selection decrease' commands on the rotation. That's almost elegant!

But the second thing is you can also use an add-on to open up access to all the data and events listed in the SDK (for the present discussion, the HEADING_BUG_INC, HEADING_BUG_DEC and HEADING_BUG_SET events are relevant). Since the internal architecture of FSX and P3D are essentially the same you can bet if a function is available in P3D it is also available in FSX if you can get to it. The traditional tool for opening up such access has been FSUIPC, but SPAD.neXt has some amazingly powerful features and is considerably more accessible than FSUIPC. So with either tool you can manipulate the heading bug in FSX just like you can in P3D.

The ease of "programming" the commands in Prepar3d makes it worth buying. X-Plane 10/11 may have the same ease. I just don't know how extensive the control settings are.

In my brief experience of X-Plane 11 it is more flexible than FSX but has some gaping holes. I have discovered two show-stoppers so far (unless someone can correct me):

(1) It can't distinguish between two or more instances of the same hardware device. Specifically, in my case, two Saitek throttle quads or seven Leo Bodnar BBI-32 boards. Taking the Bodnar boards as an example, all the devices appear in the XP-11 joystick setup screen (although they are listed with indistinguishable names) and I can program functions onto the switches of each one apparently independently. However, the switches are not recognised when the sim is running.

(2) There is no way to program actions onto button-up events. This is a crippling limitation for most cockpit hardware designs.

Thankfully there are solutions, again using add-ons. I have bought SPAD.neXt and it plus both of those gaps.

[oldairmail]

OK, two rather knowledgeable people.

JackZ, when I saw your post - Mouse rotary encoder for heading bug, I thought that you were looking for a simple, and cheap, of method of entering data/moving a header bug with a DIY encoder. I tried to keep it simple, but see that, that is not needed. The same goes for MarkH.

MarkH brought up SPAD.neXt. Click on the link, I'm VERY sure that you'll find it interesting. Essentially, it gives you the ability to use just about any USB/HID input device to get the most out of just bout anything that can recognize a USB/HID input. Got to the site, it'll start to make sense.

BTW - SPAD.neXt works with FSX, Prepar3d, X-Plane 10/11, and a lot of other stuff. I've been watching it from when Ulrich started asking if anyone was really interested. I've bought the registered version and then the "Complete Edition", and even made a donation when he started out and didn't have much equipment.



Just a quick note - You can use SPAD.next to accelerate the turns on an encoder.



MarkH already know about it so I'll talk to JackZ, and anyone who wanders along.

I started with a mention of the Arduino Controller boards, so let me put in a few links than can help explain my enthusiasm (these are on the SPAD.neXt site);
Arduino controller
Arduino boards to use as USB/HID controllers
Arduino controller - Building a GPS


MarkH, you mentioned a problem with X-Plane not being able to distinguish multiple instances of the same board. Ulrich may have that solved with the newer versions of SPAD.neXt. I know that I can give different names to multiple instances of the same Arduino board.

This is just 1 board, but as you can see, I gave it a named that I can easily recognize.




I'm sorry to cut and run like this but I just noticed that I've run out of time. Rather than me going on and on let me suggest that you check out the SPAD.neXt YouTube site

This might be a good place to start

[russ]

Hopefully Air Manager for Raspberry Pi will allow even more people to love buttons and knobs too....with very little new stuff to learn. The API is almost the same as for screen controls and no extra plugins or stuff to learn.