Custom Service Structure

[phipi]

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?

[endnode]

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;)

[phipi]

The device is not always connected but the central will command the device to start sampling and sending data so essentially it will be connected the whole time it's sampling. Are there downsides for using a separate characteristic for ADC1, ADC2, IMU and Commands other than discovery overhead?

[endnode]

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)

[endnode]

(2/2)

However if you don't care about 1-3 seconds of delay between actual connection on link layer and start of data transfer on application layer then you want to at least separate Tx and Rx "tubes" into two characteristics (because it seems that this can help with bandwidth during full-duplex transfers if you have them in your use case) or go and separate each "function" to separate characteristics (one for reporting of sensor data type X1, second for reporting of sensor data X2, third for sending management commands to sensor gateway etc.)

[phipi]

Thanks, that makes a lot of sense. For sending the ADC data is the proper way still to use notification from the device? Also, is it possible to use a single global notify enable? I'm working from the NUS sample which seems like it's close to what I'm looking to do.