| Hi All,
We have submitted this bug to Apple as Problem ID #13779917. You'll have to search for the bug here as Apple doesn't provide a direct link: https://bugreport.apple.com.
Cheers, Anthony
On Apr 30, 2013, at 5:35 PM, Anthony Stevens < email@hidden> wrote: Hi Jason,
We're connecting our iOS devices to a T.I. CC2540 w/blestack 1.3. We haven't submitted the bug yet. Our plan was to create an iOS peripheral and connect to it via an iOS device to see if the issue can be replicated that way too. That would prove the bug definitively as in iOS.
Unfortunately we haven't had time to implement that test case. If anyone already had an iOS device acting as a peripheral, the test would be fairly quick.
Anthony
On Apr 30, 2013, at 3:52 PM, Jason Conn < email@hidden> wrote: Anthony,
First off, impressive analysis of the situation. This isn't the first time I've heard of a sporadic connection issue like this but, so far, we haven't been able to reproduce it in-house. Your repro steps may help us correct that.
In the meantime, have you filed a bug for this issue? I'm also curious what your peripheral is in this situation - is it also an iOS device?
- Jason
On Apr 30, 2013, at 3:40 PM, Anthony Stevens < email@hidden> wrote: Hi William,
We experienced the same issue which seems to be an issue with Apple's bluetooth implementation. We submitted this to the list awhile ago but haven't found a workaround.
Here's why we concluded this was a bluetooth issue: When a valid connection is made, the bluetooth icon is active/white when CBCentralManager replies on didConnectPeripheral. When a invalid connection is made (will rapidly timeout and disconnect), the bluetooth icon is inactive/gray when CBCentralManager replies on didConnectPeripheral. , This seems like a smoking gun that something is odd on the iOS bluetooth stack side."
Here's a more detailed explanation of our test suite:
We're developing an app using iOS's low energy bluetooth stack. The app connects with a peripheral device to periodically read data. All's great except for a persistent, yet random, immediate peripheral timeout on re-connect. This is the error detail from CBCentralManager at didDisconnectPeripheral.
> Domain=CBErrorDomain > Code=6 > NSLocalizedDescription=The connection has timed out unexpectedly
Each disconnect happens as soon as we call discoverServices on the newly connected peripheral (which has [peripheral isConnected] == YES). When looking at the peripheral's logs, it shows it is not receiving a connection request from iOS over bluetooth. When placed in a bluetooth isolation chamber, our bluetooth sniffer sees no bluetooth connection request packets for these timed-out connections…implying that CBCentralManager is replying in didConnectPeripheral with a peripheral that cannot really be connected.
We've written a test harness to reliably reproduce this issue. The harness establishes a connection, transmits/receives some data, explicitly writes a characteristic to have the peripheral terminate the connection, then attempts to reconnect. For every 100 connect-then-reconnects, an average 10 of these will experience a peripheral timeout on re-connect. After 2-3 timeout on re-connect attempts, a lasting connection is established and the harness proceeds with its cycling.
Here are the steps followed by the test harness:
1. Scan for a peripheral. 2. Stop scan 3. Call [CBCentralManager connectPeripheral] 4. CBCentralManager replies on didConnectPeripheral. 5. Call discoverServices on peripheral 6. Read/write data to/from peripheral 7. Explicitly disconnect peripheral by writing a characteristic 8. CBCentralManager replies on didDisconnectPeripheral > CBErrorDomain Code=7 > The specified device has disconnected from us 9. Perform a reconnect by returning to step 1
Roughly 10% of the time when we perform the reconnect in step 9, we see the below happen 2-3 times before a successful reconnect
1-5 as above 6. CBCentralManager replies on didDisconnectPeripheral > Domain=CBErrorDomain > Code=6 > NSLocalizedDescription=The connection has timed out unexpectedly 7. Perform a reconnect by returning to step 1
Any more guidance anyone can offer would be greatly appreciated.
Thank you,
Anthony On Apr 30, 2013, at 2:34 PM, William Henderson < email@hidden> wrote:
I am running as a central on OS 10.8.3. In normal circumstances everything works great. As you are probably aware, there is quite a bit of interference while connected to a 2.4ghz WiFi network. This is particularly bad when transferring a lot of data (running Airplay or Time Machine).
Anyway, when connect to a 2.4ghz and running Airplay my system will sometimes get into a state where I can't connect to any peripherals. I get the centralManager: didConnectPeripheral: callback but it is immediately proceeded by centralManager: didDisconnectPeripheral: error:. No error is present.
If I stop using Airplay or switch to a 5ghz wifi network, everything works as normal (and stops working again when I switch back). However, nothing else does – restarting my Mac app, turning Bluetooth on/off, etc. Sounds like a bug?
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|