USB charging cable error

[barteq100]

I have managed to run everything smoothly on ASUS BT-400.
But I'm running into wall when tring to send nfc data. I'm getting error 2115-0064. Which states I'm connected via USB charging cable.
Is there a flag I can set for that?

[Poohl]

Not really sure what makes the switch think that, but I read something about it claiming three joycons are plugged in so i'm not suprised...
Try bluetoothctl power on to mark the bt-controller as self powered.
For more info run bluetoothctl show (while joycontrol is on) and comment the output, maybe that yields something.

Regarding the "Flag" for that: if you feel like poking in the code the byte after the timer encodes information about power, but its set to Full battery, discharging, battery powered by default (and currently cannot be changed outside the code).

And a few more questions if you don't mind: What branch are you on? what switch os version? We're having a few way worse problems with NFC or really anything on V12.

[barteq100]

I'm at V12_fixes. And switch os is 12.0.1.

[barteq100]

And my bluetooth show:

Controller 94:58:CB:44:55:66 (public)
	Name: raspberry
	Alias: Pro Controller
	Class: 0x000c0000
	Powered: yes
	Discoverable: no
	Pairable: yes
	UUID: Headset AG                (00001112-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0532
	Discovering: no

Sadly it still doesn't work with power on

[thxomas]

Hello, did you run bluetoothctl show with joycontrol running ? Yours shows that the class isn't 0x2508 and HID profile is missing..

[barteq100]

Yes I did. I forgot to uncomment main.conf name and class. After uncommenting:

pi@raspberry:~ $ sudo bluetoothctl show
Controller 94:58:CB:44:55:66 (public)
	Name: raspberry
	Alias: Pro Controller
	Class: 0x000c0508
	Powered: yes
	Discoverable: no
	Pairable: yes
	UUID: Headset AG                (00001112-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0532
	Discovering: no

But the issue is still the same

[Poohl]

But you can get it to connect like that? Using reconnect I assume?

B.c. all the SPD-things are on. Try disabling those maybe that ... changes things. but our current understanding of this would suggest it shouldn't work at all.
See #4 on how to disable the SPD stuff (dont forget restarting the service).

Ps @barteq100 use three backticks to preserve code formatting

```
formatted code/output here
```

[barteq100]

Its getting paired and reconnected withotu a problem. It doesn't even get disconnected unless I connect other controller. Everything works as intented. Only error I get is when I try to connect amiibo in Animal Crossing.
I have set the ExecStart=/usr/lib/bluetooth/bluetoothd -C -P sap,input,avrcp

[Poohl]

ok, Not to lie, I'm baffled by this issue.

Best I can offer is you wireshark connection to the problem and I'll compare that to known good traces and look for a difference...
If you have UI install wireshark and capture bluetooth-monitor (than save that)
If you don't, install tshark, run tshark -i bluetooth0 -w output.pcapng

If you want to investigate yourself: The captures I have on Gdrive

[barteq100]

Sorry it took so long. Work etc...
Here is my tshark file.
GDrive

[Poohl]

Ok, I went through the the capture and coudn't really find anything out of the ordinary.
When ignoring the "Num of completed packets" events it's just regular communication at 15Hz until the connection is lost the same way V12 disconnects when it doesn't like the simulation. (Max-Slots-Change, Mode change, Disconnection-request)

Maybe try to capture the pairing/connection process (start tshark about a second before joycontrol) as that's the only other time where critical info is exchanged. I dont know too much about this SPD-stuff but maybe someone else can interpret that data and the rest is dissected by Wireshark, that is, easy to compare.

[Poohl]

From @munichi-jasuda in the closed V12 Thread:

I think the problem is definitely with the device class. Even after changing the MAC address and successfully connecting with the Switch, the device is eventually identified as invalid when reading NFC.

I ran the bluetoothctl show command both before and after successfully connecting with my Switch, and it seems my device class is unaffected (0x001c0000). It's not 0x2508, as it should be in order to be identified as a valid controller that can read Amiibo.

And when looking at @barteq100's post, the class is also not 0x2508 (it's 0x000C0508).

So it looks like @munichi-jasuda is right and we need a way for you to change the device-class.

My ideas:

• Run sudo hciconfig hci0 class 0x2508 and just before and after that sudo bluetoothctl show. Maybe the class is set but resets rather quickly.
• edit /etc/bluetooth/main.conf (uncomment the class line) and then restart bluetooth (systemctl daemon-reload and systemctl restart bluetooth.service), this should change the default device class.
• check Cursed Bluetooth Hardware #4, maybe someone with more knowledge about bluetooth hardware posted a trick. General hardware problems are over there.