How to pair (and NOT bond) without peer manager

[RMV]

My setup is a custom board with the nRF52832 and a remote BLE client e.g. nRF Connect tool kit on an Android phone.

The application periodically broadcasts a 'beacon' but every now and then there is a need to 'pair' to the remote device and allow that device to update some characteristics.  I have seen some examples of 'peer manager' but all such examples somehow universally assume that the application has to 'bond' with the remote. I tried using the nRF peer manager and set the 'bond' parameter to '0' (i.e. disable it) but the peer manager still appears to require the use of the 'fds' component.

Is there an option to 'pair' either without using the peer manager, or if we have to use it, then do not 'require' the FDS to be included in the build?

- RMV

[RMV]

HI

Thanks for the link on legacy pairing....

Maybe I am not sure too as to what I want to achieve.

As a first step I want a remote client (central?) to be able to modify the device's (peripheral?) name. At this time I have not decided whether it will be the short name or the long name.

The idea is for the device to periodically broadcast (non-connectable) its 'name' in the advertising payload.  However, under certain circumstances, such as a sensor connected to a GPIO being activated, the device will switch to a 'connectable advertisement'.  The remote client will then receive this broadcast and somehow try to 'connect' to the device and write to that device's name characteristic.

Maybe it is my minimal knowledge but I assumed that for this exchange to occur, the remote client must at the minimum, pair to the device.

If pairing is not required in this use case then what are the other options? My requirements only allow for over-the-air connectivity (e.g. BLE) with no allowances for physical or proximity connections such as a wired UART, NFC, etc.

[Vidar Berg]

Hi,

Thanks for the clarification. So pairing/bonding is only needed if you want to encrypt the link. Examples such as ble_app_uart does not require any security (or support it for that matter), you just connect to it and start exchanging data.

I also think the ble_app_uart example could be a good starting point for your project. You can remove the UART dependencies and re-configure the advertiser so that it advertises non-connectable advertising packets until connectable advertisments are activated by a GPIO input event. I think I will have time next week to put toghether a simple example if it helps you get started, just let me know. 

[RMV]

Hi,

I will mark this as an answer but it would be nice if you could, as you offered, put together a very simple example at your convenience

Cheers

RMV

[Vidar Berg]

Hi,

I have attempted to make a simple example project for you now, please see attached below. I used button 1 on the nRF52 DK to trigger the change to connectable configuration mode (button 1 is connected to P0.13 and is active low).

Project is based on nRF5 SDK v17.0.2 and it must be extracted and copied to the \examples\ble_peripheral\ directory before it can be built with Segger embedded studio.

nRF5_SDK17.0.2_ble_app_connectable_beacon.zip

Hope this helps. Just let me know if you have further questions.

Cheers

Vidar

[RMV]

Thanks for the exampl -- I will review it shortly.

In my browsing of the Nordic sites, and other forums, I came to the conclusion that SDK 15.3.x is the last SDK that is compatible with the nRF52832+S132 combination (i.e. the nRF52 DK5).
Your example uses SDK 17. 0.2 -- is that a valid combination, and if so, what are the tradeoffs (and are they worth it) for me to consider migrating from 15.3.x to newer SDK releases?

Cheers

RMV