设备在连接间隔期间发送的数据量取决于中央允许发送外围设备的数据包。具有标准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. If you would like to send more than 20 bytes of data you will have to increase your MTU size, then the L2CAP will take of the rest, chop the data and fit them in more than one packets.
请查看附件的截图。我已经实现了一个256字节的“无响应写入”特性。此外,.max_mtu=259,我在user_on_connection中使用了上面的代码片段。为了让您了解,我研究了SDK5.0.4的ble_app_peripheral示例。正如您在附件的快照中所看到的,256字节被分成了更小的数据包。256字节以1个连接间隔从BLE通用应用程序发送到外设。您可以看到,当通过空中发送数据时,只使用了Channel-30,这意味着只有一个连接间隔。通过的有效负载是7400比特/秒。您获得较小吞吐量的可能原因是您可能没有进行MTU交换,因此发送256字节需要超过1个连接间隔。注意,可能会发生重传。 You are able to use API uint16_t gattc_get_mtu(uint8_t idx) to poll the negotiated MTU. Regarding you question for the sniffer; I used the Frontline sniffer products for debugging BLE protocol.
嗨pvmellor,
谢谢你的屏幕截图。让我检查一下,我会尽快回复你。你能澄清你如何发送数据吗?你在使用通知吗?此外,嗅探器日志将非常有帮助,以了解如何在空中交换Tha数据包。
谢谢,PM_Dialog
数据从智能手机(Android和iOS)发送到DA14850。它通过简单的特征写入,无需响应(或发送)。数据包嗅探器已订购,但我们希望您可以帮助我们从DA14580软件方面跟踪该过程。
我们已经尝试修改user_config.h中的参数user_gapm_conf和user_connection_param_conf,但是对实际传输速度没有任何影响。你对此有什么想法/建议吗?它确实很慢。是否有一种方法可以告诉在运行时使用了哪些参数?
嗨pvmellor,
你能查一下MTU的最大尺寸是多少吗?请将user_config.h中user_gapm_conf结构的max_mtu项设置为256。
谢谢,PM_Dialog
好的试过这个 - 没有区别我害怕。任何其他想法?你能重现这个吗?一个简单的应用程序反复写入256byte特征应该展示问题。
我们在这方面做了很多工作。我们可以成功地发送L2CAP连接参数更新请求
我们看到主设备(智能手机)更改的连接间隔,新参数符合我们在响应消息中看到的步骤
这些也匹配GTL流的开/关轮询周期。这些都工作得很好,我们可以把连接间隔设为15ms。
然而,它仍然需要太多的连接事件周期来传输数据:大约44个256字节的特征写入。即使我们将特征的大小减少到64字节,也需要10个连接事件才能将其写入DA14580。如果需要,我可以提供踪迹(遗憾的是,我们不能只是添加一个jpeg到这些票)。而且在只有16字节长的情况下,一个特征仍然需要2个连接事件来传输。
所以我有一些问题:
感谢您的及时支持,因为有客户在等着我们……
谢谢,
保罗
嗨pvmellor,
让我检查你的问题,并尝试复制你的问题,我会尽快给你回复。
谢谢,PM_Dialog
嗨,抱歉唠叨,但你在这方面有进展了吗?我们现在被困住了,等待你们那边的答复/帮助。请参见上面的具体问题。
谢谢!
嗨pvmellor,
设备在连接间隔期间发送的数据量取决于中央允许发送外围设备的数据包。具有标准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. If you would like to send more than 20 bytes of data you will have to increase your MTU size, then the L2CAP will take of the rest, chop the data and fit them in more than one packets.
具体地,设备可以通过空中发送的字节数由MTU(最大传输单元)限制,默认情况下MTU受限于包括ATT层开销的23个字节,因此有效载荷是20个字节。通过增加MTU大小,意味着您可以通过空中发送更多字节。在您的情况下,最大传输单元应该是您想要发送+ 3额外字节的字节数。您应该更改user_config.h头文件的user_gapm_conf结构的.max_mtu。在此之后,为了执行与中央的交换,您应该在具有连接时发送GattC_EXC_MTU_CMD(在USER_ON_CONNECTIONCE)中,580将执行交换。对于MTU Exchange功能而言,没有实现API,但您可以使用以下代码段:
Static user_gattc_exc_mtu_cmd(uint8_t conidx)
{
struct gattc_exc_mtu_cmd *cmd = KE_MSG_ALLOC(gattc_exc_mtu_cmd,
TASK_APP KE_BUILD_ID (TASK_GATTC conidx),
gattc_exc_mtu_cmd);
cmd - > req_type = GATTC_MTU_EXCH;
ke_msg_send (cmd);
}
请查看附件的截图。我已经实现了一个256字节的“无响应写入”特性。此外,.max_mtu=259,我在user_on_connection中使用了上面的代码片段。为了让您了解,我研究了SDK5.0.4的ble_app_peripheral示例。正如您在附件的快照中所看到的,256字节被分成了更小的数据包。256字节以1个连接间隔从BLE通用应用程序发送到外设。您可以看到,当通过空中发送数据时,只使用了Channel-30,这意味着只有一个连接间隔。通过的有效负载是7400比特/秒。您获得较小吞吐量的可能原因是您可能没有进行MTU交换,因此发送256字节需要超过1个连接间隔。注意,可能会发生重传。 You are able to use API uint16_t gattc_get_mtu(uint8_t idx) to poll the negotiated MTU. Regarding you question for the sniffer; I used the Frontline sniffer products for debugging BLE protocol.
谢谢,PM_Dialog