简体   繁体   English

在Android 4.4.4 Nexus 4上写入多个BluetoothGatt对象

[英]Writing to Multiple BluetoothGatt objects on Android 4.4.4 Nexus 4

I know this has been discussed at length, but I have not found an answer that seems to solve the issue I am facing with Android Bluetooth LE. 我知道已经对此进行了详尽的讨论,但是我还没有找到一个似乎可以解决我所面临的Android Bluetooth LE问题的答案。

The system we have designed allows connections to multiple devices. 我们设计的系统允许连接到多个设备。 Discovery and connection to multiple devices works great. 发现并连接到多个设备非常有用。 Each BluetoothGatt object instance is saved based on the MAC address of the device and each of these instances is assigned a unique callback object (this is based off information from Nordic Semiconductor's website regarding multiple device connections in Android). 每个BluetoothGatt对象实例都基于设备的MAC地址保存,并且为每个实例分配一个唯一的回调对象(这是基于Nordic Semiconductor网站上有关Android中多个设备连接的信息)。

The issue comes about when I try to write the same data to multiple devices. 当我尝试将相同的数据写入多个设备时,就会出现问题。 Typically, each individual write is the same data on the same characteristic UUID but on different BluetoothGatt instances. 通常,每个单独的写入都是在相同特征UUID上但在不同BluetoothGatt实例上的相同数据。 All writes are queued in the app to ensure only one write request is pending at a given time with the BT Stack on Android. 所有写入操作都在应用程序中排队,以确保在给定时间只有一个写入请求通过Android上的BT Stack挂起。 I am well aware of the perils of doing otherwise as there is a plethora of information about it. 我深知这样做的危险,因为关于它的信息太多。

The behavior I am seeing is that one of the devices, usually the first one to which I connect, always receives the data. 我看到的行为是其中一个设备(通常是我连接的第一个设备)始终接收数据。 The other devices never receive the data. 其他设备从不接收数据。 However, the BT stack returns onCharacteristicWrite for every write I send. 但是,BT堆栈对于我发送的每个写入都返回onCharacteristicWrite。 So, the BT stack seems to think it wrote the data to all devices, but instead, it seems to queue it up. 因此,BT堆栈似乎认为它已将数据写入所有设备,但是似乎要排队。 If, after some time has passed (unknown amount of time), I send a command only to one of the devices that was not receiving data, the BT stack seems to push all unsent data to the device and then whatever command I last sent as if it was sent a flush() command. 如果经过一段时间(未知时间)后,我仅向未接收数据的设备之一发送命令,则BT堆栈似乎会将所有未发送的数据推送至设备,然后再发送我上次发送的命令如果发送了flush()命令。 Here is a logcat of the behavior: 这是行为的日志:

11-18 01:58:55.571 E/testapp( 1110): writeDataToCharacteristic(characteristic. Value: [111, -1, 95]) 11-18 01:58:55.571 E / testapp(1110):writeDataToCharacteristic(characteristic。Value:[111,-1,95])

11-18 01:58:55.571 D/testapp( 1110): Characteristic WriteType: 1 11-18 01:58:55.571 D / testapp(1110):特征WriteType:1

11-18 01:58:55.571 I/testapp( 1110): writeCharacteristic for CF:9E:D0:9A:98:90 with value - [-1, -102, -112] 11-18 01:58:55.571 I / testapp(1110): CF:9E:D0:9A:98:90的 writeCharacteristic值-[-1,-102,-112]

11-18 01:58:55.571 D/BluetoothGatt( 1110): writeCharacteristic() - uuid: 9a143cb6-d775-4cfb-9eca-6e3a9b0f966b 11-18 01:58:55.571 D / BluetoothGatt(1110):writeCharacteristic()-uuid:9a143cb6-d775-4cfb-9eca-6e3a9b0f966b

11-18 01:58:55.571 D/BtGatt.GattService( 1204): writeCharacteristic() - address= CF:9E:D0:9A:98:90 11-18 01:58:55.571 D / BtGatt.GattService(1204):writeCharacteristic()-address = CF:9E:D0:9A:98:90

11-18 01:58:55.571 D/BtGatt.btif( 1204): btif_gattc_write_char 11-18 01:58:55.571 D / BtGatt.btif(1204):btif_gattc_write_char

11-18 01:58:55.571 D/BtGatt.btif( 1204): btgattc_handle_event: Event 1015 11-18 01:58:55.571 D / BtGatt.btif(1204):btgattc_handle_event:事件1015

11-18 01:58:55.571 D/BtGatt.btif( 1204): btif_gattc_upstreams_evt: Event 4 11-18 01:58:55.571 D / BtGatt.btif(1204):btif_gattc_upstreams_evt:事件4

11-18 01:58:55.571 D/BtGatt.GattService( 1204): onWriteCharacteristic() - address= CF:9E:D0:9A:98:90 , status=0 11-18 01:58:55.571 D / BtGatt.GattService(1204):onWriteCharacteristic()-address = CF:9E:D0:9A:98:90 ,status = 0

11-18 01:58:55.571 D/BluetoothGatt( 1110): onCharacteristicWrite() - Device= CF:9E:D0:9A:98:90 UUID=9a143cb6-d775-4cfb-9eca-6e3a9b0f966b Status=0 11-18 01:58:55.571 D / BluetoothGatt(1110):onCharacteristicWrite()-设备= CF:9E:D0:9A:98:90 UUID = 9a143cb6-d775-4cfb-9eca-6e3a9b0f966b状态= 0

11-18 01:58:55.571 I/testapp( 1110): onCharacterisiticWrite 11-18 01:58:55.571 I / testapp(1110):onCharacterisiticWrite

11-18 01:58:55.571 E/testapp( 1110): writeDataToCharacteristic(characteristic. Value: [111, -1, 95]) 11-18 01:58:55.571 E / testapp(1110):writeDataToCharacteristic(characteristic。Value:[111,-1,95])

11-18 01:58:55.581 D/testapp( 1110): Characteristic WriteType: 1 11-18 01:58:55.581 D / testapp(1110):特征WriteType:1

11-18 01:58:55.581 I/testapp( 1110): writeCharacteristic for DB:7B:3E:47:AF:1A with value - [-1, -102, -112] 11-18 01:58:55.581 I / testapp(1110): DB:7B:3E:47:AF:1A的 writeCharacteristic值-[-1,-102,-112]

11-18 01:58:55.581 D/BluetoothGatt( 1110): writeCharacteristic() - uuid: 9a143cb6-d775-4cfb-9eca-6e3a9b0f966b 11-18 01:58:55.581 D / BluetoothGatt(1110):writeCharacteristic()-uuid:9a143cb6-d775-4cfb-9eca-6e3a9b0f966b

11-18 01:58:55.581 D/BtGatt.GattService( 1204): writeCharacteristic() - address= DB:7B:3E:47:AF:1A 11-18 01:58:55.581 D / BtGatt.GattService(1204):writeCharacteristic()-address = DB:7B:3E:47:AF:1A

11-18 01:58:55.581 D/BtGatt.btif( 1204): btif_gattc_write_char 11-18 01:58:55.581 D / BtGatt.btif(1204):btif_gattc_write_char

11-18 01:58:55.581 D/BtGatt.btif( 1204): btgattc_handle_event: Event 1015 11-18 01:58:55.581 D / BtGatt.btif(1204):btgattc_handle_event:事件1015

11-18 01:58:55.581 D/BtGatt.btif( 1204): btif_gattc_upstreams_evt: Event 4 11-18 01:58:55.581 D / BtGatt.btif(1204):btif_gattc_upstreams_evt:事件4

11-18 01:58:55.581 D/BtGatt.GattService( 1204): onWriteCharacteristic() - address= DB:7B:3E:47:AF:1A , status=0 Stack claims write success, but the data is never received on device and the characteristic value remains unchanged 11-18 01:58:55.581 D / BtGatt.GattService(1204):onWriteCharacteristic()-address = DB:7B:3E:47:AF:1A ,status = 0 堆栈声明写入成功,但是从不接收数据设备且特性值保持不变

11-18 01:58:55.581 D/BluetoothGatt( 1110): onCharacteristicWrite() - Device= DB:7B:3E:47:AF:1A UUID=9a143cb6-d775-4cfb-9eca-6e3a9b0f966b Status=0 11-18 01:58:55.581 D / BluetoothGatt(1110):onCharacteristicWrite()-设备= DB:7B:3E:47:AF:1A UUID = 9a143cb6-d775-4cfb-9eca-6e3a9b0f966b状态= 0

11-18 01:58:55.581 I/testapp( 1110): onCharacterisiticWrite 11-18 01:58:55.581 I / testapp(1110):onCharacterisiticWrite

In the above, there are two characteristic writes to the same characteristic UUID on two different devices. 在上面,在两个不同的设备上有两个特征写入相同的特征UUID。 The main difference being the device address which I have bolded for clarity. 主要区别是设备地址,为清楚起见,我将其加粗。 The stack claims to have performed both writes, but it in fact did not. 堆栈声称执行了两次写入,但实际上没有执行。 I have not found a solution to this issue as it seems the stack is caching the write to the second device but not actually writing it out. 我没有找到解决此问题的方法,因为堆栈似乎正在缓存对第二个设备的写入,但实际上并未将其写入。 Note that I have a delay between each set of writes but each individual write is delayed only by waiting for the onCharacteristicWrite callback from the stack. 请注意,每组写入之间都有一个延迟,但是每个单独的写入仅通过等待堆栈中的onCharacteristicWrite回调而延迟。

Some pseudo code to show how the data is being sent to all connected devices. 一些伪代码,用于显示如何将数据发送到所有连接的设备。 I will add more if necessary for this discussion: 如果需要进行讨论,我将添加更多内容:

if(canWrite) {
    for (BTDevice device : deviceList) {
        /* Each write is queued at a lower level. */
        device.sendData(data);
    }

    nextChangeAllowed = System.currentTimeMillis() + 100;
    canWrite = false;
}

if(nextChangeAllowed < System.currentTimeMillis()) {
    canWrite = true;
}

Has anyone else run in to this issue and solved it? 还有其他人遇到这个问题并解决了吗?

I faced a similar problem as yours. 我遇到了与您类似的问题。 I needed to write the same characteristic to two devices, and what I did is implement an algorithm that wrote the characteristic to the second device, only when the first one was written and read (when onCharacteristicRead was called). 我需要向两个设备写入相同的特征,而我所做的是实现一种算法,该算法仅在写入和读取第一个设备时(调用onCharacteristicRead时)才将特征写入第二个设备。

So that canWrite flag (on your pseudocode), should be changed inside the callback onCharacteristicRead when the previous characteristic written has been completed written and read. 因此,当先前写入的特征已完成写入和读取时,应在回调onCharacteristicRead内部更改canWrite标志(位于伪代码上)。

Hope this helps. 希望这可以帮助。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM