Heading Increment Bug (10 degree instead of 1) Explained

Note: You might enjoy the latter posts in this topic:

[Huge performance hit when "breaking out" instruments]

I agree with you completely about MS / Asobo natively – and correctly – supporting the major peripherals, especially those of “partners”. Let’s talk about the Honeycomb Yoke as a specific example.

As I’m sure you’re aware, this is actually a Windows issue for USB controllers. It only supports up to 32 buttons as of the current version of Win 10 and back. USIPC7 uses low-level device calls to read additional button information that Windows doesn’t expose. So the solution must be done above the Windows level.

So MS/A announced a partnership with Honeycomb and native support for their products. Honeycomb Yokes (Alpha) and Throttle Quadrants (Beta) now show up in the sim control panels. Good deal right? No. Read on.

Honeycomb adds another sim complication because of their “constant-on” switches. Most joysticks and switch panels only send a command when the state of a switch changes. Honeycomb products, however, have their switch panels send a repeating “on” command for each switch, and that applies to whether the switch is in the physical on or off position. For example, the Battery switch on the yoke actually controls two logical switches – say logical switches 35 and 36. If the physical switch is off, then the yoke sends a continually repeating “switch 35 on” command. If the physical switch is on, then the yoke sends a continually repeating “switch 36 on” command.

As soon as we map any of those switches in the sim, it appears to work correctly but causes a certain bizarre behavior. Everyone attributes that behavior to a bug in the Honeycomb yoke, but it really isn’t. Yes, in other sims that don’t have native Honeycomb support, you have to use the Honeycomb drivers and specifically interpret the constant on behavior to toggle a switch in the sim, but the other sims don’t suffer from a peculiar bug that is unique to this sim.

There is a bug that is triggered by the Honeycomb constant-on switches, but it is also trigger by many virtual cockpit controls being clicked (incremented or decremented) too rapidly. It is NOT a Honeycomb-only bug.

For example, un-map all the Honeycomb switch panel switches (battery, alternator, etc.). Get in a plane on the ground and start it up. In the virtual cockpit, click the heading rotary knob (don’t use the mouse wheel – click it). Verify that it changes the heading bug by 1 degree. If not, restart the sim, and verify again.

Now click and hold it to increment the heading. You should see it begin to increment (or decrement) by 10 degrees with each click, and if you held it down, cause the heading bug to spin around and around even after you release the mouse. Now click the altitude rotary. It should increment by 1000 instead of 100, and go all the way to its limit. Click the trim wheel – and it will rapidly spin up or down to its limit.


  1. The native button handling for Honeycomb products works properly in the sim. It is natively using a (probably Honeycomb) driver that allows the sim to do the same thing as FSUIPC in regards to sensing the buttons above 32.

  2. Those buttons (switches) above 32 issue constantly repeated “on” commands.

  3. If you map those buttons to sim commands, they work as they should BUT…

  4. Mapping constantly repeating “on” switches OR manually doing the same behavior by rapidly clicking certain virtual cockpit controls (heading, altitude, trim, etc.) cause ALL controls to exhibit the global increment speed-up behavior.

  5. This is therefore a fault in the sim code, not a fault in Honeycomb products.

Since the problem is in the sim code, we’re stuck with waiting on MS/A (Microsoft/Asobo) to fix it. Until then, un-map the Honeycomb panel switches and use the mouse wheel to increment and decrement virtual cockpit controls.

If having the Honeycomb switches is absolutely necessary, for now you have to use FSUIPC or SPAD.



Brilliant - thank you @T1gger65. I actually have both the yoke and the quadrant (quadrant arrived yesterday!) but only had the quadrant plugged in when I was experimenting with FSUIPC - all to avoid the 10/1 increment bug. I’ll plug both in and match what you’ve got in the INI file here and see if that works and report back!

@T1gger65 - plugging in both the yoke and the throttle and updating the INI as you had worked a treat! Now just to figure out how to map all 48 buttons!!

Many thanks!

1 Like

