Apple

I have been seeing the same problem on iOS 6.1.3 connecting to BLE112 (Bluegiga device latest stack ble-1.1.1-71 ), which uses CC2540 I am seeing failure in about 15% connection attempts - connecting up to 4 peripherals simultaneously. My use case is similar to that described by Anthony

Some usage guidelines appear to have fallen out of a discussion on Core Bluetooth discussion forum.

https://devforums.apple.com/thread/179310?tstart=15

However I am pleased it is now on Apples Radar â I hope they add it to their use - case testing ideally using multiple peripheral silicon vendors.

Steve.

From: bluetooth-dev-bounces+steve=email@hidden [mailto:bluetooth-dev-bounces+steve=email@hidden] On Behalf Of William Henderson
Sent: 01 May 2013 22:06
To: John Earl
Cc: email@hidden Bluetooth
Subject: Re: Immediate disconnect after connection attempts?

Here's what I am seeing:

Summary: With 100% reproducibility, I get unexplained connection failures when running either a Time Machine backup or AirTunes on a 2.4ghz network.

Setup: A 10.8.3 Macbook Pro Retina 15" (Mid 2012) connected to a Time Capsule. The Time Capsule is setup host 5Ghz and 2.4Ghz networks separately. There is also an Airport Express on the network, setup to join the wireless network.

Repro steps:

Using the HeartRateMonitor sample project.

My only modification was to remove the UDID in [CBCentralManager scanForPeripheralsWithServices: options:]. I don't have a heart rate monitor sitting around, so I'm just having it hit my existing iOS peripheral project.

Normally, the HeartRateMonitor project discovers my device and connects fine.

When a Time Machine backup is running, every connect is followed by an immediate disconnect. In didDisconnectPeripheral, no error is given.
When I start streaming via AirTunes that are connected to the network, every connect is followed by an immediate disconnect. In didDisconnectPeripheral, no error is given.

If I switch to the Time Capsule's 5Ghz network, connecting works fine (even if running a TM backup and/or steaming via AirTunes).

Radar is #13785322.

William Henderson

On Wednesday, May 1, 2013 at 3:28 AM, John Earl wrote:

For additional information on this:

As we have previously thought we'd seen similar problems, so having seen this thread, we tried reproducing this with the Nordic nRF8001 and we are not seeing this behaviour even after 500 disconnect/reconnect cycles. We have the Nordic as peripheral and the iPhone as central. iPhone is writing a characteristic to ask Nordic to disconnect -- I presume this is the same as Anthony's test.

We have used iOS 6.1.2 and an iPhone 4S for this test but we are going to try some other iOS versions/devices later on. We have security enabled, i.e. devices are paired before beginning the test sequence.

We also have a minor difference from Antony's description with his peripheral. We achieve disconnect on the Nordic by resetting the radio. Accordingly the iPhone sees every commanded disconnect CBErrorDomain Code=6 (timeout). Don't know if this affects.

John

On 1 May 2013, at 03:33, Anthony Stevens wrote:

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

We have also tried scanning just the first time during the harness testing and reusing the original peripheral. The results are the same. Our issue sounds suspiciously similar to the one posted by Maxim in February: http://lists.apple.com/archives/bluetooth-dev/2013/Feb/msg00090.html

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?

--

William Henderson

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________

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

This email has been scanned by Netintelligence
http://www.netintelligence.com/email