⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程//www.wsdof.com/support.我们会在接下来的几天修复bug /优化搜索和标记。
21个员额/ 0个新员额
最后发表
karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
当前连接查询

亲爱的团队对话框,

我尝试在线程的最后一条和第三条最后一条评论中使用连接电流:-

https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl..。

观察:

1.我发现在默认连接间隔配置中连接电流为210uA。(min_interval =10ms, max_interval = 20ms)

2.我发现当min_interval = 300ms, max_interval = 310ms时,连接电流是~25uA

3.最初,无论连接间隔(2-3秒),最初就是100uA。之后基于连接间隔配置,当前生效。

查询:

1.将连接间隔从默认配置的10ms移动到300ms有什么不利影响?

2.我理解它会影响吞吐量,但如果我的用例每天传输几个字节(最多400字节)。每天,马克斯。每次40字节),我应该配置什么时间连接间隔?

3.是否可以更改连接间隔运行时?如果是,您可以指向代码中的API /地点吗?

4.与120uA相比,有什么可能的原因:-

https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl..。

5.你能详细说明观察的原因吗?

如果您需要任何其他细节,请告诉我。

提前谢谢,

Karan.

设备:
PM_Dialog
离线
最后看到:4小时39分钟前
工作人员
加入:2018-02-08 11:03
嗨Karanshah28,

嗨Karanshah28,

你能说明一下你目前的消耗测量是遵循什么程序吗?我假设你得到的是平均电流消耗。系统进入睡眠模式之间的广告或连接间隔。因此,更大的连接或广告间隔意味着系统处于睡眠模式的时间更长,因此功耗会更低。

设备在连接间隔期间发送的数据量取决于中心允许外设发送的数据包。使用标准MTU选择的每个数据包的有效负载为20字节。所以你发送的每个数据最多可以携带20个字节。你不能控制BLE在一个连接间隔内发送多少数据包,因为这取决于连接的主人,如果他不想接受数据,他就不会接受它,即使你表明你有更多的数据要发送。此外,对于您的应用程序,没有固定的连接间隔。

让我快速描述您的连接参数更新过程:

正在发布的外围设备充当从设备的角色,而正在搜索要连接到的设备的扫描设备在连接过程中充当主设备的角色。后者负责执行各种强制操作,包括传输哪个通道和使用哪个事件间隔。然而,在成功连接后,从设备可以通过更新连接参数请求提出自己的首选参数(连接间隔,监控超时等)。之后,如果奴隶的要求得到批准,主人就会对奴隶做出回应。为此,外围设备发送连接参数更新请求,协商过程将通过空中进行,如果推荐通过,将发生连接参数更新事件。有关更新连接参数的更多信息,请参阅蓝牙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.

关于1连接事件,你是如何衡量它的?你应该像附件中的图像那样测量它。这是一个连接事件。我的功率分析仪为这个测量。

谢谢,PM_Dialog

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
谢谢你的简介

谢谢你的简短解释。

我们将分享您的详细信息,我们如何衡量当前。

在我们的测试中,我们发现当我们设置连接间隔超过100ms时,我们看到中心设备和da14586之间的连接断开。

你对此有何评论?这是预期的行为吗?或者设备应该保持连接?

另外,有没有办法改善这个?

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
嗨,对话框的团队,

嗨,对话框的团队,

等待你的回复。

谢谢,卡兰

PS_Dialog
离线
最后看到:4个月2个星期前
加入:2018-01-15北京
嗨Karan,

嗨Karan,

哪个是您连接的中心设备?

BR,保罗

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
嗨Paolo,

嗨Paolo,
我们正试图与Android手机连接。
谢谢,卡兰

PS_Dialog
离线
最后看到:4个月2个星期前
加入:2018-01-15北京
你好,

你好,

我在前一个线程中看到你谈到了一个范围扩展器,你还在这里使用吗?

您是否使用了自定义PCB或我们的Pro Starter Kit +我们的Daugther Loard?

Android手机离主板的距离是多少?

BR,保罗

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
你好,

你好,

我们正在使用范围扩展器。
我们使用定制的pcb。
距离是3米。

谢谢,卡兰

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
你好,

你好,

当最小间隔是10毫秒,最大间隔是300毫秒时,我们甚至会断开连接

除了10毫秒的最小间隔和20毫秒的最大间隔,你还能提供其他连接设置吗?

