How to increase number of characteristics

[Tim]

Hi,

Using S130 via mBed, I'd like to have a fairly large number of characteristics (say 30). Unfortunately this seems to be too many, as sd_ble_gatts_characteristic_add() returns an error after I get to maybe 18 characteristics (i.e. 17 works, 18 doesn't, it also depends on the specific characteristics). Also the mBed code has a hard limit of 20 characteristics (well actually the code is buggy and will overflow/crash if you go past 20). I have submitted a patch for that.

As I understand it, some data about the characteristics (I assume UUID, characteristic value buffer, CCCD, etc.) is stored in an internal table of the softdevice. Is there any way to increase the size of this table?

According to the documentation you can specify BLE_GATTS_VLOC_USER instead of BLE_GATTS_VLOC_STACK in custom_helper.cpp, but I don't really want to change the library code, and also it says it will only store the attribute value in user memory, which is only one or two bytes in my case. The UUID is much bigger, so I doubt I'll save much there.

Is there any solution?

[endnode]

Hi Tim,

BLE ATT (Attribute) layer which is base of GATT client/server layers in BLE Stack is configurable in latest Nordic SoftDevices. This is done during SoftDevice init by function sd_ble_enable(...). See API documentation in Nordic infocenter here and also read chapter 13.1 of S130 SoftDevice Specification (link to PDF version if you prefer). Note that changing Attribute Table Size has consequences on memory layout during linking of final firmware binary, see chapter 13.2.1 and other references in SDS.

Cannot leave the reply without this comment: what about redesigning your usage of Bluetooth LE ATT/GATT layer because most of the job could be done over single Service and Characteristic handles (actually 1 for the Service and 3 for the Char)? Or is it so that your device will really potentially offer so many characteristics to different applications? (e.g. if you have just one dedicated app then merge all features to applicative protocol running over one bi-directional characteristic which will safe resources as well as time during service discovery and I believe overhead will hardly harm your throughput unless you have very specific use case of many fast-changing but short and completely asynchronous values...)

Cheers Jan

Update on September 30, 2015:

Hi Tim,

This is exactly what I've tried to point out: while GATT client/server architecture looks like "in the spirit of BLE" it doesn't scale. I assume that if your 30 "properties" (whatever it is) are really independent and there should be "general" applications which can discover full (or partial) list and pick just few they should be rather grouped on Primary Service level, don't they? In every case you will have huge penalty (it can take even couple of seconds when you increase the GATT table usage) during each connection (if full service discovery will be done by central side) plus you will have troubles once you would like to secure the link (because BT Smart security mechanism doesn't scale in practice) so the whole concept of "general" properties in the practice collapses into "one bonded/paired central device with my application". And thus simple stupid "pipe" would do all the job more efficiently. In the system where server (peripheral) can accept only one connection at the time the principle of applicative fragmentation already on GATT layer somehow loses the charm. And when new devices supporting more complex server-client topologies arrive (compliant to BT SIG specs 4.2/5.0) - which will take couple of years - there will still be majority of the devices living in this old "low energy" (and resources) design. (And sweet secret: "one pipe for all things and applicative discovery mechanism on top of it" will work efficiently even on these "rich topologies";)

Just an opinion after my 2-year experience with BT Smart...

Cheers Jan

[Tim]

Perfect thanks! Yeah I could just use a single characteristic and write to/notify from it as if it were a pipe. But that's less discoverable and doesn't really seem like it's in the spirit of BLE!

[Tim]

Jan's answer is great, but actually my problem turned out to be not due to the ATTR_TAB_SIZE. It was because I was using distinct UUIDs for all my characteristics. I totally forgot you are supposed to use a very small number of "base" UUIDs, and then just change the third and forth bytes.

custom_helper.cpp in mBed restricts the number of distinct base UUIDs to 8:

static const unsigned UUID_TABLE_MAX_ENTRIES = 8; /* This is the maximum number of 128-bit UUIDs with distinct bases that
                                                   * we expect to be in use; increase this limit if needed. */

I changed my UUIDs so that the bases match and now it is fine (I also had to increase the hard limit of 20 in nRF5xGattServer.h, but I didn't have to change the ATTR_TAB_SIZE from its default (0x600).

[endnode]

My answer to this exceeds 900-word limit so I amend my answer above;)

(Btw. I hope you've tricked your mBed drivers/SDK to accept more UUIDs under one 128-bit base because all Characteristics should share the UUID base of their ancestor Primary Service, don't they?)

[Tim]

Re update: Interesting, can you explain why the BLE security mechanism doesn't scale? Also is it necessary to do a full service discovery when connecting? If I already know all the GUIDs (because I designed the device) surely I don't need to?