Hello everyone,
i am using SDK 5.0.3 to program a DA14583 Bluetooth peripheral.
I have a specific Question to the following code part:
struct custs1_val_ntf_req* req = KE_MSG_ALLOC_DYN(CUSTS1_VAL_NTF_REQ,
TASK_CUSTS1,
TASK_APP,
custs1_val_ntf_req,
DEF_CUST1_NTF_CHAR_LEN);
...
ke_msg_send(req);
I assume this code will result in a Notification message (based on CUSTS1_VAL_NTF_REQ), which is an asynchronous message, without waiting for an acknowledge packet, is that right?
I want to make use of as much as possible packets per connection interval (highest throughput) and this is why i think i should use messages without acknowledgements, is that also right?
My peripheral is connected to a Samsung Galaxy S5, which supports (i am not that sure about it, but i think it is) 5 packets per connection interval, since i can see 5 peaks within one connection intervall on the oscilloscope by measuring the current drawn by the chip.
However, based on counting the packets i receive on the smartphone (checked for packet loss by counters) in a certain time interval and considering the connection interval parameter chosen by the smartphone, i calculated an average of 2,5 packets per connection interval.
As i expected it to be 5 packets per CI, this leads me to the assumption, the the sending operation invoked by my DA14583 code, are somehow acknowledged and thereby dropping the average usable packets per CI to 2.5 (half of possible packets per CI).
Can someone tell me, whether i am right with my assumption or if i indeed invoke a asynch message sending and the issue must be somewhere else?
Kind regards,
Florian
Hi fgruetzmacher,
Yes the snippet that you pasted in your post, allocates and sends a command that the profile level of your application will handle and it will result in sending a notification to the central that you have a connection with, if with the asynchronous you mean that there is no application ack from the master side, then yes, the notifications dont involve ack's in the BLE spec.
The amount of packets send by the peripheral depends on the central, for example the peripheral might be able to send more than 5 packects (in the case of the 58x more than 5 packets can be send in one connection interval) but that does not mean that the central will stay awake and receive those packets, the flag that indicates to the central that the peripheral wishes to send more data is the MD flag. The flow control and ackowledgement in the notifications is done by a lower level of the BLE stack (Link Layer) using the SN and NESN bits in order to implement a lazy ackowledgement scheme, so there is an ack scheme in BLE but not in a higher level that you could control from your application. You can find more info regarding the MD, SN and NESN flags in the BLE specification.
Thanks MT_dialog