Apple

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>

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

On Dec 2, 2012, at 12:00 PM, email@hidden wrote:

Send Bluetooth-dev mailing list submissions to
email@hidden

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.apple.com/mailman/listinfo/bluetooth-dev
or, via email, send a message with subject or body 'help' to
email@hidden

You can reach the person managing the list at
email@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bluetooth-dev digest..."
Today's Topics:

  1. Peripheral load limit within background application
     (Arvydas Sidorenko)

From: Arvydas Sidorenko <email@hidden>

Subject: Peripheral load limit within background application

Date: December 1, 2012 5:48:01 PM PST

To: email@hidden

Application communicates with a bluetooth accessory while running in
the background. I am wondering is there a limit how much the
peripheral can interrupt the phone? Can the application be rejected if
peripheral gives too much load for the phone reducing battery life?

_______________________________________________
Bluetooth-dev mailing list
email@hidden
https://lists.apple.com/mailman/listinfo/bluetooth-dev

==========================

Anders Grunnet-Jepsen, Ph.D.

CTO

ThinkOptics, Inc.

5568 Del Oro Dr.

San Jose Ca 95124

email@hidden

+1 765-88-WAVIT [765-889-2848] (Office)

+1 408 823 0930

fax: 408 431 Wavit

==========================

_______________________________________________
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

References:
	>Repeated Connect-and-disconnect (From: Anders Grunnet-Jepsen <email@hidden>)
	>Re: Repeated Connect-and-disconnect (From: Etan Kissling <email@hidden>)