• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 10 replies
  • Subscribers 75 subscribers
  • Views 2349 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 247495
Options
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

BjoernSchmitz

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

  • 0 in reply to Simonr

    Yes, NRF_SDH_BLE_GATT_MAX_MTU_SIZE in file sdk_config.h is set to 247 for both devices, so I expect that these values are used by default. And this seems to be correct, since I receive the NRF_BLE_GATT_EVT_ATT_MTU_UPDATED event without asking for changing the MTU size from my application.

    NRF_SDH_BLE_GAP_EVENT_LENGTH  is set to 320 on both device. Is this correct, or would you suggest a higher value? I tried to enlarge this value but this did not have any effect.

  • 0

    Hi

    That NRF_SDH_BLE_GAP_EVENT_LENGTH should be sufficient. Did you take a look at the blog post I linked to in order to see how to best increase the throughput? I'm having some trouble seeing what exactly is causing this. Are you able to upload a sniffer trace for me to take a look?

    Best regards,

    Simon

  • 0 in reply to Simonr

    Tanks, but I already know this Blog Post and it really helped me back then, when I searched for it. However, throughput is not the Issue here. I measured Latency from peripheral to host as about one Connection Interval, which is set to 7,5 ms. This is as good as it can get, according to Bluetooth Spec.

    What I am trying, is to minimize the delay from start of advertising, till receiving the first application data package on the central. My problem is that when I set  NRF_SDH_BLE_GAP_EVENT_LENGTH  to something different from 23, my packets are blocked until the MTU size is negotiated between Host and peripheral (NRF_BLE_GATT_EVT_ATT_MTU_UPDATED received).

    I understand why this is happening, what I would like to know is if it is possible to directly start a connection with a higher MTU size then 23, when the peripheral has been bonded before. Thus, I could skip negotiating the maximum MTU size between Peripheral and Central and could directly start sending application data.

    Best regards,

    Björn

  • +1

    Thank you for your clarification Björn!

    The reason the MTU negotiation is initialized upon connection is that the ble_conn_params.c file starts this negotiation for you upon a connected event. In order to skip/avoid the MTU negotiation, you can remove the ble_conn_params.c file from your project. Keep in mind that there are some other functions in this file as well that you'll miss out on.

    Best regards,

    Simon

Related
Terms of service