2

使用普通特性只读将读取 MTU 大小（20 字节）的数据。我的客户将提供更大尺寸（约 100 字节）的特征。

我看到 BLE 提供了一个“长读”功能，它会一直读取直到达到特征的大小。（https://bluegiga.zendesk.com/entries/25053373--REFERENCE-BLE-master-slave-GATT-client-server-and-data-RX-TX-basics）

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

但是如何在 Android 中使用此功能？BluetoothGatt 类只提供了一个简单的“Read()”——iOS 也是如此。

增加 MTU 是不可能的，因为我们需要支持 AP 级别 < 21 的设备（增加 MTU 是在 API 21 中引入的）

4

1 回答 1

1

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

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

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

Experiment to prove above.

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.

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.

于 2018-03-29T03:55:26.407 回答