iOhYes Retired


A podcast by iOS developers for iOS developers, delivering news, tips, and rants for professional iOS/Mac developers, with something for enterprise and indie developers alike.

Hosted by Darryl Thomas and John Sextro.

← Previous Episode   |   Next Episode →

96: Discovering Core Bluetooth

December 16, 2015 at 11:45AM • 1 hour 7 minutes • Wiki Entry

Darryl and Nolan take a journey of exploration through the world of Bluetooth and Core Bluetooth.

Tweet Shoutouts

Discussion - News we missed

  • Swift is Open Source!
    • Apple starting to accept pull requests (notably the removal of C-style for loops)
    • Docs are also open, and a call has been made for translations
  • Apple to remove headphone jacks??
    • Audio over Lightning?
    • Bluetooth

Discussion - Core Bluetooth

  • Bluetooth’s Background
    • Invented by Ericsson in 1994 as a wireless alternative to RS-232 serial interfaces
    • IEEE 802.15.1 (Bluetooth) part of IEEE 802.15 (Personal Area Network: PAN) within IEEE 802 (Local and Metropolitan Area Networking, LAN & MAN) Wikipedia Link
    • The name is a nod to King Harald "Blåtand" Gormsson (Bluetooth is an anglicanized version of "Blåtand"). King Bluetooth is said to have united the Danish tribes into a single kingdom.
    • The logo is a bind rune forming the initials H. B. (sort-of)
  • Versions
    • 1.2
      • 1 Mbps data rate, > 80 kbps application throughput
      • Probably the first version considered “viable.”
    • 2.0 + EDR
      • 3 Mbps data rate, > 80 kbps application throughput
    • 3.0 + HS
      • 24 Mbps data rate, but not really: The connection is negotiated over a BT link, but 802.11 is used for data transfer
    • 4.0 (Classic and HS) & 4.0 LE (Branded as Bluetooth Smart)
      • 24 Mbps data rate, but not really: See 3.0 + HS and LE has extremely low throughput by design (like less than 100 kbps)
      • Bluetooth LE
        • Totally new protocol specifically designed for low energy consumption and simplified communications
        • Peripheral devices can implement just LE, just Classic or both
  • Bluetooth LE and Core Bluetooth
    • Core Bluetooth provides a layer of abstraction over the GATT profile (Generic Attribute Profile)
    • Peripherals are “servers”
    • Centrals are “clients”
    • Peripherals serve one or more Service(s)
    • Services have Characteristics (can be thought of as attributes or properties)
    • Characteristics have a value, which may be readable, writable or notifiable
  • Using CBCentralManager
    • Instantiate the manager and then check for availability (implement the -centralManagerDidUpdateState: delegate method and check for PoweredOn state
    • Scan for services with service UUIDs you provide using -scanForPeripheralsWithServices:options:
    • When peripherals are discovered, the -centralManager:didDiscoverPeripheral:advertisementData:RSSI: delegate method will be called
  • Connect to a peripheral using -connectPeripheral:options:, which in turn will call the delegate’s -centralManager:didConnectPeripheral: method.
  • At this point, you can start using the peripheral directly. (And get responses through the CBPeripheralDelegate protocol)
  • Discover services with -discoverServices:, which will result in the delegate’s -peripheral:didDiscoverServices: method being called
  • Similarly, discover characteristics of a service using -discoverCharacteristics:forService:, from which you can expect a -peripheral:didDiscoverCharacteristicsForService:error: message
  • Depending on the peripheral’s configuration, values for a characteristic can be read, written to or monitored for changes (notified)
  • Characteristic values are expected to be small. (Like 20 bytes or smaller.) If you need to send larger payloads, it’s possible to roll-your-own streaming protocol atop characteristics.
    • I don’t really recommend this, but it’s a fairly common approach
    • I suspect some of this comes from the legacy of BT being treated as a dumb serial link
    • Apple has recognized this trend and in recent versions of iOS/OS X, they have tried to accommodate higher throughput by negotiating higher MTUs when possible. They even demonstrate how this can be done in one of their WWDC sessions.