You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello Ricardo,
as agreed in the discord chat, I'll explain my request.
Use case
Manage/drive several device with the same controller (obviously one at time), without re-pair the controller with the device.
Example: I have several combat antbot (something like battlebots/robotwars bot, but smaller and made of 3D printed parts) and I use ESP32 + bluetooth joypads to drive it. Setting the same bluetooth address in every bots makes the pairing process simpler (turn on the bot, turn on the joypad without the need of re-pair process).
Another advantage is: you have already paired the controller with the device, so there is no risk that another device could "catch" your controller during the pairing phase (think a competition with several bot belonging to different owners, you can't go to every guy saying "please please turn off all your bot because I have to re-pair mine!!").
Possible solution
There are two function on ESP-IDF SDK:
esp_err_t esp_read_mac(uint8_t mac, esp_mac_type_t type)doc here esp_err_t esp_base_mac_addr_set(uint8_t* mac)doc here
The first function retrieve the current MAC address, the second function set the new MAC address.
I use these function in my library for DualShock4 controller.
I tried to modify the bt address, but your library seems to save it somewhere (maybe because already initialized) so the changes doesn't affect the address used by your library.
Here what I did:
Set the Arduino environment to use your library
Loaded your Arduino example (Controller.ino)
in the setup(), at the beginning and just below the serial initialization I added this snippet (to set the bluetooth MAC address)
// Define your new MAC address
uint8_t newMAC[] = { 0x08, 0x03, 0x19, 0x77, 0x00, 0x00 - 0x02 };
// Set the new MAC address
if (esp_base_mac_addr_set(newMAC) == ESP_OK) {
Serial.println("\n\nMAC address set successfully");
}
else {
Serial.println("\n\nFailed to set MAC address");
}
Just before the end of the setup() block, I added this snippet (to print the bluetooth MAC address)
esp_read_mac(baseMac, ESP_MAC_BT);
Serial.print("Bluetooth MAC: ");
for (int i = 0; i < 5; i++) {
Serial.printf("%02X:", baseMac[i]);
}
Serial.printf("%02X\n", baseMac[5]);
Compiling and uploading, this is what I get (Serial monitor):
Bluepad32 (C) 2016-2024 Ricardo Quesada and contributors.
Version: v4.1.0
BTstack: Copyright (C) 2017 BlueKitchen GmbH.
BTstack up and running at 48:F3:52:AD:C3:76
VMDPR_
MAC address set successfully
Firmware: Bluepad32 for Arduino v4.1.0
BD Addr: 48:F3:52:AD:C3:76
Bluetooth MAC: 08:03:19:77:00:00
In other word, your library start with the default ESP32 bluetooth MAC address, then I change the MAC address successfully, then I call your library member function BP32.localBdAddress() and the output is the default bt address (as nothing was done) but calling the ESP-IDF SDK function esp_read_mac() returns the custom bt address set before.
A proof that your library is still using the default bt address can be retrieved by pairing a controller and than reading the bt address paired.
I did it with a DualShock 4 pad, after paired I used the sixaxispairtool to read the bt address stored in the controller.
So I guess that something must be done inside your library, maybe deinitializing the library, changing the bt address and then initializing once again the library.
Hoping that my explanation is clear enough, thank you for you huge work!
Regards,
Stefano
The text was updated successfully, but these errors were encountered:
Hello Ricardo,
as agreed in the discord chat, I'll explain my request.
Use case
Manage/drive several device with the same controller (obviously one at time), without re-pair the controller with the device.
Example: I have several combat antbot (something like battlebots/robotwars bot, but smaller and made of 3D printed parts) and I use ESP32 + bluetooth joypads to drive it. Setting the same bluetooth address in every bots makes the pairing process simpler (turn on the bot, turn on the joypad without the need of re-pair process).
Another advantage is: you have already paired the controller with the device, so there is no risk that another device could "catch" your controller during the pairing phase (think a competition with several bot belonging to different owners, you can't go to every guy saying "please please turn off all your bot because I have to re-pair mine!!").
Possible solution
There are two function on ESP-IDF SDK:
esp_err_t esp_read_mac(uint8_t mac, esp_mac_type_t type)
doc hereesp_err_t esp_base_mac_addr_set(uint8_t* mac)
doc hereThe first function retrieve the current MAC address, the second function set the new MAC address.
I use these function in my library for DualShock4 controller.
I tried to modify the bt address, but your library seems to save it somewhere (maybe because already initialized) so the changes doesn't affect the address used by your library.
Here what I did:
setup()
, at the beginning and just below the serial initialization I added this snippet (to set the bluetooth MAC address)Compiling and uploading, this is what I get (Serial monitor):
In other word, your library start with the default ESP32 bluetooth MAC address, then I change the MAC address successfully, then I call your library member function
BP32.localBdAddress()
and the output is the default bt address (as nothing was done) but calling the ESP-IDF SDK functionesp_read_mac()
returns the custom bt address set before.A proof that your library is still using the default bt address can be retrieved by pairing a controller and than reading the bt address paired.
I did it with a DualShock 4 pad, after paired I used the sixaxispairtool to read the bt address stored in the controller.
So I guess that something must be done inside your library, maybe deinitializing the library, changing the bt address and then initializing once again the library.
Hoping that my explanation is clear enough, thank you for you huge work!
Regards,
Stefano
The text was updated successfully, but these errors were encountered: