亲爱的对话团队，
我试图通过在螺纹上次和第三条评论中建议的连接电流进行游戏： -
https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...
观察结果： -
1.我发现连接电流为210UA，默认连接间隔配置。（min_interval = 10ms，max_interval = 20ms）
2.当MIN_INTERVAL = 300ms时，我发现连接电流为〜25ua，max_interval = 310ms
3.最初，无论连接间隔（2-3秒），最初就是100ua。之后基于连接间隔配置，当前生效。
查询： -
1. What are the adverse effect of moving to connection interval 300ms from default configured 10ms?
2.我明白它可以影响吞吐量，但如果我的usecase每天传输几个字节（最多400字节。每天，最多40个字节），我应该如何配置时间？
3.是否可以更改连接间隔运行时？如果是，您可以指向代码中的API /地点吗？
4.与120UA相比，在第三次上次评论中建议的120岁以下的可能原因是什么： -
https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...
5.您能详细说明3次观察原因吗？
如果您需要任何其他细节，请告诉我。
提前致谢，
Karan.
设备：
嗨Karanshah28，
Can you please indicate the procedure you are following for the current consumption measurements? I assume that you are getting an average current consumption. The system goes into sleep mode between advertising or connection intervals. So, having bigger connection or advertising intervals means that the system is in sleep mode more time and as a result the power consumption will be lower.
设备在连接间隔期间发送的数据量取决于中央允许发送外围设备的数据包。具有标准MTU选择的每个数据包的有效载荷为20字节。所以您发送的每个数据都可以载有20个字节。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.
让我快速描述您的连接参数更新过程：
作为广告的外围设备假设从设备的作用，而正在搜索用于连接到设备的扫描仪设备，则在连接过程上假设主设备的作用。后者，负责执行各种强制性的操作，包括要传输的频道以及要使用的事件间隔。但是，在成功的连接之后，从设备可以通过更新连接参数请求提出其自己的优选参数（连接间隔，监控超时等）。之后，如果已获批准，主人会响应奴隶。为此，外围设备发送连接参数更新请求，协商过程将发生在空中，如果已批准，则会发生连接参数更新的事件。有关更新连接参数，请参阅蓝牙LE规范。
user_gapm_conf结构保持用户的配置，并且在连接时设备将具有来自此结构的连接间隔。user_connection_param_conf保留连接参数更新配置。连接间隔由中央定义，因此您可以做的是发出连接更新请求，中央将决定它是否会接受您所要求的连接参数。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.
Regarding the 1 connection event, how you are measuring it? You should measure it like the attached imaged. This is 1 connection event. I power analyzer for this measurement.
谢谢，PM_DIALOG.
谢谢你的简要说明。
我们将分享您的详细信息，我们如何衡量当前。
在我们的测试中，我们发现当我们设置高于100ms的连接间隔时，我们会看到中央设备和DA14586之间的断开连接。
你对此有什么意思？这是预期的行为吗？或设备应保持连接？
另外，有没有办法改善这个？
Hi Dialog Team,
等待您的答复。
谢谢，Karan.
嗨Karan，
哪个是您连接的中心设备？
BR, Paolo
嗨Paolo，
我们正试图与Android手机连接。
Thanks, karan
你好，
我在前一个线程中看到你谈到了一个范围扩展器，你还在这里使用吗？
您是否使用了自定义PCB或我们的Pro Starter Kit +我们的Daugther Loard？
At which distance is the Android phone from the board?
BR, Paolo
你好，
我们正在使用范围扩展器。
We are using custom pcb.
距离为3米。
谢谢，Karan.
你好，
We are even getting disconnected when min interval is 10ms and max interval is 300ms
您是否可以提供10毫秒最小间隔和20毫秒最大间隔的连接设置，这会降低电流？
嗨Karanshah28，
As the high throughtput is not required, maybe you can try：
INTV_MIN：300ms.
intv_max: 400ms
延迟：0
connect_timeout：5s.
布尔
宜宾
你好，
我们使用参数进行了测试，但设备断开连接。
我们用多个中央设备和浅蓝色应用测试了这一点。
您能否向我们建议我们可以使我们拥有除10ms和20毫秒以外的连续连接和连接间隔的新设置
- 卡伦
我错误地点击了“接受答案”链接。请忽略它
- 卡伦
Hi Dialog Team,
我们可以快速解决是否脱离问题？
我们的目的是保持连接到中央设备，在这种情况下可以是Android或iOS手机。一旦连接，我们从不断开连接。如果中央或外围设备远离BLE范围，我们只会断开连接。感谢您对此的及时帮助。
问候，卡兰
嗨Karan，
您可以确认不同的连接参数会导致不同的结果吗？连接参数适用于此用例吗？
你能告诉断开的原因代码吗？您可以在断开事件回调函数中打印出来（user_app_on_disconnect（））。
布尔
宜宾
你好，
对于相同的连接参数，我们看到了不同的观察。
The first time device got disconnect after 1 hour and 5 min and second time device got disconnect in 17minutes.
And both the time the disconnection reason was 0x13 in disconnect callback.
如果需要更多信息，请告诉我们。
什么可能是断开的问题？
有什么我们可以调整连接参数，可以解决问题吗？
问候，
Karan.
嗨Karanshah28，
0x13 means timeout disconnection.
以下是我可以想到的所有可能原因：
1.应用程序（中央设备）被手机系统杀死。
2. In the firmware, the ble event can not be handled timely. That means, there is a long time process in you firmware, which blocks your main process.
3.射频性能不好。例如，RF TX的功率较弱，或者频率偏移量大等。
4.手机和设备之间存在兼容性。在这种情况下尝试另一个手机进行测试。
布尔
宜宾
亲爱的支持团队，
感谢更新。
出于4个理由，我们必须找出实际原因。为此，我们确实在实验之后。
我们将BLE_ALL_IN_ONE项目二进制文件二进制于电路板和带有手机的连接板。
该连接建立并连接到7小时，2分钟后，该设备与断开原件断开连接0x8。
但是，BLE_ALL_IN_ONE固件中的性能很好，但仍然已断开连接。
那么这里有什么原因？
1) Mobile application did not crashed because I received disconnection message in application. I have attached screenshot for the same.
2) Now I guess we can say it's not because of long process in firmware, as we used ble_all_in_one. Please correct me if I am wrong.
3）RF性能不好。不确定这一点。请注意，我们在董事会中使用了频率扩展Sky66111-11。有没有办法检查rf性能是问题吗？
是否有其他方法或建议可以找到问题的根本原因？
问候，
Karan.
嗨Karanshah28，
有各种原因可以破坏连接的连接，例如将同行设备超出范围，电源故障条件，多个干扰等根据蓝牙LE规范，因为上述原因可能发生在没有任何先前警告的情况下，这是重要的对于这两者来说
master and the slave to monitor the status of the connection. To do so, both Central and Peripheral shall use a Link Layer connection supervision timer, in order to detect a link loss. Refer to Bluetooth core specifications for getting more information on this topic. In user_connection_param_conf configuration structure of the SDK, there is a parameter named. time_out. This is the Connection supervision timeout which defined the maximum time between two received Data Packet PDUs before the
连接被认为是丢失的。根据核心规格，连接监管超时应为10毫秒的10毫秒的倍数为32.0秒，它应大于
(1 + connection_latency) * connection_interval * 2. What is the supervision timeout that you have set to the device? If you set a longer timeout, the device will take more time to disconnect or is cannot disconnect? The CO_ERROR_CON_TIMEOUT = 0x08 error is the Connection Timeout error code indicates that the link supervision timeout has expired for a given connection.
谢谢，PM_DIALOG.
亲爱的Suport团队，
我们正在使用BLE_ALL_IN_ONE作为我们的基本代码，并添加了一些更改（范围扩展器芯片驱动程序https：//www.dialog-seminile.com/sites/default/files/rext_sky66111-1 ...+一些产品级别更改）在该代码之上。
And we have observed disconnection within 2 hours and some times within 15 minutes with our firmware.
要进一步调试此问题，我们确实在实验之后：
Please note we are using range extender chip in our design : SkY66111.
以下是所有观察的摘要：
1) We flashed our firmware in our board and observed disconnection within 2Hours of time and sometimes within 15 minutes also.
我们的固件是BLE_ALL_IN_ONE + RANGE扩展器驱动程序+有关更改的一些产品。
2）然后找到断开的问题，我们将BLE_ALL_IN_ONE FIRINE BINARE BINAR BINARD DO14586 EVM板闪烁，未观察到断开10小时。
3）然后，我们将BLE_ALL_IN_ONE Fireware二进制闪烁到我们的电路板中，并观察到相同的结果，即未观察到10小时的断开连接。
4）然后我们假设我们的固件中存在一些问题，因为我们没有观察到与我们的电路板的BLE_ALL_IN_ONE代码断开连接。
5）然后我们从我们的固件代码中删除了范围扩展器驱动程序支持，即我们的固件代码将是BLE_ALL_IN_ONE +一些产品有关更改的产品。
在这种情况下，我们也没有观察到移动电话断开超过9小时。
因此，基于此实验，我们得出的结论是，范围扩展器驱动程序存在一些问题。
What can be the root cause of this issue ?
这个问题是否与range扩展器芯片断开连接是已知的问题？
有没有解决方案？
FYI，移动总是在我们进行测试的PCB旁边。如果需要，我们可以共享代码。
Thanks and Regards,
Karan.
嗨支持团队，
Can you please update on this? This is blocking issue for us.
问候，Karan.
嗨Karanshah28，
Can you please check if the code Is running after the disconnection or is gets somewhere stuck? For example, after the disconnection, what is the application doing? Does the device start advertising again after the disconnection? Are you able to detect it in the air after the disconnection and without resetting the board? Is it possible for you to use a BLE sniffer in order to check the packets that are transmitted over the air?
Which is the disconnection reason code? You can print it out in the disconnect event callback function ( user_app_on_disconnect() ) as it is already mentioned in the post.
I read again your post, and I found that the disconnection reason is 0x13. Can you please make sure for that?
“断开原因的时间都在断开回调时为0x13。”
0x13（co_error_remote_user_term_con）错误代码，命名远程用户终止连接，并指示远程设备上的用户终止了连接。你有自定义移动应用程序吗？
“我们在董事会中闪过固件，并观察到2小时内的断开连接，有时在15分钟内。我们的固件是BLE_ALL_IN_ONE + RANGE EXTENDER驱动程序+有关更改的一些产品。“
Do you have the Range extender reference design in order to try to replicate this issue? Have you done any modifications in the ble_all_in_one?
“然后找到断开的问题，我们将BLE_ALL_IN_ONE FIRICWARE二进制闪存到DA14586 EVM板中，未观察到10小时的断开连接。“
Can you please clarify the board? Do you mean Pro DK or the 585 Range Extender?
然后，我们将BLE_ALL_IN_ONE FIRIN DINARY闪存到我们的电路板上，并观察到相同的结果，即未观察到10小时的断开连接。
与下面的结果相同？断开连接没有发生。？另外，有或没有SKY66111？
“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小时。“
你能分享更多的澄清有关吗the driver that you mentioned?
创建一个新的论坛帖子是最好追踪断开的问题，因为初始帖子与连接电流消耗有关。但这取决于你。
谢谢，PM_DIALOG.