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

[endnode]

And btw. if you start to care really about security (which I hope all the people involved in IoT will soon!) then you encounter problems such as anonymity through tracking of MAC addresses (Adv. Address in case of BLE GAP Peripheral role). This is already problem with classic BT and Wifi and some manufactures (e.g. iOS) already started to randomize these things (at least a bit - e.g. with long rotation period but but better then nothing). Now if you project this into BLE I believe you see where it is going (and why it is again more interesting to use "minimal" part of BLE stack as "tube" and do clever things on applicative layer - unless you design really largely interoperable schemes such as new GAP profile which should work on various devices from multiple vendors or you are designing new IoT protocol which should be widely adopted and coexist with current GAP profiles).