IOBluetooth对某些服务不返回任何特征 [英] IOBluetooth is returning no characteristics for some services

问题描述

我正在尝试从Bluetooth LE设备上的服务读取特征.由于某些原因，出于某些特征，在调用-[CBPeripheralManager discoverCharacteristics:forService]之后，peripheral:didDiscoverServices:回调将获得0个特征.有什么变通办法可以让我阅读此服务的特征吗?

I’m trying to read characteristics from a service on a Bluetooth LE device. For some reason, for some characteristics, after calling -[CBPeripheralManager discoverCharacteristics:forService], the peripheral:didDiscoverServices: callback is getting 0 characteristics. Are there any workarounds to allow me to read the characteristics of this service?

在安装用于Xcode的硬件IO工具时并运行PacketLogger时，很明显DiscoverServices调用引起了0x08的按类型读取请求(蓝牙®核心规范第3卷，F部分，第3.4.4.1节)，起始句柄= 0x1a，结束句柄= 0x1a，属性类型= 0x2803

When installing Hardware IO Tools for Xcode and running PacketLogger, it is apparent that the discoverServices call is causing a 0x08 Read By Type request (Bluetooth® Core Specification Volume 3, Part F, Section 3.4.4.1) with Starting Handle=0x1a, Ending Handle=0x1a, Attribute Type=0x2803.

此外，通过定义以下类扩展来读取受保护的字段，很明显，我感兴趣的服务0x180a =设备信息，也具有ATT处理的舒适度太接近:_startHandle = 0x1a和_endHandle = 0x1a.

Also, by defining the following class extensions to read the protected fields, it is apparent that the service that I’m interested in, 0x180a=Device Information, also has ATT handles too close to comfort: _startHandle=0x1a and _endHandle=0x1a.

@implementation CBService(ProtectedProps)
- (NSNumber*) startHandle {
    return self->_startHandle;
}
- (NSNumber*) endHandle {
    return self->_endHandle;
}
@end
@implementation CBCharacteristic(ProtectedProps)
- (NSNumber*) descriptorHandle {
    return self->_handle;
}
- (NSNumber*) valueHandle {
    return self->_valueHandle;
}
@end

顺便说一句，当我在iPhone 4S上从LightBlue读取设备时，该服务运行正常，并且我可以读取该服务的3个特征.

By the way, when I read the device from LightBlue on an iPhone 4S, the service works fine, and I can read the 3 characteristics of this service.

我正在使用Apple Bluetooth软件版本:4.2.0f6 12982在OSX 10.9 Mavericks上对其进行测试.我正在测试的设备是Livescribe 3.

I’m testing this on OSX 10.9 Mavericks with Apple Bluetooth Software Version: 4.2.0f6 12982. The device that I’m testing is a Livescribe 3.

这是实际的GATT句柄，CBService句柄和UUID的表.在将128位UUID弄乱表之后，看起来好像有了16位UUID.蓝牙4.0第3.1节指出，应该"将16位UUID服务组合在一起以提高性能，但我认为它们不是必须的.

Here is a table of the actual GATT handles, CBService handles, and UUIDs. It looks like having a 16-bit UUID after a 128-bit UUID messed up the table. Bluetooth 4.0 section 3.1 states that 16-bit UUID services "should" be grouped together for performance, but I don’t think they must.

1. 0001–0004 0001–0004 uuid:1801
2. 0005-0009 0005-0009 uuid:1800
3. 0010–0019 0010–0019 uuid:128位UUID
4. 001A–0020 001A–001A uuid:180a
5. 0021-0023 缺失 uuid:180f
6. 0024–002A 0021–0027 uuid:128位UUID
7. 002E–0031 002B–002E uuid:128位UUID

1. 0001–0004 0001–0004 uuid:1801
2. 0005–0009 0005–0009 uuid:1800
3. 0010–0019 0010–0019 uuid:128 bit UUID
4. 001A–0020 001A–001A uuid:180a
5. 0021–0023 missing uuid:180f
6. 0024–002A 0021–0027 uuid:128 bit UUID
7. 002E–0031 002B–002E uuid:128 bit UUID

推荐答案

读取与128位UUID交错的16位UUID的错误可能已在OSX 10.9.1中修复.但是，由于计算机仍与外围设备绑定，因此不良值仍被缓存.因此，如果您先前已连接到外围设备，则由于缓存的GATT值不正确，无论您重新连接或重新启动多少次，该错误仍然会自行显现.

The bug in reading 16-bit UUIDs interleaved with 128-bit UUIDs was probably fixed in OSX 10.9.1. However, the bad values were still cached because the computer was still bonded with the peripheral. So if you previously connected to the peripheral, the bug will still manifest itself no matter how many times you reconnect or restart because of the bad cached GATT values.

我必须擦除绑定缓存/Library/Preferences/com.apple.Bluetooth.plist并杀死blued.请参阅我的其他问题蓝缓存ATT是否值，以及如何清除缓存?以了解更多详细信息.

I had to erase the bonding cache /Library/Preferences/com.apple.Bluetooth.plist and kill blued. See my other question Does blued cache ATT values, and how to clear the cache? for more details.

这篇关于IOBluetooth对某些服务不返回任何特征的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！