You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
-
Hi, I think you are correct in that it's a limitation of tinyB. The format you mention is exactly what I'm seeing with the xxxx's replaced with the 16bit UUID value.
Thanks for that link, that's exactly what I wanted so at least I know there is no fudging happening when I try to identify the correct service and characteristic.
JohnH
@Gordon
I imagine it's a TinyB issue - Puck.js will be reporting back 16 bit UUIDs over BLE - it's not even sending the bytes for 128 bit UUIDs. If you use something like nRF connect you should see them fine.
You could always try TinyB on some other type of BLE device to make sure but I imagine you'd find the same.
There's some info on 16 bit UUIDs here: https://stackoverflow.com/questions/36212020/how-can-i-convert-a-bluetooth-16-bit-service-uuid-into-a-128-bit-uuid
Basically a 16 bit UUID should be represented as
0000xxxx-0000-1000-8000-00805F9B34FB- so you'd actually expect there to be some 'garbage' (see my response to your other post - sending 00000 instead of the extra data definitely won't make a 16 bit UUID).However if the UUID being reported back isn't the very specific form above, something seems wrong.