search

DanielOgorchock / linux

Other
49 stars 7 forks source link

Pro Controller disconnects when connected via Bluetooth #33

Open twoxa opened 2 years ago

twoxa commented 2 years ago

When using the Pro Controller in Bluetooth mode it will randomly disconnect after some time, it might last a few minutes or a few hours (usually its a couple of minutes), it seems random. When using combined Joycons there is no issue, they work perfectly every time. When using the Pro Controller in wired mode it works normally. Tried pairing without joycond, with different Bluetooth adapters, nothing works. Logs when the controller connects:

Jan 13 20:04:55 Archer kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Jan 13 20:04:55 Archer kernel: Bluetooth: HIDP socket layer initialized
Jan 13 20:04:55 Archer bluetoothd[1386]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Jan 13 20:04:55 Archer systemd[548]: Reached target Bluetooth.
Jan 13 20:04:58 Archer kernel: hid-generic 0005:057E:2009.0006: unknown main item tag 0x0
Jan 13 20:04:58 Archer kernel: input: Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input33
Jan 13 20:04:58 Archer kernel: hid-generic 0005:057E:2009.0006: input,hidraw5: BLUETOOTH HID v0.01 Gamepad [Pro Controller] on 8c:88:2b:40:00:f1
Jan 13 20:04:58 Archer kernel: nintendo 0005:057E:2009.0006: unknown main item tag 0x0
Jan 13 20:04:58 Archer kernel: nintendo 0005:057E:2009.0006: hidraw5: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 8c:88:2b:40:00:f1
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using factory cal for left stick
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using factory cal for right stick
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using user cal for IMU
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: controller MAC = 64:B5:C6:44:80:8B
Jan 13 20:05:00 Archer kernel: input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34
Jan 13 20:05:00 Archer kernel: input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input35
Jan 13 20:05:00 Archer joycond[436]: DEVNAME=event257 ACTION=add DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34/event257
Jan 13 20:05:00 Archer joycond[436]: Creating new phys_ctlr for /dev/input/event257
Jan 13 20:05:00 Archer joycond[436]: Found Pro Controller
Jan 13 20:05:00 Archer joycond[436]: driver_name: Nintendo Switch Pro Controller
Jan 13 20:05:00 Archer joycond[436]: MAC: 64:B5:C6:44:80:8B
Jan 13 20:05:01 Archer joycond[436]: adding epoll_subscriber: fd=5
Jan 13 20:05:01 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 4 dropped IMU reports
Jan 13 20:05:01 Archer kernel: nintendo 0005:057E:2009.0006: delta=90 avg_delta=15

Logs when the controller disconnects: 

Jan 13 20:06:29 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 4 dropped IMU reports
Jan 13 20:06:29 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=14
Jan 13 20:06:33 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:33 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:36 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:36 Archer kernel: nintendo 0005:057E:2009.0006: delta=79 avg_delta=11
Jan 13 20:06:41 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:41 Archer kernel: nintendo 0005:057E:2009.0006: delta=77 avg_delta=11
Jan 13 20:06:50 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:50 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:53 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:53 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:58 Archer kernel: nintendo 0005:057E:2009.0006: timeout waiting for input report
Jan 13 20:06:58 Archer joycond[436]: Lone controller paired
Jan 13 20:06:58 Archer joycond[436]: DEVNAME=event257 ACTION=remove DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34/event257
dogtopus commented 2 years ago

What kind of Bluetooth controller are you using? Judging from the OUI I'm guessing it's one of those cheap USB dongles (probably with very short internal antenna). Could just be signal quality issue then? What does blueman say about the link quality?

twoxa commented 2 years ago

I don't think it's a signal issue because then why would the Joycons work normally (they also use Bluetooth with the same adapter), also tried it with the adapter right next to the controller still disconnects. Tried it on a different computer also running Linux with its internal Bluetooth adapter, still disconnects.

aeghn commented 2 years ago

Thank you for your efforts for this feature!

Same question here.

The pro controller with vibration will disconnect after a few minutes of connection, while it works fine on Windows (same machine) and on my NS.

The bluetooth adapter is: Intel AX200

I am using Archlinux with linux 5.16.12-arch1-1. The logs are as follows:

journalctl -u bluetooth:

Mar 05 17:12:44 chindpc bluetoothd[25826]: Adv Monitor app :1.369 disconnected from D-Bus
Mar 05 17:12:44 chindpc bluetoothd[25826]: Path / reserved for Adv Monitor app :1.370
Mar 05 17:12:44 chindpc bluetoothd[25826]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Mar 05 17:12:44 chindpc bluetoothd[25826]: Adv Monitor app :1.370 disconnected from D-Bus

btmon


> HCI Event: Disconnect Complete (0x05) plen 4         #73275 [hci0] 557.690726
        Status: Success (0x00)
        Handle: 512
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8    {0x0001} [hci0] 557.690733
        BR/EDR Address: xx:xx:xx:xx:xx:xx (Nintendo Co.,Ltd)
        Reason: Connection terminated by local host (0x02)
> HCI Event: Number of Completed Pack.. (0x13) plen 5  #73276 [hci0] 557.693726
        Num handles: 1
        Handle: 256
        Count: 1

...

< HCI Command: Disconnect (0x01|0x0006) plen 3         #73569 [hci0] 560.522601
        Handle: 512
        Reason: Authentication Failure (0x05)

...

> HCI Event: Remote Name Req Complete (0x07) plen 255  #73585 [hci0] 560.681756
        Status: Remote User Terminated Connection (0x13)
        Address: xx:xx:xx:xx:xx:xx (Nintendo Co.,Ltd)
        Name:
> HCI Event: Disconnect Complete (0x05) plen 4         #73586 [hci0] 560.682761
        Status: Success (0x00)
        Handle: 512
        Reason: Connection Terminated By Local Host (0x16)
> HCI Event: Number of Completed Pack.. (0x13) plen 5  #73587 [hci0] 560.683760
        Num handles: 1
        Handle: 256
        Count: 1

