nRF8001 rev. D on iOS 6-7

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Tue, 15 Apr 2014 10:37:45 GMT

You can request a beta release of this feature in the support portal at www.nordicsemi.com/.../Contact-Support-Team This should be released in the following weeks.

RE: nRF8001 rev. D on iOS 6-7

David — Mon, 14 Apr 2014 10:54:10 GMT

We did a couple of tests, here are the results:

"No securitiy required" and "Security request delay" = 10s does not solve the reconnection-problem of iOS. It is still impossible to reconnect to an iOS-device with these profile-settings...
iOS 7.1 works fine without using the "ACI Bond security request" on the nRF8001 side, so Apple Bluetooth design guidelines are respected.
Some or Android 4.4.2 devices work with the "Security required" option in our profile, but there is always a problem at the first connection (nRF8001 ACI Bond). The services (indication/notification) are never activated. At reconnection these services are activated on some devices, whereas others still don't work...

Your alternative solution might be a good idea. Unfortunately I did not find the required option in nRFgo Studio. Can you explain a little bit more? Bluetooth speification v4.1 suggests "Authenticated Signed Writes" property for characteristics, but I can't find this option in nRFgo Studio...

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Thu, 10 Apr 2014 10:34:00 GMT

Yes, the device appears under Bluetooth devices in iOS and can be removed (forget this device). Ok, so the device was successfully paired.

Setting security request delay to 10 seconds (together with Device security required) does not change anything for Android or Windows. Not tested on iOS, but as it already worked with the previous modification (Device security -> Security required), I don't understand why...

Let me rephrase (2), Can you set Device Security -> No Security Required , Security request delay to 10 seconds . You will use ACI Bond and ACI bond Security Request. You can also set the timeout in the ACI Connect to a few minutes so you can check that you get a Disconnected Event (Timed out), if there is no connection . Can you try this out.

iOS actually does not like this method of pairing of using the ACI Bond Security Request and is not the recommended method according to iOS, however I do see that you have got it working on the C version.

See section 3.9 of the developer.apple.com/.../bluetoothdesignguidelines.pdf

Now that I understand your situation let me see if I can re-produce it. Caveat: Remember the Apple guidelines clearly do not approve this I am attempting to re-produce for my understanding and to see if there is a work around.

= Alternative: Device Security -> No Security Required Set a Characteristic to have Security required and use this Characteristic to enable security from the iOS app, by reading or writing to it. This however means that the method you have used to work with Android and iOS needs to change a bit.

RE: nRF8001 rev. D on iOS 6-7

David — Wed, 09 Apr 2014 13:37:08 GMT

Yes, the device appears under Bluetooth devices in iOS and can be removed (forget this device).
Setting security request delay to 10 seconds (together with Device security required) does not change anything for Android or Windows. Not tested on iOS, but as it already worked with the previous modification (Device security -> Security required), I don't understand why...

There seems to be some confusion. I think we have to explain the whole thing:

Both profiles for nRF8001 revision C and D (as posted on Monday by Jiu) work correctly with Windows (Bluegiga BLED112) and Andoid 4.3/4.4, but only nRF8001C works with iOS. nRF8001D does connect and pair with iOS, but it is impossible to reconnect the same chip to the same Apple device (no events on nRF8001D after command Connect).
When changing the profile for nRF8001D (Device security -> Security required) it works fine with iOS but not with Windows nor Android. When reconnecting to a paired master (Win or Android) the nRF8001D disconnects with ACI Status 0x8D (Bond required to proceed with connection).

As Android and Windows do both accept our present profile, why does iOS have issues? We need a configuration that works with every operating system.

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Wed, 09 Apr 2014 11:29:55 GMT

Now I understand better. The ACI Bond Security request will work on Android and I have checked that.

Can you verify that the device that you paired with on the iOS is present in Settings -> Bluetooth and show it as a paired device.

nRF8001 D version: nRFgo studio Can you change the Security Request Delay to 10 seconds, in nRF8001 configuration -> Security, and then test it with iOS

Let me know about 1 and 2.

RE: nRF8001 rev. D on iOS 6-7

David — Wed, 09 Apr 2014 10:23:58 GMT

You are right. We use ACI Bond for all connection attempts until reception of the Bond Status Event (Success). For all further connections we only use ACI Connect. In detail: A successful connection following the ACI Bond command generates a Connected Event, we then send the ACI Bond Security Request which leads to the Bond Status Events (Success).

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Wed, 09 Apr 2014 09:41:11 GMT

When you are using the ACI Bond you should continue to use ACI Bond on all connection attempts until you get a ACI Bond Status Event (Success) , and then you can start using ACI Connect. The proximity example should follow the same method, can you comment on how you used ACI bond ?

RE: nRF8001 rev. D on iOS 6-7

Schaller — Tue, 08 Apr 2014 10:53:07 GMT

So we try using the same profile generated with the option "Required Security" and that works (with more current consumption) . But the Revision C use "No security" too and works...

The problem occures only on iOS, with Android device there is no problem with C or D.

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Tue, 08 Apr 2014 10:47:06 GMT

Can you also take a look at this thread as you may be facing a similar issue. https://devzone.nordicsemi.com/index.php/nrf8001-re-connection-fails-with-hardware-error#reply-340

RE: nRF8001 rev. D on iOS 6-7

Schaller — Tue, 08 Apr 2014 10:06:43 GMT

At first, we use the ACI Bond command to create paired connection then we use the Connect command for further connection. We use "No Security" because we don't need encrypted connection all the time (It also saves current). We will check the ble_proximity_template.

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Tue, 08 Apr 2014 08:35:59 GMT

I see that you are not using pairing as you have marked your device security setting as "No Security". I do not see how the iOS would ever pair to your device ? Are you using ACI Bond or ACI connect as the initial call to the radio. Let me check your XML as well. If you are using pairing use the ble_proximity_template as an example.

RE: nRF8001 rev. D on iOS 6-7

Schaller — Mon, 07 Apr 2014 10:44:33 GMT

So we put the profil that we use in Rev C in Rev D but nothing change. Always the same result where the device can't reconnect to the master.

Here are the two XML for the C and D version perhaps that will help.

Metrology_PM289_nRF8001C_mod.xml

Metrology_PM289_nRF8001D.xml

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Mon, 07 Apr 2014 10:10:01 GMT

Can you set the nRFgo studio XML that you are using, to use the D version in the pull down on the nRF8001 Configuration -> Device and let me know the results.

RE: nRF8001 rev. D on iOS 6-7

Schaller — Mon, 07 Apr 2014 09:56:29 GMT

Sorry, but I can't give you the full marking because your chip is integrated in another chip.

This is i can give you: DateCode : 1304 GetDeviceVersion : 0x840900150002020100289C00

If the anomaly #5 happened, i will never be able to connect to a Rev D no? Because the problem occures only when i try to reconnect to an already bonded device (so the first connection works fine).

Jiu

RE: nRF8001 rev. D on iOS 6-7

David Edwin — Mon, 07 Apr 2014 08:53:32 GMT

Can you post the full markings on top of the chip. You will see something like nRF D 8001 xxyyzz. Can you also post the Command Response Event for the ACI Get Device Version. This error can be explained by this product anomaly see Anomaly #5