KurtE
commented
1 year ago To follow up on the first post, I am still trying to figure out what the
bool ATTClass::discoverDescriptors(uint16_t connectionHandle, BLERemoteDevice* device) code is doing when it is tries to enumerate the services/Characteristics to discover the attributes:
I added some debug code at the start of this, that enumerates some of the stuff we know when we get here: Serial.printf("\tService Count:%u\n", serviceCount);
#if 1
// Lets print out the information we know:
Serial.println("****************** Service characteristic list ******************");
for (int i = 0; i < serviceCount; i++) {
BLERemoteService* service = device->service(i);
Serial.printf("Service(%u): UUID: %s Handle Range: %u %u\n", i, service->uuid(),
service->startHandle(), service->endHandle());
int characteristicCount = service->characteristicCount();
for (int j = 0; j < characteristicCount; j++) {
BLERemoteCharacteristic* characteristic = service->characteristic(j);
Serial.printf("\tcharacteristic(%u): UUID: %s Handle Range: %u %u\n", j, characteristic->uuid(),
characteristic->startHandle(), characteristic->valueHandle());
}
}
Serial.println("****************** end ******************");And for example if I run the PeripheralExplorer with the Microsoft "Surface Arc Mouse"; running in pairing mode, I see:
Service Count:5
****************** Service characteristic list ******************
Service(0): UUID: 1800 Handle Range: 1 7
characteristic(0): UUID: 2a00 Handle Range: 2 3
characteristic(1): UUID: 2a01 Handle Range: 4 5
characteristic(2): UUID: 2a04 Handle Range: 6 7
Service(1): UUID: 1801 Handle Range: 8 8
Service(2): UUID: 180a Handle Range: 9 13
characteristic(0): UUID: 2a29 Handle Range: 10 11
characteristic(1): UUID: 2a50 Handle Range: 12 13
Service(3): UUID: 180f Handle Range: 14 17
characteristic(0): UUID: 2a19 Handle Range: 15 16
Service(4): UUID: 1812 Handle Range: 18 65535
characteristic(0): UUID: 2a4e Handle Range: 19 20
characteristic(1): UUID: 2a4d Handle Range: 21 22
characteristic(2): UUID: 2a4d Handle Range: 25 26
characteristic(3): UUID: 2a4d Handle Range: 29 30
characteristic(4): UUID: 2a4d Handle Range: 33 34
characteristic(5): UUID: 2a4d Handle Range: 37 38
characteristic(6): UUID: 2a4d Handle Range: 41 42
characteristic(7): UUID: 2a4d Handle Range: 45 46
characteristic(8): UUID: 2a4d Handle Range: 49 50
characteristic(9): UUID: 2a4d Handle Range: 53 54
characteristic(10): UUID: 2a4d Handle Range: 57 58
characteristic(11): UUID: 2a4d Handle Range: 61 62
characteristic(12): UUID: 2a4d Handle Range: 64 65
characteristic(13): UUID: 2a4d Handle Range: 67 68
characteristic(14): UUID: 2a4d Handle Range: 70 71
characteristic(15): UUID: 2a4d Handle Range: 73 74
characteristic(16): UUID: 2a4d Handle Range: 76 77
characteristic(17): UUID: 2a4b Handle Range: 79 80
characteristic(18): UUID: 2a33 Handle Range: 81 82
characteristic(19): UUID: 2a4a Handle Range: 84 85
characteristic(20): UUID: 2a4c Handle Range: 86 87
****************** end ******************
Then when the current main code is trying to enumerate let's say the first Service with 3 characteristics: I have some additional debug output, condensed here:
0 Service: 1800 #characteristic:3
(0, 0) characteristic: 2a00 0x20203590, range: 4 5
Handle:04 UUID:280e
Handle:05 UUID:2a0e
(0, 1) characteristic: 2a01 0x202035f0, range: 6 7
Handle:06 UUID:280e
Handle:07 UUID:2a0e
(0, 2) characteristic: 2a04 0x0, range: 8 7
1 Service: 1801 #characteristic:0
2 Service: 180a #characteristic:2So the first characteristic it looks like it is passing in the range for the 2nd one. Second one, the third, and the third one invalid range so it returns nothing for it.
I know I am probably missing something obvious here, My Gut (read that as my Naive and very little understanding of BLE) wonders if this code Could simply call the while (1) loop with the range maybe incremented by 1? like: Service(0): UUID: 1800 Handle Range: 1 7 And guessing if the handle returned matches one of the start handle, value handle of a characteristic add the object to that one?
EDIT: Or maybe if >= start handle of one and less then then next one then add it...
But again, I more or less am throwing darts here.
Thoughts?
bediver
Stoutscientist
fstrugar
If you update an XBox One controller to the latest firmware, the update will convert the controller to running using BLE. Microsoft shows a few different ways to do the update, including I believe simply plug it into USB to XBox One that is running the latest stuff. I updated one of mine using the Windows XBox Accessories App.
Side note: trying to add BLE support to our Teensy USBHost_t36 code base. We already have some bluetooth support, and for example we can connect and use an XBox one controller, with the original firmware, but not after they are updated.
So I thought I would experiment using the ArduinoBLE library, and first tried on Arduino Nano 33 IOT as well as BLE and this call fails. Note: I now also have a fork/branch of this library that runs on Teensy boards (T3.6 and 4.x) and right now doing most of my stuff I am using a bluetooth dongle plugged into an USBHost connector on either a 4.1 or a Micromod.
In order for BLE to see this you need to put the controller into pairing mode. Hopefully after I figure out this part will then figure out how to do an actual BLE pairing (Again sort of outside of this issue).
When in pairing mode I found a windows App, that can talk to the device.
Note: I posted Some of these details up on both a PJRC forum thread as well as an Arduino one: https://forum.arduino.cc/t/arduinoble-trying-to-connect-to-xbox-one-controller-and-other-ble-devices/1054844/3 https://forum.pjrc.com/threads/71503-USBHost-Bluetooth-gt-BLE-gt-ArduinoBLE
As the title mentioned, the discoverAttributes call fails. I have added a lot of debug outputs and the like to code including into my TeensyTransport code. This includes doing some decoding of the data that is sent back and forth with the ATT messages.
It looks like the code is properly enumerating the Services and the Characteristics and then fails after that:
From my debug output: first enumerating the Services: Pardon some of my cryptic outputs:
But it looks here like it found: Handle:0001 ID: 1800 0008 ID: 1801 0009 180a 0012 180f 0016 1812
Which map to:
It then goes through all 5 of these Services looking for Characteristics:
I won't go through all 5 groups here to decode. But looking at the first we see:
So as I read this, the first group should have 3 handles 2, 4 and 6 I have not fully decoded the 5 bytes, but it looks like 2 goes to UUID 0x2A00 and likewise and 04->0x2A01 Which maps to: case 0x2A00: return "Device Name"; case 0x2A01: return "Appearance"; Which again matches the data I see with the Windows app.
Again the call discoverCharacteristics works, but then the call to: bool ATTClass::discoverDescriptors(uint16_t connectionHandle, BLERemoteDevice* device) Fails on the first items. That is i=0 and j=0;
If fails in the while(1) { loop. Some debug from that part:
Something that does not feel right here is: As I mentioned earlier is it looks like the first one has handle 2 but it is searching for it with the range 4,5? It finds the 2nd one with ID 4, It then tries a search on 5-5 which then bails with an error and I don't see any response on the ACLDATA for it.
Still investigating