SPBTLE-RF. Upper limit when creating characteristics and services

[Clive Vallance]

Posted on October 06, 2017 at 12:14

Hi,

I am using the SPBTLE-rf bluetooth module to create a device that advertises for connections and once connected will present a number of characteristics and services.

Essentially almost all of it is working as I would expect. I have created services and characteristics for most of the attributes I need to convey.

The sticking point is when I exceed 60 attributes. 

So I have three services and 28 characteristics. Two of the characteristics have three attributes (because they use notifications) and the rest use two. There is also an attribute for each service.

This brings me to a grand total of 61 attributes. When I run the code I obtain an error when trying to create all the attributes on the module.

If I remove one characteristic (i.e. two attributes) the code runs and generates the characteristics and services without error. 

Does anyone know why there is a limit of 60 (I assume it is a memory limitation) and is there any way of increasing the value.

Thanks,

Clive

[Antonio Vilei]

Posted on October 09, 2017 at 12:50

Dear Clive,

there is no definite limit for the amount of attributes as it depends on many aspects.

You correctly pointed out that the way you create services and characteristics affects the total number of attributes that you need (for example if you need descriptors and notifications).

Moreover, please take into account that you can use different lengths for your characteristics and this will have an impact on the total memory occupation.

If allowed by your application, you may try reducing the length of some of your characteristics to free up some extra space for more attributes.

Also, the chip has four modes that you can select on startup (please refer to Table 285. Aci_Hal_Write_Config_Data members of

http://www.st.com/content/ccc/resource/technical/document/user_manual/6d/a1/5b/6c/dc/ab/48/76/DM00162667.pdf/files/DM00162667.pdf/jcr:content/translations/en.DM00162667.pdf

). For your case, please make sure you are using mode 4.

Here is the description of the modes.

1. Slave and master

Only one connection

6 KB of RAM retention

2. Slave and master

Only one connection

12 KB of RAM retention

3. Master and Slave

Up to 8 connections

12 KB of RAM retention

4. Master and Slave

Simultaneous advertising and scanning

Up to 4 connections

This mode is available starting from

BlueNRG-MS FW stack version 7.1.b

[Clive Vallance]

Posted on October 09, 2017 at 14:57

Hi, many thanks for the response.

I have tried implementing the suggestions you made and it does not seem to make any difference.

I have read back the mode of the device and the default seems to be 2. When I write a value of 4 into this location it succeeds (for anyone reading this post it must be the first command after a reset) and I read it back correctly. The characteristics still fail to be created. 

In order to test your statement on the length of the characteristics I reduced the overall length required to store the attributes from 125 bytes down to 74 bytes (this would not work in my real application but in order to see if it made a difference I shortened all the characteristics). Still the extra characteristic could not be created. 

The firmware version on the SPBTLE-RF is 7.2c so i don't think that would cause any problems. I really don't see how I could have used up all the memory. The attributes i have exposed are mostly two to four bytes in length (numeric values - 2 byte integers and floats).

Clive.

[Clive Vallance]

Posted on October 09, 2017 at 15:17

Sorry, I have just noticed that simply changing the mode from 2 to four stops the characteristics from being created correctly. Is there something else that also need to change?

[Antonio Vilei]

Posted on October 09, 2017 at 15:25

Hi Clive,

the limit is implementation specific and may change across firmware versions.

Just out of curiosity, what kind of application are you targeting?

I don't know if this may be suitable in your case, but if you're using a proprietary profile and have no particular constraints, you may also try aggregating more items into single characteristics, so you won't need to allocate so many attributes in the first place.

If feasible in your case, this may probably lower the power budget for your device. Indeed, you could squeeze-in more data into a single packet and reduce the inefficiency of sending multiple packets with the related link-layer overhead.

[Antonio Vilei]

Posted on October 09, 2017 at 15:30

Do you need to be central and peripheral at the same time? If you're just interested in the peripheral role, you can go back to mode 2.

[Clive Vallance]

Posted on October 09, 2017 at 15:58

I only need a peripheral role.

[Clive Vallance]

Posted on October 09, 2017 at 16:20

Hi,

So if the limit is implementation specific, you must know what the limits are and why they are there. I also assume that this means there is no direct user control over this limit.

The way you have described it also suggests that this limit could change up or down without notice. This is a little alarming.

With regard to the sharing of characteristics. In principle yes I could, although it does make it a little more complex. My biggest issue is the time and effort required to explain this to our app developer. If I can avoid this I would like to.

It is a little annoying as I had been very careful to stay below this observed limit, as my initial design had used more. We are generating a device that will use two of the services during configuration and the third for data delivery. The main data delivery service is quite small, so i don't think the reduction in overhead will be that great. The only reason I am having to look at adding one is the limitation in iOS that stops you writing to the device name characteristic.

[Antonio Vilei]

Posted on October 09, 2017 at 18:18

The way you have described it also suggests that this limit could change up or down without notice. This is a little alarming.

You don't need to worry because in case of any changes, they would be applied as additional Modes, preserving the behavior for the existing ones.

[nicolas b]

Posted on November 08, 2017 at 18:38

In mode 2, the limit for attributes is around 700 bytes (minus 36 bytes for GAP and GATT services).

You can find this information in the BlueNRG-MS release notes (in BlueNRG-DK / docs).

Actually, I'm quite surprised by the 60 attributes / 28 characteristics, it seems a lot.

Do you use 16 bits or 128 bits UUID ?