This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can I reduce the negotiation time of Bluetooth nRF51822

image description

Follow up this image. I want to reduce the negotiation time.

10:44:43.655 --> Connected to D6:9E...

10:44:45.123 --> Services Discovered

= 45.123 - 43.655 = 1.468 Sec

I want reduce to 300ms. How can I do?

Thank you in advance.

  • When a Central connects to a Peripheral, it passes some parameters to it. One of them is the connection interval which determines the rate at which packets will be sent in that connection. In the Master Control Panel, you should be able to set these parameters (I've just tested with the desktop version). If you choose a low interval of 7.5ms, the packets will be sent faster and thus will result in a faster service discovery.

    During service discovery, the Master control panel requests a listing of all services. If you bond to a device (that means you cache all this information between connections), you do not need to perform a service discovery for the second time you connect to this device. The device will then tell you if sth. has changed since the last time.

    What's your exact use-case?

    Marius

  • Yes, lowering connection interval is most powerful method in general but as it is controlled by central side you cannot really force it (e.g. most of the phones will drop connection if you try to set values below 20ms through Preferred Connection Parameters). But in case you are owner of peripheral side then hints are obvious:

    • Lower number of GATT handles in the stack to minimum (should be 8 with standard Nordic Soft Devices).
    • Do not include "Service Changed" Characteristic so Central side will cache GATT handles and should skip whole enumeration during Service Discovery when connecting next time (this is what Marius describes but it's not linked to bonding because I suppose even if you bond device will do enumeration when you indicate that your services might change). Note that this caching is done by low level FW on central side usually (if it is phone/tablet/PC...) so you cannot control it from application layer (apart from forcing deleting of the record) and it can get "erased" under different conditions (e.g. phone FW upgrade, wipe of network settings, cache overflow, some record might be considered too old etc.)

    In the best case you control both sides (HW&FW) and then simply make your GATT stack static on peripheral side, use the lowest connection interval of 7.5ms from central side (unless you need to keep connection with multiple peripherals where such low connection interval doesn't scale - that's the reason why most of the phone OS releases today set default connection interval to 30-50ms and prevent you going below) and hardcode handle numbers of your GATT Services/Characteristics/Descriptors on central side so you can issue GATT commands to them straight after the connection without any discovery.

    Cheers Jan

  • I want to use nRF51822 as the IR Remote in order to many users can access nRF51822 in the same time. Users are smart phone devices. I have 2 concepts below.

    1. Reduce negotiation time from 1.5 sec to 300 ms(Acceptance). When users sent data and promptly disconnect. because other users can use nRF51822.
    2. Use nRF51822 as 2 roles in one or 2 nRF51822 are used to be a central role and peripheral role.
  • Hi, have you thought about using the advertising channel for broadcasting data? What about your power requirements? Because if you have enough power on the nRF51 side, you can just scan a lot and your smartphones send advertising packets. That would give you an instant response. I think that 300ms for a single press is already too high. If all your smartphones are bonded and therefore do already know all services, you can also have your nRF advertising at around 20-50ms so that it can be connected very fast. I think that should give you timings of under 100ms and would consume a little less power, but if there's many users, they would block each other.

Related