Support for SwitchOS 12 #18
Comments
|
I tried with already known mac address but it didn't work. I stripped bluetoothd with
and uninstalled some packages:
but I still have 3 UUIDs left: I think we should have no default UUIDs like a common controller: |
|
Here is a debug log: |
|
Thanks for putting in work on this @ggzengel. You're close on the profile-side of things with what we need to do. I've ended up spending the better part of the last few days debugging/testing the new update and I think I've managed to get a preliminary v12 compliant version of NXBT working again. From my findings, a fair amount has changed since the previous update. Most of the changes are encountered during the initial connection to the Switch and few others pertain to communication frequency changes. I'll list out my findings below: Connection Changes
Communication Changes
Changes to NXBTThe following changes apply to the v12_fix branch on the repo:
Ideally, I would like to eliminate the use of further CLIs within NXBT, so if anyone has any ideas on replicating the functionality/use-cases of hciconfig/hcitool/sdptool within NXBT, let me know! If anyone's willing to help test/debug things, you can try out the SwitchOS v12 compliant version of NXBT by cloning/installing the v12_fix branch or with the following command(s): Updated September 7 5:55 PM PST # If you have a previous version of NXBT
sudo pip3 uninstall nxbt
# Install the v12 compliant version with the following
sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@b48b030b5e8c92666ed446be5c01a8ee2ec93c6fThanks again for everyone's interest in this project! |
|
@ggzengel Thanks for pointing that out. I've swapped in use of hcitool with the latest commit on the v12_fix branch. Funny enough, I was actually using bdaddr with an RPi4. I must have been using a patched version. Anyways, I think hcitool is the better bet going forward since it seems more hardware agnostic. @dentedghost Thanks ;) I'll try to run some frequency tests soon to check what the relative "speed limits" are on the Switch now. I'm thinking that the |
|
For the speed limit, you probably need to wait for one of the x30/x31/x32/x33 commands which switch the official controllers into high frequency (60Hz) push. Additionally, since the limit is 120, you should be scheduling at significantly below that as a safety margin. |
|
This is my first time trying to be helpful in any project, so I don't really know if this is useful or not, hope it is, if it's not I will gladly delete the post. I tried running the demo using It doesn't do or print anything else. I did run bluetoothctl on the background and got this: I had to turn off and on Bluetooth in order to pair. On the Switch nothing happened. Never got the controller to appear on the Change Grip/Order screen. So I Ctrl + C the demo and tried using nxbt tui while it was still paired. Using |
this is happening for me too |
|
@riking Excellent point. I double checked and the emulated controller is still being sent the x30 command. The original jump to 60/120Hz in the emulation server (before the v12 update) didn't happen until a few commands after this. I ran a quick test where I reconnected within a game where the full refresh should be allowed, however, I'm still seeing disconnections above anything over 18Hz. I wonder if this is something to do with packet timing (eg the timing byte, time received, time between, etc) rather than a speed limit? I would still (ideally) like to run the frequency test to see what the authentic controllers are doing since I have a hunch they may still be functioning at the full frequency on the menus. Another thought: maybe the transition to 60/120Hz must happen immediately after the x30 command is sent now? If the frequency transition doesn't happen immediately afterwards, maybe this disallows future frequency increases? @donelwero @S1monuwu From reading over the debug log, it looks like you're using an old version of NXBT. I'm not seeing the class getting set to the gamepad class (0x2508) and the |
|
I am using joycontrol on Linux + python to send bluetooth commands to auto play some nintendo games. My question: me switching to NXBT, can I call connect/reconnect, press and keep button pressed, release button etc from within my python script ? Something similar to JoyControl ? |
You should be able to do similar things, but from what I understood it doesn't looked like NXBT works with 12.0.0 either |
After installing.. I ran the demo and its stuck |
|
Been running the V12 Fix Branch for the past 48 hours on Raspberry Pi 4b 4gb, with Ubuntu 20.04.2 LTS with pi-bluetooth/bluez and am able to run Demo and Webapp with Switch running v12 firmware. Initial connection can take a while after 'create controller' function is initiated from webapp. Sometimes network adapter get's hung up but rebooting the pi seems to resolve any locks. For the most part the V12 fix appears to be working. |
|
@Willsie-Digital could you be a little more specific? Where are the network adapter hangups, and are you on the switch change grip menu or somewhere else? Can you run macros? |
|
Thank you ! I posted my findings here : Poohl/joycontrol#3 (comment) My main interest is in getting amiibos writing back to work to play Zelda ;) And there seems to be changes on the way it works too. |
|
Just to add to the knowledge base: I was able to get nxbt working (the v12 fix branch linked in this post) in an Xubuntu virtual machine on Windows (set up according to the VM portion of the instructions here), on firmware v12.0.0, with the ZEXMTE Bluetooth dongle. I've put together a complete set of instructions here: https://github.com/Venryx/switch-resources/blob/master/NXBT.md However, the "Pro Controller" that nxbt creates for the Switch, has some connection limitations:
If I only connect one joycon alongside the fake-controller, the connection is stable. (at least as far as I tested; I played a full match of Smash Bros Ultimate, and did multiple shorter tests after that, each without issue) If I connect two joycons, the fake-controller disconnects as soon as I leave the change-grip-order page. Any ideas on why the fake-controller would be stable with only one joycon connected, but unstable with two connected? Some additional notes:
|
|
I had modest success using the v12 branch on a raspberry pi with Raspbian and later Ubuntu 20.10. |
|
Was the v12 branch tested with firmware version 12.0.1 already? I tested with 12.0.0 and it worked but someone reported that it's not working with 12.0.1. |
|
I have it running with v12 branch on 12.0.0. Not brave enough to try 12.0.1 yet. |
|
Yes, v12 branch of NXBT worked fine for me on 12.0.1. (though note that I only did a brief test so far, so maybe wait till I do longer tests, if you're worried) |
|
Confirmed, it works for me on 12.0.1 as well. |
|
I did a longer test (about an hour and a half, playing Smash Bros Ultimate), and had no disconnects. For NXBT users, 12.0.1 appears safe to update to. (I don't know about JoyCon Droid, joycontrol, etc., as I'm not using those. I know that at least one JoyCon Droid user said it broke the real-left-joycon, fake-right-joycon approach that they'd been using fine on v12.0.0; I'm guessing this is an Android-specific issue though, not applying to NXBT and joycontrol.) |
|
@Brikwerk i see some unnecessary changes in your v12fix. it is enough to change the device class. you don't need to remove sdp records or changing the mac address. i tested it on my android phone with a patched libbluetooth.so with switch fw 12.0.0 (need to test it with fw 12.0.1 though). EDIT: Can you tell me how you got the device class for the pro controller? i need the device classes for joycon left/right too and running |
|
@dtrunk90 Thanks for double checking that. It does seem to be the case from some preliminary testing on my end as well. I think the device class was the last thing I fixed/changed and didn't catch that in my A/B testing due to the occasional weird connection refusals the Switch would sometimes fall into. I pushed these changes into a new patch on the branch. I do my debugging from a Mac using the Bluetooth explorer utility. It lists all stats (including device class) through a device inquiry service it provides. Joy-Cons have the same device class as the Pro Controller (0x2508) from a quick check. From my testing, the 12.0.1 update seems to improve the stability of the Bluetooth on the Switch. I don't seem to be encountering the random refusal to connect that seemed characteristic of the 12.0.0 update. For those noting disconnections after the Change Grip/Order Menu, please keep in mind that this is an acknowledged bug that I'm still working on. NXBT operates at a 15Hz frequency at the moment to mitigate this issue, however, this is more of a temporary fix. I'm finding that a lower frequency when exiting the Change Grip/Order menu seems to translate to lower disconnect rates. As an additional update on my part, I've found some success in restoring the original 60Hz frequency when reconnecting and exiting the Change Grip/Order menu, however, this still needs some research/work. It seems that by throwing out an occasional "slow" packet (eg: at 15Hz or lower) the Switch doesn't mind accepting a bunch of "fast" packets (60Hz or higher even). |
|
@Brikwerk Thanks for the device class information but I guess it's a different device class because my android device is always recognized as a pro controller as I can see the pro controller symbol when paired instead of a joycon symbol. |
|
Another quick update for those unable to connect with an adapter that worked in the past: If you previously had paired/used either Joycontrol or NXBT on a version prior to SwitchOS v12, you should delete the Bluetooth pairing with the Switch before trying to emulate a controller. This can be done through the respective Bluetooth GUI provided by your distro or through the bluetoothctl CLI (use the I had the chance to run through testing use of only setting the device class on a few different adapters I have. Some adapters that had paired previously with the Switch (and retained the link keys) fell into the connect/disconnect loop. After deleting the pairing profile, they happily connected to the Switch. |
|
Thanks for the info @Brikwerk! On my side, I received my second Magic-NS adapter today, and tried connecting a second Xbox controller (alongside the NXBT simulated controller, the existing Magic-NS/Xbox controller, and the 1 joycon); it worked! I can now use NXBT alongside three physical controllers, which is really nice. It looks like you could also just keep adding more Magic-NS adapters, as the USB-based controllers don't seem to "count toward the limit" of the issue hit with bluetooth-based simulated controllers. Since the Switch has three USB ports, this gives a maximum of five players (1 NXBT, 1 joycon, and 3 Magic-NS/Xbox/PS/etc. controllers). [it's possible you could add even more actually, if USB splitters/hubs work for the Switch) Of course, it's ideal if a way is found to have the NXBT simulated controller not disconnect when more than 1 joycon is connected; but in the meantime, using Magic-NS adapters to fill the gap works fine. |
|
Hey, So let me share my experiences with you. While i was testing nxbt and playing around i noticed the following things:
Hope that information is helpful |
|
Hi! bluetoothctl says as follows. Do you have any information for fix it? OS : Raspian Linux raspberrypi 5.10.11+ #1399 Thu Jan 28 12:02:28 GMT 2021 armv6l GNU/Linux |
|
@device-high to get the best conditions :
If it still doesn't connect, use |
|
By chance, the solution proposed by Brikwerk can be implemented in an Esp32 with Bluetooth ?, previously it worked in versions lower than firmware 12 for nintendo switch |
|
I played around with v12_fix. My Switch is on 12.0.1 firmware and I'm using Raspberry Pi 4B to run nxbt. Connecting controller isn't as stable as it used to be but it seems to work in at least 50% of cases. Once I'm able to exit "Change Grip/Order" successfully, connection seems stable. Now things get weird. I'm not sure if I should post this as a separate issue but I don't know if this is a new thing related to v12 or not. The problem is that I can play Zelda but I cannot play Pokemon Sword unless in-game menu is open. If I exit the menu or simply don't open it before connecting fake controller, it will disconnect me after about 1-2 seconds. I immediately assumed this problem is caused by local communication features which are extensively used in Pokemon games (infamous Y-Comm). There's no way to turn off this feature in-game but I used airplane mode to disallow Wi-Fi entirely and left only Bluetooth on. This confirmed my theory because after reconnecting nxbt everything went smoothly. Honestly this makes no sense to me because controllers are using Bluetooth and Y-Comm is using Wi-Fi, so common sense suggests this should be completely independent. Unfortunately that's clearly not the case. It seems that changing Wi-Fi mode from normal to local affects connected controllers in some way (some kind of "refresh all connections" mechanism?) and it just kills emulated controller with 100% success rate. Do you have any idea about this? |
Thank you for this information mappzor. I have come to the same conclusions. I will also experiment a little again tomorrow. |
|
Hello there. I just discovered this amazing tool, however I am already in Nintendo Switch version 12.0.3 and I am unable to get nxbt conected. |
|
Hi all, Apologies for the lack of updates with this project. Some real-world commitments have been consuming my free time lately. Anyways, I have found some time recently to take another stab at correcting issues with SwitchOS v12 and NXBT. The good news is that I believe I've corrected the disconnection issues happening when users initially connect a controller on the "Change Grip/Order" menu. The new commits pushed to the v12_fix branch include the following changes
The new communication process NXBT employs (while talking to the Switch) is effectively a redundancy optimization procedure. Every packet constructed in the mainloop is only sent if the previous packet (excluding the timing byte) doesn't exactly match. This (1) eliminates the situation whereby the Switch would kick a controller off after receiving packets at full frequency and (2) seems to slightly increase input accuracy due to decreased computational burden. If you're interested in giving this new version a spin, please follow the installation instructions below. This version was tested on a Raspberry Pi 4b (4GB) with Raspbian and a Switch with SwitchOS v12.1.0. It would be great to hear if this does fix the disconnection issue for others. # If you have a previous version of NXBT
sudo pip3 uninstall nxbt
# Install the v12 compliant version with the following
sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@b48b030b5e8c92666ed446be5c01a8ee2ec93c6fEdit: I've successfully tested the current branch on a Pinebook Pro. If you're encountering difficulties connecting (eg: you're stuck at the "Connecting" stage), please make sure that you've deleted any previous pairings with your Switch. |
|
Hey hello Brikwerk, nice to hear from you again!! I have tried what you said with different setups and this is what i got: Using Raspberry Pi 4b (8GB) with Pi OS Lite (32bit) + Nintendo Switch 12.1.0: Using Raspberry Pi 4b (8GB) with Pi OS Desktop (32bit) + Nintendo Switch 12.1.0: Thanks again for your contribution!!
|
|
Same results as @DhSufi here - though I can't get the demo to ever connect. |
|
Thanks for trying out the changes, everyone. I've pushed some new additions to the v12_fix branch that should hopefully help with the issues I'm seeing. @DhSufi First, I recommend against using Raspbian Lite for Bluetooth functionality. From some personal testing and evidence online, Bluetooth can be buggy on this version. Second, I'm unable to reproduce the error above that you're encountering. For testing, I used a clean installation of Raspbian (full version) on an RPi 4b and an RPi 3b with a Switch (v12.1.0). If possible, could you try running New Changes:
To use the new version, please run the following: |
Thanks a lot for your reply. I just tested it and it works perfect!! I am using RPi4b with clean Raspbian (full version) and Switch v12.1.0 Both, sudo nxbt test and sudo nxbt demo worked for me!!
|
|
Likewise - updated to bef7180 here, with no other changes on my RPi 4b since the last attempt, and it now looks to work perfectly. Looking forward to some fun with this over the weekend (time permitting) - thanks!! |
|
Alright, thanks everyone for testing! I've pushed a few more changes in the meantime and I believe we're close to a new release. At this point, I'm fairly satisfied with the compatibility level on SwitchOS v12 and v13. Unfortunately, there are still a couple quirks that I haven't been able to completely chase down, however, I think it's more important to get this version of NXBT (as it stands) onto PyPi. I'll list out the new additions/changes below: Changelog (Sept 26 2021)
Known Bugs
If anyone would like to test the new changes, please feel free! I'll let this sit for a few days and slice off of a new release if no huge bugs come through. With these latest changes, I think we can start bringing this issue to a close 🥳 |
|
@Brikwerk I am still unable to get it to work, even after uninstalling and reinstalling v12_fix. The emulated controller connects to the Switch, exits the "Change Grip/Order" menu, and then disconnects. Edit: Ubuntu VM, Virtual Box, Windows 10 Host :) |
|
@unsightedmetal6 Just to make sure, you're reinstalling with the following, right? sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@v12_fixCan you try uninstalling/reinstalling again, please? I've pushed a patch that should help a large amount with the disconnects. It turns out that there was a bug with the reconnection procedure previously. The new patch should enable NXBT to save itself when a disconnection occurs. Based on some previous reports/issues, I'm starting to think that Windows VMs might be more prone to "Change Grip/Order" disconnects than other devices. I'm not able to produce consistent disconnects on a macOS VM or other Linux devices. I'll try to do some debugging on a Windows VM when I have time. |
|
@Brikwerk Uninstalling, reinstalling, and running |
|
@unsightedmetal6 Great to hear! Thanks for testing the new version. For everyone: I'm going to start the process of merging the v12_fix branch and publishing a release. After this is done, I believe this issue can officially be brought to a close. |
|
The release should be officially out now. To those of you who have installed NXBT from the v12_fix branch, I recommend uninstalling and reinstalling with the official PyPi version. Thanks again to everyone who tested and helped! |
|
@Brikwerk I'm so sorry to dig up this issue-- I'm working on a general use API for ESP32 and I may have an easy resolution for the refresh rate issue. I believe that the 'enable rumble' command may be a bit more than meets the eye. When it's disabled, it might be a 'low power' mode specifically for menus and playback of media (netflix etc). I suspect that the lowering of the refresh rate is also a power saving measure on top of not sending voltage to the linear actuators. In my code, when handling the interrupt reports, I set the report frequency in coordination with the vibration bit being 1 or 0 and I have not had any disconnects at this point :) Hope this helps! |
and others
Nintendo has recently pushed SwitchOS v12.0.0 which has changed the functionality behind controller connection and input. NXBT is not compatible with this update and, as such, will throw some ugly errors (or not connect at all) if you attempt to initially connect or reconnect an emulated controller.
I'm currently in the process of adding support for this version. This issue will serve as a hub for how support is coming along.
What's Changed with this New Version
TODO
Initial controller emulation needs tweaking or possibly an overhaul. Using the Bluetooth name, SDP record, Bluetooth class, etc isn't seemingly enough anymore to lure the Switch into connecting.
A new variable input frequency needs to be added to the mainloop of the controller server
The text was updated successfully, but these errors were encountered: