Error enabling connection event extension in UART example

RE: Error enabling connection event extension in UART example

Vidar Berg — Thu, 23 Aug 2018 12:24:26 GMT

Yes, please mention me in the new ticket. Thanks.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Thu, 23 Aug 2018 11:49:36 GMT

I will open a private ticket. Should I tag you in the new ticket?

RE: Error enabling connection event extension in UART example

Vidar Berg — Thu, 23 Aug 2018 07:17:50 GMT

Are you able to share your project so I can try to test it here? You can create a new private ticket if you don't want to post it here. Please provide instructions on how I should test it if you can share it.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Thu, 23 Aug 2018 07:03:09 GMT

Unfortunately this didn't work.

I tried first with the configuration that was already working for me (interval min=max=15, event length=6).
I tried not waiting for BLE_GATTS_EVT_HVN_TX_COMPLETE and just update the indices of the ring buffer if ble_nus_data_send returned with NRF_SUCCESS.

I tried a different approach also, looping ble_nus_data_send until it returned with NRF_SUCCESS, I had many losses/distortions of data.

RE: Error enabling connection event extension in UART example

Vidar Berg — Thu, 23 Aug 2018 06:54:12 GMT

There is a limit to how many packets you can send per event where it won't help to increase the event length. Not sure what it is for the softdevice, but the largest number of packets I have been able to sent is 12 packets (27 byte link layer packet), and that was with a nRF52 and an iphone 7. For better throughput, the central must support data length extension, long MTU and 2M PHY.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Thu, 23 Aug 2018 06:40:19 GMT

I don't fully understand.

What if my connection interval is long and I set a high value for the event length, I still can't send more than 12 packets?

RE: Error enabling connection event extension in UART example

Vidar Berg — Thu, 23 Aug 2018 06:35:23 GMT

dani_cvetanov, thanks for your comments! Clonimmus74, hvn_tx_queue_size defines the number of notification packets you can queue in the softdevice's tx buffer. You can't send more than ~12 packets per connection so I don't think it makes sense to increase the buffer to more than 12.

excerpt from API documentation for sd_ble_gatts_hvx():

The number of Handle Value Notifications that can be queued is configured by ble_gatts_conn_cfg_t::hvn_tx_queue_size When the queue is full, the function call will return NRF_ERROR_RESOURCES. A BLE_GATTS_EVT_HVN_TX_COMPLETE event will be issued as soon as the transmission of the notification is complete.The application can keep track of the available queue element count for notifications by following the procedure below:

Store initial queue element count in a variable.
Decrement the variable, which stores the currently available queue element count, by one when a call to this function returns NRF_SUCCESS.
Increment the variable, which stores the current available queue element count, by the count variable in BLE_GATTS_EVT_HVN_TX_COMPLETE event.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Thu, 23 Aug 2018 06:30:23 GMT

What do you mean by:

"add the message in your queue"

"you can remove completely your queue"

Is there a limit on HVN queue size, and is it measured in bytes?

Thanks

RE: Error enabling connection event extension in UART example

dani_cvetanov — Wed, 22 Aug 2018 17:41:15 GMT

You don't need to wait for BLE_GATTS_EVT_HVN_TX_COMPLETE in order to send the next packet. Just send it whenever you can by calling ble_nus_data_send. Only if it returns error (i.e. the HVN queue is full), then you can add the message in your queue. Or you can remove completely your queue and in case you need more space to buffer the TX packets, then just increase the HVN queue size as mentioned above.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Wed, 22 Aug 2018 14:07:59 GMT

Can you please elaborate, as I'm extremely new to BLE, and Nordic especially....

Thanks

RE: Error enabling connection event extension in UART example

dani_cvetanov — Wed, 22 Aug 2018 14:04:34 GMT

Solved on my side! It seems that our issue is that we have our own message queue and we're waiting for the BLE_GATTS_EVT_HVN_TX_COMPLETE event in order to send the next packet. However, this limits the maximum TX packets to 1 per connection interval. We should use the HVN queue if we want to boost the throughput.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Wed, 22 Aug 2018 11:24:23 GMT

Yes, I tried it with a phone running Android 8 (Honor 9).

I also tried it with Nordic Central (same chip, using eval board PCA10040)

RE: Error enabling connection event extension in UART example

dani_cvetanov — Tue, 21 Aug 2018 15:33:00 GMT

Gents,

I have absolutely the same issue with that SDK and that chip. I have set the MTU to 244 bytes. With the default connection interval (min=20. max=75mS) I get ~700bytes/sec. When I reduce the connection interval to 15mS (min and max), then the throughput increases to 2100bytes/sec.

What are we missing?

RE: Error enabling connection event extension in UART example

Clonimmus74 — Tue, 21 Aug 2018 11:58:27 GMT

Thank you
What is hvn queue size and is there a limit to its size?

RE: Error enabling connection event extension in UART example

Vidar Berg — Tue, 21 Aug 2018 11:20:56 GMT

ble_nus_data_send() will only transfer data if it returns NRF_SUCCESS so your buffer handling appears to be correct. But you are less likely to run out of buffer space when you have a shorter CI (15 ms). Please try to increase the hvn queue size to see if it helps:

in ble_stack_init()

{

...

// Configure the BLE stack using the default settings.
// Fetch the start address of the application RAM.
uint32_t ram_start = 0;
err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
APP_ERROR_CHECK(err_code);

memset(&ble_cfg, 0, sizeof(ble_cfg_t));
ble_cfg.conn_cfg.conn_cfg_tag = APP_BLE_CONN_CFG_TAG;
ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 12;
err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);
APP_ERROR_CHECK(err_code);

RE: Error enabling connection event extension in UART example

Clonimmus74 — Mon, 20 Aug 2018 07:53:03 GMT

As I said, with connection interval of min = 15 max = 15 it works fine, so yes, my ring buffer implementation is good (and used in other projects as well).

What do I do if ble_nus_data_send returns with something other than NRF_SUCCESS?
What I currently do is leave the ring buffer indices as they are (as to force re-transmit). What is not clear is if ble_nus_data_send can return with error but manage to send parts of the data, in which case I will get distorted buffers.

I work in debug mode so I can see if I stop in app_error_fault_handler, so I configured the RAM as was indicated the first time I got an error. still the configurations with higher event length didn't work well.

RE: Error enabling connection event extension in UART example

Vidar Berg — Mon, 20 Aug 2018 07:01:44 GMT

If you see lost or corrupted packets it is likely caused by an error in the application code on one of your devices (see endnode's answer in this thread). As long as ble_nus_data_send() is called with the correct data and returns NRF_SUCCESS you should not see this problem. Have you verified that your ring buffer implementation works as intended?

Given that you are checking return codes, your application would have failed during initialization if you had the wrong RAM configuration.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Sun, 19 Aug 2018 08:08:03 GMT

When I say it doesn't work I mean the transfer is too slow and I lose packets or get distorted ones.

I increased the application RAM but still the mentioned configurations didn't work, was I missing something?

min=max=15 msec is not a good idea for me since it is the minimum allowed by iOS and Android at the moment, if in next versions of the OS they will decide to raise the minimum as they did before, the application will not work (though 30 msec or longer with longer event length, should).

Another solution is to use 100-200 msec interval when using low data rate (45 bytes per second) in my case, and lower it to 15 msec when needed. Not sure if it will work though. constant interval of 200-400 with higher event length seems better, as it covers all scenarios.

RE: Error enabling connection event extension in UART example

Vidar Berg — Fri, 17 Aug 2018 13:32:14 GMT

The transmit code can send "m_ble_nus_max_data_len" bytes at a time. It will not be limited to 20 bytes if the gap central supports a larger MTU. You make the following changes to main.c to print out the actual MTU and link layer packet size:

--- a/examples/ble_peripheral/ble_app_uart/main.c
+++ b/examples/ble_peripheral/ble_app_uart/main.c
@@ -452,7 +452,11 @@ void gatt_evt_handler(nrf_ble_gatt_t * p_gatt, nrf_ble_gatt_evt_t const * p_evt)
     if ((m_conn_handle == p_evt->conn_handle) && (p_evt->evt_id == NRF_BLE_GATT_EVT_ATT_MTU_UPDATED))
     {
         m_ble_nus_max_data_len = p_evt->params.att_mtu_effective - OPCODE_LENGTH - HANDLE_LENGTH;
-        NRF_LOG_INFO("Data len is set to 0x%X(%d)", m_ble_nus_max_data_len, m_ble_nus_max_data_len);
+        NRF_LOG_INFO("MTU is set to %d", p_evt->params.att_mtu_effective);
+    }
+    else if ((m_conn_handle == p_evt->conn_handle) && (p_evt->evt_id == NRF_BLE_GATT_EVT_DATA_LENGTH_UPDATED))
+    {
+        NRF_LOG_INFO("ll len is set to %d", p_gatt->links[m_conn_handle].data_length_effective);
     }
     NRF_LOG_DEBUG("ATT MTU exchange completed. central 0x%x peripheral 0x%x",
                   p_gatt->att_mtu_desired_central,

When you say it doesn't work, is the transfer speed too low, or is it not advertising/connectable? Note that you need to increase the application RAM base when increasing the GAP event length in order to allocate more RAM to the softdevice, see debug log for appropriate RAM base/size.

I would suggest to set min=max=15 msec if that works. The connection param module (ble_conn_params.c) will notify the application through the registered callback if the central rejects the requested connection interval. In that case you have request a new longer interval, or disconnect.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Thu, 16 Aug 2018 08:24:37 GMT

Yes this is a hard requirement, only with Android and Nordic Central (as in PCA10040).
When the data length is 244, m_ble_nus_max_data_len = 244 (or 241 not sure), since in gatt_evt_handler we have:

    m_ble_nus_max_data_len = p_evt->params.att_mtu_effective - OPCODE_LENGTH - HANDLE_LENGTH;

The transmit code sends packets up to m_ble_nus_max_data_len per transmission, but my understanding is that notification (via ble_nus_data_send) can send only 20 bytes at a time, can this be part of the problem?

As I said, it worked for me with connection interval min=max=15 msec, and with the same phone/Nordic central, it didn't work using the following configurations:

1. connection interval min = 200 & max = 400, NRF_SDH_BLE_GAP_EVENT_LENGTH = 160 & BLE_GATT_ATT_MTU_DEFAULT = 23

2. connection interval min = 100 & max = 200, NRF_SDH_BLE_GAP_EVENT_LENGTH = 80 & BLE_GATT_ATT_MTU_DEFAULT = 23

3. connection interval min = 15 & max = 30, NRF_SDH_BLE_GAP_EVENT_LENGTH = 12 & BLE_GATT_ATT_MTU_DEFAULT = 23

4. connection interval min = 15 & max = 30, NRF_SDH_BLE_GAP_EVENT_LENGTH = 6 (without event extension) & BLE_GATT_ATT_MTU_DEFAULT = 23

RE: Error enabling connection event extension in UART example

Vidar Berg — Wed, 15 Aug 2018 13:47:25 GMT

Transfer speed is typically limited by the phone and it will not be possible to guarantee the 906 byte requirement for all phones unfortunately. Is this a hard requirement? I think most, if not all phones support a connection interval of 30 ms, but the number of packets per connection event can be less than 6 (w standard 27 byte link layer packet). See attached pdf section 4.5 for a comparison between a selection of phones that we have tested internally.

devzone.nordicsemi.com/.../BLE_5F00_on_5F00_Android_5F00_v1.0.1.pdf

"244 byte data length means you can send 6x244 bytes every 30 msec?" Yes, this means the radio will send 244 byte packets except the number of packets per event depends on the event length and connection interval. See "Bluetooth Low energy data throughput" in the softdevice specification for max. transfer speed achievable with the softdevice: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.sds/dita/softdevices/s130/ble_data_throughput/ble_data_throughput.html?cp=2_3_1_0_16. Note that support for data length extension, long MTU, and 2M mode is not available on "most" phones, but you can test these features with iphone 7 or newer.

You can use the connection parameter negation module to renegotiate connection interval (doc) as needed (power consumption vs transfer speed).

RE: Error enabling connection event extension in UART example

Clonimmus74 — Tue, 14 Aug 2018 07:45:10 GMT

My Central device can either be iOS (iPhone 6/7 was tested), Android (tested with HTC that has Android 4, and Honor 9 which has Android 8), or Nordic nRF52832 (PCA10040 board).

I managed to get good results with connection interval min=max=15 msec, and NRF_SDH_BLE_GAP_EVENT_LENGTH = 6. I don't like this option as it has no negotiation for connection interval, and I don't want to be limited in case the Central will not support this interval. In addition this interval is not optimized for power consumption in the case where I send small amounts of data (45 bytes once a second).

My understanding of BLE is limited, I don't understand how your configuration can work. 244 byte data length means you can send 6x244 bytes every 30 msec?

I have BLE_GATT_ATT_MTU_DEFAULT = 23, and I saw that I also got 244 byte data length in my configuration, but I don't think it will always be the case, no? if BLE_GATT_ATT_MTU_DEFAULT = 23 the data length can actually be 23, no? In which case, using your configuration, you can achieve only 6x20 per 30 msec, that is about 808 bytes every 220 msec (short of my requirements of 906 bytes).

I tried BLE_GATT_ATT_MTU_DEFAULT = 247, but it caused problems and didn't always work.

When I tried connection interval min = 15 & max = 30, NRF_SDH_BLE_GAP_EVENT_LENGTH = 12 & BLE_GATT_ATT_MTU_DEFAULT = 23, I also got 244 byte data length but had missed/uncompleted packets.

I tried even:

1. connection interval min = 200 & max = 400, NRF_SDH_BLE_GAP_EVENT_LENGTH = 160 & BLE_GATT_ATT_MTU_DEFAULT = 23

2. connection interval min = 100 & max = 200, NRF_SDH_BLE_GAP_EVENT_LENGTH = 80 & BLE_GATT_ATT_MTU_DEFAULT = 23

Most of the data was missed.

Do I need to set the option API in the [Nordic] Central as well? What about Android Central?

RE: Error enabling connection event extension in UART example

Vidar Berg — Mon, 13 Aug 2018 13:40:05 GMT

Hi,

The option API must be called after sd_ble_enable(). This is probably why you got 0x3001 error ( corresponds to BLE_ERROR_NOT_ENABLED) . As for the data rate, are you using a central device that supports Data length extension (nRF52 dev kit or a newer ios/android device)? I did a quick test with the ble_app_uart example and an iphone 7 and got ~9.8 kB/s throughput @ 30 ms , 244 byte data length, NRF_SDH_BLE_GAP_EVENT_LENGTH = 6.

RE: Error enabling connection event extension in UART example

Clonimmus74 — Mon, 13 Aug 2018 10:53:17 GMT

Moved the code right after ble_stack_init();

Now the error doesn't appear, but data rate is awful.

I have connection interval min = 15, max = 30

Event length = 12

sending 906 bytes every 220msec and every 4-6 packets I have a few packets missing.

The data is sent, instead of within the interrupt, in main, using the following function:

static void SendDataToHost(void)
{
  static uint16_t length_to_send;
  static uint16_t current_length_to_send;

  uint32_t err_code;

  if (ring_buffer_out_point < ring_buffer_fill_point)
    length_to_send = ring_buffer_fill_point - ring_buffer_out_point;
  else if (ring_buffer_out_point > ring_buffer_fill_point)
  {
    length_to_send = kEND_OF_TX_RING_BUFFER_LOCATION - ring_buffer_out_point;
    length_to_send += (ring_buffer_fill_point - application_tx_ring_buffer);
  }

  do
  {
    if (f_ble_tx_complete)
    {
      if (length_to_send > m_ble_nus_max_data_len)
      {
        current_length_to_send = m_ble_nus_max_data_len;

        if ((current_length_to_send + ring_buffer_out_point) > kEND_OF_TX_RING_BUFFER_LOCATION)
          current_length_to_send = kEND_OF_TX_RING_BUFFER_LOCATION - ring_buffer_out_point;

        f_ble_tx_complete = 0;
        err_code = ble_nus_data_send(&m_nus, ring_buffer_out_point, &current_length_to_send, m_conn_handle);

        if (err_code != NRF_SUCCESS)
          f_ble_tx_complete = 1;
        else
        {
          ring_buffer_out_point += current_length_to_send;
          if (ring_buffer_out_point >= kEND_OF_TX_RING_BUFFER_LOCATION)
            ring_buffer_out_point = application_tx_ring_buffer;
          length_to_send -= current_length_to_send;
          current_length_to_send = 0;
        }
      }
      else if (length_to_send)
      {
        if ((length_to_send + ring_buffer_out_point) > kEND_OF_TX_RING_BUFFER_LOCATION)
          current_length_to_send = kEND_OF_TX_RING_BUFFER_LOCATION - ring_buffer_out_point;
        else
          current_length_to_send = length_to_send;

        f_ble_tx_complete = 0;
        err_code = ble_nus_data_send(&m_nus, ring_buffer_out_point, &current_length_to_send, m_conn_handle);
        if (err_code != NRF_SUCCESS)
          f_ble_tx_complete = 1;
        else
        {
          ring_buffer_out_point += current_length_to_send;
          if (ring_buffer_out_point >= kEND_OF_TX_RING_BUFFER_LOCATION)
            ring_buffer_out_point = application_tx_ring_buffer;
          length_to_send -= current_length_to_send;
          current_length_to_send = 0;
        }
      }
    }
  } while(length_to_send);

  length_to_send = 0;
  current_length_to_send = 0;

  (void)err_code;
}

The ring buffer is of 4KB.

f_ble_tx_complete is set in BLE_GATTS_EVT_HVN_TX_COMPLETE event.