MOZA AB6 doing weird things

Hmm no, both axes should get heavier as you move away from center.

The AB6 is not tested as such - I own the AB9 and have tested and validated that. it might be a difference between the two sticks, even though both are from Moza.

Please submit a support bundle (Support → Diagnostics → Export — it includes your hardware settings).

If this confirms a stick whose two axes are oppositely polarized, the right fix on our side is a per‑axis polarity option so pitch and roll can be inverted independently — the global switch you have today simply can't express that.

Could you also submit a report with FFB-Probe? https://ffb-probe.com/

That will help me see if there's a difference between the two sticks and fix this issue. We'll get it sorted, no worries.

FFB-Bridge wrote: Hmm no, both axes should get heavier as you move away from center. The AB6 is not tested as such - I own the AB9 and have tested and validated that. it might be a difference between the two sticks, even though both are from Moza. Please submit a support bundle (Support → D...

hey there, i did some messing about with your code and found that these 2 lines inside "FfbBridge.Core.Physics.ForcePipline.Tick" are causing the weird behaviour.

pitchForce = Math.Clamp(pitchForce + rkPitch, -t.Forces.MaxOutputForce, t.Forces.MaxOutputForce); pitchForce = Math.Clamp(pitchForce + sfPitch, -t.Forces.MaxOutputForce, t.Forces.MaxOutputForce);

after removing those 2, i can feel the forces as expected. it feels like the more i pull on the stick, the less force i get with those 2 lines of code. so the force does seem to be in the correct orientation but it just gets less as deflection increases

EDIT: the code brackets dont work on this forum btw

regarding ffb probe, i am having issue with this program since i have multiple devices including vjoy (virtual joystick), it just keeps testing the virtual joystick, maybe you should create like a dropdown list where one can chose which one to test in that

i uploaded the support bundle via the form

adding to my previous post, i also noticed that pitch forces like stick drop go the wrong way. it falls towards me instead of forward

Thanks for this, let me look through the support bundle and the code and see what's what.

Confirmed, issue found. I will have a fix for you soon - I'm implementing a UI that allows users more granularity - you can set each axis individually, that allows for all possible cases to be dealt with.

Moza has some weirdness around this, XPForce ran into the same thing.

https://www.fsmissioneditor.com/moza-force-feedback-support/

EDIT - Not needed. New version releasing shortly.

Try this. It splits the axis' up and you can individual invert forces as well as centering. This should let you dial in whatever combination works on this device.

https://i.postimg.cc/056qJFPs/image.png

If this works, I'll create a Wizard in the app that will guide users on what the forces _should be_, and then walk them through picking the right options.

Without that, this is reminding me a bit too much of my boolean logic classes way back when..

FFB-Bridge wrote: https://ffb-bridge.com/dl/diag/8Ek-wDl55seHrWY5Not12YBW0MEsIvu_HPSN3GgA-3Y Try this. It splits the axis' up and you can individual invert forces as well as centering. This should let you dial in whatever combination works on this device. https://i.postimg.cc/056qJFPs/image...

i gave the new version a shot and the new settings do what you said they would - seperately inverting the axis but..

the issue remains sadly. let me try to explain what i am seeing now:

if i am not inverting pitch: on the ground the stick drops forward, i guess is how its supposed to be. i then accelerate on the runway and the stick goes to center - correct aswell in flight as soon as any sort of force comes it pushes the stick more and more aggressive in that direction. so if i am slightly pulling back (nose up) the stick starts to move further and further back to full deflection.

if i am inverting pitch: i am getting stick drop to the back, general pitch forces seem correct but if i am pulling the stick force decreases.

to me it seems like individual forces are swapped and not the axis itself. aspecially the stick drop is a very strong indicator and also if i remove specific forces like the surfacefollow and rotationkick it seem correct.

as a test i swapped the effect direction directly in code and that made it feel exactly how i expected it (also same with the stick drop) could it be that xplane telemetry is direction swapped or something?

https://i.imgur.com/mYJ2Ju0.png

double checked with MSFS2020 identical stuff to xplane happening, not telemetry related

Yes, that's a real bug. It all stems from the fact that I started this project solely for my sidewinder on Linux, and didn't use the correct polarity convention (I just went with what worked). That then led to me needing to flip signs all over the place as I started supporting more sticks and more OSs.

I have fixed the polarity convention now, and most of the code is now clean, there are a few places left where the signs aren't correct and this is one of them. And it doesn't help that MSFS and XP do treat things differently in a few places.

But now, between your feedback bundle and your code investigation, I should be able to fix this shortly. I'll have a new build for you in a few hours.

Thanks for the great detective work, was very helpful. We'll have this fixed shortly.

FFB-Bridge wrote: Yes, that's a real bug. It all stems from the fact that I started this project solely for my sidewinder on Linux, and didn't use the correct polarity convention (I just went with what worked). That then led to me needing to flip signs all over the place as I started supporting mo...

lovely to hear, glad i could help.

as a suggestion, maybe you could add tests to the mock sim for those things, like roll and pitch direction. for example, a button with "nose up" would move the stick "back" towards the user.

one last important note:

if i am using the test or mock sim, my joystick is moving correctly without inverting anything!

so maybe the real issue is the normal pitch force/roll force and not the other effects!

because right now when i am testing the direction, i see it moving correctly and then it asks me if the joystick moved as expected. i click yes, and now it's not inverted, but in-game it will still be sending forces in the wrong direction.

i think thats 2 different issues which are masked by each other

Yes, before I release any more builds, I'm building the "Guided Tour" that will run a test that explains what you should be feeling, and will test all these paths on the user's stick. There are tests that run during the build process, but those are deterministic, code path tests which can't pick up on this kind of user-feel issue.

Good news. You'll have a release announcement soon...

I have revoked the link to the test build. There's a new version coming soon.

Hi, I'm the developer of the SimInvent DIY Yoke. I am also having problems with reversed forces and with the build linked above (1.1.4 with the 4 extra options) I still have problems I'm afraid. Even if this thread is about the Moza yoke I think the issues are similar.

If I reverse polarity fully (global setting), I get correct response on spring forces, meaning I have to fight the stick to go dive/climb/roll. Trim works also as expected. It is just the Stick drop that is reversed, elevator pointing up.

If I check *only* the two rightmost settings, My yoke will pull out and *fully to the right* on idle on the runway

If I set the two leftmost options (invert pitch & roll direction) then all centering forces appears to work correctly, except trim. Meaning stick/yoke input will now have to be forced against the centering force. Trim however is having the inverted effect, i.e changing trim just moves the centering offset of the yoke. I never have to fight the stick if inproperly trimmed. Elevator on standstill is still pointing up here as well.

So all in all, fully reversed polarity makes everything work *except stick drop*, which I can't fix with the options given. One thing of note is that if I leave stick drop on and accelerate, the air speed forces will cancel out the faulty stick drop and center the stick properly. So all telemetry etc works once I get up to speed.

Happy to tell you everything is fixed. The proof of the pudding etc., so just wait a bit for the new release. Should be out within the hour.

Sounds great! Maybe a release candidate first to make sure everything is fixed?

The docs are not updated yet, but you can download the installer now - https://ffb-bridge.com/download

Check out Flight Check. I think you'll find it quite interesting.+

Full docs, release notes, etc are happening now. Email to users after that.

Flight Check is awesome! Way to go!

However, still problems to iron out. I run with Normal polarity set. In Flight check everything checks out except:

• Centering Spring. Does absolutely nothing, Yoke is limp.
• Rotation kick. It moves the yoke fully back.... No kick...? What force effect are you using here?

And in general, it would seem you use the effects forces at their default or 100% settings which is way to strong on my yoke. I have dialled down all those runway/engine rumbles and buffet effects. But aside from that it works fine.

So, flight check (except for spring effect which did not activate??) tells me everything is Ok in Normal polarity . In MSFS with a Cessna 172 everything works out except roll force which is reversed strangely enough. Checking _that single checkbox_ solved everything in 1.1.2!

There is a bug which may actually have fooled me in interpreting results wrongly earlier! If I have FFB Bridge up-and-running and then start MSFS - I end up with the yoke being pulled out towards me and rotate fully right when I start a new flight!

If I restart FFB Bridge while MSFS is running and just resume my session there - it now works perfectly!! Spring centering , stick drop, force directions.

So, FFB Bridge behaves differently if it is started before or after MSFS! Only if started *after* MSFS do we get the correct behaviour.

Barsk wrote: There is a bug which may actually have fooled me in interpreting results wrongly earlier! If I have FFB Bridge up-and-running and then start MSFS - I end up with the yoke being pulled out towards me and rotate fully right when I start a new flight! If I restart FFB Bridge whil...

How interesting. Let me see if I can recreate this. But good to know it works perfectly otherwise; I'm confident now that all the polarity issues are gone.

I did have my device to auto-arm. Maybe that is interferring and causing that problem? It seems that if I disarmed/re-armed it did return to normal, without needing to restart anything. But I haven't confirmed this fully.

Nah, I know the issue. MSFS is sending spurious data bursts during the loading process that are not being silently discarded. On my sticks (Moza, sidewinder), the stick moves briefly, but then the firmware must be recentering/resetting so I never saw that issue you are seeing.

The variable I'm gating on (Sim = 1) is fired during the initial load to the menu, and that data burst makes it through. I'm working on a quick fix, will send you a build to test. If that works, I'll push out a 1.2.1 hotfix