Dear Dialog Team,
I tried to play around with the connection current as suggested in last and third last comment in thread:-
https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...
Observations:-
1.我发现连接电流为210UA，默认连接间隔配置。（min_interval = 10ms，max_interval = 20ms）
2. I found connection current to be ~25uA when min_interval = 300ms, max_interval = 310ms
3. Initially the current is 100uA regardless of connection interval (for 2-3 seconds). After that based on the connection interval configuation, the current takes effect.
Queries:-
1.从默认配置的10ms移动到连接间隔300ms的不利影响是什么？
2. I understand that it can affect throughput, but if my usecase is transferring a few bytes per day (400 bytes max. per day, max. 40 bytes at a time), what time I connection interval I should configure?
3. Is it possible to change connection intervals runtime? If yes, can you point us the apis/places in the code?
4.与120UA相比，在第三次上次评论中建议的120岁以下的可能原因是什么： -
https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...
5. Can you elaborate on causes of observation 3?
Let me know if you need any other detail.
Thanks in advance,
Karan
Hi karanshah28,
您能否注明当前消耗测量所关注的程序？我假设你正在获得平均的电流消耗。该系统在广告或连接间隔之间进入睡眠模式。因此，具有更大的连接或广告间隔意味着系统处于睡眠模式，因此功耗将较低。
The amount of data that the device sends during a connection interval depends on the packets that the central allows to a peripheral to send. The payload for each packet with the standard MTU selection is 20 bytes. So each data that you send can carry up to 20 bytes. You can't control the how many packets the BLE will send during a connection interval because is up to the master of the connection, if he doesn't want to accept the data he just won’t accept it even if you indicate that you have more data to send. In addition, there are is not a fixed connection interval regarding your application.
Let me quickly describe you the Connection Parameters Update procedure:
作为广告的外围设备假设从设备的作用，而正在搜索用于连接到设备的扫描仪设备，则在连接过程上假设主设备的作用。后者，负责执行各种强制性的操作，包括要传输的频道以及要使用的事件间隔。但是，在成功的连接之后，从设备可以通过更新连接参数请求提出其自己的优选参数（连接间隔，监控超时等）。之后，如果已获批准，主人会响应奴隶。为此，外围设备发送连接参数更新请求，协商过程将发生在空中，如果已批准，则会发生连接参数更新的事件。有关更新连接参数，请参阅蓝牙LE规范。
user_gapm_conf结构保持用户的配置igurations and the device upon connection will have the connection interval from this structure. The user_connection_param_conf keeps the connection parameter update configuration. The connection intervals are defined by the central, so what you can do, is to issue a connection update request and the central will decide if it will accept the connection parameters that you have requested. If the current parameters don’t match will send a request to the central in order to update the connection parameters (the request is sent 10 seconds after the connection is established), so if the central accepts the parameters the connection will change to the specified values in the user_connection_param_conf structure.
关于1个连接事件，您如何测量它？您应该像附加的成像一样衡量它。这是1个连接事件。我的电力分析仪进行此测量。
Thanks, PM_Dialog
Thanks for the brief explanation.
We will share you the details how we measure current shortly.
In our testing, we found that when we set connection interval above 100ms, we are seeing disconnections between central device and da14586.
你对此有什么意思？这是预期的行为吗？或设备应保持连接？
Also, is there a way to improve this?
嗨对话小组，
Waiting for your response.
Thanks, Karan
Hi Karan,
Which is the central device you are connecting to?
BR，Paolo.
Hi Paolo,
We are trying to connect with Android mobile phone.
谢谢，Karan.
Hi,
I saw in the previous thread you talked about a range extender, are you using it also here?
Are you using a custom PCB or one of our Pro starter kit + our Daugther Board?
在哪个距离是来自董事会的Android手机？
BR，Paolo.
Hi,
We are using range extender.
我们使用自定义PCB。
And distance is 3m.
Thanks, Karan
Hi,
当MIN间隔为10ms时，我们甚至断开连接，最大间隔为300ms
Can you provide the Connection settings other than 10ms min interval and 20 ms max interval which reduces current?
Hi karanshah28,
由于不需要高的延迟，也许您可以尝试：
intv_min: 300ms
INTV_MAX：400ms
latency: 0
connect_timeout: 5s
Br
Yibin
Hi,
我们使用参数进行了测试，但设备断开连接。
We tested this with multiple central devices and with light blue application.
Can you suggest us any new settings that would enable us to have continous connection and connection intervals other than 10ms and 20 ms
- karan
I mistakenly clicked "accept answer" Link. Please ignore it
- karan
嗨对话小组，
Can we have quick resolution to disconnection issue?
Our purpose is to stay connected to Central device which in this case can be android or iOS phone. Once connected, we never disconnect. We only get disconnected if either central or peripheral are moved away from ble range. Appreciate your timely help on this.
问候，Karan
Hi Karan,
Can you confirm that different connection parameters will lead to different results? What the connection parameters is good for this use case?
Can you tell the disconnect reason code? You can print it out in the disconnect event callback function ( user_app_on_disconnect() ).
Br
Yibin
Hi,
For same connection parameters we seen different observation..
第一次设备在1小时后与5分钟后断开连接，第二个时间设备在17分钟内断开连接。
断开原因的时间都在断开回调时为0x13。
如果需要更多信息，请告诉我们。
What can be the issue of disconnection?
Is there anything we can tune connection parameters and can solve the issue ?
问候，
Karan
Hi Karanshah28,
0x13表示超时断开连接。
Here are all the possible causes i could think of：
1.应用程序（中央设备）被手机系统杀死。
2.在固件中，无法及时处理BLE事件。这意味着，固件中有很长的时间，这会阻止您的主要过程。
3. The RF perfomance is not good. For example, the power of RF TX is weak, or the frequency offset is large etc.
4. There is a compatibility probem between your mobile phone and your device. Try another mobile phone for testing in this case.
Br
Yibin
Dear Support Team,
Thanks for the update.
So out of 4 reasons we have to find out the actual reason. For that we did following experiment.
我们将BLE_ALL_IN_ONE项目二进制文件二进制于电路板和带有手机的连接板。
The connection was established and connected till 7 Hours and 2 min and after that device got disconnected with disconnection reason 0x8.
However the performance is good in ble_all_in_one firmware but still the device got disconnected.
So what can be the reason here ?
1）移动应用程序没有崩溃，因为我收到了应用程序中的断开消息。我有附加截图。
2）现在我猜我们可以说它不是因为在固件中的长过程，因为我们使用了BLE_ALL_IN_ONE。如果我错了，请纠正我。
3) The rf performance is not good. Not sure about this. Please note we have used range extender SKY66111-11 in our board. Is there any way to check is rf performance is the issue or not ?
是否有其他方法或建议可以找到问题的根本原因？
问候，
Karan
Hi karanshah28,
There are various reasons that can broken a connection down, such as moving the peer device out of the range, power failure conditions, several interferences etc. According to Bluetooth LE specifications, since the aforementioned reasons may happen without any prior warning, it is important for both the
Master和Slave监视连接的状态。为此，中环和外围设备都应使用链路层连接监控定时器，以便检测链路损耗。有关此主题的更多信息，请参阅蓝牙核心规范。在sdk的user_connection_param_conf配置结构中，有一个名为的参数。超时。这是连接监控超时，它定义了两个接收到的数据包PDU之间的最长时间
connection is considered lost. According to the core specifications, the Connection supervision timeout shall be a multiple of 10 ms in the range of 100 ms to 32.0 sec and it shall be larger than
（1 + connection_latency）* connection_interval * 2.您已设置给设备的监控超时？如果设置较长的超时，设备将需要更多的时间才能断开连接或无法断开连接？co_error_con_timeout = 0x08错误是连接超时错误代码，指示链路监控超时已过期为给定连接。
Thanks, PM_Dialog
Dear Suport Team,
We are using ble_all_in_one as our base code and added some changes(Range extender chip driver//www.wsdof.com/sites/default/files/rext_sky66111-1...+一些产品水平的变化)的代码。
我们在使用固件后15分钟内观察到2小时内的两次断开连接。
To debug further this issue we did following experiments:
请注意，我们在我们的设计中使用范围扩展器芯片：Sky66111。
Here is the summary of all observation:
1）我们在董事会中闪现了固件，并观察到2小时内的断开连接，有时在15分钟内。
Our firmware is ble_all_in_one + Range extender driver + Some product regarding change.
2) Then to find the issue of disconnection, we flashed ble_all_in_one firware binary into DA14586 EVM board and did not observed disconnection for 10 hours.
3) Then, we flashed ble_all_in_one firware binary into our board, and observed same result, i.e. did not observed disconnection for 10 hours.
4) Then we assumed that there is some issue in our firmware as we have not observed disconnection with ble_all_in_one code with our board.
5) Then we removed Range extender driver support from our firmware code i.e our firmware code will be ble_all_in_one + Some product regarding changes.
在这种情况下，我们也没有观察到移动电话断开超过9小时。
So based on this experiments we concluded that there is some issue with range extender driver.
这个问题的根本原因是什么？
Is this issue of disconnection with range extender chip is known issue ?
Is there any solution available for this ?
FYI, mobile is always next to the pcb which we are testing. we can share the code if required.
感谢致敬，
Karan
Hi Support Team,
你能更新这个吗？这对我们来说是阻止问题。
问候，卡兰
Hi karanshah28,
请检查代码是否在断开连接后运行或陷入困境？例如，断开连接后，应用程序是什么？断开后设备是否再次启动广告？在断开连接后是否能够在空中检测到空气中，而不重置电路板？您是否可以使用BLE嗅探器才能检查通过空中传输的数据包？
哪个是断开的原因代码？您可以在断开事件回调函数中打印出来（User_App_On_disconnect（）），因为它在帖子中已提及。
我读了你的帖子，我发现断开的原因是0x13。你能肯定吗？
“And both the time the disconnection reason was 0x13 in disconnect callback.”
The 0x13 ( CO_ERROR_REMOTE_USER_TERM_CON ) error code, named REMOTE USER TERMINATED CONNECTION and indicates that the user on the remote device terminated the connection. Do you have a custom mobile application?
“We flashed our firmware in our board and observed disconnection within 2Hours of time and sometimes within 15 minutes also. Our firmware is ble_all_in_one + Range extender driver + Some product regarding change.”
您是否拥有Range Extender参考设计，以便尝试复制此问题？您是否在ble_all_in_one中完成了任何修改？
“Then to find the issue of disconnection, we flashed ble_all_in_one firware binary into DA14586 EVM board and did not observed disconnection for 10 hours. “
你能澄清董事会吗？你的意思是pro dk或585 range extender？
Then, we flashed ble_all_in_one firware binary into our board, and observed same result, i.e. did not observed disconnection for 10 hours.
The same result as below? Disconnection not happened.? Also, with or without the SkY66111?
“然后我们从我们的固件代码中删除了范围扩展驱动程序支持，即我们的固件代码将是BLE_ALL_IN_ONE +一些产品有关更改的产品。
在这种情况下，我们也没有观察到移动电话断开超过9小时。“
您能否在您提到的司机分享更多澄清？
创建一个新的论坛帖子是最好追踪断开的问题，因为初始帖子与连接电流消耗有关。但这取决于你。
Thanks, PM_Dialog