Heading Increment Bug (10 degree instead of 1) Explained

It does. That’s why I don’t get the people saying it was fine as long as you “clicked” on the heading wheel etc. You still had messed up trim!

while it’s a pity you can go for FSUIPC and LINDA, assign the swtiches via linda and have no problem anymore

The trim issue is different from the heading bug.

I think this is the best thing regarding opening up the sim though. WT was a 3rd party, and they experienced first hand all the pain of the platform, so they are the most suitable one to work on that. They might still be constraint by their contract with Microsoft, but at least they can now steer the ship from the inside.

1 Like

I think what you are referring to are DPST vs SPST switches. Dual Pole Single Throw switches physically have one common terminal and two switch terminals. The switch when thrown connects one of the poles to the common while disconnecting the other. Single Pole Single Throw switches have only one switch terminal along with the common. When thrown one way the switch is connected. The other way gives you no connection.

But these our Honeycombs are physical switches, rocker and toggle switches and they are dual pole, i.e. both sides of the switches are wired to circuits. They are not momentary-on switches that open when you let go of them. so they will always present a closed circuit on one pole.

In the description of the cause of the bug I have seen mentioned the “set” commands, like Set NAV Lights or Set Yaw Damper. If it is the form of the command would it make any difference if instead of “Set Yaw Damper” on one side of the switch you used “Yaw Damper On” & “Yaw Damper Off” on the two sides of a switch?

1 Like

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…

2 Likes

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:

4 Likes

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?

Thanks,

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