• State Verified Answer
  • Replies 10 replies
  • Subscribers 63 subscribers
  • Views 9540 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 109488
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

  • 0 in reply to endnode

    Re Security: there is actually only one mode which is really secure in BT SIG 4.0&4.1 defined for LE: OOB (Out-Of-Bend). There you distribute the keys yourself (e.g. derive from static master key known to all parts or transported by other media such as keyboard or NFC). With fix in spec 4.2 which brings asymmetric bootstrapping with ECC it makes some sense to use "native" security layer provided by LE stack but it isn't really adopted yet. In addition to the scaling: most of the implementations (e.g. all SoftDevices from Nordic) are limiting number of devices (logically - it's deeply embedded system not server with "unlimited" space for large DB) - number is 8 I guess. So you cannot really deploy system where devices on both sides "randomly" meet and communicate securely (unless you do it on applicative layer which is what all the guys such Apple HomeKit or Google Weave).

  • 0 in reply to endnode

    Re discovery procedure: you are right, if stack on peripheral side is static (+ does not provide "Service Changed Characteristic") it's good chance that central stack will cache it (link it to Adv. Address). However this is not perfect because also central stack is some sort of embedded device so it cannot log all the addresses, it is also usually out of your control (e.g. in the mobile phone or similar rich OS platform) so you never know if and how well it does this caching (it can decide to delete "old" records randomly or based on time or just during OS upgrade...) So in general there are catches and if you claim that in your special case it will work (which I'm perfectly fine and in-line) then it leads back to my original remark: why to make it so "general" and complex when in the end it will be just your proprietary protocol between one "peripheral" and dedicated "central app"?

  • 0 in reply to 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).

  • 0 in reply to Tim

    I've not read that anywhere - and actually it worked with every service and characteristic having totally different base UUIDs (up to the limit of 8). However in my code I now use the same base UUID for everything.

  • 0 in reply to Tim

    You are right, BT SIG don't mandate grouping 128-bit UUIDs by any base for Service and its Characteristics, it's just the routine.

Related