Telink BLE Mesh Proxy Notify Characteristic Non-standard Behaviour

Topic

FAQ

wsyeo

Apr 10, 2018 13:28

中 /A

Hello,

I found that Telink BLE Mesh GATT proxy device is behaving in a non-standard way when subscribing to the NOTIFY characteristic (00010203-0405-0607-0809-0a0b0c0d1911).

The standard way of subscribing to a characteristic with notify property is to set Notifications enabled bit in Client Characteristic Configuration Descriptor of the characteristic (see https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.descriptor.gatt.client_characteristic_configuration.xml).

But the current Telink implementation is:
1. Write one byte value (1) to NOTIFY characteristic supposedly to enable notifications.
2. Enable value updated/changed event (on your Bluetooth library).

The ATT table of the Telink BLE Mesh proxy device does not contain the Client Characteristic Configuration Descriptor for NOTIFY characteristic and this is causing issues with many Bluetooth libraries out there (for example, on WinRT/UWP platform, you cannot enable "ValueChanged" event the NOTIFY characteristic because the event is implicitly disabled unless you set Notifications Enabled bit in the Client Characteristic Configuration Descriptor, in accordance with the Bluetooth standard).

I've tried adding Client Characteristic Configuration Descriptor to the ATT table in the light firmware, but for some reason, it caused the firmware to freeze.

Please consider fixing this issue in the future releases, as it could cause many potential compatibility issues (in fact, I've already experienced multiple compatibility issues, both on Windows WinRT and Linux BlueZ stack platforms).

1 replies

wsyeo [Author] Apr 10, 2018 22:48

中 _/A

More details about my attempt to manually add CCC (Client Configuration Characteristic) to the ATT:

I modified the "SppDataServer2Client" in the ATT as follows:

[code]
    {0,2,1,1,(u8*)(&characterUUID),         (u8*)(&SppDataServer2ClientProp), 0},               //prop
    {0,16,1,1,(u8*)(TelinkSppDataServer2ClientUUID),    (u8*)(SppDataServer2ClientData), &meshStatusWrite},    //value
    {0,2,2,2,(u8*)&clientCharacterCfgUUID, (u8*)(&SppDataServer2ClientDataCCC), 0},
    {0,2,sizeof (spp_Statusname), sizeof (spp_Statusname),(u8*)(&userdesc_UUID), (u8*)(spp_Statusname), 0},
    
const u16 clientCharacterCfgUUID = GATT_UUID_CLIENT_CHAR_CFG;
static u8 SppDataServer2ClientDataCCC[2] = {0};
[/code]

I've tried reading the CCC descriptor and it successfully reads the value of SppDataServer2ClientDataCCC, but an attempt to write to it results in a connection loss (the firmware does not freeze and I can still reconnect, but the write operation does not proceed).

It seems the BLE stack used for Telink Bluetooth Mesh is very outdated and does not support writing to descriptor attributes (I've looked at newer versions of Telink's BLE stack and they allow specifying access permission for every attribute).

~~[b]~~Would it be possible for you to update the BLE stack version used for Telink Bluetooth Mesh, or at least allow writing to certain descriptors?[/b]

I have managed to get notifications working without CCC on Android and iOS platforms, but not for Windows (using WinRT BLE interface) because it simply would not invoke characteristic updated event before you actually call the function that writes to the CCC descriptor and set notifications enabled value. There is no externally available interface that allows me to bypass such behaviours.

p.s. Looking at SIG Mesh ATT, it clearly does implement CCC.

[code]
	{0,ATT_PERMISSIONS_READ,2,1,(u8*)(&my_characterUUID), 		(u8*)(&SppDataServer2ClientProp), 0},				//prop
	{0,ATT_PERMISSIONS_READ,16,sizeof(SppDataServer2ClientData),(u8*)(&TelinkSppDataServer2ClientUUID), (u8*)(SppDataServer2ClientData), 0},	//value
	{0,ATT_PERMISSIONS_RDWR,2,2,(u8*)&clientCharacterCfgUUID,(u8*)(&SppDataServer2ClientDataCCC)},
	{0,ATT_PERMISSIONS_READ,2,sizeof(TelinkSPPS2CDescriptor),(u8*)&userdesc_UUID,(u8*)(&TelinkSPPS2CDescriptor)},
[/code]

I understand that Telink Mesh is to be phased out and the SIG Mesh should replace it. But for now, I found Telink's SIG Mesh SDK to be too unstable for production use and the only option I have at the moment is to use Telink Mesh. Given that it will take some time for the SIG Mesh to be production ready, please do update the Telink Mesh SDK to provide CCC for NOTIFY characteristic.