UPDATE: the UUID bytes are reversed!! Any ideas why that would be? easy way to undo it?
I can get it to work if i set UUID to 21111111-1111-1111-1111-111111111111 and then tell the iOS app the UUID is 11111111-1111-1111-1111-111111111121
———————————————————
I’m running the BLE_ibeacon sketch. I’m using the Radius Networks ibeacon app on iOS called Locate.
I can get the iBeacon to be identified, but only if the UUID is a string of constant values, i.e. all 0’s, or all F’s or all 1’s. as soon as i add any other different value, it wont show up. I thought it might be endian related, so tried making the UUID = FF00FF00-FF00-00FF-FFFF-00FF00FF00FF, then tried to detect the UUID = 00FF00FF-00FF-FF00-FFFF-FF00FF00FF00, but that didn’t work. Unfortunately, on iOS you have to specify a UUID before it can be detected, so i can’t see what the UUID really is.
i tried to detect the iBeacon on MACOS high sierra using the app called Beacon Scan from TwoCanoes, but that app never detects the iBeacon regardless of the UUID.
i also tried printing out the beacon bytes over serial, but didn’t get very far – still working out the details of the cpp in arduino stuff.
Help???
Hello, that’s extremely weird… It shouldn’t be reversed and I don’t have a good explanation for that. I also never tried that app “Radius Networks ibeacon”.
Does it work with the app that I recommend in the course “nRF Connect”?
I apologize for taking so long to get back to you.
Thanks for your patience,
Rui
nRF connect sees the ESP32, but it doesn’t give me any info other than complete local name and tx power.- i think it wants to connect and exchange bytes, not read iBeacons.
do you have any tutorials on how to build arduino libraries?
there is a parameter in the BLEUUID code that tells whether to reverse byte order or not of UUIDs. its set to false now, but maybe if i set to true and rebuilt it would fix?
here is the reference: https://github.com/nkolban/ESP32_BLE_Arduino/blob/master/src/BLEUUID.cpp
here is the snippet that reverses the bytes:
else if (value.length() == 36) {
// If the length of the string is 36 bytes then we will assume it is a long hex string in
// UUID format.
m_uuid.len = ESP_UUID_LEN_128;
int n = 0;
for(int i=0;i<value.length();){
if(value.c_str()[i] == ‘–‘)
i++;
uint8_t MSB = value.c_str()[i];
uint8_t LSB = value.c_str()[i+1];
if(MSB > ‘9‘) MSB -= 7;
if(LSB > ‘9‘) LSB -= 7;
m_uuid.uuid.uuid128[15-n++] = ((MSB&0x0F) <<4) | (LSB & 0x0F);
i+=2;
}
}
Exactly… I think nRF Connect only gives that information for a connected client.
That is weird and it shouldn’t happen (it never happened to me), but it looks like that was the problem comes from.
Unfortunately I don’t have any resources on that subject, but I would recommend submitting a issue on Github for that file with all the details that you can provide: https://github.com/nkolban/ESP32_BLE_Arduino