Irregular Disconnect-Reconnect issue when using cable
Has there been a recent update where some standard for what is acceptable behavior in USBs was raised, or something similar? Meaning could what may have previously caused brief lagspikes now cause disruptive disconnects and closes pc link? Or am I without luck and need a new cable or port? I don't have spare cables or ports to test...
Since a few weeks ago I've been experiencing disconnects and reconnects ranging from every few minutes to stability periods of hours. I can usually reconnect immediately, but sometimes need to replug. It often crashes games and settings so is very disruptive. The cable is a third party cable sold with the Quest 3 from an official vendor and worked and tested perfectly for almost a year (when other updates didn't mess up link).
It happens even when PC-link isn't launched yet but the app recognizes the device is connected, and the headset is stationary for a long time in stand-by mode, only connected by cable. The issue is unaffected by greatly lowered display and bitrate settings in PC-link use. Disconnection sounds still happen when I'm leaving it connected as normal but Airlink is active, but here slow charging notifications occur (which may be normal because my PC USB-C port isn't rated to fully keep up with the Quest 3 charging, but this hasn't caused a problem before). Using this cable in a wall socket works fine without any disruptions and keeps the battery stable.
I did a lot of standard hardware/software troubleshooting/reinstalling and made a support ticket already. There is no apparent damage to the cable or either port. Cleaning, slight pulling on the cable or wiggling and reseating the connectors or other movement on either side does not affect the disruption frequency.
Oculus Service Logs shows notable errors at the time of disconnection:
{!ERROR!} [xrstreaming] [V2] WinUsb_ReadPipe(handle:0x000001B94DBADD10, ep:129, len:1024) failed: (31) A device attached to the system is not functioning.
{!ERROR!} [Kernel:Error] OVR Error:
Code: -6102 -- ovrError_XRStreamingUSBIssue
About half a second later (but I remember the widespread user reports of false positives of water damage):
{INFO} [HardwareSDKRelay] HMD [...] got health event with error code -4503: Flaky cable
But soon after also these:
{INFO} [HardwareSDKRelay] HMD [...] got attached event with error code 0:
{INFO} [HardwareSDKRelay] HMD [...] got health event with error code 0:
Windows Event Log didn't show USB disconnections in these disruptions unless I unplug it physically (but does always play the disconnect and reconnect sound)...
Solution: It is very likely a hardware issue with the cable itself after all, something to do with the signal-integrity. There has been a small bend somewhere in the cable for most of its lifetime so I didn't think anything of it, but it must be the culprit.
For anyone else having similar link cable problems in the future but no spare parts:
The USB 2.0 white charging cable can apparently start PClink and stream at fine encoding speeds, so it may be used to do some troubleshooting for the ports and rule out some software issues. But if there is an issue with only the USB 3.0 pins on the ports, this won't find it. The white cable had no disconnections in the hour I left it on. Everything would work fine despite the no-USB 3.0 warning. Please correct me if it is a bad idea to use this cable for PClink hardware testing if you suspect the other cable is broken. If PClink doesn't work then try opening the Quest's MTP storage.
Then, as I couldn't find another USB 3.0 device, I tested the link cable on a USB 2.0 audio device, and short clipping sounds appeared every few seconds. Using the white charging cable on this device, no such clipping sounds were there, so I think it's conclusive this is a cable fault. If there is an issue with only the USB 3.0 wires in the cable, this won't find it either, but I think it proved useful in detecting issues with shielding or integrity of the cable.
I hope Meta can upgrade the USB Test software in Link to give more accurate errors, because it kept saying there were no issues when tested (unless timed right on the rare disconnects, but even then it's vague), even though it was obvious when using it on an audio device. The only other indicator was the bandwidth that had also dropped by a few hundred mbps compared to testing I remember long ago.
