<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/69472/ble-multilink-att-timeout-problem-occurs-when-the-number-of-connections-increases</link><description>Recently I am using BLE in Zephyr to implement the multilink central function However, none of the references currently have a similar function, and there is also the nordic zephyr code https://github.com/nrfconnect/sdk-nrf &amp;lt;-There are only examples of</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 21 Dec 2020 09:59:25 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/69472/ble-multilink-att-timeout-problem-occurs-when-the-number-of-connections-increases" /><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285999?ContentTypeID=1</link><pubDate>Mon, 21 Dec 2020 09:59:25 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6603b040-fcab-4bac-b6d2-19f1768c1f18</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Poyi,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;I would suggest to try testing using our Softdevice LL.&amp;nbsp;&lt;br /&gt;Please note that in this support channel we focus on Nordic&amp;#39;s products so if you plan to use Zephyr LL,&amp;nbsp;you may want to post your question on the Zephyr Github channel.&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285912?ContentTypeID=1</link><pubDate>Fri, 18 Dec 2020 19:32:25 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b8ddffa4-5abf-4843-af1a-9c705f6bd859</guid><dc:creator>hmw</dc:creator><description>&lt;p&gt;Hello,&lt;br /&gt;I think I use Zephyr natively&lt;br /&gt;I have set this in my autocpnf.h&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;#define CONFIG_BT_LL_SW_SPLIT 1&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;Also in my autoconf.h did not see &lt;strong&gt;CONFIG_BT_LL_SOFTDEVICE&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;I am glad to hear this news, if there is any improvement, please let me know&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks,&lt;/p&gt;
&lt;p&gt;Poyi&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285893?ContentTypeID=1</link><pubDate>Fri, 18 Dec 2020 16:07:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a077d0f4-008e-45ee-85fd-59810b4668a3</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Poyi,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Did you use our NCS repository or you are using Zephyr natively ?&amp;nbsp;&lt;br /&gt;You can check inside autoconf.h to see if you have&amp;nbsp;CONFIG_BT_LL_SOFTDEVICE 1 or not.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;By default if you use NCS and if you don&amp;#39;t&amp;nbsp;have&amp;nbsp;&lt;span&gt;CONFIG_BT_LL_SW_SPLIT =y then it will be our softdevice LL used.&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Our team is working with the case on github that I pointed. I will check with them and get back to you if we find anything.&amp;nbsp;&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285708?ContentTypeID=1</link><pubDate>Thu, 17 Dec 2020 17:40:10 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6e7bd8ca-d542-4337-be8b-12efd9a3ec3b</guid><dc:creator>hmw</dc:creator><description>[quote userid="2121" url="~/f/nordic-q-a/69472/ble-multilink-att-timeout-problem-occurs-when-the-number-of-connections-increases/285703#285703"] you will need a bigger buffer than 18[/quote]
&lt;p&gt;In zephyr, I can only set it to 18 at most, and it cannot be set even larger than this. If I set more than 18, I will not be able to compile&lt;/p&gt;
[quote userid="2121" url="~/f/nordic-q-a/69472/ble-multilink-att-timeout-problem-occurs-when-the-number-of-connections-increases/285703#285703"] You may receive an error of full buffer when you try to queue write command when buffer is full.&amp;nbsp;[/quote]
&lt;p&gt;The error is in &lt;strong&gt;\zephyr\subsys\bluetooth\controller\hci\hci.c&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Shown in&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;node_tx = ll_tx_mem_acquire();
if (!node_tx) {
    BT_ERR(&amp;quot;Tx Buffer Overflow&amp;quot;);
    data_buf_overflow(evt);
    return -ENOBUFS;
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I am not sure which LL I am using, I did not set &lt;strong&gt;BT_LL_SOFTDEVICE&lt;/strong&gt; in my prj.conf&lt;br /&gt;I downloaded the sample from Zephyr&amp;#39;s official website to make changes. Website:&lt;a href="https://github.com/zephyrproject-rtos/zephyr"&gt;https://github.com/zephyrproject-rtos/zephyr&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;I am currently connected to 15 connections, there will be TX overflow, is there any good way, or what can explain the reason for this error&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks,&lt;/p&gt;
&lt;p&gt;Poyi&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285703?ContentTypeID=1</link><pubDate>Thu, 17 Dec 2020 17:09:16 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8f9a531b-cdb9-4857-b6ba-757bacd715d1</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Poyi,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;I meant if you queue a write command for every single connection&amp;nbsp;on every connection event, you will need a bigger buffer than 18 as you have 20 connection concurrently. However, this shouldn&amp;#39;t cause tx overflow as far as I know. You may receive an error of full buffer when you try to queue write command when buffer is full.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Please note that our softdevice controller currently only officially support maximum 20 concurrent connections at a time. See &lt;a href="https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/bluetooth/Kconfig#L16"&gt;here&lt;/a&gt;. I assume you plan to use&lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_ble_controller.html"&gt; our&amp;nbsp;Nordic LL &lt;/a&gt;? not the Zephyr LL ? From what I can tell when compiling locally here you are using our Nordic LL.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;If you are sending your data at 1s interval I don&amp;#39;t see much point of having shorter interval, please describe your application in more detail.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Please try again with&amp;nbsp;CONFIG_THREAD_NAME=y so that the thread got overflow be printed out.&amp;nbsp;&lt;br /&gt;&lt;br /&gt;But could you clarify that you no longer see MPU fault and now only see TX Overflow ? On how many peripherals connected do you start seeing that ?&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285442?ContentTypeID=1</link><pubDate>Wed, 16 Dec 2020 17:42:45 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:04d2f600-d5c5-476f-8aef-061c5256ce53</guid><dc:creator>hmw</dc:creator><description>&lt;p&gt;Hello&lt;br /&gt;&lt;br /&gt;I don&amp;#39;t quite understand what you mean&lt;/p&gt;
[quote userid="2121" url="~/f/nordic-q-a/69472/ble-multilink-att-timeout-problem-occurs-when-the-number-of-connections-increases/285429#285429"]you may pass the number of 18 tx buffer .&amp;nbsp;[/quote]
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;It is true that my problem is very similar to it, but no one has provided a good solution yet, which troubles me a lot.&lt;br /&gt;The problem now is that I keep sending, and &lt;strong&gt;Tx Buffer Overflow&lt;/strong&gt; will appear in the central after a while.&lt;br /&gt;&lt;pre class="ui-code" data-mode="text"&gt;&amp;lt;err&amp;gt; bt_ctlr_hci: Tx Buffer Overflow&lt;/pre&gt;&lt;br /&gt;When this error occurs, my central will continue to send data, but some peripherals will not receive the &lt;strong&gt;bt_gatt_write_without_response&lt;/strong&gt; sent by central, but they will still stay connected to central&lt;/p&gt;
&lt;p&gt;In this case, it seems that there is no clear solution&lt;/p&gt;
&lt;p&gt;Is 500ms your estimated value, or is there an algorithm?&lt;/p&gt;
&lt;p&gt;I will try to look at 500ms and 1s, but in my situation, if I can transmit and receive data as quickly as possible, the better&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks,&lt;/p&gt;
&lt;p&gt;Poyi&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285429?ContentTypeID=1</link><pubDate>Wed, 16 Dec 2020 16:07:36 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9ef361e5-d4b7-4253-9492-70d57c1703d6</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Poyi,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Please clarify do you still see the error when you change these to:&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096&lt;br /&gt;CONFIG_BT_RX_STACK_SIZE=4096&lt;/p&gt;
&lt;p&gt;But this suggestion was based on the MPU (memory protection unit) fault, it suggested there was an issue with the memory/stack.&lt;/p&gt;
&lt;p&gt;You may think of increasing&amp;nbsp;CONFIG_BT_L2CAP_TX_BUF_COUNT. If you have 20 peripheral and if you try to send a write command to all of the 20 peripherals you may pass the number of 18 tx buffer .&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Your issue seems to be similar to this on going report:&amp;nbsp;&lt;a href="https://github.com/zephyrproject-rtos/zephyr/issues/30378"&gt;https://github.com/zephyrproject-rtos/zephyr/issues/30378&amp;nbsp;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Could be the same issue.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Do you have a sniffer ? If you can sniff the whole activity we can check which exact action caused the timeout.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;My concern is that when you have 20 connection, and each connection has an interval of 90ms there are only 4.5ms for each connection and if the scheduler couldn&amp;#39;t schedule all the connections good enough you will have packet drop. I would suggest to change the device that sends packet every one second to switch to 1 second interval instead of 90ms. Or at least change them to 500ms interval.&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285266?ContentTypeID=1</link><pubDate>Wed, 16 Dec 2020 09:54:10 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:62fff422-5ca7-4e84-92e5-705f3aa81384</guid><dc:creator>hmw</dc:creator><description>&lt;p&gt;You mean, I set&lt;br /&gt;&lt;pre class="ui-code" data-mode="text"&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096&lt;/pre&gt;&lt;br /&gt;Come again&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096&lt;/pre&gt;&lt;br /&gt;Is that so?&lt;/p&gt;
&lt;p&gt;In addition, currently the smallest can only be set like this&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_BT_CTLR_DATA_LENGTH_MAX=32
CONFIG_BT_L2CAP_TX_MTU=65
CONFIG_BT_L2CAP_RX_MTU=65&lt;/pre&gt;&lt;br /&gt;I don&amp;rsquo;t know if it matches my packet size&lt;/p&gt;
&lt;p&gt;Currently my central only uses bt_gatt_write_without_response&lt;br /&gt;And bt_gatt_write_without_response is in cmd_write&lt;br /&gt;The method to change to work_queue is as follows&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;void write_work_handler(struct k_work *work)
{
int err;
printk(&amp;quot;test now_conn %d\n&amp;quot;,now_conn);
cmd_write(service_handle, now_conn);
To
}
K_WORK_DEFINE(write_work, write_work_handler);&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;ATT Timeout appears after a while after connecting with all peripherals, and the time of appearance is random&lt;/p&gt;
&lt;p&gt;I don&amp;rsquo;t really understand the data traffic you mentioned. I thought that after cnetral announced the interval connection, the peripherals would automatically select an interval value to determine how long it would take to send it.&lt;/p&gt;
&lt;p&gt;Five of my peripherals will be sent every 100ms, the rest will be sent every 1 second, and 8bytes will be sent every time.&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;static uint8_t test[8];

rc = bt_gatt_notify(NULL, &amp;amp;hrs_svc.attrs[1], &amp;amp;test, sizeof(test));&lt;/pre&gt;&lt;br /&gt;test[8] is the data that my peripheral wants to send&lt;/p&gt;
&lt;p&gt;and also&lt;br /&gt;Is there any good solution to the Tx Buffer Overflow error mentioned above?&lt;br /&gt;&lt;pre class="ui-code" data-mode="text"&gt;[00:36:55.371,032] &amp;lt;err&amp;gt; bt_ctlr_hci: Tx Buffer Overflow
[00:36:55.371,063] &amp;lt;wrn&amp;gt; bt_hci_core: Data buffer overflow (link type 0x01)
[00:36:55.371,063] &amp;lt;err&amp;gt; bt_conn: Unable to send to driver (err -55)&lt;/pre&gt;&lt;br /&gt;Or is it related to my &lt;strong&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE&lt;/strong&gt; and &lt;strong&gt;CONFIG_BT_RX_STACK_SIZE&lt;/strong&gt;?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks,&lt;/p&gt;
&lt;p&gt;Poyi&lt;/p&gt;
&lt;div style="left:-17px;position:absolute;top:955px;" id="gtx-trans"&gt;
&lt;div class="gtx-trans-icon"&gt;&lt;/div&gt;
&lt;/div&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285251?ContentTypeID=1</link><pubDate>Wed, 16 Dec 2020 09:14:14 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:93d87547-3bd3-4918-9d56-7eaacae94cc3</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Poyi,&amp;nbsp;&lt;br /&gt;Please try to increase one stack size at a time.&amp;nbsp;&lt;br /&gt;I would suggest to increase&amp;nbsp;CONFIG_BT_RX_STACK_SIZE first. The current default value in your project as 1024, correct ? Please try to increase it to 2048 first.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;The next you want to try is&amp;nbsp;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE. Please try with 4096. I don&amp;#39;t think the CONFIG_MAIN_STACK_SIZE need to be increased.&amp;nbsp;&lt;br /&gt;Please make sure you put all the BLE API calls in to a work queue, or in main thread.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;If you don&amp;#39;t plan send large data packet, please set the&amp;nbsp;CONFIG_BT_L2CAP_RX_MTU ,&amp;nbsp;CONFIG_BT_CTLR_DATA_LENGTH_MAX to match with your packet size.&amp;nbsp;&lt;br /&gt;&lt;br /&gt;Please let me know until how many peripherals do&amp;nbsp; you see the &amp;quot;ATT Timeout&amp;quot; error ? What&amp;#39;s the data traffic ? How often the peripheral send notification? What&amp;#39;s the data size of the notification?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;Please try testing with larger connection interval and with slave latency.&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285239?ContentTypeID=1</link><pubDate>Wed, 16 Dec 2020 08:42:40 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3084cf12-e82e-4ae1-9be0-89def7289f67</guid><dc:creator>hmw</dc:creator><description>&lt;p&gt;Hello&lt;br /&gt;I modified the following parameters to&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096&lt;/pre&gt;&lt;br /&gt;Then an error appeared, as shown in the figure below. What is the cause of this?&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;&amp;lt;wrn&amp;gt; bt_conn: Disconnected while allocating context&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/communityserver-discussions-components-files/4/pastedimage1608107979933v1.png" alt=" " /&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;After trying to change these three parameters to 8192, the above error did not appear.&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
CONFIG_MAIN_STACK_SIZE=8192
CONFIG_BT_RX_STACK_SIZE=8192&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;But there is a Tx Buffer Overflow error, as shown below&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;[00:36:55.371,032] &amp;lt;err&amp;gt; bt_ctlr_hci: Tx Buffer Overflow
[00:36:55.371,063] &amp;lt;wrn&amp;gt; bt_hci_core: Data buffer overflow (link type 0x01)
[00:36:55.371,063] &amp;lt;err&amp;gt; bt_conn: Unable to send to driver (err -55)&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/communityserver-discussions-components-files/4/pastedimage1608108023968v2.png" alt=" " /&gt;&lt;/p&gt;
&lt;p&gt;However, it didn&amp;rsquo;t stop my data transmission, but it looks like it&amp;rsquo;s not right&lt;br /&gt;For my TX Buffer related settings, I set the official maximum value, as follows&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_BT_CONN_TX_MAX=18
CONFIG_BT_L2CAP_TX_BUF_COUNT=18
CONFIG_BT_CTLR_RX_BUFFERS=18
CONFIG_BT_CTLR_TX_BUFFERS=18
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_RX_MTU=247
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_RX_BUF_LEN=258&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;How can I modify it to prevent the Data buffer overflow error from happening again?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks.&lt;/p&gt;
&lt;p&gt;Poyi&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285152?ContentTypeID=1</link><pubDate>Tue, 15 Dec 2020 15:49:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b79e280d-b83a-492a-a62b-a9460540d77c</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;It will the actual byte you send so if you set the length to 8 the actual number of byte should be 15 bytes (7 bytes overhead). If you don&amp;#39;t plan to send large packet, you can reduce the MTU size and the Datalength max. This is given the notification from the peers also don&amp;#39;t have large packet size.&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285151?ContentTypeID=1</link><pubDate>Tue, 15 Dec 2020 15:40:09 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:44ce2c97-6e6e-4226-a3ab-24c0bfafb229</guid><dc:creator>hmw</dc:creator><description>&lt;p&gt;Is there any relationship between the connection interval and the number of peripherals?&lt;br /&gt;What if I want to connect 20 peripherals?&lt;/p&gt;
&lt;p&gt;So I set ATT_MTU 247 bytes and DLE 251 bytes, is it actually sending so many bytes?&lt;/p&gt;
&lt;p&gt;I thought my &lt;strong&gt;write_params.length&lt;/strong&gt; set to 8 would only send 8 bytes&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;write_params[bt_conn_index(conn)].length = 8;&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;&lt;/p&gt;
&lt;p&gt;You mean that in my prj.conf&lt;br /&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_BT_RX_BUF_LEN=258
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_RX_MTU=247&lt;/pre&gt;&lt;br /&gt;Can these be changed to 8 or 16 bytes, so that my interval can be set smaller?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285147?ContentTypeID=1</link><pubDate>Tue, 15 Dec 2020 15:19:59 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:241c2434-b170-4f2b-83b6-4451537c3dab</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;I would suggest to do bt_gatt_write() in a work queue instead of calling it a callback.&amp;nbsp;&lt;br /&gt;You may need to consider increasing the connection interval. You are having 90ms connection interval but having 20 connection and with the ATT_MTU 247 bytes and DLE 251 bytes, if you use all 251 bytes it won&amp;#39;t be enough time to serve all 20 connections (4.5ms/connection).&amp;nbsp;&lt;br /&gt;You may consider turn&amp;nbsp;SLAVE_LATENCY on if not all peripheral need to transmit data at the same time.&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285132?ContentTypeID=1</link><pubDate>Tue, 15 Dec 2020 14:55:10 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d3523341-6d4f-41af-abb3-053214165627</guid><dc:creator>hmw</dc:creator><description>&lt;p&gt;Currently I set the interval as follows&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;#define MIN_CONNECTION_INTERVAL         72     
#define MAX_CONNECTION_INTERVAL         72    
#define SLAVE_LATENCY                   0    
#define SUPERVISION_TIMEOUT             50 &lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I use the BLE example central_hr and peripheral provided by Zephyr to make changes, it should be Zephyr stack&lt;/p&gt;
&lt;p&gt;My central will look for peripherals first&lt;br /&gt;Establish a connection, peripherals will send data to central(use notify), and central will return data to it (use &lt;strong&gt;bt_gatt_write&lt;/strong&gt;)&lt;/p&gt;
&lt;p&gt;And the data is just a simple sequence&lt;/p&gt;
&lt;p&gt;I thought only the following parameters need to be set&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_BT_RX_BUF_LEN=258
CONFIG_BT_ATT_TX_MAX=10
CONFIG_BT_ATT_PREPARE_COUNT=10
CONFIG_BT_CONN_TX_MAX=18
CONFIG_BT_L2CAP_TX_BUF_COUNT=18
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_RX_MTU=247
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_RX_BUFFERS=18
CONFIG_BT_CTLR_TX_BUFFERS=18
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I will try the three parameters you suggested again&lt;/p&gt;
&lt;p&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096&lt;br /&gt;CONFIG_MAIN_STACK_SIZE=2048&lt;br /&gt;CONFIG_BT_RX_STACK_SIZE.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Besides, I want to ask&lt;br /&gt;When the central receives the notification from the peripheral, the central will go to the &lt;strong&gt;notify_func&lt;/strong&gt;, I print the data I received in the &lt;strong&gt;notify_func&lt;/strong&gt; and use &lt;strong&gt;bt_gatt_write&lt;/strong&gt; to return the information&lt;br /&gt;Is it illegal to do &lt;strong&gt;bt_gatt_write&lt;/strong&gt; in this function? as follow&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;static uint8_t notify_func(struct bt_conn *conn,
			   struct bt_gatt_subscribe_params *params,
			   const void *data, uint16_t length)
{
	uint32_t mantissa;
	int8_t exponent;
	int err;
	int a=0,b=0;
	int unsub_conn = 0;

	start_time = k_uptime_get_32();

	if (!data) {
		unsub_conn = bt_conn_index(conn);
		printk(&amp;quot;[UNSUBSCRIBED] %d %d %d\n&amp;quot;,unsub_conn,params-&amp;gt;value_handle,subscribe_params[unsub_conn].value_handle);
		subscribe_params[unsub_conn].value_handle=0U;
		 is_connecting = false;
		return BT_GATT_ITER_CONTINUE;
	}
	
	printk(&amp;quot;index %d recv %u %u %u %u %u %u %u.\n&amp;quot;, bt_conn_index(conn),((uint8_t *)data)[0],((uint8_t *)data)[1],((uint8_t *)data)[2],((uint8_t *)data)[3],((uint8_t *)data)[4],((uint8_t *)data)[5],((uint8_t *)data)[6]);
	
	gatt_write_buf[0] = ((uint8_t *)data)[0];
	gatt_write_buf[1] = count;
	gatt_write_buf[2] =88;
	gatt_write_buf[3] =99;	

	count++;

	write_params[bt_conn_index(conn)].data = gatt_write_buf;
	write_params[bt_conn_index(conn)].length = 8;
	write_params[bt_conn_index(conn)].handle = service_handle;
	write_params[bt_conn_index(conn)].offset = 0;
	write_params[bt_conn_index(conn)].func = write_func;

	err = bt_gatt_write(conn, &amp;amp;write_params[bt_conn_index(conn)]);
	
	if (err) {
		printk(&amp;quot;Write failed (err %d)\r\n&amp;quot;, err);
	} 
	return BT_GATT_ITER_CONTINUE;
}&lt;/pre&gt;&lt;br /&gt;Or is it normal to do &lt;strong&gt;bt_gatt_write&lt;/strong&gt; in the while loop of main?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks,&lt;/p&gt;
&lt;p&gt;Poyi&lt;/p&gt;
&lt;div style="left:88px;position:absolute;top:238px;" id="gtx-trans"&gt;
&lt;div class="gtx-trans-icon"&gt;&lt;/div&gt;
&lt;/div&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE multilink ATT timeout problem occurs when the number of connections increases</title><link>https://devzone.nordicsemi.com/thread/285117?ContentTypeID=1</link><pubDate>Tue, 15 Dec 2020 14:30:02 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:84383d5a-fd9a-434b-8efa-2685cee33b96</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Hmw,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Could you describe a little bit more about your application ?&amp;nbsp;&lt;br /&gt;What&amp;#39;s the connection interval you used ? What data do you send/receive , which direction ?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;You actually got a MPU fault, suggesting there could be a stack overflow. Please try increasing this:&amp;nbsp;&lt;a href="https://docs.zephyrproject.org/1.10.0/reference/kconfig/CONFIG_BT_RX_STACK_SIZE.html"&gt;CONFIG_BT_RX_STACK_SIZE&lt;/a&gt;. Try double the stack size, maybe to 4096.&amp;nbsp;&lt;br /&gt;Also, try to increase these if it&amp;#39;s already as follow:&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096&lt;/span&gt;&lt;br /&gt;&lt;span&gt;CONFIG_MAIN_STACK_SIZE=2048&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Are you using Zephyr stack or Nordic stack ?&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>