Connection sometimes dropping

[joverbeeke]

Since upgrading from moza R9 to R12 I sometimes have the connection drop mid race. I got the following message from dmesg -w

[ 3142.289418] hid-universal-pidff 0003:346E:0006.0007: output queue full
[ 3142.289422] hid-universal-pidff 0003:346E:0006.0007: output queue full

I was running a 240 Hz HID Update rate which I have now reduced to 120 Hz which might solve it.

[Lawstorant]

HID update rate? I'm not aware of any way to reduce the polling rate on Moza devices. Normally, a full output queue would mean a game is spamming the FFB too much and the device/driver/subsystem can't handle it.

Could you post some more info like your distro, kernel version, which game causes this? Maybe a little info about your system/

[writequit]

I have an R12. The only time I get that error is running Richard Burns Rally (RSF version). In the launcher you can set "Parallel FFB effects" and the update frequency. If I set it to 1000Hz I get a lot of "output queue full" errors.

Setting it at 500Hz almost completely stopped the errors but actually sometimes I get the disconnect midrace and when it happens I get that error again. I'd forgotten about the frequency adjustment so I just tried lowering that again to 400.

So far so good but at 500 it didn't happen often so will take a while to know.

I'm running updated Debian Sid. The errors when running at 1000Hz happen consistently since I installed RBR about 12 months ago.

I don't have issues in any other game and don't notice a difference between 1000Hz and 400.

[joverbeeke]

I am running a arch linux system 5700x3d, 6700xt. In the boxflat software, which is the linux version of moza pithouse the hid polling rate can be adjusted between 20 and 240 hz.

The game it happens in most is assetto corsa. Might be a content manager setting but it didnt happen with the R9

[Lawstorant]

So ummmm, yeah. I'm the author of Boxflat and that setting only changes how often Boxflat checks the position of axes to display the output. It doesn't actually change anything about the connection. I might rename it to tp better reflect what it does, or just hardcode it.

When it comes to AC. Is there any setting that would enable you to lower the FFB refresh rate? If not, you can try ffbwrap to throttle the ffb

[joverbeeke]

Could it maybe have something to do with the ffb interpolation setting? I turned that off as well and now i have had 2 hours of driving without it happening

[Lawstorant]

I tried interpolation as well and only found it weird and unnecessary. It even messes up some effects. If you don't need ot, don't use it.

And yeah, it could i troduce additional lag and proxessing time which could lead to more issues with queue.

Still, if you ever have issues again, you could try ffbrap, it's a great tool.

I think we can mark it as resolved for now as thereynothing in the driver we could do at the moment

[joverbeeke]

I have turned down the ingame ffb frequency and did turn of the ffb interpolation as well. It still happens from time to time. I will try ffbwrap. I just find it strange that it only began happening when I moved to the R12.

[JacKeTUs]

Hmm, driver (not ours, hid-core one) does this (https://github.com/torvalds/linux/blob/cabb4685d57ed50cd197498d2ac946ad5b6272e7/drivers/hid/usbhid/hid-core.c#L534)

What do you mean by "connection drop"? Is device reconnects itself? Or you mean FFB drops sometimes?

[Lawstorant]

I think the connection drops (device restarts?) might be unrelated to the output queue. I'll test BeamNG at 1000 Hz with My R9 as well

[writequit]

In my case I lose input and FFB. Restarting RBR would get it working again. I've put quite a few hours in since reducing to 400Hz in RBR and it hasn't happened again.

[JacKeTUs]

do you see any logs related to the device disconnection in the kernel?

[JacKeTUs]

May be device itself can't keep up with higher refresh rate (>400hz?) and disconnects itself? Just guessing at this point ngl

[joverbeeke]

I lose ffb and input, restarting the base most of the times gets everything working again. Only message in dmesg -w is the output full one. At this point i suspect that the base might somehow be the limitation

[writequit]

Did some more testing here.

Updated the driver to current.
Disconnected a somewhat suspect USB device.
Increased FFB rate to 1000Hz in RBR.

Result is loads of "output queue full" log spam in the order of about 1000 per minute but no disconnect and no other issues observed.

So I think my disconnect issue was caused by another USB device causing RBR to get confused and the "output queue full" messages in that case were only a symptom.

Also seems the limit for the actual base is less than 1000Hz. This is interesting as windows people are all using 1000Hz but maybe the windows driver limits it.

[Lawstorant]

I very much think so. When running wheelcheck.exe I think it avarages around 1.3 ms when set to 1ms so it's at least netween 600 - 800 hz.

Apart from queue full messages, it continued to work properly? If yes, I think we could close this issue

[JacKeTUs]

@writequit @joverbeeke , what versions of Moza wheelbases do you have? v1/v2/v3?

[Lawstorant]

V2 versions only changed the wheel connection (wireless vs pogo pins on the shaft). They are the same when it comes to firmware. Moreover, Moza does way more hw revisions. R9 actually had 6 (two v1 and four v2).

[writequit]

Not sure how to tell what version it is? Testing some more with RBR I get some queue full messages at 700Hz and none at 600Hz.

Confident my disconnects were due to a dodgy USB device.