1 of 1 people found this helpful
I checked with CySmart Dongle it is working fine I can see the Characteristic. But with lower Versions of Android mobile(like Android v4.4.2 & Bluetooth v4.0) i'm not able to see the characteristic.
Can you please check with other mobile.
I tested on 3 different devices, which, upon checking, all happen to use Bluetooth v4.0.
I also happen to notice that this problem only occurs when the service uuid is set to 32 bit.
... and there is more to this.
If I set the service uuid to 16bit and make the characteristic uuid 32bit or 128bit, I can see my characteristic listed, however, the characteristic uuid gets altered if I set the characteristic uuid (32 or 128 bit) starting with something different to the "0000", such as 0A03F7E2-0000 for example.
Note that if I set this uuid to 0000F7E2 it is fine or as identified earlier it is a 16bit uuid.
For Bluetooth v4.2 and above devices it is working fine i.e., we can see the Characteristic with any uuid (16bit, 32 bit, 128 bit). For devices with lower version of Bluetooth (like v4.0) this problem is occurring. PSoC 4 ble is fully compliant with Bluetooth LE v4.2 specifications.
Ok, thanks for explanation. It is very helpful.
So, would it be better to use a PSoC BLE 4.1 module instead of 4.2 if I need to communicate with Bluetooth 4.0 devices and aim to use 32-bit/128-bit uuid's.
... and I just switched to a CY8C4247LQI-BL483 module, which I believe is a BLE 4.1 device and the problem persists.
When using 128 bit I get two results. If the first 16bits are set to 0000 then fine. If I set to anything else then the characteristics are not shown.
Can you please tell me what Bluetooth versions your mobile is supporting.
Please change both services and characteristics to 128 bit uuid and check.
All 3 devices ...use Bluetooth v4.0."
Testing 128-bit and works fine... and now, in fact, 32-bit works too for some reason. Which makes we now wonder if something unconnected (as in a self-inflicted software bug) was blocking my code. I know I did have problems with the default uart debug code but had disabled this part.
One thing I did discover though is that you cannot add in a 16-bit characteristic, such as a battery level characteristic, for example, to a custom service if the custom service uuid is set to 32-bit or 128-bit. This caused no characteristics to be displayed.
As said, this had me baffled...
Anyway, thanks for all your replies. These were much appreciated.
There is definitely something strange going on.
I am now back to the 128-bit option not working again.
So basically had the situation where it was working. I then added the Battery Level characteristic. This made it stop working. I then removed the battery level characteristic from my custom service and it has not returned back to the working state.
I just happen to be developing a simple Android app on the side. Still early days, but in my first test, it flagged an error message about the device having an invalid uuid.
Now more baffled than ever.
The problem appears to be with the first 16 bits... as indicated before.
By stripping right back and starting over again, I started by using a 16 bit option first. In this case, you are able to create your own custom number and this is stored as follows when compiled 0000XXXX- etc.
Now I was able to make progress as I could then switch to 32bit and this worked. I then switched to 128bit and this too worked.
All because the first 16 bits of the 128 bit uuid were back to default "0000"
Now once I am at this stage, and only now, am I able to change these 1st 16 bits.
... but please don't ask me to now try and replicate this problem.
Finally found a way around this issue.
As mentioned, if I use 128bit or 32bit but set the first 16bits to be unique, my BLE 4.0 devices did not like it. E.g. a1b2000-0000-1000-etc.
Well, I discovered that if using 128bit and I change bits 33 to 48 to be unique then this worked. As in a1b2000-1234-1000-etc.
My Bluetooth 4.0 devices (phone + tablets) were happy with this.
I suspect that for some reason the way things are stored, for the custom service t clashes with the standard 0x1800 and 0x1801 services. Just a guess.