BLE:使用Android/iOS读取长特征值 [英] BLE: Read Long Characteristics Value using Android / iOS

查看:501
本文介绍了BLE:使用Android/iOS读取长特征值的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

具有正常特征时,将仅读取MTU大小(20字节)的数据. 我的客户将提供较大的特征(大约100字节).

With a normal Characteristics Read only the MTU Size (20bytes) of data will be read. My customer will offer a characteristics with a larger size (about 100bytes).

我看到BLE提供了长时间读取"功能,该功能可以读取直到达到特征的大小为止. ( https://bluegiga.zendesk.com/entries/25053373--REFERENCE-BLE-master-slave-GATT-client-server-and-data-RX-TX-basics )

I saw that BLE offers a "Long Read" feature which reads until the size of the characteristics is reached. (https://bluegiga.zendesk.com/entries/25053373--REFERENCE-BLE-master-slave-GATT-client-server-and-data-RX-TX-basics)

attclient_read_long命令-启动一个过程,在此过程中,客户端首先向服务器发送正常的读取请求,如果服务器返回的属性值的长度等于BLE MTU(22字节),则客户端将继续发送"read"长"请求,直到读取了其余的属性.仅在读取长度超过22个字节的属性时适用.为了简单起见,构造GATT服务器以使它没有长属性通常更为简单.请注意,BLE协议仍然要求将数据打包为最大包. 22字节的块,因此使用"read long"不会节省传输时间.

attclient_read_long command - Starts a procedure where the client first sends normal read request to the server, and if the server returns an attribute value with a length equal to the BLE MTU (22 bytes), then the client continues to send "read long" requests until rest of the attribute is read. This only applies if you are reading attributes that are longer than 22 bytes. It is often simpler to construct your GATT server such that there are no long attributes, for simplicity. Note that the BLE protocol still requires that data is packetized into max. 22-byte chunks, so using "read long" does not save transmission time.

但是如何在Android中使用此功能? BluetoothGatt类仅提供一个简单的"Read()"-与iOS相同.

But how can I use this feature in Android? The BluetoothGatt class only offers a simple "Read()" - same for iOS.

无法增加MTU,因为我们需要支持AP级别< 21(increaseMTU是在API 21上引入的)

Increasing the MTU is not possible since we need to support devices with AP Level < 21 (increaseMTU was introduced at API 21)

推荐答案

我可以为iOS确认将首先执行按照标准的读取操作.然后,如果服务器返回完全填充的PDU,则iOS设备将继续执行blob读取操作.在运行iOS 11.2.x的iPhone 7上进行了测试

I can confirm for iOS that a read operation as per standard will occur first. Then if the server returns a completely filled PDU, the iOS device will then continue to perform the blob read operation. Tested with iPhone 7 running iOS 11.2.x

对于长属性,您不需要多次调用外围设备. CoreBluetooth会在后台进行所有这些操作.

You do NOT need to call the peripheral.readValue(characteristic) multiple times for long attributes. CoreBluetooth does all of this under the covers.

请参阅Bluetooth Spec Core v5.0,特别是第3卷,F部分长属性值".

Refer to the Bluetooth Spec Core v5.0, specifically Vol 3, Part F. "Long Attribute Values".

上面要证明的实验.

我有一个Android Thing充当服务器,在读取操作期间,我正在用iPhone返回最大长度. iOS和我的RPI3交换的MTU为185.因此,读取响应的长度为(MTU-1)184个字节.然后,服务器(RPI)接收偏移为184的新读取请求,然后您可以返回更多数据.一直持续到偏移量> 512,或者最后一个读取响应返回的值小于MTU-1的长度.

I have an Android Thing acting as the server that I'm making return the maximum length with my iPhone during a read operation. iOS and my RPI3 exchange a MTU of 185. So the read response is (MTU - 1) 184 bytes long. The server (RPI) then receives a new read request with an offset of 184, which you can then return more data. This is continued until the offset is > 512, or the last read response returns less than the MTU - 1 length.

基于BluetoothGattServer支持长属性的事实,我认为BluetoothGatt对象也可以.由于无法通过API设置要读取的偏移量,因此我假设您只能调用一次read.

Based upon the fact that the BluetoothGattServer supports long attributes, I'd assume the BluetoothGatt object does as well. Since there is no way via the API to set the offset to be read, I'd assume you can invoke read just once.

这篇关于BLE:使用Android/iOS读取长特征值的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