Just a heads up – not all sim functions are available yet. FSUIPC7 changes at least once a month as the SDK and available “LVARS” change. So if you find something in the sim that isn’t yet available in the FSUIPC button mapping, you can always have FSUIPC send that keystroke to the sim for now.

Make sure to wade through the documentation and examples anytime you run across a problem. I’ve seen you lurking around the more technical threads, so I think you may enjoy dabbling with FSUIPC.

Be warned, however. There’s this thing that happens the first time you program anything that makes the sim behave how you want it. You get addicted! And it’s really bad.

If you start craving a fix, eventually you need to visit the FSUIPC forum. It’s sim specific and has a lot of users trying to do the same things you’ll want to:


Happy flying and programming!



Thanks for the heads up. Sending a key to the sim v mapping sounds interesting. I think I may be hooked already. How hard can this coding thing be, right??

Hoping I can at least sort out the 10/1 bug and maybe take it from there.

The quadrant is awesome though and really adds to my set up and looks the part

If I find myself on the FSUIPC forums, I’ll let you know!

1 Like

Please allow me to explain why this is not explaining anything and why this is not solving the issue.

  1. This 10deg increment bug is well known and well documented since at least 2004 (I’ve posted links to a few topics at avsim talking about this as an example). I remember perfectly well this problem back in the time and this was raised during FSX Beta and never acknowledged for nor corrected*

  2. I believe (but I might be wrong) FSX-SE did correct this problem, and/or Prepar3d and probably not until P3D2 maybe (but I might be wrong too - I lost track of these).

  3. If Honeycomb code is continuously sending their ON or OFF position state this is wrong too, and this is actually this kind of coding practice which is causing a lot of grief among simmers trying to mix different products together, like the RXP GNS/GTN with third party aircraft which gauge code does the same internally.
    The “proper” way to code this sort of things to me is in the form of changed states, not absolute states. In other words:
    a) read FS simvar value
    b) if simvar disagree from your switch position, send a command to rectify.
    Nothing more is needed, but because of the actual FS2020 SDK logic which is nothing else than the FSX SDK logic, and because this implies this implementation can only be done via polling for most of the monitored simvars, there could be a short gap between the state change in FS and the command issued by the hardware driver, which leads me to the next point:

  4. Asobo seems to be working mostly with a few Aircraft vendors and is putting them in the position of teaching Asobo how are the third party developers doing their aircraft in FS specifically. Because aircraft developers have limited exposure to the questions pertaining to inter-gauge/inter-vendor interactions because the aircraft is a whole in the FS SDK world, this gives little change to Asobo getting much expertise about these practical questions other vendors are confronted with daily for their products.
    Furthermore, in working mostly (if not only) with aircraft developers doing FS products, this shuts the door to learning how the same things are better done in other simulators and therefore how FS2020 could benefit from doing differently. And this makes me revising point 3) above:
    in XP11 for example, you can intercept commands and dataref state changes so that the “short gap” I was mentioning would be inexistent: the moment the state change, the hardware driver would immediately send the command to restore the state matching the hardware switch.

As a conclusion: there are two disconnected problems with the Honeycomb hardware and FS2020 in my opinion:

  1. FS2020 is not accelerating event inputs per inputs, but globally, which is wrong. Only the ones repeating should be accelerated, all others shouldn’t be affected.

  2. Honeycomb driver is trying enforcing the FS2020 state in sending a stream of events, instead of just sending the event needed to make the simulator state matching the hardware state when both disagree.

Both of these problems are independent of the other: Asobo should correct the implementation details of the acceleration system because it is problematic with or without hardware, and Honeycomb should correct the implementation logic so as to not hammering the simulator with non-stop events (for nothing 99.9999% of the time when no hardware switch changes position). At least, Honeycomb could easily implement a user selectable implementation: “Enforcing” (the current one) and “State change” (the proposed one).

*This shows how much FSX logic and SDK is still rooted in FS2020 in the sense instead of rethinking the simulator outside the box, the chosen path of taking the FSX code base and its SDK, removing what is not good and keeping what is good only works if you do have the knowledge about what is good and for this knowledge, you rather talk with a wider audience of 3rd party developers than just a select few.