CYibin
离线
最后看到:6个月2周前
工作人员
加入:2017-12-14 02:48
嗨Karanshah28,

嗨Karanshah28,

由于不需要高吞吐量,也许您可以尝试:

INTV_MIN:300ms.

intv_max: 400毫秒

延迟:0

connect_timeout:5s.

Br

宜宾

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
你好,

你好,

我们用你的参数进行了测试,但设备断开了。

我们用多个中央设备和浅蓝色应用程序测试了这个。

您能否向我们建议我们可以使我们拥有除10ms和20毫秒以外的连续连接和连接间隔的新设置

——卡兰

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
我错误地点击了“接受”

我错误地点击了“接受答案”链接。请忽略它

——卡兰

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
嗨,对话框的团队,

嗨,对话框的团队,

我们能快速解决断网问题吗?

我们的目的是保持连接到中央设备,在这种情况下可以是Android或iOS手机。一旦连接,我们从不断开连接。如果中央或外围设备远离BLE范围,我们只会断开连接。感谢您对此的及时帮助。

问候,卡兰

CYibin
离线
最后看到:6个月2周前
工作人员
加入:2017-12-14 02:48
嗨Karan,

嗨Karan,

你能确认不同的连接参数会导致不同的结果吗?对于这个用例,什么连接参数是好的?

你能说出断开原因代码吗?你可以在disconnect事件回调函数(user_app_on_disconnect())中打印出来。

Br

宜宾

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
你好,

你好,

对于相同的连接参数,我们看到了不同的观测结果。

第一次装置在1小时5分钟后断开,第二次装置在17分钟后断开。

在disconnect callback中,断开原因的时间都是0x13。

如果需要更多信息,请告诉我们。

断开连接会有什么问题呢?

有什么我们可以调整连接参数并解决这个问题吗?

问候,

Karan.

CYibin
离线
最后看到:6个月2周前
工作人员
加入:2017-12-14 02:48
嗨Karanshah28,

嗨Karanshah28,

0x13表示超时断开连接。

以下是我可以想到的所有可能原因:

1.应用程序(中心设备)被手机系统杀死。

2.在固件中,ble事件不能被及时处理。这意味着,在您的固件中有一个长时间的进程,它阻塞了您的主进程。

3.射频性能不好。例如,RF TX的功率较弱,或者频率偏移量大等。

4.手机和设备之间存在兼容性。在这种情况下尝试另一个手机进行测试。

Br

宜宾

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
亲爱的支持团队,

亲爱的支持团队,

感谢更新。

所以在四个原因中我们要找出真正的原因。为此我们做了以下实验。

我们将ble_all_in_one项目二进制flash到板上,用手机连接板。

该连接建立并连接到7小时,2分钟后,该设备与断开原件断开连接0x8。

但是,BLE_ALL_IN_ONE固件中的性能很好,但仍然已断开连接。

那么原因是什么呢?

1)手机应用程序没有因为在应用程序中收到断开消息而崩溃。我附上了同样的截图。

2)现在我想我们可以说这不是因为固件的长进程,因为我们使用了ble_all_in_one。如果我错了,请纠正我。

3)RF性能不好。不确定这一点。请注意,我们在董事会中使用了频率扩展Sky66111-11。有没有办法检查rf性能是问题吗?

是否有其他方法或建议可以找出问题的根本原因?

问候,

Karan.

PM_Dialog
离线
最后看到:4小时39分钟前
工作人员
加入:2018-02-08 11:03
嗨Karanshah28,

嗨Karanshah28,

有各种各样的原因可以导致连接中断,例如移动对端设备超出范围,电源故障,一些干扰等。根据Bluetooth LE规范,由于上述原因可能会在没有任何预先警告的情况下发生,因此这对两者都很重要

主机和从机监控连接状态。为了做到这一点,中央和外设都应该使用链路层连接监督定时器,以检测链路丢失。有关此主题的更多信息,请参阅蓝牙核心规范。在SDK的配置结构user_connection_param_conf中,有一个参数名为。time_out。这是连接监督超时,它定义了在接收到的两个数据包pdu之间的最大时间

连接被认为丢失了。根据核心规范,在100 ms - 32.0 sec范围内,连接监控超时时间应为10 ms的倍数,且大于

