Indication and GATT DB

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

I am having some issues understand some concepts of the data transfer in BLE.

Basically, what I want to do is to transfer several KBs of persistent data to a client, in a reliable fashion.

So from what I understood I should use the bleprofile_sendIndication function.

But I have trouble understand the role of the GATT DB in this case. The prototype of bleprofile_sendIndication is the following

void bleprofile_sendIndication(HANDLE, DATA, LENGTH, CALLBACK)

Why do I need to specify the HANDLE? The function is going to store DATA into the GATT DB, then send the indication to ask the client to read the recently stored value? Or is the DATA is directly sent through the network?

The CALLBACK is triggered when the server receives the ACK?

An unrelated question: How do I write more than 23B of data into the GATT from the server? The bleprofile_writeHandle function takes a PDU struct which takes 23 bytes of data maximum.

Thank you for your insights.

0 Likes
1 Solution
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

For easier implementation, it's recommended that you start off with bleprofile_sendNotification(...). The only difference between indications and notifications is that an indication requires an ack from the client at the application level. As a result this will slow your data rate.

"The function is going to store data into the GATT DB, then send the indication to ask the client to read the recently stored value? Or is the DATA is directly sent through the network?"

     In sending a notification, you're not requesting that the client read your GATT DB, you're actively pushing that data out over the air for the client to receive (whether or not the client wants to receive it). *The client can notify you that it doesn't want to be pushed notifications via a client configuration descriptor, but this is not definitive. You can still push the data over the radio, but it won't be received.


The callback is irrelevant to you if you do, indeed, use the notification functionality as recommended.

"How do I write more than 23B of data into the GATT from the server? The bleprofile_writeHandle function takes a PDU struct which takes 23 bytes of data maximum."

     23 bytes is the size of a characteristic per the BLE spec. You can refill a single characteristic and send it over the radio via notification every 7.5ms (maximum speed per connection interval). OR you can have multiple characterisitics and send them one at a time, but you cannot send more than 23 bytes per 7.5ms, per the BLE spec (in reality 20 bytes is available for raw data).

     However, there does exist something in the SDK called a long characteristic which supports a variable length value. But this long characterisitic is not yet supported by the the BLE spec and therefore will not be received correctly by anything other than a Broadcom chip on the other end.


Conceptual steps for sending a notification:

     Read Handle

     Write Handle

     Call send notification

     *at this point the app waits for whats called a connection event, at which point the notification will be sent

     *These connection events are what can be set to as low at 7.5 ms, but only if the client approves that fast of a rate

     *Once this notification is blasted, register a callback to re-begin this process for the next notification


Jacob

View solution in original post

5 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

For easier implementation, it's recommended that you start off with bleprofile_sendNotification(...). The only difference between indications and notifications is that an indication requires an ack from the client at the application level. As a result this will slow your data rate.

"The function is going to store data into the GATT DB, then send the indication to ask the client to read the recently stored value? Or is the DATA is directly sent through the network?"

     In sending a notification, you're not requesting that the client read your GATT DB, you're actively pushing that data out over the air for the client to receive (whether or not the client wants to receive it). *The client can notify you that it doesn't want to be pushed notifications via a client configuration descriptor, but this is not definitive. You can still push the data over the radio, but it won't be received.


The callback is irrelevant to you if you do, indeed, use the notification functionality as recommended.

"How do I write more than 23B of data into the GATT from the server? The bleprofile_writeHandle function takes a PDU struct which takes 23 bytes of data maximum."

     23 bytes is the size of a characteristic per the BLE spec. You can refill a single characteristic and send it over the radio via notification every 7.5ms (maximum speed per connection interval). OR you can have multiple characterisitics and send them one at a time, but you cannot send more than 23 bytes per 7.5ms, per the BLE spec (in reality 20 bytes is available for raw data).

     However, there does exist something in the SDK called a long characteristic which supports a variable length value. But this long characterisitic is not yet supported by the the BLE spec and therefore will not be received correctly by anything other than a Broadcom chip on the other end.


Conceptual steps for sending a notification:

     Read Handle

     Write Handle

     Call send notification

     *at this point the app waits for whats called a connection event, at which point the notification will be sent

     *These connection events are what can be set to as low at 7.5 ms, but only if the client approves that fast of a rate

     *Once this notification is blasted, register a callback to re-begin this process for the next notification


Jacob

Anonymous
Not applicable

Conceptual steps for sending a notification:

     Read Handle

     Write Handle

     Call send notification

     *at this point the app waits for whats called a connection event, at which point the notification will be sent

     *These connection events are what can be set to as low at 7.5 ms, but only if the client approves that fast of a rate

     *Once this notification is blasted, register a callback to re-begin this process for the next notification


Jacob

jakewtorres

And if sending notifications does not involve writing the data to the GATT DB, why do we need to specify the handle of a characteristic when calling bleprofile_sendNotification()? Because the data sent is not related to the GATT DB.

How do you register a callback for a notification? I know how to do this with an indication but not with a notification.

0 Likes

Sending a notification is based completely around the GATT DB. You must write your data to the GATT DB, then call sendNotification() to send that specific characteristic's data out on the next connection event. All data that is sent out the radio, first passes through the GATT DB.

There's no way to register for a callback to a notification. There is a way to register for notifications some amount of time prior to a connection event, but that doesn't mean that a notification was sent in that connection event. An example of this can be found in wiced_sense.c. Indications have callbacks as a result of them requiring an ACK to be sent.

Jacob

Anonymous
Not applicable

Even though the data might not have to be related to the GATT DB, but the notifications are related to the GATT DB.

The notifications packets have information about the attribute(which includes the handle).

pastedImage_1.png

Anonymous
Not applicable

Alright... I got it!

Thank you for the support.

0 Likes