PS: I feel compelled explaining a little more the little “rant” I’ve written just above in italic about the SDK. I strongly believe Asobo is doing a superb job with everything non gauge/system related in the SDK. It really shows new structures and logic, new implementation and modern interfaces and tooling. However, for everything gauge/system/modules, it is nothing else than FSX SDK in worst. Worst because not all is working yet, worst because the same bugs and limitations are therefore still there, worst because you can’t even re-code the deficiencies of the simulator because of the sandboxing approach depriving 3rd party vendors from enhancing the simulator internals. I find this a waste of energy trying to perpetuate these antiquated concepts inherited from the FS5 age and dating back from than 20 years.
For example, Asobo has built a solid JS/HTML system which really has deep capabilities for 3rd party developers, and this system is based on revolutionary concepts internally. Yet, they spend energy trying to “bridge” this with the antiquated constructs of the past so that 3rd party vendors can “easily port” their existing code… I’d rather them saying to us: “if you want to do an add-on, you’ll have to redo your code. We’re offering the choice of a future proof object oriented construct you can expand upon, or, a very low level down-to-the-entrails C++ access to the most basic internal structures. If you want anything which resemble the older SDK so that you port your aircraft faster, you’ll have to do it yourself.” The same reasoning makes me still wondering why it is they want to implement a XML gauge bridge into FS2020. Sure it will help porting existing XML gauge code, but why not just directly use the JS/HTML code path, ditch the old stuff and technological debt and let FS2020 fly higher…


While I do agree with most of your post, I will disagree there, though. A continous signal may be unnecessary most of the time, it does have merit, too. You do need this for the “START” position on the Alpha key switch because the duration of a state change does not suffice for starting a prop engine. Also, someone might be inclined to map a light test switch function to one of their toggle switches which also wouldn’t work nicely with a state-change-only solution.


Regardless of whether your explanation is correct or helpful (and personally I found it helpful and seems to tie in with what I’ve experienced) your final point seems to be the key one. Hence my foray into the world of FSUIPC!

although it might seem so, this is not true either: say start key on the “start” pos, send engine start event, key turned back on the “on” position, send engine on event.

If during the time you’re keeping the key in the “start” position, another gauge/module, or in fact just the user is sending an event to put it back in the “on” position, there is nothing much you can do even if you’re hammering the event queue in FS, because such event producer will get its slot and send the “on” event in the middle of the “start” events you’re sending.

And honestly, it would really take a convoluted case for this specific start key problem, and light test problem, to be interrupted by external gauge/module or user sending a contradictory event. In effect, when you’re starting the engine, you wouldn’t also trigger the “key to the ON position” with a keyboard shortcut at the same time…

Last but not least, if you’re polling at the gauge update notification rate (PRE_UPDATE in all FS from FS9 to P3D5), you won’t miss any state change when polling simvars because this is the rate at which all gauges and modules gets their turn in the loop, that is their opportunity to change such state you’re trying to monitor.

In other words, either you’re dealing with commands only, or states. The start switch deals with events only, the light switch deals with states. In both cases you don’t need to send a non-stop queue of events to the simulator, this is why I’m saying doing this is wrong. But in all cases, this event and simvar FSX model is not suited best. Instead, the XP11 system which is based on event handlers (command event handler, datarefs read/write event handlers) permits intercepting any such event and state change without any need to polling.

It is not rocket science and actually It is very easy to implement this in the existing FS structures and code logic (from FS9 to P3D5 at least): we’re actually augmenting FS with this facility for the RXP GNS and GTN implementation…


We’re on the same page, and that’s why I keep jumping in on topics that try to blame Honeycomb for what I call the “Global Increment Speed-Up” bug. Anyone proposing a solution to the Honeycomb switches or workarounds using FSUIPC or SPAD needs to admit its a partial solution. The real issue is the Speed-Up bug, and all you have to do is click and hold a virtual cockpit control to trigger the bug, which then affects many other controls.

You’re right – only the ones repeating should be accelerated, all others shouldn’t be affected." And there must be some kind of individual acceleration cancel logic as well.

