• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: iOS BLE peripheral during HFP call
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: iOS BLE peripheral during HFP call

  • Subject: Re: iOS BLE peripheral during HFP call
  • From: Robert Hartman <email@hidden>
  • Date: Tue, 21 Jun 2016 14:50:08 -0400
Thank you, Craig, for the very helpful response. System design constraints do indeed have us looking to have the iOS be the central, as you suspected.

Rob

On Mon, Jun 20, 2016 at 3:28 PM, Craig Dooley <email@hidden> wrote:
Hi Robert,
While this *should* work, it’s complicated, and many factors can affect your performance.  If you are using a modern headset that supports eSCO, and allows the phone to be the master, then the controller should be able to find an event every 50ms to talk to the central.  If you are using an older headset that is SCO only, and the timing does not match (being the peripheral side of the link, the iOS device cannot guarantee that these events will be interleaved), events can be significantly delayed, though they should not be totally starved.  There are additional factors like additional LE accessories, WiFi throughput, and even potentially LTE coex, so like I said, it’s complicated.

Most likely you have design constraints that have led to the iOS device being the peripheral side of the connection, but my advice would be to have the iOS device be the central if at all possible.  iOS attempts to be the master of Classic connections, and is typically the central for LE connections, so it can own the clock and effectively schedule these multi-device scenarios.

- Craig

> On Jun 20, 2016, at 11:58 AM, Robert Hartman <email@hidden> wrote:
>
> We're developing an application that relies upon an iOS device acting as a peripheral, sending messages to a central at 20 Hz. We're curious what the implications on our application would be with the same device also performing a hands-free phone call, via bluetooth headset for example. We've witnessed degraded performance in a different iOS application during a HFP call, but with the app acting as a central. (Sorry, I don't have detail on exactly how the performance was degraded). We're basically wondering if anyone has experience with this, and how we can expect to be impacted when sending small messages at 20Hz under such a scenario?
> _______________________________________________
> 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
References: 
 >iOS BLE peripheral during HFP call (From: Robert Hartman <email@hidden>)
 >Re: iOS BLE peripheral during HFP call (From: Craig Dooley <email@hidden>)

  • Prev by Date: Re: Expose all GAP Characteristics to CoreBluetooth clients
  • Next by Date: iPhone as BLE Peripheral AND GATT Client
  • Previous by thread: Re: iOS BLE peripheral during HFP call
  • Next by thread: iPhone as BLE Peripheral AND GATT Client
  • Index(es):
    • Date
    • Thread