Heading Increment Bug (10 degree instead of 1) Explained

There are basically three choices at least:

  • Binding a SET command on a SPST for the up position only (meaning 1 when up, 0 when down)

  • Binding a SET command on a DPST for the up position only (meaning 1 when up, 0 when down)

  • Binding a pair of commands on a DPST (thank you for the acronym!) )(meaning ON when up, OFF when down)

Each case is as valid as another and in all these cases, the only problem is FS2020 accelerating any command as long as 1 and only 1 is always active. If FS2020 is accelerating only the “SET” commands though, it would then be better mapping the switch positions to the ON and OFF commands instead but this is a user facing problem only, not a hardware problem.

However, because of the DPST nature of the switch, the autodetection of input when setting up the controls in other games doesn’t work, because activating a switch changes 2 inputs instead of 1. For these, it would be best having an alternate firmware mode when each switch is working as a SPST. It can be easily done in removing all the switch down position inputs from HID, as if each switch would only have a UP position (1 is up, 0 if down), or if not possible to remove them from the list exposed via HID, at least making the down positions always 0.

I hope this makes sense?!

PS: about the ON/OFF commands, some of them are presently not working as expected, or not at all in FS2020… I believe this is affecting the LIGHTS ON/OFF commands (the first 3 switches from the left in the Alpha).

I was thinking that it was strange to have both on/off pairs of commands and set commands. Some even have a toggle command. I am assuming this is a by product of a large development team with less than ideal coordination. Unless maybe it is intentional so it will work for both single and dual switch devices.

That is all just musing, what is important to me now is what to do. I understand there is a fix coming, presumably in the next sim update at end on March. Is there an easy work around that doesn’t require un-mapping all of my switches? If it is too much bother I guess I could wait a couple of weeks for the fix. The thing is I have already waited so long for it to arrive, now that I have it, I want to play with it.

1 Like

You probably meant it right, but the fix is actually planned for the next World Update, not to be confused with “the next sim update”. I think history shows that this release scheme was a bad decision by MS/Asobo because it causes more confusion than clarity.

If you want to try a work-around, my impression is that Gremlin+vJoy is one of the most favored. I also understand that there should be a free utility available on flightsim.to, but the name of it escapes me. FSUIPC can also do the trick but that one costs money.

I have decided to wait and see.

I have this bug too n it was after the last update mainly after autopilot is engage i am using the thrustmaster airbus officer pack any work around this? :rage: :rage:

Apparently now is for sometime 2021 based on today’s dev update blog post… They said that mouse interaction is fixed.

So it seems that for the honeycomb bravo knob to work as expected will have to wait longer than world update 4…


It appears you’re correct: [BLOG] March 18th, 2021 Development Update

Now even I begin to wonder if they even understand what the error is about and how it affects us…:confounded:


I have this prb since last update with every plane i use a Saitek JS x55 but also if don’t map any function to js button and i use mouse to roll the knobs(CRS HDG) it moves 1° on ground, but when the plane get speed and airborn the gap became 10°. it’s not funny play at this way!!! especially with simple plane like c152 i can’t get the correct VOR radial!

1 Like

It’s a bit of a shame but now I’ve removed the bindings from the Master switches on my honeycomb it seems to work.

I like the discrete jumps, but 10 deg is too much.

I suggest switching to 1 deg and accelerating as the button is held down to increment or decrement. This is better than having a different button for fine vs. coarse.

OK, so after the last dev updated were they move to sometime 2021 the fix I decided to go ahead and spend hours configuring vJoy and Gremlin for my Honeycomb Alpha and Bravo set.

After creating all the macros in Gremlin Joystick and the remapping in FS2020, the buttons started to work… there is only one issue left to resolve.

Button 13 on the Alpha (Master Alt On) keeps stuck even in Gremlin the macro says Press → Pause → Release. And when that happens the 10 degree bugs is back.

Is not al the time, when I test it on Controls Panel in FS2020 or in Joystick Gremlin seems to work fine (it gets released), but in the cockpit of the C172 seems to get stuck, and it shows when you go to controls setting and I see button 13 pressed (screenshot below)

Button 13 macro:

Button 13 stuck:

Anyone had this issue and managed to resolved?


Am I the only one for whom this did work right until the latest update? I used to be able to click for 1’s and scroll for 10’s – now it’s all 10s.

I have the Alpha/Bravo, but had them before this update and only had the 10 increment issue when using their dials.

No, you’re not alone. Same here.

So the fix they released in SU3 actually made things even worse for us.
“Us” being those who suffer from the bug discussed here.

Yea, everything was usable until this update. Now I need to tell VATSIM in remarks that I can only accept headings increments of 10.

Has Asobo made any mention of addressing this situation? The one mention of a “heading bug” was actually addressing something else according to their last live stream. I can’t believe this is that difficult to fix.

1 Like

Actually, they said that it would be included in WU4, but the latest Developer Update only says “2021”.

There has been so much confusion about which error they were referring to, that I’m becoming unsure that they fully understand what this thread is about and what the consequences of it is for us.

All the fuss about performance hit in SU3 has probably thrown most of their plans up in the air, too.


The 3-18-2021 Feedback Snapshot says the "Heading Increment Bug (10 instead of 1) ‘Mouse Interaction Fixed’.
So, what the heck does that mean? What about keypress interaction?

1 Like

I skimmed this thread but didn’t read everything carefully. So if this detail has already been discussed then I apologize for duplicating.

Today I started using a keymapping software after seeing a youtube video from Overkill about a possible fix to the increments. Through a couple hours of trial and error it seems the bug is tied to the Gear Down command for my Bravo Throttle when set inside MSFS controls. If I set Gear Down to a keyboard command and then assign that command to my gear lever through RS Mapper instead of MSFS, then the increments work correctly. I don’t know if this is a coincidence or an actual solution for the Bravo or other throttle quadrants, but it seems to work for me.

I’m not sure either, but I presume “Mouse Interaction Fix” is the one Martial referred to in the 5th Developer Q&A when he claimed that “it is fixed” and would be included in “the next update”. Everybody here took it as the bug discussed here. (Often referred to as the “Honeycomb bug”, although it affects all controllers with persistent switches of various kinds).

A few days later Jummivana regretted to inform us that the fix didn’t make into SU3 but would be included in WU4.

In the 6th Q&A (the latest one) Martial apologized for the confusion, but I don’t remember him saying anything about changed plans, just that he had mixed up the two issues in his previous announcement.
So we all thought WU4 remained the target, but this latest update just adds to the confusion, and there really is no way to tell if we should go ahead with some workarounds or wait for WU4.

@Jummivana, do you have a status for us?


The conversation went a bit like this:

“How’s it going with X?”
“Yeah sorry, I mixed up X and Y last time”
“Oh ok thanks!”

Everyone else: “Yeah but how’s it going with X??”

1 Like