If the information provided is not enough, I will gladly continue to provide it.

nfp0 commented 2 years ago

I have tried my Pro Controllers with 5 different Bluetooth radios and they all presented the same behavior: When used with games that have rumble, they disconnect (specially if more than 1 controller is connected).

I have tried the following Bluetooth radios:

All of them are officially certified Bluetooth products, with the exception of the 1st one.

I tested by playing the N64 Super Smash Bros on RetroArch with 2 Pro Controllers and I consistently get a disconnect usually in less than 5 minutes. Sometimes in just a few seconds.

Using the controllers with rumble through Steam on Windows does not cause a disconnection. That, together with the fact that all 5 radios show the same behavior makes me believe this is not an hardware issue.

@DanielOgorchock @nicman23 I would really like to help you debug this issue. Is there any way for me to help? Any logs I can provide?

nfp0 commented 2 years ago

I forgot to mention: When using the 2 Pro controllers and a 3rd non-Nintendo controller all connected to the same Bluetooth, only the Pro controllers disconnect after a while, while the 3rd controller, keeps connected and functioning. Furthermore, the 2 Pro Controllers, usually disconnect at the same time or within a few seconds of each other.

This gives weight to the theory that there must be something wrong in the code and not in the hardware. I wish I knew how to debug this, though.

Should I also post this info on https://github.com/nicman23/dkms-hid-nintendo/issues/33 for awareness?

twoxa commented 2 years ago

