I know it doesn’t make sense, but if I use my Honeycomb yoke (rather than my Saitek yoke), the heading bug increments in 5-10 degree jumps rather than 1 degree.
Switch back to the Saitek and 1deg increments return.
Oddly enough seems to be related to a mapping of the magneto switch and/or lights. If you clear that mapping, it works fine. I’ve submitted a Zendesk ticket.
Problem SOLVED temporarily!
I also have a Honeycomb yoke and having the same issue. I verified it by unplugging the yoke. It seems to me to be an issue with the mag switch continually sending feedback to the sim. So my temporary fix, for now, is to clear the binding for the Magnetos Start. When I start the engine, I use the mouse to switch to Start. The switch, in the sim, is sprigged to switch back to Both when you release it. I can use the switch on the Honeycomb to do my run-up. When I’m done with the run-up, I switch the mag switch on the Honeycomb back to Start (that has no bindings since I cleared it).
With the mag switch in a position with no bindings (Start), then I can use the scroll wheel on my mouse to advance the Heading Bug, Heading Correction, VOR1 OBS, VOR2 OBS, Attitude Indicator or ADF in 1 degree increments.
This problem happens when a button that is mapped is constantly in a pressed state (Held on). The Honeycomb has multiple on/off switches that could be bound to lights etc. However, whenever you do so, this problem happens. As soon as your release all buttons or switches from their constantly pressed state to off state things return to normal.
Another thing you’ll notice is when you’re in the settings for the controls, if one of the buttons is in a pressed state, and you press other buttons/switches… they will NOT flash like they normally do on the mapping screen. Nothing flashes while the pressed buttons stays lit.
I think this problem not only causes the 10/1000 intervals but also other problems such as forced full trims etc.
I don’t have the honeycomb yoke but I have a home-made switch box and I use a Leo Bodnar board and same thing happens when I have one of the switches flipped to ON (lights). I can only use buttons that are momentary on/off for now. Not switches.
so either unbind those switches or use them as on/off meaning, use as toggle instead of set states.
I’m a Honeycomb yoke user with this problem but as you’ve indicated its not peripheral specific but can be caused by any device that uses ON state switches. I’ve found several different threads on the issue and I know many of us have submitted Zendesk tickets. My ticket was marked as solved and they emailed back to say it has been entered into their internal bug-tracker and prioritized.
Sadly the issue wasn’t resolved as part of the patch #2 released today.
I hadn’t considered that this might also be affecting autopilot trim but I’ve also had that happen to me using the 172 steam gauge AP so it makes sense. This is a terrible bug and hope that it gets resolved soon.
Just wanting to double check what I’m reading. If switches are bound to say beacon light on and beacon light off for the beacon switch then it causes the problem but if instead it’s bound so either direction is beacon toggle I.e. if it was momentary then one press would be on and the next off then it doesn’t cause a problem? If so trying to understand how that will work with these always on switches. Or are you saying for example again on the beacon switch to set on position as toggle and the other not assigned then flip to the toggle position and back in order to use it?
I managed to order one of these from the MS store Tuesday night when they apparently had a few in stock. I was aware of the 10 degree issue prior to that and had heard about the magneto fix but nothing about the other switches so just want to know for sure what’s needed to set it up Monday when it supposedly arrives.
I’ve not looked into changing the lighting switches, alt, battery, avionics etc to toggles if those mappings exist in the controller configuration settings. It might work so you could test it out. I ended up un-mapping all the Yoke pedestal on/off switches and the magneto rotary switch. After that the 10 degree increment issue has gone away for the OBS and Heading bug in the 152 and 172 steam gauge. In addition the 172 steam auto pilot seems to be behaving much better as I was having issues with the trim going full up and losing control of the aircraft.
Really disappointed that I’ve had to un-map the switches and revert to the mouse for those controls but at least navigation and AP has improved until Asobo can get this sorted out.
To add some more investigation to this problem. As far as I now have experieced it is a problem that is not only tied to honeycomb. After clearing all the bindings that ‘set’ a state (e.g. Set Alternator) the heading bug and OBS moved with one degree. Not only with the mouse but also the rotaries on my goflight autopilot worked. Had a nice flight without issues.
Next flight I connected the simionic G1000 iPad app which had showed the same 10 degree bug before. Lo and behold, this now also worked per one degree! Problem solved, I thought…
But no, after activating several different autopilot settings from the Simionic app I noticed that the heading bug started to show the 10 degrees bug again. And when I shut down the connection on the iPad the trim bug also raised it’s ugly head and drove me straight int the ground.
So, my conclusion, many problems we are experiencing are tied to buggy communication via simconnect.
Yes this is a known bug and I’ve also raised it. Unmapped magneto switch fixes it. It also solved a related issue i had with excessive trim sensitivity.
It seems to relate to any controller input that sends a continuous signal like the magneto switch on the yoke. But I don’t have any other controllers that do that so not entirely sure
I also have a Honeycomb yoke and switch panel and have unmapped the starter switch and have noticed several improvements.
I can now turn the Cessna 172 type aircraft starter switch using the mouse, previously unable to do this plus could not use the keyboard keys either. I had been having considerable trouble with ILS and RNAV approaches with the aircraft flying through the approach without descending, or starting the descent early with the green dot stuck at the top of the descent display. I have tried a couple of approaches today, after unbinding the magneto switch completely, using ILS and RNAV and both have worked as they should.
It’s a MSFS bug and not something for Honeycomb to solve. Any controller with switches mapped to the set commands which have continuous ON states can trigger this behaviour. Submit a Zendesk ticket if you haven’t already.