Android为BLE BLOB请求所需的大约时间是多少？
我正在使用BLOB请求来读取超过23个字节的属性。我的应用程序的MTU是23.我可以在sniffer中看到，要转移512个字节，它将以22次偏移为24个内部BLOB请求，服务器将数据发送给我。 在我的情况下，每个内部BLOB请求都需要大约105毫秒，而LightBlue应用程序则为中央。 我不太了解Android BLE的这种内部碎片。 有人可以确认我是否为每个内部请求的105ms和2.5秒的读取512字节是由于内部机制造成的吗？
I am using Blob Request to read an attribute which is more than 23 Bytes. My application's MTU is 23.I could see in the sniffer that, to transfer 512 bytes, it is taking 24 internal blob requests with incremental offset of 22, server sends me the data back.
It is taking around 105 ms for each internal Blob request in my case and with LightBlue app as central.
I am not much aware of this internal fragmentation by Android BLE.
Could someone confirm me if that 105ms for each internal request and 2.5 seconds to read 512 bytes is due to internal mechanism?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来很合理。我想您尚未更新连接间隔，因此使用默认值约52毫秒。我还猜想您的远程设备未经优化，以便能够在同一连接事件中使用读取BLOB响应（必须在150微秒内完成）。因此，每次交易都将进行两个连接事件，您最终会以105 ms的速度出现。考虑增加MTU，切换到通知或切换到L2CAP COC以获得更高的吞吐量，并使用LE数据长度扩展。否则，只需降低连接间隔即可增加您可以执行的每秒交易数量。
Sounds reasonable. I guess you have not updated the connection interval and hence use the default of ~52 ms. I also guess your remote device is not optimized to be able to respond with a Read Blob Response in the same connection event (which must be done within 150 microseconds). Therefore every transaction will take two connection events and you end up with 105 ms. Consider increasing the MTU, switching to notifications or switching to L2CAP CoC to get higher throughput, as well as use the LE Data Length extension. Otherwise just lower the connection interval to increase the number of transactions per second you can perform.
您观察到的时机取决于许多因素，因此您的观察只是许多可能性之一。它可能会更快一些，但也要慢得多。
由于蓝牙收音机是共享资源，因此其他应用程序也可以同时访问它。接收器侧的收音机也可能还有其他事情要做，从而改变了时间延迟。最后但并非最不重要的一点是，通常还对2.4 GHz WLAN有一个依赖性，因此，例如，同时进行的数据传输也会影响传输速度。
The timing you observe depends on a number of factors, so your observation is only one of many possibilities. It could just as well be a little faster but also a lot slower.
Since the Bluetooth radio is a shared resource, other applications can also access it at the same time. The radio on the receiver side may also have other things to do and thus change the time delay. And last but not least, there is usually also a dependency on 2.4 GHz WLAN so that, for example, a data transmission taking place there at the same time also has an influence on the transmission speed.