It is getting weirder, now the pro controller connects and if it doesn't disconnect in the first 2 minutes then it'll work until I turn it off manually. It usually takes about 3-5 times before it connects for good (so the way I use it now is: connect wait a minute or two see if it doesn't disconnect in that time its good and i can use it for how ever long I want, if it does disconnect then try again until it stays connected for those 1-2 minutes). It works but i have to keep trying to connect until the connection "sticks", not sure if its related but, I did change some settings in /etc/bluetooth/main.conf:

FastConnectable = true
JustWorksRepairing = always
ReconnectAttempts=3
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true

Forgot to mention I am also using Arch Linux on both the machines I tested it on, so it might be an Arch specific issue.

nfp0 commented 2 years ago

@twoxa Arch user here too. Interesting finds. I'll see if I arrive at the same pattern as you.

nicman23 commented 2 years ago

@nfp0 sorry i currently do not have any switch controllers to test with. btw what is your system specs and usb controller

nfp0 commented 2 years ago

I have tested this on 3 different systems:

On my desktop I have these USB controllers:

I imagine the Intel laptop has other controllers but I can't get those right now.

The USB Bluetooth dongles tested:

The laptop integrated Bluetooth radios:

All Bluetooth certified except the cheap chinese one.

The OS is Manjaro KDE, but I also tested this on Arch. I always get the exact same problem with the same behavior, regardless of system or Bluetooth dongle: a simultaneous disconnection of all HID-Nintendo managed controllers when using rumble after a few seconds or minutes. Non-HID-Nintendo controllers remain working perfectly. That's quite a lot of different hardware this fails on, and this does not happen on Windows when using rumble through Steam.

sorry i currently do not have any switch controllers to test with

@nicman23 I would like to help. I can test with multiple controllers and easily trigger the disconnection after a few seconds. How can I provide you with information to try and fix this? Any kind of logging or debugging?

SuperSamus commented 2 years ago

~I don't know if it's just me, but it seems that games with a strong rumble intensity tend to disconnect more frequently. For example, Rocket League rumbles the controller basically all the time, but it's low intensity. I played it quite a lot of hours, and I only ever got one disconnection. Another game, Wondersong, almost never uses rumble, but when it does, it's of high intensity, and I got quite a lot of disconnections on that game (and only in the parts where there is that rumble). There is one section of the game where rumble is instead done all the time, with the same high intensity, and the controller couldn't stay connected one minute in that section.~

~Does my experience match yours?~

~EDIT: Maybe it's related: https://github.com/DanielOgorchock/joycond/issues/104.~

SuperSamus commented 2 years ago

I submitted a bug on Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216218.

nfp0 commented 2 years ago

@SuperSamus Interesting!

RetroArch allows to choose the intensity of the vibration. I'll test it at max and minimum vibration intensity and report back if there is a pattern or not.

Labaman commented 2 years ago

I have the same problem. @SuperSamus You're right, I checked with Yuzu - there you can control the intensity of vibration, as well as turn it off. In games where vibration is used often (e.g. Super Mario Oddesey) - the controller is turned off within a few minutes after the start of the game. In games where vibration is used infrequently (such as Legend Of Zelda BOTW), the controller can run for up to several hours without turning it off. If you completely disable vibration in the control settings, the controller does not turn off during the game at all. And similarly, with a wired connection, the controller does not turn off regardless of whether vibration is on or not. It's not a hardware problem - the problem is reproduced on 2 different controllers. And not a problem with bluetooth - I also have an Xbox One controller that does not turn off with vibration on.

nfp0 commented 2 years ago

@Labaman Yeah, it's certainly not a hardware problem. I've tested with 5 different bluetooth radios with 2 different Pro Controllers. Same problem happens in any of them.

Labaman commented 2 years ago

So is there any hope of improving the situation?

nfp0 commented 2 years ago

Since we can easily reproduce the bug, we could provide debug help to @nicman23, but he's been absent for a while. :disappointed:

DanielOgorchock commented 2 years ago

Does there appear to be any correlation with the strength of the rumble? Does higher rumble intensity seem to cause disconnects more frequently than light rumble events?

If so, I can try decreasing the driver's maximum amplitude. I wonder if there's a power supply brownout occurring when connected via bluetooth that doesn't occur over USB (since the controllers can draw power from USB instead of battery in the latter case)

Labaman commented 2 years ago

@DanielOgorchock I'm afraid not. Well, or the effect is insignificant. I tested on Yuzu + Super Mario Oddesey with vibration intensity 100%, 50%, 40% and 30% - the controller still disconnects. I did not notice any noticeable difference in the frequency of controller disconnects. The most interesting thing is that on Windows with the same controller on the same Bluetooth adapter - a similar problem is not observed.

nfp0 commented 2 years ago

@Labaman And is the perceived rumble intensity on Yuzu the same between Windows and Linux?

Labaman commented 2 years ago

@nfp0 yep. @DanielOgorchock It is highly unlikely that it is related to the USB power supply, with a wired connection: Did the following test: connected an external charger to the Pro Contronller - same result - controller disconnects when vibration is on.

a-priestley commented 2 years ago

I think it may also have to do with gyro. After turning rumble and haptic feedback off, it still happens. But it seems to correlate with gyro use. I really think it is the bluetooth stack though, and not hid_nintendo, because I can blacklist the module, passing the responsibility to steam, and it still occurs. Every time it does, I get:

Bluetooth: Frame is too long (len 54, expected len 51)

I think it might go deeper than steam input or hid_nintendo

nfp0 commented 2 years ago

I really think it is the bluetooth stack though, and not hid_nintendo, because I can blacklist the module, passing the responsibility to steam, and it still occurs.

Interesting... If that's the case then it should not be hid_nintendo. I'm gonna try and test the same way you did.

a-priestley commented 2 years ago

I really think it is the bluetooth stack though, and not hid_nintendo, because I can blacklist the module, passing the responsibility to steam, and it still occurs.

Interesting... If that's the case then it should not be hid_nintendo. I'm gonna try and test the same way you did.

I don't think I blacklisted the module properly. It was still being loaded with the kernel, but after (I think) solving that, rumble off + haptics off in Steam, I'm not having the issue any longer. Gyro seems to be fine. This is a really inconsistent issue though in my experience so I can't be sure about any of this.

nfp0 commented 2 years ago

Bluetooth: Frame is too long (len 54, expected len 51)

@a-priestley Where are you getting this error message? I've checked the logs from bluetooth.service but I don't see it anywhere when the controller disconnects.

a-priestley commented 2 years ago

Bluetooth: Frame is too long (len 54, expected len 51)

@a-priestley Where are you getting this error message? I've checked the logs from bluetooth.service but I don't see it anywhere when the controller disconnects.

journalctl prints it out.

nfp0 commented 2 years ago

journalctl prints it out.

@a-priestley Really? I've been using journalctl -u bluetooth.service -b after the disconnect happens and I don't see that message anywhere. Am I targeting the correct service?

a-priestley commented 2 years ago

@nfp0 well I'm not querying userland. The exact command I'm issuing is sudo journalctl -p 3 -xb You could target Bluetooth if you wanted but that set of arguments should be specific enough for it to show up unobscured

nfp0 commented 2 years ago

@a-priestley Even with that command, I don't get the error. You did not get that error while using it through Steam, did you? I've raised -p to 4 and I get these warnings instead:

kernel: nintendo 0005:057E:2009.0027: timeout waiting for input report
tlp[38355]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
tlp[38355]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
tlp[38355]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
tlp[38355]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
kernel: ata1.00: supports DRM functions and may not be fully accessible
kernel: ata1.00: supports DRM functions and may not be fully accessible
org_kde_powerdevil[11683]: QObject::disconnect: Unexpected nullptr parameter
org_kde_powerdevil[11683]: QObject::disconnect: Unexpected nullptr parameter

These are just warnings though. I wonder why I'm not getting the same error as you.

Furthermore: I re-tested this and it seems to happen even more frequently now (I can always reproduce it in under 60 seconds of use), but now the controllers don't disconnect at the same time, as they did previously. They seem to disconnect at random times, as long as rumble is enabled.

The controllers never disconnect if I completely disable rumble, which leads me to believe this is exclusively triggered by rumble and not related to gyro. But I noticed that if I have rumble enabled, but at 0% strength on RetroArch, they still disconnect, even though they don't physically vibrate. Perhaps because the rumble signals are still being sent?

SuperSamus commented 2 years ago

Maybe we could take and test some values from other drivers like BetterJoy or DS4Windows (Joy, Pro)? For example (from a quick skim), the rumble queue from BetterJoy is size 15 (as opposed to hid-nintendo's 8).

a-priestley commented 2 years ago

@nfp0 I'm not sure where the discrepency is. I am using a usb bluetooth adapter that's connected to a hub, so that might be it. I'll see if I can test out a direct I/O connection when I get home.

nfp0 commented 2 years ago

I am using a usb bluetooth adapter that's connected to a hub

@a-priestley Same here. I don't believe connecting it directly will make a difference, as I believe most Bluetooth radios connect through internal USB hubs. I might be wrong though.

nfp0 commented 2 years ago

For example (from a quick skim), the rumble queue from BetterJoy is size 15 (as opposed to hid-nintendo's 8).

@SuperSamus Not really knowing what I'm doing, I've changed the JC_RUMBLE_QUEUE_SIZE to 15 and to 4 to try and get some different behavior, but the issue still occurs more or less with the same frequency.

Should we play with some of these other rumble values, or is it pointless?

#define JC_RUMBLE_DATA_SIZE 8
#define JC_RUMBLE_QUEUE_SIZE    8

static const u16 JC_RUMBLE_DFLT_LOW_FREQ = 160;
static const u16 JC_RUMBLE_DFLT_HIGH_FREQ = 320;
static const u16 JC_RUMBLE_PERIOD_MS = 50;
static const unsigned short JC_RUMBLE_ZERO_AMP_PKT_CNT = 5;
DanielOgorchock commented 1 year ago

Sorry for the lack of responsiveness. I also feel that we need to deep dive a bit into the bluetooth stack. I've tried a lot of mitigations on the driver level, and by reducing the number of rumble control packets sent to the controller, it reduces the rate of these disconnects. However, it doesn't completely eliminate the issue as many of you have noticed.

Another thing we can try is modifying the JC_RUMBLE_DFLT_LOW_FREQ and JC_RUMBLE_DFLT_HIGH_FREQ values to see if that makes any difference (I doubt it will).

The fact that the driver works fine via USB makes me suspicious of the bluetooth stack. Maybe we can test with Android's bluetooth stack to see if it exhibits the same problem.

nfp0 commented 1 year ago

@DanielOgorchock Glad to see you back! :slightly_smiling_face: Let's see if we can tackle this problem once and for all.

I was just now testing this issue with Steam by blacklisting hid_nintendo and the controller never disconnects.

I've setup Super Smash Bros 64 on RetroArch through Steam and let the game run for 45 minutes while the computer players hammered on my character (producing lots of constant rumble) and the controller never disconnected once. I can run the test longer if you wish. If I use hid_nintendo on this same scenario (not on Steam), it usually disconnects in less than a minute.

Maybe we could take and test some values from other drivers like BetterJoy or DS4Windows (Joy, Pro)? For example (from a quick skim), the rumble queue from BetterJoy is size 15 (as opposed to hid-nintendo's 8).

I think this idea from @SuperSamus might get us somewhere. It doesn't hurt to try their values. It would also be nice if we could check what values Steam is using, but that might be harder.

a-priestley commented 1 year ago

@nfp0 Are you able to quickly walk me through the process you use for blacklisting the module? I'm on arch and I followed the steps on the wiki. I can also lsmod showing that hid_nintendo is not there. But I still get disconnects in Steam with rumble/haptics.

nfp0 commented 1 year ago

@a-priestley I also followed the instructions on Archwiki.

Basically I just added a no_hid_nintendo.conf file with a blacklist hid_nintendo line to /etc/modprobe.d/ and rebooted.

To verify that the module is really not loading, you just need to check that the controller LEDs continue to flash left and right indefinitely. You can also verify that the controller will not have any rumble support at all inside a game. After verifying that, open Steam and the controller should be detected and the LEDs will stop flashing left and right. Now the controller should rumble in games. If this is not happening, make sure you have Switch Configuration Support enabled on Settings->Controller Settings.

Please note that on that same menu, Steam has a Controller shutdown time setting to save battery on idle controllers. Make sure you set it to Never for the purpose of testing this issue. I also thought the controller was disconnecting on Steam, but that's because I left the controller sitting idle vibrating while I go do some other thing, but in the end it was just reaching that idle shutdown timer. Now it never disconnects.

EDIT: Also please make sure your controller has plenty of charge, so that a disconnection by low battery charge is not mixed up with this issue.

a-priestley commented 1 year ago

@nfp0 okay thanks for this. Yeah I did the exact same thing. I can't remember exactly what the result was but I'll have to revisit this soon. Do you use grub?

nfp0 commented 1 year ago

Do you use grub?

@a-priestley I do, yes. Why?

a-priestley commented 1 year ago

Do you use grub?

@a-priestley I do, yes. Why?

The reason I ask is because the kernel module blacklisting is likely different for each bootloader. But I've only ever used grub

nfp0 commented 1 year ago

I did not blacklist it on the bootloader's kernel parameters though. Adding the blacklist to the /etc/modprobe.d/ folder and a reboot was enough. Since the LED kept flashing left and right it was easy to confirm the blacklist worked.

EDIT: lsmod also stopped showing hid_nintendo.

DanielOgorchock commented 1 year ago 
> ACL Data RX: Handle 6 flags 0x02 dlen 54                                     #14897 [hci0] 106.898081
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e7 80 00 00 00 3f 18 79 c6 c7 74 0b 09 fb  .0.....?.y..t...
        e5 05 69 0e 78 ff 74 02 fc fe 15 fb ea 05 99 0e  ..i.x.t.........
        d2 ff 94 02 1b ff 03 fb 1d 06 cd 0d d5 ff ab 02  ................
        35 ff                                            5.              
> ACL Data RX: Handle 6 flags 0x02 dlen 54                                     #14898 [hci0] 106.928099
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e9 80 00 00 00 40 f8 78 c4 c7 74 09 24 fc  .0.....@.x..t.$.
        50 06 1c 0e cc ff 55 02 3d ff e1 fb 4c 06 26 0e  P.....U.=...L.&.
        fb ff 49 02 34 ff 66 fb 04 06 70 0e e8 ff 57 02  ..I.4.f...p...W.
        16 ff                                            ..              
< ACL Data TX: Handle 6 flags 0x00 dlen 15                                     #14899 [hci0] 106.928117
      Channel: 65 len 11 [PSM 0 mode Basic (0x00)] {chan 65535}
        a2 10 06 00 89 40 62 00 89 40 62                 .....@b..@b     
> ACL Data RX: Handle 6 flags 0x02 dlen 54                                     #14900 [hci0] 106.930598
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 eb 80 00 00 00 3d 08 79 c4 b7 74 09 21 fc  .0.....=.y..t.!.
        3d 06 78 0d 1c 00 18 02 d0 ff 29 fc 40 06 af 0d  =.x.......).@...
        ad ff 25 02 99 ff 19 fc 5b 06 e1 0d dc ff 47 02  ..%.....[.....G.
        6a ff                                            j.              
> ACL Data RX: Handle 6 flags 0x02 dlen 54                                     #14901 [hci0] 106.931956
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 ed 80 00 00 00 41 28 79 c3 b7 74 09 11 fc  .0.....A(y..t...
        21 06 38 0d f4 ff 88 01 15 00 1c fc 15 06 23 0d  !.8...........#.
        87 ff c0 01 e5 ff 2b fc 20 06 65 0d 7d ff ee 01  ......+. .e.}...
        c6 ff                                            ..              
> HCI Event: Number of Completed Packets (0x13) plen 5                         #14902 [hci0] 106.933263
        Num handles: 1
        Handle: 6
        Count: 1
> ACL Data RX: Handle 6 flags 0x02 dlen 54                                     #14903 [hci0] 106.940572
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f0 80 00 00 00 3f 18 79 c2 c7 74 0c c4 fb  .0.....?.y..t...
        34 06 e9 0c 61 ff cc 00 21 00 df fb 2a 06 fe 0c  4...a...!...*...
        9e ff 0e 01 26 00 05 fc 11 06 12 0d 9f ff 67 01  ....&.........g.
        0e 00                                            ..              
> HCI Event: Disconnect Complete (0x05) plen 4                                 #14904 [hci0] 107.108265
        Status: Success (0x00)
        Handle: 6
        Reason: LMP Response Timeout / LL Response Timeout (0x22)
@ MGMT Event: Device Disconnected (0x000c) plen 8                            {0x0001} [hci0] 107.108271
        BR/EDR Address: 98:B6:E9:B1:88:81 (Nintendo Co.,Ltd)
        Reason: Unspecified (0x00)
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1                          #14905 [hci0] 107.376059
        Scan enable: Page Scan (0x02)

Here's my btmon output when the controller disconnects during a rumble event.

The disconnect I'm seeing appears to be due to a link layer response timeout. I'll see if this is consistently the logged reason or if it differs each time.

edit: It does appear to be consistent.

< ACL Data TX: Handle 9 flags 0x00 dlen 15                                     #68455 [hci0] 495.786799
      Channel: 65 len 11 [PSM 0 mode Basic (0x00)] {chan 65535}
        a2 10 09 00 6f c0 5b 00 05 40 41                 ....o.[..@A     
> HCI Event: Number of Completed Packets (0x13) plen 5                         #68456 [hci0] 495.790912
        Num handles: 1
        Handle: 9
        Count: 1
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #68457 [hci0] 495.791737
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 ab 80 08 00 00 de 7d 99 c7 47 72 0b 69 02  .0......}..Gr.i.
        90 fe bd 10 e0 ff 21 00 cd ff 7f 02 90 fe 3a 10  ......!.......:.
        1a 00 45 00 d3 ff 76 02 b3 fe 4f 10 2c 00 29 00  ..E...v...O.,.).
        c5 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #68458 [hci0] 495.794230
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 ad 80 08 00 00 de 7d 99 c7 57 72 0b 75 02  .0......}..Wr.u.
        79 fe 01 10 91 ff 11 00 e0 ff 81 02 85 fe 17 10  y...............
        d1 ff 57 00 e8 ff 83 02 7e fe 1e 10 e8 ff 46 00  ..W.....~.....F.
        da ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #68459 [hci0] 495.824244
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 af 80 08 00 00 d7 7d 98 c6 57 72 0c a5 02  .0......}..Wr...
        94 fe 71 0f c5 ff 8d 00 14 00 8a 02 7a fe 36 10  ..q.........z.6.
        a9 ff 63 00 02 00 8c 02 77 fe 1b 10 bb ff 5f 00  ..c.....w....._.
        f7 ff                                            ..              
< ACL Data TX: Handle 9 flags 0x00 dlen 15                                     #68460 [hci0] 495.824273
      Channel: 65 len 11 [PSM 0 mode Basic (0x00)] {chan 65535}
        a2 10 0a 00 ab c0 6a 00 03 c0 40                 ......j...@     
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #68461 [hci0] 495.826762
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 b1 80 08 00 00 dc 3d 98 c6 57 72 0c 80 02  .0......=..Wr...
        6d fe 69 0f c4 ff c8 00 2d 00 77 02 6f fe e2 0f  m.i.....-.w.o...
        81 ff 60 00 13 00 88 02 6b fe 3c 10 a2 ff 77 00  ..`.....k.<...w.
        0f 00                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #68462 [hci0] 495.828104
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 b4 80 08 00 00 d5 5d 98 c8 67 72 0c 50 02  .0......]..gr.P.
        80 fe 11 10 c1 ff 7c 00 41 00 49 02 88 fe a4 0f  ......|.A.I.....
        ab ff 71 00 38 00 55 02 76 fe b1 0f 97 ff 76 00  ..q.8.U.v.....v.
        26 00                                            &.              
> HCI Event: Number of Completed Packets (0x13) plen 5                         #68463 [hci0] 495.828912
        Num handles: 1
        Handle: 9
        Count: 1
> HCI Event: Disconnect Complete (0x05) plen 4                                 #68464 [hci0] 495.990916
        Status: Success (0x00)
        Handle: 9
        Reason: LMP Response Timeout / LL Response Timeout (0x22)
@ MGMT Event: Device Disconnected (0x000c) plen 8                            {0x0001} [hci0] 495.990928
        BR/EDR Address: 98:B6:E9:B1:88:81 (Nintendo Co.,Ltd)
        Reason: Unspecified (0x00)
DanielOgorchock commented 1 year ago

When looking at the timestamp deltas between the RX packets leading up to these disconnections, it seems that they're inconsistent with the expectations.

Here's some logs from shortly before a disconnection:

> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67866 [hci0] 490.965464
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 de 80 08 00 00 34 84 b5 c7 37 72 0b b0 02  .0.....4...7r...
        fd fe 2d 10 f1 ff 75 ff e0 ff 9d 02 fd fe 2f 10  ..-...u......./.
        f4 ff 74 ff e2 ff 8d 02 0a ff 34 10 f8 ff 6f ff  ..t.......4...o.
        e5 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67867 [hci0] 490.966754
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e0 80 08 00 00 39 c5 b1 c7 57 72 0b d4 02  .0.....9...Wr...
        f4 fe 19 10 dc ff 80 ff d9 ff ce 02 f0 fe 1f 10  ................
        e0 ff 79 ff d9 ff c0 02 f6 fe 29 10 ea ff 75 ff  ..y.......)...u.
        dd ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67868 [hci0] 490.995491
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e2 80 08 00 00 8d 46 b1 c6 47 72 0b e5 02  .0......F..Gr...
        f9 fe fc 0f cc ff a0 ff d4 ff e4 02 fb fe 02 10  ................
        cd ff 97 ff d4 ff dc 02 f5 fe 0f 10 d4 ff 87 ff  ................
        d6 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67869 [hci0] 490.997980
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e4 80 08 00 00 5a 57 ad c6 37 72 0b dc 02  .0.....ZW..7r...
        e8 fe d4 0f c1 ff cd ff e0 ff df 02 e8 fe df 0f  ................
        c3 ff c0 ff db ff e8 02 f0 fe ee 0f c6 ff ae ff  ................
        d6 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67870 [hci0] 491.000473
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e7 80 08 00 00 26 b8 a9 c5 57 72 0b ec 02  .0.....&...Wr...
        d8 fe ac 0f b9 ff 08 00 e4 ff e6 02 e2 fe b4 0f  ................
        b9 ff f3 ff e2 ff db 02 e8 fe c8 0f bd ff d8 ff  ................
        df ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67871 [hci0] 491.027984
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 e9 80 08 00 00 1b b9 a9 c6 57 72 0b fc 02  .0.........Wr...
        dd fe 99 0f b4 ff 50 00 dd ff f7 02 d8 fe 9a 0f  ......P.........
        b4 ff 3d 00 df ff f0 02 d5 fe a3 0f b7 ff 1a 00  ..=.............
        e1 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67872 [hci0] 491.032972
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 eb 80 08 00 00 af f9 a8 c6 57 72 0b e4 02  .0.........Wr...
        e4 fe 98 0f bc ff 8d 00 d4 ff ee 02 e8 fe 96 0f  ................
        b8 ff 81 00 d5 ff f9 02 e4 fe 98 0f b5 ff 66 00  ..............f.
        d9 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67873 [hci0] 491.034231
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 ed 80 08 00 00 29 fa a7 c4 47 72 0b c4 02  .0.....)...Gr...
        e4 fe ad 0f c5 ff a9 00 c9 ff c8 02 e0 fe a5 0f  ................
        c1 ff a6 00 cb ff d4 02 e0 fe 9b 0f bd ff 99 00  ................
        d0 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67874 [hci0] 491.063000
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f0 80 08 00 00 49 cb a1 c6 47 72 0b b8 02  .0.....I...Gr...
        d0 fe d5 0f c0 ff 98 00 c5 ff b9 02 d7 fe cb 0f  ................
        c2 ff 9e 00 c3 ff b9 02 e0 fe ba 0f c4 ff a7 00  ................
        c6 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67875 [hci0] 491.065488
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f2 80 08 00 00 8c 3c a1 c7 17 72 0b 90 02  .0......<...r...
        88 fe f8 0f a4 ff 64 00 cc ff 9c 02 9c fe e7 0f  ......d.........
        ae ff 76 00 c7 ff b1 02 c2 fe d9 0f b8 ff 8d 00  ..v.............
        c5 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67876 [hci0] 491.067973
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f4 80 08 00 00 ae dd 9e c6 47 72 0b bd 02  .0.........Gr...
        dc fd f5 0f 98 ff 4d 00 c9 ff 98 02 29 fe f1 0f  ......M.....)...
        97 ff 3e 00 d5 ff 89 02 81 fe 06 10 9e ff 52 00  ..>...........R.
        d0 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67877 [hci0] 491.095491
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f6 80 88 00 00 c4 ad 9d c5 67 72 0b 44 02  .0.........gr.D.
        35 fe dd 10 a5 ff 14 00 f1 ff 27 03 fe fd c2 10  5.........'.....
        a9 ff 3f 00 e0 ff e3 02 ce fd 3f 10 9d ff 54 00  ..?.......?...T.
        c3 ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67878 [hci0] 491.100481
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f9 80 88 00 00 c0 4d 9d c7 47 72 0b 85 01  .0......M..Gr...
        20 fe 6d 10 e0 ff f1 00 d1 ff d9 01 0c fe 16 10   .m.............
        e6 ff d2 00 d2 ff 24 02 4e fe 3f 10 be ff 5f 00  ......$.N.?..._.
        ce ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67879 [hci0] 491.101740
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 fb 80 88 00 00 d4 3d 9a c4 47 72 0b c8 01  .0......=..Gr...
        59 fe cd 10 91 ff 51 01 ec ff 90 01 4b fe b9 10  Y.....Q.....K...
        a0 ff 2a 01 de ff 6c 01 32 fe 9d 10 c1 ff fe 00  ..*...l.2.......
        cf ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67880 [hci0] 491.130517
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 fd 80 88 00 00 de fd 97 c6 47 72 0b 14 02  .0.........Gr...
        94 fe e9 10 39 ff 50 01 29 00 01 02 89 fe f4 10  ....9.P.).......
        50 ff 5e 01 1b 00 e2 01 6b fe e1 10 7f ff 62 01  P.^.....k.....b.
        fd ff                                            ..              
> ACL Data RX: Handle 9 flags 0x02 dlen 54                                     #67881 [hci0] 491.132986
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 ff 80 88 00 00 d9 0d 94 c5 47 72 0b 5c 02  .0.........Gr.\.
        c9 fe 95 10 19 ff 05 01 71 00 45 02 b9 fe a2 10  ........q.E.....
        1b ff 1a 01 5c 00 29 02 9d fe c7 10 29 ff 3d 01  ....\.).....).=.
        3b 00                                            ;.

The input reports are expected to arrive every 15ms from the pro controller. In the logs above, the deltas are sporadic (e.g. 28ms, 2ms, etc.). I'm not sure if this is a scheduling issue on the controller's fw or if its something being introduced at the BLE layer.

Compare to when the controller is operating nominally:

> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #471 [hci0] 7.888166
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 ef 80 00 00 00 1d 28 7d c7 47 73 09 1e ff  .0......(}.Gs...
        d7 fd 37 10 ef ff 0d 00 09 00 1b ff d9 fd 39 10  ..7...........9.
        ef ff 0c 00 0a 00 1b ff dd fd 39 10 ee ff 0b 00  ..........9.....
        0b 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #472 [hci0] 7.903165
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f2 80 00 00 00 1c 18 7d c5 67 73 09 1d ff  .0.......}.gs...
        cd fd 36 10 ed ff 0e 00 09 00 1e ff d0 fd 38 10  ..6...........8.
        ec ff 0d 00 09 00 1c ff d3 fd 36 10 ed ff 0e 00  ..........6.....
        09 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #473 [hci0] 7.919401
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f5 80 00 00 00 1d 28 7d c5 67 73 09 1d ff  .0......(}.gs...
        c6 fd 3a 10 eb ff 0e 00 09 00 19 ff c6 fd 39 10  ..:...........9.
        ea ff 0e 00 0a 00 1d ff c9 fd 38 10 eb ff 0f 00  ..........8.....
        0a 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #474 [hci0] 7.933173
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 f8 80 00 00 00 1c 18 7d c5 57 73 09 1a ff  .0.......}.Ws...
        c1 fd 37 10 ed ff 10 00 0c 00 1d ff c3 fd 39 10  ..7...........9.
        ed ff 0f 00 0c 00 1e ff c6 fd 39 10 ea ff 0e 00  ..........9.....
        0a 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #475 [hci0] 7.948164
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 fb 80 00 00 00 1c 18 7d c3 57 73 09 13 ff  .0.......}.Ws...
        bb fd 3a 10 f2 ff 0b 00 0d 00 16 ff b7 fd 38 10  ..:...........8.
        f0 ff 0f 00 0d 00 16 ff be fd 39 10 ee ff 10 00  ..........9.....
        0b 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #476 [hci0] 7.963175
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 fe 80 00 00 00 1c 18 7d c7 47 73 09 17 ff  .0.......}.Gs...
        cf fd 3b 10 f4 ff 0d 00 0c 00 17 ff c9 fd 3d 10  ..;...........=.
        f5 ff 0d 00 0b 00 14 ff c2 fd 3d 10 f4 ff 0c 00  ..........=.....
        0b 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #477 [hci0] 7.978173
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 01 80 00 00 00 1c 28 7d c5 37 73 09 17 ff  .0......(}.7s...
        d2 fd 35 10 f0 ff 0a 00 0d 00 19 ff d4 fd 36 10  ..5...........6.
        f1 ff 0c 00 0c 00 19 ff d1 fd 3a 10 f3 ff 0d 00  ..........:.....
        0d 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #478 [hci0] 7.993166
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 04 80 00 00 00 1b 18 7d c4 67 73 09 1a ff  .0.......}.gs...
        d6 fd 36 10 f0 ff 0a 00 0d 00 17 ff d2 fd 35 10  ..6...........5.
        f0 ff 0b 00 0c 00 18 ff d0 fd 35 10 f0 ff 0a 00  ..........5.....
        0d 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #479 [hci0] 8.008165
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 07 80 00 00 00 1c 18 7d c3 47 73 09 15 ff  .0.......}.Gs...
        d7 fd 3c 10 f3 ff 0d 00 0f 00 18 ff d8 fd 39 10  ..<...........9.
        f2 ff 0e 00 0e 00 1a ff d6 fd 36 10 f1 ff 0c 00  ..........6.....
        0c 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #480 [hci0] 8.023166
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 0a 80 00 00 00 1d 28 7d c4 57 73 09 14 ff  .0......(}.Ws...
        d5 fd 3d 10 f8 ff 10 00 0f 00 14 ff d6 fd 3c 10  ..=...........<.
        f7 ff 0f 00 0f 00 14 ff d7 fd 3c 10 f4 ff 0e 00  ..........<.....
        0e 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #481 [hci0] 8.038173
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 0d 80 00 00 00 1c 28 7d c7 47 73 09 13 ff  .0......(}.Gs...
        d1 fd 40 10 f9 ff 0b 00 0e 00 12 ff d2 fd 40 10  ..@...........@.
        fa ff 0d 00 0e 00 15 ff d6 fd 3e 10 f9 ff 0f 00  ..........>.....
        0e 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #482 [hci0] 8.053174
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 10 80 00 00 00 1b 08 7d c5 57 73 09 17 ff  .0.......}.Ws...
        d5 fd 3b 10 f6 ff 09 00 0e 00 15 ff d5 fd 3c 10  ..;...........<.
        f8 ff 09 00 0e 00 14 ff d3 fd 3f 10 f9 ff 0a 00  ..........?.....
        0d 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #483 [hci0] 8.068165
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 13 80 00 00 00 1d 28 7d c6 57 73 09 20 ff  .0......(}.Ws. .
        dd fd 3b 10 f4 ff 09 00 0d 00 1f ff da fd 39 10  ..;...........9.
        f4 ff 0a 00 0f 00 1b ff d9 fd 3a 10 f4 ff 09 00  ..........:.....
        0f 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #484 [hci0] 8.083166
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 16 80 00 00 00 1c 18 7d c5 57 73 09 24 ff  .0.......}.Ws.$.
        e2 fd 3a 10 f1 ff 0f 00 0f 00 24 ff e1 fd 3a 10  ..:.......$...:.
        f2 ff 0c 00 0f 00 23 ff df fd 3b 10 f2 ff 0b 00  ......#...;.....
        0e 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #485 [hci0] 8.098173
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 19 80 00 00 00 1c 28 7d c5 47 73 09 1f ff  .0......(}.Gs...
        df fd 3d 10 f5 ff 0d 00 11 00 1f ff e0 fd 3a 10  ..=...........:.
        f4 ff 0e 00 0f 00 20 ff e3 fd 38 10 f2 ff 0f 00  ...... ...8.....
        10 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #486 [hci0] 8.113174
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 1c 80 00 00 00 1d 38 7d c7 57 73 09 1a ff  .0......8}.Ws...
        e5 fd 41 10 f8 ff 0c 00 12 00 19 ff e1 fd 42 10  ..A...........B.
        f8 ff 0d 00 10 00 1c ff e1 fd 40 10 f7 ff 0d 00  ..........@.....
        11 00                                            ..              
> ACL Data RX: Handle 10 flags 0x02 dlen 54                                                                                                                                                   #487 [hci0] 8.128173
      Channel: 65 len 50 [PSM 0 mode Basic (0x00)] {chan 65535}
        a1 30 1f 80 00 00 00 1e 28 7d c6 67 73 09 1d ff  .0......(}.gs...
        e3 fd 40 10 f8 ff 0c 00 11 00 1f ff e1 fd 40 10  ..@...........@.
        f7 ff 0c 00 10 00 1b ff e4 fd 41 10 f9 ff 0b 00  ..........A.....
        11 00

The RX timestamps above are far closer to 15ms apart.

nfp0 commented 1 year ago

@DanielOgorchock I believe you forgot to post the timestamps in your last log, or am I looking at the wrong place?

DanielOgorchock commented 1 year ago

@DanielOgorchock I believe you forgot to post the timestamps in your last log, or am I looking at the wrong place?

It seems to have been pasted funny. They're there, but you have to scroll far to the right.

Soul-Miku commented 1 year ago

very good and I hope you have solved your problem but a question out of curiosity, I see that you mention that you have the TP-Link UB500 Adapter and that adapter is a Bluetooth V5.0 the problem that I have and well it already seems to be known is that it seems that the Joycons and the Pro Controller do not work with Bluetooth V5.0 adapters, for example they connect me the first time, but if I turn off the Joycons/Pro Controller or the pc they no longer pair again and the only way is to desynchronize and synchronize and so on yes I turn off the PC, I have to repeat the same procedure, it does not happen to me with Bluetooth V4.0 adapters but I want to use V5.0 since there is no Input Lag in the joycon and I feel the connection is much more stable but with the detail that it is not They pair again unless I repeat the procedure, I would like to know in your case, when the control was disconnected with the TP-Link UB50, did you synchronize immediately with a single button or did you have to repeat the synchronization procedure?

nfp0 commented 1 year ago

@DanielOgorchock Indeed, I've checked your values and there's a clear discrepancy between the deltas on the two situations.

During normal operation:

Timestamp ms since last timestamp
7.888166  
7.903165 14.9990000000004
7.919401 16.2359999999993
7.933173 13.7720000000003
7.948164 14.9910000000002
7.963175 15.0109999999994
7.978173 14.9980000000003
7.993166 14.9930000000005
8.008165 14.9989999999995
8.023166 15.0009999999998
8.038173 15.0070000000007
8.053174 15.0009999999998
8.068165 14.9910000000002
8.083166 15.0009999999998
8.098173 15.0069999999989
8.113174 15.0010000000016
8.128173 14.9989999999995
Shortly before disconnection: Timestamp ms since last timestamp
490.965464  
490.966754 1.28999999998314
490.995491 28.7370000000351
490.99798 2.48899999996866
491.000473 2.4930000000154
491.027984 27.5110000000041
491.032972 4.98799999996891
491.034231 1.25900000000456
491.063 28.7690000000111
491.065488 2.48800000002802
491.067973 2.48499999997875
491.095491 27.5179999999864
491.100481 4.9900000000207
491.10174 1.25900000000456
491.130517 28.776999999991
491.132986 2.46900000001915

These seem extremely irregular. So, what does this tells us? Do we have a path forward, or is this external to hid_nintendo?

@Soul-Miku I also have the TP-Link UB500 Adapter and I remember having the same issue as you, but not consistently. Sometimes it connects afterwards, and other times it doesn't. I have not found a pattern and I'm not sure if it's specific to Nintendo controllers or if other devices are also affected. Regardless, that's a completely separate issue from this one.

DanielOgorchock commented 1 year ago

@DanielOgorchock Indeed, I've checked your values and there's a clear discrepancy between the deltas on the two situations.

These seem extremely irregular. So, what does this tells us? Do we have a path forward, or is this external to hid_nintendo?

I have been experimenting with approaches to detecting these sporadic timestamp states in the driver. I tried disabling rumble packets during those times with mixed success.

I will continue experimenting to see if there's a good recovery mechanism (maybe toggling rumble support on and off or something like that)

It's still not clear to me why steam's user space driver doesn't run into this issue.

nfp0 commented 1 year ago

It's still not clear to me why steam's user space driver doesn't run into this issue.

@DanielOgorchock Is it possible to capture and observe how packets with rumble info are sent to the Pro Controller from Steam and check for differences?

Soul-Miku commented 1 year ago

@nfp0 yes, I know, just out of curiosity, I just wanted to see if someone solved it, the problem is not the adapters and it seems to be more a problem with the nintendo controllers than with the bluetooth 5.0 adapters since I can pair my 2 ps4 controllers that are controls from 9 years ago and my headphones without any problem, I have seen that the problem has been out for almost 2 years since bluetooth 5.0 came out and it is already a thing of nintendo that they do not want to update the firmware of their Joycons and Pro controller because if they want they do it seems that They just don't like it and you have to wait, because most likely if Nintendo releases a new console in the future, that console should come with Bluetooth 5.0 or higher and also, most likely, both Joycon and Pro controllers will be compatible with the new console. that comes out and the person is not going to be very happy that those controls do not work, so in the future Nintendo will have to release an update for their controllers and so that they can support Bluetooth 5.0

Soul-Miku commented 1 year ago

since I have tried to find a solution in almost all the forums and looking for an answer in searches of up to 2 years but it seems that there is still no way for it to work with bluetooth 5.0, the only "Solution" to solve your problems if that is what it can be called is to use bluetooth 4.0 adapters believe me if so not because my Joycons work perfectly and no input lag with bluetooth 5.0 I would still use bluetooth 4.0 but as always nintendo making "quality" products xD