Advertisement data not parsed correctly

[ghost]

It has been reported that service UUIDs in the advertisement data record are not parsed correctly. This applies to EasyBLE and to the extended BLE plugin API in this pull request: https://github.com/evothings/cordova-ble/pull/118

Hello, I am scanning for bluetooth LE devices using easyble and looking at the advertisedServiceUUIDs to find the service uuid of my service. I am using bleno to create the service, and I set the service uuid to 'DC57FFAA-D960-4202-82FD-5492696B02F6', BUT the advertisedServiceUUIDs i can see using easyble is 'f6026b69-9254-fd82-0242-60d9aaff57dc'. Reading from right to left you can see it is the 'same' uuid Why does this happen? When i check with the "nRF Connect" application it shows 'DC57FFAA-D960-4202-82FD-5492696B02F6'...

With BLE Explorer the advertised uuid looks correct: https://drive.google.com/file/d/0BzeOdzETDWYEUFZvNVV2eHVMeTA/view It is only the 128bit uuid that looks wrong. And the error appears to be in the "arrayToUUID" function withing the "ensureAdvertisementData" function of easyble. I changed the line "string += evothings.util.toHexString(array[offset-k], 1);" to "string += evothings.util.toHexString(array[offset+15-k], 1);" to make it look correct.

[ghost]

Test results

Testing parsing of advertisement data by comparing results on iOS and Android. On iOS advertisement data are parsed by native iOS functions, on Android by JavaScript code in EasyBLE and in the extended BLE plugin API. Two independent BLE scanning apps were also used to verify advertisement data (LightBlue and TI SensorTag app).

As BLE device the TI SensorTag CC2650 was used.

On iOS advertisement data looks like this:

{"kCBAdvDataLocalName":"CC2650 SensorTag",
 "kCBAdvDataServiceUUIDs":["0000aa10-0000-1000-8000-00805f9b34fb"],
 "kCBAdvDataTxPowerLevel":0,
 "kCBAdvDataIsConnectable":true}

And on Android:

{"kCBAdvDataLocalName":"CC2650 SensorTag",
 "kCBAdvDataTxPowerLevel":0,
 "kCBAdvDataServiceUUIDs":["0000aa10-0000-1000-8000-00805f9b34fb"]}

The advertised service UUIDs are the same on iOS and Android.

Is is possible to get the bleno code to do futher testing?

[ghost]

The line "string += evothings.util.toHexString(array[offset-k], 1);" is "offset+k" in easyble.js and not "offset-k". But I don't see how this would explain the reversed order of the UUID.

[ghost]

Status is that I have not been able to reproduce the problem. Let me know if this problem persists. Will leave the issue open for some time, then close if inactive.

[ghost]

Closing this issue, let me know if there are any problems and I will reopen.