Custom Service Structure

RE: Custom Service Structure

endnode — Thu, 02 Nov 2017 22:05:06 GMT

No, once you use SD API call to create Characteristic with Notification or Indication GATT method capability the stack will take care to create CCCD handle automatically for you. All you need to do is store handles' references returned in p_handles structure supplied to sd_ble_gatts_characteristic_add call for future use because there you have both your Characteristic Value handle and CCCD handle (so once there is Write event you can check to which one, look into data and interpret them correctly).

RE: Custom Service Structure

phipi — Thu, 02 Nov 2017 17:00:04 GMT

And finally, I need to create a separate notify enable flag for each characteristic, correct?

RE: Custom Service Structure

endnode — Thu, 02 Nov 2017 16:36:38 GMT

Yes, NUS is exactly such multipurpose "tube" example and that's also the reason why it is so popular;) From GATT Server side you have basically 3 options (pull method through Read and push methods Notification and Identification) from which Notify method is the most effective (only simple command no round-trip needed).

RE: Custom Service Structure

phipi — Thu, 02 Nov 2017 16:18:13 GMT

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.

RE: Custom Service Structure

endnode — Thu, 02 Nov 2017 15:06:17 GMT

(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.)

RE: Custom Service Structure

endnode — Thu, 02 Nov 2017 15:03:49 GMT

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)

RE: Custom Service Structure

phipi — Thu, 02 Nov 2017 14:11:53 GMT

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?

RE: Custom Service Structure

endnode — Wed, 01 Nov 2017 22:36:56 GMT

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