In my instance (current use cases) I have
removed the issue though the implementation of connect retries. Makes me think
that I haven’t seen the same problem as you as in my case error != nill and contained
text that indicated a connection timeout
My current problem is the occasional “CoreBluetooth[ERROR] XPC connection interrupted,
resetting” which I have not yet
found a fix for.
Cheers, Steve
From:
bluetooth-dev-bounces+steve=email@hidden
[mailto:bluetooth-dev-bounces+steve=email@hidden] On Behalf Of William Henderson
Sent: 17 May 2013 20:19
To: email@hidden
Subject: Re: Immediate disconnect
after connection attempts?
Still no solution here. This is 100% reproducible anytime a large
amount of data is being transferred over a 2.4ghz WiFi connection (Radar
is #13785322).
When running PacketLogger, after every connection attempt I get:
[HCI EVENT] Read Remote Version Information Complete - status:
0x3E -
Read Remote
Version Information Complete - status: 0x3E -
Parameter
Length: 8 (0x08)
Status: 0x3E -
Connection Failed To Be Established
Connection
Handle: 0x0040
Manufacturer
Name: 0x0000
[HCI EVENT] Disconnection Complete - Connection Failed To Be
Established (0x3E) - Connection Handle: 0x0040
Disconnection
Complete - Connection Failed To Be Established (0x3E) - Connection Handle:
0x0040
Parameter
Length: 4 (0x04)
Connection
Handle: 0x0040
However, my delegate gets didDisconnectPeripheral (with error==nil)
rather than didFailToConnectPeripheral as I'd expect. So, not only can I not
work around the bug, I can't even detect that I'm hitting it...
On Thursday, May 2, 2013 at 6:59 AM, Steve Childerley
wrote:
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.
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.
- 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).
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.
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.
On Apr 30, 2013, at 5:35 PM, Anthony Stevens <email@hidden> wrote:
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.
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?
On Apr 30, 2013, at 3:40 PM, Anthony Stevens <email@hidden> wrote:
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.
> 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.
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
> 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
6. CBCentralManager replies
on didDisconnectPeripheral
> 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.
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
_______________________________________________
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.
Help/Unsubscribe/Update your Subscription:
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
|