Re: Repeated Connect-and-disconnect
Re: Repeated Connect-and-disconnect
- Subject: Re: Repeated Connect-and-disconnect
- From: 原晶 <email@hidden>
- Date: Wed, 05 Dec 2012 18:03:04 +0800
I met the same problem (connected->disconnected loop) sometimes, especially in the device of iPod touch5.
The coreBluetooth print "unknown error 14" before disconnected. Dose anyone know what's the meaning?
<<
CoreBluetooth[WARNING] Unknown error: 14
>>
br,
Kim
------------------------------
Message: 3
Date: Mon, 03 Dec 2012 08:42:48 +0000
From: Etan Kissling <email@hidden>
To: Anders Grunnet-Jepsen <email@hidden>
Cc: "<email@hidden> " <email@hidden>
Subject: Re: Repeated Connect-and-disconnect
Message-ID:
<email@hidden>
Content-Type: text/plain; charset="utf-8"
Anders,
I cannot reproduce your problem. So here are some general hints that may push you into correct direction:
- can you show an air trace of your full cycle of connect => disconnect?
=> http://www.ti.com/tool/packet-sniffer
- are you splitting discovery / connect on multiple views?
=> maybe something in your state machine to handle your application state is wrong then
- are you using multiple CBCentralManagers?
=> receiving a CBPeripheral, then passing it to another CBCentralManager is a bad idea.
Because passing the CBUUID between CBCentralManager's wont work as of new iOS 6
"features", you'll need to pass your original CBCentralManager and the original CBPeripheral
between your views
- peripheral fully powered with a new battery and at <1m range?
=> I recall having similar problems as you with a device at max range and with a device at low battery
power. However I cannot ensure that this problem only occurred to me on the first connection
- warnings shown in the log?
=> Always helpful :-) Or otherwise a simple "No warnings in the log".
- try to log didConnectPeripheral, didFailToConnectPeripheral and didDisconnectPeripheral calls
and print the UUID on every of those.
=> When does the UUID appear for the first time?
Is it already appearing in your endless loop?
Is the peripheral in the didDisconnectPeripheral callback the same as the one you are trying to connect to?
Does the error argument of the didDisconnectPeripheral call contains information about a reason for
remote-initiated disconnect?
Workaround:
- Build in a connection timeout starting on the first connect request, and ending when the connection is
established and GATT structures (services, characteristics, discovered) are discovered.
=> Your application won't get stuck anymore
- Just add a cancel button for the user
=> Fixes all CB-related issues and gives your user control over how long he wants to wait :-)
Probably, you will need to implement one of those workarounds anyways. Otherwise, you cannot handle
the situation when iPhone moves out of range after discovery and prior connect. If you do not implement
one of the workarounds, your iPhone will stay in a connecting state until you come either back in range
or you cancel the connection request (either through timeout or cancel-button for the user).
Etan
On 03.12.2012, at 07:16, Anders Grunnet-Jepsen <email@hidden<mailto:email@hidden>>
wrote:
I am seeing a very strange issue and I am hoping someone can help.
The very first time an iPhone sees a Peripheral, the UUID is returned as "null".
This has been discussed before (it is a new feature of iOS6) and is not directly the problem, because supposedly you should be able to connect anyway and all subsequent connections you make will show a valid UUID.
However, during this initial connection, I find that the iPhone decides to disconnect the connection immediately after the connection has been established.
When I see an "unwanted" disconnect I immediately try to reconnect again from within the "didDisconnect" method. The result is that I end up with a never ending sequence of connect, disconnect, connect, disconnect....
The only way to fix this is to I to exit the app, re-power the peripheral, and restart the app. From now on and forever after this particular iPhone+Peripheral connection works wonderfully.
So to summarize, it is the very first connection that is giving this headache.
Has anyone else seen this, and what is correct way to address this issue?
Anders
_______________________________________________
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