在Android上同时与多个BLE设备进行可靠的沟通

虽然没有文档记载,但使用Android BLE API的传统知识是,某些特定操作(例如读/写特性和描述符)应该一次一个地完成(尽pipe某些设备比其他设备更宽松)。 但是,我不清楚这个策略是否只适用于一个单独的连接,也不适用于所有的活动连接。

我听说最好一次发起一个设备连接。 这可能是一个应该在所有设备之间串行执行的操作(connect / connectGatt)的例子。

但是对于读写特性等其他操作,如果每个连接都是串行执行操作,还是需要在所有设备之间共享一些全局操作队列,以便所有设备之间只有一个操作正在执行,那么是否足够好?

Solutions Collecting From Web of "在Android上同时与多个BLE设备进行可靠的沟通"

在Android上, 每个BluetoothGatt对象一次只能执行一个操作(请求mtu,发现服务,读/写特征/描述符),否则会出错。 您必须等到相应的callback被调用,直到您可以执行下一个操作。

关于同时有多个设备的挂起连接,如果你使用autoConnect = true,那么没有问题,但如果你使用autoConnect = false,那么Android的蓝牙堆栈将只尝试连接到一个设备,这意味着它将排队如果有多个未完成的连接请求。 有一个特定的错误,它不能取消仍然在队列中的挂起连接(当你调用.disconnect()或.close())时,最近在Android中已经修复。

请注意,还有最大数量的连接/待定连接/ gatt对象,其行为完全没有logging,当超过这些限制时会发生什么情况。 在最好的情况下,你只是得到一个错误状态的callback,但在某些情况下,我已经看到,Android蓝牙堆栈卡在一个无尽的循环,在每次迭代告诉蓝牙控制器连接到设备,但控制器发回错误代码达到最大连接数。

虽然我不能说上层,但我可以涉及在较低的硬件水平上会发生什么,并可能为您的devise提供一些见解。

上层的堆栈究竟在做什么,最后操作必须由收发器芯片来处理。

BLE运行在40个以上的通道频段,其中3个用于广播和其他数据传输。 这样做是为了能够将多个设备通信在一起,限制在其他频段上的冲突。

这些频段是根据噪声(或stream量)最低的频段进行select的。

收发器本身一次只能在一个频段中进行通信(说话和听),并且必须在频段之间切换才能到达其他设备。 这是通过非常严格的沟通时间来完成的。

另一个事实是,无线收发器基本上是一种带有碰撞检测的半双工通信,它不能同时发送和收听,也不能同时在同一个频段上发射。 因此,它是按照devise(和自然规律)连续或顺序的。

如果你实现某种操作队列或者线程实现,最后所有的东西都必须由收发器按顺序对待。

如果通过不同的线程访问它,收发器可能不得不在通道之间跳转,或者如果在上层处理不好,可能会感到困惑。

我认为在线程上处理这个问题的唯一好理由是收发器的处理时间明显低于要运行的上层协议栈,而您将利用多核处理器。

但除此之外,除非有非常特定的软件需求或体系结构,否则我不相信你会获得与串行不同的实现方面的重大收益,而且为了上面解释的考虑,我也会一个接一个地对所有的奴隶说话。

BLE被devise为asynchronous和事件驱动。 你可以发送你喜欢的命令,而且你可以按照特定的顺序得到回应。 如果你发送一个命令,并希望下一个数据包是响应,你将会遇到麻烦。

这就是说,我不确定Android库是如何构造的。