Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Use NUS Service on bonded devices without discovery

Hi,

I am developing a system with 2 nrf52840 devices, communicating via the NUS Service. I am programming both the central and peripheral project. I am using the NRF5 SDK with S140 Softdevice on both sides.

I am trying to speed up the connection procedure as far as possible. Therefore, I bond both devices. I know that characteristics, that are notified on bonded devices, stay notified the next time they connect. It seems to work, since I can skip "ble_nus_c_tx_notif_enable()" for bonded device and still receive value notifications on the TX characteristic. However, the NUS event handler is not called before I call "ble_nus_c_on_db_disc_evt()".

The problem is that characteristic discovery takes to long for my application. Thus, I would like to directly start communicating with bonded devices, without discovery. Is there a way to do that? Do I have to call  ble_nus_c_on_db_disc_evt with the parameters read from the peer manager (e.g. by using pm_peer_data_remote_db_load()).

Thank you and best regards

Bjoern

Parents
  • Hi Bjoern

    This has been discussed in length in this thread, even though it is rather old it should still be relevant.  It should be fairly simple, seeing as if you know the handles you can just utilize these directly. It might be that some SDK functions are tied together and make some trouble, but I think you should be fine if you remove the discovery module from your project altogether.

    Best regards,

    Simon

Reply
  • Hi Bjoern

    This has been discussed in length in this thread, even though it is rather old it should still be relevant.  It should be fairly simple, seeing as if you know the handles you can just utilize these directly. It might be that some SDK functions are tied together and make some trouble, but I think you should be fine if you remove the discovery module from your project altogether.

    Best regards,

    Simon

Children
  • Hi Simon,

    thanks for the quick response. This helps a lot. My solution is to store handles, when bonding the devices, and reusing this handles for all later connections. And this actually does speed up the connection process, since I can skip discovery. It doesn't help as much as I hoped it would, though. 

    Currently, I can establish a connection within less than 50 ms after advertising was started on peripheral side. Since I reuse the handles, and both devices are bonded (thus pairing process should also be skipped), I would expect the device to directly be able to communicate via NUS. However, even though I start transmitting value notifications from the peripheral side, as soon as the connection is established, it takes another 100 ms (more or less) until the first notification reaches the central. It seems that the notifications are queued somewhere. Then 100 ms after the connection was established, I receive all notifications, which I did send in the meantime.

    Do you have an idea how to speed that up, or what could cause the initial delay? Min and max connection interval are already at 7.5 ms, so that shouldn't be the problem. After the initial delay, latency from peripheral to central side is constantly below 20 ms. So this problem seems to exist only directly after connecting.

    My aim is to transmit data from peripheral to central side, via NUS value notifications, within 100 ms (counted from start of advertising to the reception of the value notification in the NUS event handler on central side). Do you think that is possible? Currently, I managed to transfer data within 150 ms, so I need a way to save at least another 50 ms, within the connection process.  

    Best regards

    Bjoern

Related