Can not notify

RE: Can not notify

Ulrich Myhre — Mon, 03 Aug 2015 09:34:37 GMT

You are right, I could have been more clear here. I wanted to highlight that buffer_count_get() does not return the number of free buffers, but the maximum number of available buffers. I will edit my answer to mention reconnections.

RE: Can not notify

Matteo Scordino — Tue, 28 Jul 2015 10:49:27 GMT

I think there is an error here; you should not "Get the maximum number of buffers" ONCE as stated in the answer. I think you should do it at every reconnection, otherwise the counter will get out of sync with the actual number of available buffers and you will be unable to transmit.

This is what I see: if a disconnection occurs after one buffer is used and BEFORE it is freed again, you won't get a BLE_EVT_TX_COMPLETE event, but on disconnection the buffers will be freed. As a result, you will think that you have N-1 available buffers, but you actually have N. This will accumulate every time you have a disconnection while a packet is "over the air", with the result that in the end you will always think you have 0 available buffers.

RE: Can not notify

Ulrich Myhre — Thu, 19 Mar 2015 16:10:03 GMT

Hi,

Please refer to the documentation for sd_ble_gatts_hvx() and sd_ble_tx_buffer_count_get() for information on this.

The application has a number of application buffers available to be queued for sending, and you must keep track of these. This is well-explained in the documentation for buffer_count_get(), but in short pseudo-code you would do something like this:

// Get the maximum number of buffers (this is done in the CONNECTED event, only once per connection)
uint32_t buffers_free;
sd_ble_tx_buffer_count_get(&buffers_free);

// When calling a function that consumes a buffer
if (buffers_free > 0) { // Else, queue it internally in your app - or discard
    sd_ble_gatts_hvx(...);
    buffers_free--;
}
on_ble_evt(evt) {
   switch (evt->header.evt_id) {
       case BLE_EVT_TX_COMPLETE:
           buffers_free += evt.count;
           break;
      case other events:
         (...)

If the connection interval is longer than the sending rate, the peer is NACKing the packets (its buffers are full), or i there is too much noise to do the full throughput you will eventually run out of application buffers. All the successfully queued packets will eventually be sent, in the same order as you queued them.