Talk:Bluetooth Passthrough

Adapter Test Results refactoring

So, apart from small additions here and there, the adapter test results haven't received any meaningful update for some years. I have plans to at least partially address that, but before continuing, I really think we should completely drop the range column: it didn't turn out how we planned and I strongly think it has no meaningful significance for the reader (e.g. how far "Long" or "Very Long" actually is? Does it account for obstacles or other interferences?).

The audio column, on the other hand, still is relevant, but I think we should limit the allowed values to either ? (not tested), No (doesn't work or has major issues), Limited (works but has small issues on specific conditions -- e.g. multiple Wiimotes playing audio simultaneously) or Yes (works the same or better than the Wii Bluetooth module), just like the existing columns.

And finally, I would like to add a new column telling if the adapter in question is a standalone USB adapter or if it's the Bluetooth portion of a WiFi Card. Could be as simple as a "Type" column where the two allowed options are USB or PCIe. Thoughts? mbc07 (talk) 00:09, 14 December 2019 (CET)

I think those all sound like good ideas. I don't see a problem with any of that. My only idea is to label the rest of the columns with hover-over descriptions like the VID/PID have so it's obvious what the possible answers should be, to keep everything tidy. (Or a little clickable question mark/number instead, so that the hover-over descriptions can be read on mobile.) - Xerxes (talk) 21:15, 15 December 2019 (CET)

It's somewhat half-way done, ended having more columns than I expected. I was considering making another column for the chipset used and decouple that from the adapter name (currently listed under [] on the adapter name) but I think I'm crossing the line and going way too technical. Any thoughts before continuing? Any feedback on the added columns? mbc07 (talk) 21:51, 18 December 2019 (CET)

Another column isn't a big deal to add in my opinion since removing the range column and adding in the type and BT columns added up to the same width, and adding another chipset column would still be just as wide afterwards anyways. But it looks good the way it is too with the chipset in brackets, so it's really whatever you want. I think it looks really good so far. - Xerxes (talk) 00:28, 19 December 2019 (CET)

Removal of "One Remote is Stable but Four is Not" from the troubleshooting section

I've been occasionally adding new test results to the page in the past few years and that recommendation of "always use USB 3.0 ports due to bandwidth issues" just doesn't make any sense for me:

• Original Wiimotes are based on Bluetooth 2.0 spec. The theoretical maximum transfer speed of the protocol (even with EDR considered) doesn't exceed USB 1.1 speeds, let alone USB 2.0 speeds;
• Poorly shielded USB 3.0 ports are somewhat common and are known to cause interference with radios operating in the 2.4 GHz range, so it can make things potentially worse (I've personally witnessed that);
• We have various tests of M.2/PCIe Wi-Fi cards with Bluetooth and they work mostly fine; they are all physically wired to a USB 2.0 controller internally, not 3.0;
• The BT Module from a real Wii is also wired internally to a USB 2.0 controller on the console, so USB bandwidth can't be an issue.

I pinged User:MayImilae on Discord about this edit on December 24th but didn't get a response, so this past week I spent more time than I should have testing this claim with the platforms and adapters I had access and as I suspected, Bluetooth Passthrough didn't improve when using USB 3.0 ports. The adapters behaved the same, or actually worse:

• Adapters tested: Orico BTA-403, UGREEN CM390 and both versions of the Wii BT Module (J27H002 and WML-C43)
• PCs tested: both of my systems, as well as an AMD AM4-based PC (Biostar B550MX/E PRO + Ryzen 3 5300G) and another AMD AM5-based PC (MSI Pro B650M-P + Ryzen 5 8500G) I had access this past week
• Tests were conducted on Dolphin 2512-79 on Windows 11 (Windows 10 on the Haswell desktop)
• My Wii BT Modules are mounted on small DIY breadboards and don't plug directly into the USB port, they have a microUSB connector and are plugged in via cable, so they should be immune from the interference from poorly shielded USB 3.0 ports (if any), as the module will be far away from the port.

The Haswell and AM4 desktops have cheap cases and practically no shielding at the front USB 3.0 ports, all adapters except the Wii BT modules performed significantly worse (barely working audio, jittery IR pointer, occasionally missing button presses and very unstable connection with just two Wiimotes). If all other USB devices were physically unplugged (leaving only the BT adapter in a USB 3.0 port), the adapters behaved slightly better but still a tad worse. No such issues when plugged directly to USB 2.0 ports, neither from the front panel or the back panel.

On the AM5 desktop and on my Tiger Lake laptop, the USB 3.0 ports seems to have adequate shielding and the adapters performed the same as when plugged on USB 2.0 ports; I couldn't really notice any difference. Yet, in both cases, the recommendation of plugging to USB 3.0 or newer ports for better stability simply didn't come true;

Now, addressing that same recommendation that was put on the blog article when Bluetooth Passthrough originally released: that happened nearly a decade ago and it might have been true with the PC hardware available at that time, after all USB controllers are often flaky (the most recent examples I can recall were with the initial motherboards from the AM4 and AM5 launches, mostly solved with BIOS updates or revised boards); the article itself also doesn't claim they behaved better due to bandwidth, as it was worded here.

TL;DR, with the limited testing I could do with more recent hardware than at the time the article launched, the recommendation doesn't hold any water, so that's why it was dropped... - mbc07 (talk) 20:37, 1 January 2026 (CET)