CoreBluetooth反复断开 [英] CoreBluetooth repeatedly disconnecting
问题描述
我一直在寻找这个问题，但似乎没有人遇到这个问题.
I've looked up and down for this problem, but no one seems to have it.
我有两个iPad.一种是始终处于前台的蓝牙外围设备.由于我对中央方面更感兴趣，因此我使我的中央iPad背景功能可用于BLE中央.我的工作流程如下:
I have two iPads. One is acting as a Bluetooth peripheral that is always in the foreground. Since I am more interested in the central side, I have made my central iPad background-capable for BLE-central. My workflow is as follows:
- 中央应用程序运行并开始扫描
- 外围设备广告服务(或在范围内)
- 中央设备连接到外围设备并停止扫描
- 外围广告(或离开范围)
- 中央设备断开连接并开始扫描
- 无论中心是在前台还是在后台，都可以无缝执行1-5步
当我运行中央iPad应用程序时，即使在整个时间内都在宣传该服务，第3步和第5步也会每10秒重复一次.这发生在前景和背景中.
When I run my central iPad app, steps 3 and 5 repeat every 10 seconds, even though the service is being advertised the entire time. This happens in the foreground and background.
在断开连接时，出现此错误:
On disconnect, I get this error:
Error occurred while disconnecting peripheral: The specified device has disconnected from us.
关于它为什么不断断开的任何想法?如果没有数据传输，CoreBluetooth是否会清理连接?现在，我的中心人员正在一次性读取外围特征.因为值是静态的，所以它不订阅更新. 谢谢！
Any ideas on why it keeps disconnecting? Does CoreBluetooth clean up the connections if no data is being transferred? Right now, my central is doing a one-off read of peripheral characteristics. It is not subscribing to updates, since the values are static. Thanks!!
推荐答案
就我而言，解决方案是订阅特征，而不管该值是否为静态.订阅似乎可以使连接保持活动状态，而如果您读取一次值，则框架将尝试节省电池寿命并断开连接，从而迫使您在执行其他读取或写入操作之前手动重新连接.
In my case the solution was to subscribe to the characteristic regardless of whether the value is static or not. It seems as though subscribing will keep the connection alive, whereas if you read one-off values the framework will try to conserve battery life and drop the connection, forcing you to manually reconnect before performing another read or write.
这篇关于CoreBluetooth反复断开的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
