This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Connection problem between Bluetooth Smart keyboard and iPhone (iOS 8.2)

Other Parts Discussed in Thread: CC2541

We have used your "CC2541" and "Bluetooth stack 1.4" on our
product to control "Bluetooth keyboard" and it had worked in good condition
on the previous "iOS".

But after upgrading iPhone to "iOS 8.2", we can't type by a keyboard even
if it is shown as "connected condition" on Bluetooth setting page. And this
problem is solved when turn off and then on again the Bluetooth function.

The keyboards with Nordic's parts have no connection problems in the
upgraded iPhone (iOS 8.2). Please inform us why your "Bluetooth stack 1.4"
has this connection problem on iOS 8.2.

  • Hi,

    It's difficult to determine the root cause without analyzing the actual failure. Can you provide a sniffer trace & highlight the issue?
    Also, are you testing with the official iOS 8.2 release or an earlier beta iOS release?

    Best wishes
  • thanks for your reply

    1. How can we provide a sniffer trace & highlight the issue?

    2. We were tested with the offcial iOS 8.2 released.

    3. We tested with the sample source code(HIDEmuKbd), and it also had the same problem.

    I look forward to hearing from you soon.

  • Hi,

    There is a connection problem between Bluetooth Smart Keyboard and iPhone(iOS 8.2), so we attach sniffer trace files.

    1. When the keyboard connects first time with iPhone(iOS 8.2), it shows "connected", but it does not work.

    2. After we turned off and on Bluetooth of iPhone, and then the keyboard connects again, the keyboard works.

    3. Attached files are sniffer trace files of Nordic.

    001 Fail-iOS8.2-First connection-TI.psd

    001 OK-iOS8.2-Second connection-TI.psd

    002 OK-iOS8.2-Second connection-Nordic.psd

  • Hi DaeHeung,

    Unfortunately, the two TI logs are not useful for the investigation. The "001 Fail-iOS8.2-First connection-TI.psd" log does not show the iOS device initiating a connection request to the peripheral, only Adv & Scan packets are shown. Perhaps the the connection was established on another Adv channel (the TI sniffer can only monitor one Adv channel, usually 37). You'll know when the connection is established when the CONNECT_REQ packet is displayed in the sniffer. Also for "001 OK-iOS8.2-Second connection-TI.psd", this does show a connection but the pairing/key exchange was done on a previous connection, so the sniffer doesn't know the encryption keys. Consequently, the sniffer cannot decode the encrypted packets. For the Nordic log, the connection & pairing is captured in the same trace.

    Can you re-capture a trace with the CC2541 showing the pairing along with the issue? This may require erasing the bonding info on the phone and/or device.

    Best wishes
  • Hello,

    I also see this issue.

    This problem is very reproducible. It happens every time with the Texas Instruments Keyfob hardware, running the HIDEmuKbrd project.

    Before 8.2 is fine. With iOS 8.2 and 8.3, I have to turn Bluetooth off and on again to type with the HIDEmuKbrd project. I could not get a trace with the TI packet sniffer, but this problem is very reproducible.

    TI engineers should be able to reproduce and fix this even if we cannot provide good logs.

    This is a very serious problem, since any device with the latest iOS will have this issue.

    The last post on this thread is from early April. Have there been any new findings since then?

    What are you doing to investigate and solve this issue?

    Thanks,
    S
  • Hello Sarah,

    This has been fixed; please check back in the next 24 hours for the update!

    Best wishes
  • Hey,
    Please use the latest BLE SDK (v1.4.1) and also make sure to make the following change;

    Set default pairing mode to GAPBOND_PAIRING_MODE_WAIT_FOR_REQ:

    #define DEFAULT_PAIRING_MODE GAPBOND_PAIRING_MODE_WAIT_FOR_REQ
  • Hi Joakim,

    Thanks, i receive this message from local TI FAE. In my test, this method only work on BLE stack-1.4.1