Xbox Controller Bluetooth Disconnect/Failure Issues

"Remember on the pi3 everything goes through a single USB port including the networking."

 I did not know that and it makes sense - that it is all connected via USB.

So while my actual network has adequate capacity and no interference -- being a VLAN, it could very well be a capacity issue on the "port" on the pi.

I'll have to check what you suggested.

Do you know if the later pi revisions have the same bottlenecking issue - do they also connect via a single port or perhaps might have bandwidth.

I tried the Bluetooth adaptor on another system - much more powerful than the Pi, and had the same issue.

I've ordered a new one - 6.0 spec this time, so I'll see if changing the adaptor makes a difference.

Depsite the new Bluetooth module on the way.

I did a bit more testing.

I watched htop [pi] and performance [windows] and looked at the network traffic up to, during and after the issue. For the most part traffic just drops yet if I move the mouse etc. that works fine so the connection is still there.

I then tested with Airpods connected to the module listening to the sound from the game -- music etc., and it never stopped or hissed/crackled etc. so this then also suggests the connection to the system is not stopping either.

Once I get the other dongle I will be able to see if that makes a difference -- it could end up being interference maybe.

I got the new dongle and had the same issue.

It seems to be something then with VirtualHere maybe -- is there a way to enable verbose logging in Windows and on Linux?

I only got a chance to look at this again over the weekend.

Going on from comments from Michael and stumbling on the answer via ChatGPT, I reckon I found the fix.

For me it was a two device issue:

• At the sender side - my gaming PC, that had the VirtualHere on a seperate VLAN via a USB Ethernet adaptor.
• The port speed or max transmit speed on the Raspberri PI side.

This is where the clue was ...

It almost sounds like its a network bandwidth and/or CPU starvation issue.

Remember on the pi3 everything goes through a single USB port including the networking.

It is that but more specifically it is that at times there could be too much burst traffic from the sending system and because "USB" protcol or signaling expect a steady stream of data -- not like what a network connection can send, it overwhelms the USB2 system.

So bascially, there is too much coming in at once for the USB stack to handle and it gets confused, but it only applys to non-buffer type traffic. So media/music etc. is fine with USB-over-IP as the stream often runs with X amount of buffer. It is real-time input that goes haywire and more so HID devices like controllers as they have tight timing.

So after a bit of eductation from ChatGPT you can fix this by actually forcing a maximum transmit size/speed on a USB2 stack (or one that shares bandwidth) -- on the recieving device. There are various ways to accomplish this from shaping the egress traffic on a (managed) switch port -- I did consider doing this, but ended up with the following command on Debian.

sudo tc qdisc add dev eth0 root handle 1: tbf rate 60mbit burst 32kbit latency 5ms

The key being limiting the network interface to 60Mbps and enforcing a cut off of 5ms of a buffer. Anything that saturates the connection over 60Mbps gets stalled, everything before it gets through and the idea is if there is a burst it won't send the stack/CPU nuts. That command is not persistent so you would have to script it for boot time.

That in itself was likely the fix, in fact after the many, many queries and scenerios I put to ChatGPT about that it was very adamant that it would resolve the issue.

But... there is more.

USB Ethernet Adaptors are heavily reliant on the CPU on the system they are plugged into and are NOT low latency/low jitter devices -- this is purely due to how they work.

• USB bus scheduling
• USB interrupt coalescing
• USB dispatcher jitter
• CPU overhead

So, despite the above fix likely resolving the issue, I then went and combined my VLANs into the one on-motherboard 2.5Gbps ethernet connection. 

Again, I was sceptical about this being a better solution for low latency/low jitter -- as why wouldn't a seperate connection be better for that specific traffic. ChatGPT -- after much interrogation, once again corrected me and explained that the switch will manage the VLAN traffic and will adequately allocate time for each VLAN and there is then effectively no congestion or jitter (due to the full duplex nature of the connection).

The added benifit then of getting rid of the USB Adaptor is further reducing jitter for VirtualHere -- a win win.

In my case I can add a Thunderbolt 4 card to my PC and that would be orders better than plain USB adaptors -- using Intel based Thunderbolt 4 adaptors instead, and in fact would be better (not night and day) than the onboard Ethernet - lower latency and jitter; I may end up doing this anyway but for now it is fine.

Aside:

It would be worth noting that Michael is also bang on about the Pi3, where if I had a Pi 4 or 5 I probably would not have had this issue anyway -- I would also not have found out about plain USB Ethernet adaptors being higher latency/jitter.