This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Custom Service Structure

I need to create a service on the nRF52832 that can send large amounts of a few different data types to the central device. For instance

  • ADC1 sampling (~256 bytes/s)
  • ADC2 sampling (~256 bytes/s)
  • IMU orientation (32 bytes/s)

And I also need to be able to receive commands from the central. This would be things like:

  • Start/ Stop sampling
  • Update device name
  • Enter Test Mode
  • Device shutdown

Should I create 1 service, and a separate characteristic for each data that I need to send? What's the best way to handle the incoming commands?

Parents
  • Depend on what is your major criteria;) Is it speed hence minimal overhead during GATT service discovery right after connection is established or you don't care about that (e.g. because your use case is rather "all the time connected" or "devices will be always bonded and GATT Server stack will be static hence Client will use cache all the time") and you rather prefer having it "nice"? I guess answering this question will give you also immediately answer to your original one;)

  • Yes, there are downsides of using ANY number of GATT objects (Services/Characteristics/Descriptors...): general GATT Clients (as implemented in Android/iOS/Windows BLE stacks) tend to do firstly so-called "full GATT Service discovery" which can cost you 1-4 connection intervals per such object. In other words if you use Android phone with default 48.75ms interval it will take 50-200ms more per each new Characteristic added to your profile. Therefore people who are interested into minimal latency between connection and actual data transfer on application layer use "one service + one characteristic" rule and have everything wrapped on top of GATT in their own application protocol (typically some headers are saying "this is command for management, this is data transfer of type X, this is transfer of type Y etc.") Simply build a tube on top of GATT to speed that layer discovery.

    (1/2)

Reply
  • Yes, there are downsides of using ANY number of GATT objects (Services/Characteristics/Descriptors...): general GATT Clients (as implemented in Android/iOS/Windows BLE stacks) tend to do firstly so-called "full GATT Service discovery" which can cost you 1-4 connection intervals per such object. In other words if you use Android phone with default 48.75ms interval it will take 50-200ms more per each new Characteristic added to your profile. Therefore people who are interested into minimal latency between connection and actual data transfer on application layer use "one service + one characteristic" rule and have everything wrapped on top of GATT in their own application protocol (typically some headers are saying "this is command for management, this is data transfer of type X, this is transfer of type Y etc.") Simply build a tube on top of GATT to speed that layer discovery.

    (1/2)

Children
No Data
Related