(1 + connection_latency) * connection_interval * 2。您为设备设置的监控超时时间是多少?如果设置的超时时间越长,设备断开连接的时间会越长,还是无法断开连接?CO_ERROR_CON_TIMEOUT = 0x08错误是连接超时错误码,表示给定连接的链路监督超时已经过期。

谢谢,PM_Dialog

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
亲爱的支持团队,

亲爱的支持团队,

我们正在使用BLE_ALL_IN_ONE作为我们的基本代码,并添加了一些更改(范围扩展器芯片驱动程序https://www.dialog-seminile.com/sites/default/files/rext_sky66111-1 ...+一些产品级别的变化)的顶部代码。
我们观察到在2小时内断开,有时在15分钟内断开。

要进一步调试此问题,我们确实在实验之后:
请注意,我们在设计中使用了量程扩展芯片:SkY66111。

以下是所有观察的总结:
1)我们在我们的板上闪烁我们的固件,观察到在2小时内断开,有时也在15分钟内。
我们的固件是BLE_ALL_IN_ONE + RANGE扩展器驱动程序+有关更改的一些产品。

2)然后找到断开的问题,我们将BLE_ALL_IN_ONE FIRINE BINARE BINAR BINARD DO14586 EVM板闪烁,未观察到断开10小时。

3)然后,我们将ble_all_in_one固件二进制写入我们的板,观察到相同的结果,即10小时没有观察到断开。

4)然后我们假设有一些问题在我们的固件,因为我们没有观察到断开与ble_all_in_one代码与我们的板。

5)然后我们从我们的固件代码中删除了范围扩展器驱动程序支持,即我们的固件代码将是BLE_ALL_IN_ONE +一些产品有关更改的产品。
在这种情况下,我们也没有观察到手机断开超过9小时。

因此,通过实验得出了增程器驱动存在问题的结论。

这个问题的根本原因是什么?
这个问题是否与range扩展器芯片断开连接是已知的问题?
有没有解决方案?

供你参考,手机总是在我们测试的pcb旁边。如果需要,我们可以共享代码。

感谢和问候,
Karan.

karanshah28
离线
最后看到:1年2个月前
加入:2018-07-14十一10
嗨支持团队,

嗨支持团队,

你能告诉我最新情况吗?这对我们来说是个阻碍问题。

问候,卡兰

PM_Dialog
离线
最后看到:4小时39分钟前
工作人员
加入:2018-02-08 11:03
嗨Karanshah28,

嗨Karanshah28,

请检查一下在断开后代码是否在运行,或者在某个地方卡住了?例如,断开连接后,应用程序在做什么?断开连接后,设备是否重新开始发布?你能在不复位板的情况下在空气中检测到它吗?您是否可以使用BLE嗅探器来检查通过空气传输的数据包?

哪个是断开原因代码?你可以在disconnect事件回调函数(user_app_on_disconnect())中打印出来,因为它已经在文章中提到了。

我又看了一遍你的帖子,发现断开原因是0x13。你能确认一下吗?

“断开原因的时间都在断开回调时为0x13。”

0x13 (CO_ERROR_REMOTE_USER_TERM_CON)错误代码,名为REMOTE USER TERMINATED CONNECTION,表示远程设备上的用户终止了连接。你有定制的移动应用程序吗?

“我们在董事会中闪过固件,并观察到2小时内的断开连接,有时在15分钟内。我们的固件是BLE_ALL_IN_ONE + RANGE EXTENDER驱动程序+有关更改的一些产品。“

你有范围扩展器参考设计来尝试复制这个问题吗?你对ble_all_in_one做了任何修改吗?

“然后为了找到断开的问题,我们在DA14586 EVM板上闪了ble_all_in_one固件二进制文件,10个小时没有观察到断开。”

你能把黑板弄清楚吗?你是指Pro DK还是585射程扩展器?

然后,我们将BLE_ALL_IN_ONE FIRIN DINARY闪存到我们的电路板上,并观察到相同的结果,即未观察到10小时的断开连接。

与下面的结果相同?断开连接没有发生。?另外,有或没有SKY66111?

“然后我们从固件代码中删除了Range扩展器驱动支持,也就是说我们的固件代码将是ble_all_in_one +一些产品相关的更改。

在这种情况下,我们也没有观察到手机断开超过9小时。”

关于你提到的那个司机,你能解释一下吗?

最好是创建一个新的论坛帖子,以便最好地跟踪断开的问题,因为最初的帖子与连接当前消费有关。但这取决于你。

谢谢,PM_Dialog