Honeycomb has finally released drivers for FSX, P3D, and X-Plane that can turn the constantly repeating switches into toggles that trigger only when the switch state changes. Without that driver, the hardware is clearly sending repeats, so their new driver must be doing the state change sensing you describe elsewhere in your post.

In FSUIPC, I do exactly what you describe for many peripheral buttons, switches, and rotaries. For example, I use FSUIPC LUA logic to poll all 6 of the Honeycomb panel switches every 20 milliseconds and process them all, matching their state to the sim switch states, and only issue a command if a state doesn’t match. For the TBM lights, I created state change events for the yoke’s light switches, and again match the switch positions to the sim’s light switch state, and change them as necessary. This is important because of the TBM’s 3-position Off/Taxi/Landing light switch.

I’m happy having to use FSUIPC – I’m going to use it anyway so that I have better control of aircraft profiles, controller sensitivities, peripheral mapping, and stuff like that. Asobo should absolutely fix the Speed-Up bug because it limits virtual cockpit interaction for the general user.

Last, I feel your pain and share your bewilderment about the way they’re handling the migration from legacy to modern products. I believe they’re still getting a feel for what they need to provide attract and support third parties. I also believe they’ve still got a few more months where their focus in going to VR and Xbox. Six months from now, hard-core simmers and third party developers will likely get more of MS/A’s attention and love.


1 Like

Oh, yeah. Just realized that I was talking nonsense. Of course state changes would be sufficient. I was just thinking about how you circumvent the bug with Joystick Gremlin and its remapping. Completely different approach. I retract my statement. :grin:

1 Like

I sincerely hope so! Thank you for your encouraging support!

Just posting here to +1 the vote. I have a Thrustmaster Airbus Officer Pack and having the same issue. It’s strange that this set is marked as being compatible, but I had to unmap some buttons from the quadrant otherwise I would have weird issues when pressing esc whilst flying and retuning into the game - my flaps and spoilers would be completely out. Although that is now fixed, I’m having the increment of 10 bug. Hopefully Asobo see this and look into fixing it.


I am amazed at the amount of discussion of whys and wherefores here. Just understand that this is a clear cut case of PPP (Pi*s Poor Programming). Any controller that has at least one button or switch mapped in the way the video from T1gger65 describes will cause the problem.

1 Like

OK, so now I understand your post!

I actually spent a good few hours on this, but think I’ve managed to get the quadrant set up just how I want it. I also understand your “send a key” thing now, which I had to do for a couple of switches where FSUIPC didn’t seem to be getting the right input from the sim.

Having taken that time though, I’ve now got a much better handle on hoq to do this going forward. Literally just set up one aircraft though (the TBM) for both my Alpha Yoke and Bravo Throttle. It’s awesome and really changes how the sim feels - I can now do pretty much everything without needing the mouse to control the plane. Only need the mouse really to programme the fight computer.

I can see how this can become addicting…

1 Like

@Hugothester what is the manual scroll wheel you’re referring to? I am having the at 10 degree increment issue and it’s impossible to try to dial many VOR radials, when using the mouse scroll wheel ( which is the only option to live the VOR OBS) please explain. Thanks.

1 Like

“Manually scroll the wheel” that means click on it instead of using the mouse wheel :wink:


What controllers are you using?

I am sorry not sure what do you mean by what controller I am using! I am using the mouse to dial the VOR bearings, I also use VR but VR controllers aren’t active controllers as of yet. Hope that is what you meant :grin:

I was going to take the time to setup the vJoy and Joystick Gremlin today to get full use of my new Bravo throttle quadrant. Now I’m thinking not. As another poster mentioned, since I generally use MSFS for GA flying only, I’d only be setting switches for lights. I can live without those and just manually enable.

I set this up to work the Zibo 737 in X-Plane 11 and it works very well, albeit, using the custom configuration tool made by Aerosoft. Hopefully this gets taken up soon. After we’ve waited months for this “supported” kit from Honeycomb, it’s a little frustrating that it hasn’t been resolved. And as others have noted, it isn’t just impacting honeycomb. I had the issue with my old Saitek X52 and Airbus TCA Sidestick.