Android app sends wrong characteristic handler

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ToVa_285016
Level 5
Level 5
100 replies posted 50 replies posted 50 questions asked

Hi,

   

I am trying to get an interrupt to change some data when an Android app sends a characteristic write request.  Both UUIDS are identical in Android Studio and PSOC Creator, however, this line never seems to match:

   

if(wrReqParam->handleValPair.attrHandle == CYBLE_DMX_CONTROLLER_CUSTOMCOLOR_CHAR_HANDLE)

   

The CYBLE_DMX_CONTROLLER_CUSTOMCOLOR_CHAR_HANDLE always has a value of 0x0014u, but the wrReqParam->handleValPair.attrHandle either has a value of 0x0010, or 0x0015.  I have checked and double checked when debugging that the app is sending the characteristic with the correct UUID (00000000-0000-1000-8000-00805f9b34f1), and cannot make sense of this.

   

Any ideas?

   

Thank you in advance.

   

Regards, Tom

0 Likes
1 Solution
Anonymous
Not applicable

The handle value is generally assigned at compile time to the BLE profile to use as an index for interacting with characeristics. Using static handles when you have written both ends of the BLE communication and know what the handle values will be has been done, but the handles are not guaranteed to remain constant over different compiles/builds of the project (generally they do).

   

It could just be the case that you didn't save/rebuild the project when you modified the characteristics at some point, and thus some values differed 🙂

   

It should be refractoring, not sure why it didn't before...

   

Discovering the service/characteristic and using the handle given by the device directly would be the nominal way to do it. And the comparison you are doing on the compile-generated constant should be fine for checking incoming handles.

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

Are there other characteristic writes being sent by the android app?

   

Have you tried modifying both UUIDs on the android app and the PSoC to see if changing the value returns a new UUID value on the write request parameter and compare?

   

Are you using the handle value on the comparison based on the compile-time constant handle value given in the PSoC creator?

   

Are you discovering the services and characteristics to obtain the correct handle value of the characteristic from the device directly?

   

Try some of the above and let us know what results you get 🙂

0 Likes

Hi,

   

Thanks for the information!  

   

There are about 5 characteristics being sent by the app, and 2 CCCDs.  I have eliminated all but one characteristic from the app.  Now the characteristic handle in the PRoC has changed to match the app!  If I add the deleted characteristics they are fine now.  Shouldn't it refractor when you change characteristics?  I would hate to have to delete everything every time I added or modified a characteristic.

   

I am using the handle value on the comparison based on the compile-time constant:

   

if(wrReqParam->handleValPair.attrHandle == CYBLE_DMX_CONTROLLER_CUSTOMCOLOR_CHAR_HANDLE)

   

I am discovering the services and chars to obtain the handle value pairs from the device:
mColorCharacteristic = gattService.getCharacteristic(UUID.fromString(customColorCharUUID));

   

Any ideas?

   

Thank you,

   

Tom

0 Likes
Anonymous
Not applicable

The handle value is generally assigned at compile time to the BLE profile to use as an index for interacting with characeristics. Using static handles when you have written both ends of the BLE communication and know what the handle values will be has been done, but the handles are not guaranteed to remain constant over different compiles/builds of the project (generally they do).

   

It could just be the case that you didn't save/rebuild the project when you modified the characteristics at some point, and thus some values differed 🙂

   

It should be refractoring, not sure why it didn't before...

   

Discovering the service/characteristic and using the handle given by the device directly would be the nominal way to do it. And the comparison you are doing on the compile-generated constant should be fine for checking incoming handles.

0 Likes