BLE Throughput too low (for large characteristic)

⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
10个帖子/ 0新
最后一篇
pvmellor
离线
最后一次露面:1 year 5 months ago
加入:2017-04-27 20:30
BLE Throughput too low (for large characteristic)

Please see details in attached PDF with timing data.

Thanks,

保罗。

依恋:
Device:
PM_DIALOG.
离线
最后一次露面:3小时14分钟前
职员
加入:2018-02-08 11:03
Hi pvmellor,

Hi pvmellor,

Thanks for your screenshot. Let me check it and I will get back to you as soon as possible. Could you please clarify how you send data? Are you using notifications? Also, a sniffer log would be very helpful in order to understand how tha packets are exchanged over the air.

谢谢,PM_DIALOG.

pvmellor
离线
最后一次露面:1 year 5 months ago
加入:2017-04-27 20:30
数据被发送到DA14850

数据被发送到DA14850FROM a smart phone (Android and iOS). It is sent via a simple characteristic WRITE with no response required (or sent). Packet sniffer has been ordered, but we had hoped you may be able to help us trace the process from the DA14580 software side.

pvmellor
离线
最后一次露面:1 year 5 months ago
加入:2017-04-27 20:30
我们已经尝试了改变

我们已经尝试更改user_gapm_conf和user_connection_param_conf的user_config.h中的参数,但没有任何对实际传输速度的差异。您有任何想法/建议可以帮助吗?它的速度很慢。有没有办法讲述运行时在运行时使用的参数?

PM_DIALOG.
离线
最后一次露面:3小时14分钟前
职员
加入:2018-02-08 11:03
Hi pvmellor,

Hi pvmellor,

你能检查一下我的最大mtu大小吗?请在user_config.h中设置user_gapm_conf结构的max_mtu项到256。

谢谢,PM_DIALOG.

pvmellor
离线
最后一次露面:1 year 5 months ago
加入:2017-04-27 20:30
好的尝试了这个 - 没有

好的尝试了这个 - 没有difference I'm afraid. Any other thoughts? Can you reproduce this? A simple app to write a 256byte characteristic repeatedly should demonstrate the problem.

pvmellor
离线
最后一次露面:1 year 5 months ago
加入:2017-04-27 20:30
我们做了很多

我们现在已经完成了很多工作。我们可以成功发送L2CAP连接参数更新请求

app_easy_gap_param_update_start(connection_idx);

We see the connection interval changed by the master (smart phone), the new parameters match those we see in the Response message

user_catch_rest_hndl()... gapc_param_updated_ind

这些也匹配GTL流开/关投票时间。所以这一切都在正常工作,我们可以设置15ms的连接间隔让我们说。

但是,对于256字节特性写入,它仍然需要太多的连接事件期限:约44。即使我们将特性的大小降低到64字节,也需要10个连接事件以将其写入DA14580。如果需要,我可以提供追踪(遗憾我们不能只添加JPEG到这些票证)。并且只需16个字节,特征仍然需要2个连接事件来传输。

So I have some questions:

  • 你希望得到这个结果吗?我们在0.66秒内获得256个字节的吞吐量 - 这是384字节/秒:当然我们可以期待更多!
  • Can you reproduce this and test it your end to see if you have the same issue? We run with an external processor and GTL enabled.
  • Can you offer an explanation as to why it takes so many connection events to send even a small amount of data? This seems to be the crucial consideration.
  • 我们尝试了一个Adafruit“Bluefruit Le Sniffer”,但它只能看到广告数据包,它无法嗅到连接包。您是否可以推荐使用DA14580的嗅探器,所以我们可以追踪在空中发生的事情?
  • Is there a way to tell what the currently active connection parameters used in the link layer are?
  • 我们的问题似乎越来越少于每个连接事件的数据包,但它也很有趣:
    • DA14580支持每个连接事件的数据包有多少?
    • There are min and max connection event parameters in "user_connection_param_conf". Do these control the number of packets sent per connection event? If so, how - could you detail them?

感谢您及时支持客户等待......

Thanks,

保罗

PM_DIALOG.
离线
最后一次露面:3小时14分钟前
职员
加入:2018-02-08 11:03
Hi pvmellor,

Hi pvmellor,

让我检查你的问题并尝试复制你的问题,我会尽快回复你。

谢谢,PM_DIALOG.

pvmellor
离线
最后一次露面:1 year 5 months ago
加入:2017-04-27 20:30
嗨,抱歉唠叨,但有

嗨,抱歉唠叨,但是你能够在这个方面取得任何进展吗?我们现在被困在你最后等待回复/帮助。请参阅上面的具体问题。

Thanks!

PM_DIALOG.
离线
最后一次露面:3小时14分钟前
职员
加入:2018-02-08 11:03
Hi pvmellor,

Hi pvmellor,

期间设备发送的数据量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. 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.

Specifically, the number of bytes that a device can send over the air is limited by the MTU (Maximum Transfer Unit), the MTU by default is limited in 23 bytes including the ATT layer overhead, so the payload is 20 bytes. By increasing the MTU size that means that you can send more bytes over the air. In your case the maximum transfer unit should be the number of bytes you would like to send + 3 extra bytes. You should change the .max_mtu of the user_gapm_conf structure of the user_config.h header file. After doing that in order to perform the exchange with the central you should send the GATTC_EXC_MTU_CMD when you have a connection (in the user_on_connection) and the 580 will perform the exchange. There is no API implemented for the MTU exchange functionality but you can use the snippet below:

静态void user_gattc_exc_mtu_cmd(uint8_t conidx)

{

struct gattc_exc_mtu_cmd * cmd = ke_msg_alloc(gattc_exc_mtu_cmd,

ke_build_id(task_gattc,conidx),task_app,

gattc_exc_mtu_cmd);

cmd-> req_type = gattc_mtu_exch;

ke_msg_send(cmd);

}

请检查附带的截图。我已经实施了256bytes - “没有回复写作”特征。此外,.max_mtu = 259,我在user_on_connection中使用上面的代码片段。为您的信息,我工作在SDK5.0.4的BLE_APP_PERITELAL示例上。正如您可以在附加的快照中看到的,则256bytes划分为较小的数据包。256bytes以1个连接间隔从BLE通用应用程序发送到外设。您可以看到,在空中发送数据时,仅使用通道-30,这意味着只有1个连接间隔。有效载荷通过7400位/秒。为什么您获得较小吞吐量的可能原因是您可能没有完成MTU Exchange,因此对于发送256bytes,需要超过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.