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

Find the optimal connection interval acceptable by the client

Hello,

I am using nRF52832 to develop a device that sends Bluetooth signals to a smartphone.
I am sending small pieces of data but it is critic to send them as quickly as possible, so it would be great to use an interval of 7.5 ms when the client supports it, and use the closest possible value that is acceptable by the client otherwise.

But how do I find that closest acceptable value?
E.g. the Apple Developer Guideline says that it should be ≥15 ms.
What if the server asks for an interval of 7.5 ms? What value will be forced by the client, will it be automatically 15 ms? If not, can I achieve this programatically?

Thanks in advance,
Tibor

Parents
  • Hello Tibor,

    But how do I find that closest acceptable value?
    E.g. the Apple Developer Guideline says that it should be ≥15 ms.
    What if the server asks for an interval of 7.5 ms? What value will be forced by the client, will it be automatically 15 ms? If not, can I achieve this programatically?

    Unfortunately, there is no way for a peripheral side of a link to force the central into a given connection interval.
    If you are designing the peripheral side of the link, you may only suggest a range of acceptable connection intervals - then the central will make a decision about which to actually use. If the central does not choose an interval within the peripheral's suggested range, the peripheral can either accept it, or terminate the link.

    In essence, this means that you may only make a suggestion about this from the peripheral side, and it is really up to the central to determine which connection interval will actually be used.
    Normally, smartphones will natively choose the highest possible interval (within their own OS requirements), to reduce power consumption. 

    You could give the peripheral a connection interval range of 7.5 ms to 15 ms, and then try to have the smartphone ask for a 7.5 ms interval. Not all smartphone OS's will allow a connection interval less than 15 ms, but this can be read about in the OS's BLE Adapter/API documentation. If you are developing for Apple, and the Apple documentation says that the connection interval must be >= 15 ms for any connection regardless of application, then there is no way for you to force it into a lower connection interval.

    Please do not hesitate to ask if any part of my answer is unclear, or if you have further questions.

    Best regards,
    Karl

  • Hello Karl,

    Thanks a lot for your help.
    Actually what I would like to do is not forcing the smartphone into an interval range; I just want to make sure the lowest connection interval is picked from its connection interval range.

    "Normally, smartphones will natively choose the highest possible interval."
    So let's say the peripheral has a connection interval range of 7.5 ms to 15 ms, and the phone has a range of 10 ms to 20 ms. Do you mean that the phone will pick 15 ms then?
    If so, is there any way to prevent this and make it choose 10 ms?
    E.g. can the peripheral somehow dynamically query for the phone's connection interval range before actually initialising the connection and call the sd_ble_gap_ppcp_set function with a parameter in which both MIN_CONN_INTERVAL and MAX_CONN_INTERVAL are 10 ms?

    Thank you,
    Tibor

  • Hello Tibor,

    Tibor Kakonyi said:
    Thanks a lot for your help.

    No problem at all, I am happy to help! :) 

    Tibor Kakonyi said:
    So let's say the peripheral has a connection interval range of 7.5 ms to 15 ms, and the phone has a range of 10 ms to 20 ms. Do you mean that the phone will pick 15 ms then?

    Yes, as far as I know, all modern smartphone OS's does this if left to choose for themselves.
    The OS is not concerned with the latency of a connection, and would rather optimize battery performance. So, if left to choose from using the radio 100 or 50 times per second, without any guidelines or requirements telling it otherwise, a phone will opt to use the radio the least, and thus choosing the highest connection interval. 

    Tibor Kakonyi said:
    If so, is there any way to prevent this and make it choose 10 ms?

    You may set both the MIN_ and MAX_CONNECTION_INTERVAL to the same number, to force this specific interval. In the iOS case, this must be equal to or higher than 15 ms, so then you may set both to 15 ms, to force the phone to choose 15 ms, which is the lowest possible interval for iOS devices.

    Tibor Kakonyi said:
    E.g. can the peripheral somehow dynamically query for the phone's connection interval range before actually initialising the connection and call the sd_ble_gap_ppcp_set function with a parameter in which both MIN_CONN_INTERVAL and MAX_CONN_INTERVAL are 10 ms?

    No, but the phone can choose 15 ms either way, regardless of the peripheral's suggestions, and it then becomes up to the peripheral if this is acceptable or if the connection should be terminated.
    All you then need to do is configure your peripheral to not terminate the link if its suggestions are not met.
    So, if you would like your phone to choose the lowest possible connection interval always - and you are designing the peripheral yourself - have the peripheral do nothing in the case that its connection parameter update request is rejected. This way, you leave it entirely up to the central to determine the connection interval. When you are designing the central side of the link as well, you may set this to the lowest possible connection interval.

    There is no use for the peripheral to query the central's connection interval range, because it does not really have a say in what connection interval the central chooses. It can only terminate the link if the central's chosen connection parameters are not in line with the suggestions of the peripheral.

    Please do not hesitate to let me know if any part of my answer should be unclear, or if you should have any other questions regarding this! :) 

    Best regards,
    Karl

Reply
  • Hello Tibor,

    Tibor Kakonyi said:
    Thanks a lot for your help.

    No problem at all, I am happy to help! :) 

    Tibor Kakonyi said:
    So let's say the peripheral has a connection interval range of 7.5 ms to 15 ms, and the phone has a range of 10 ms to 20 ms. Do you mean that the phone will pick 15 ms then?

    Yes, as far as I know, all modern smartphone OS's does this if left to choose for themselves.
    The OS is not concerned with the latency of a connection, and would rather optimize battery performance. So, if left to choose from using the radio 100 or 50 times per second, without any guidelines or requirements telling it otherwise, a phone will opt to use the radio the least, and thus choosing the highest connection interval. 

    Tibor Kakonyi said:
    If so, is there any way to prevent this and make it choose 10 ms?

    You may set both the MIN_ and MAX_CONNECTION_INTERVAL to the same number, to force this specific interval. In the iOS case, this must be equal to or higher than 15 ms, so then you may set both to 15 ms, to force the phone to choose 15 ms, which is the lowest possible interval for iOS devices.

    Tibor Kakonyi said:
    E.g. can the peripheral somehow dynamically query for the phone's connection interval range before actually initialising the connection and call the sd_ble_gap_ppcp_set function with a parameter in which both MIN_CONN_INTERVAL and MAX_CONN_INTERVAL are 10 ms?

    No, but the phone can choose 15 ms either way, regardless of the peripheral's suggestions, and it then becomes up to the peripheral if this is acceptable or if the connection should be terminated.
    All you then need to do is configure your peripheral to not terminate the link if its suggestions are not met.
    So, if you would like your phone to choose the lowest possible connection interval always - and you are designing the peripheral yourself - have the peripheral do nothing in the case that its connection parameter update request is rejected. This way, you leave it entirely up to the central to determine the connection interval. When you are designing the central side of the link as well, you may set this to the lowest possible connection interval.

    There is no use for the peripheral to query the central's connection interval range, because it does not really have a say in what connection interval the central chooses. It can only terminate the link if the central's chosen connection parameters are not in line with the suggestions of the peripheral.

    Please do not hesitate to let me know if any part of my answer should be unclear, or if you should have any other questions regarding this! :) 

    Best regards,
    Karl

Children
  • Hi Karl,

    Thanks for the update!

    Let's say then that on the peripheral side, I set both the minimum and maximum intervals to 7.5 ms and I let it keep the connection in case of unacceptable connection parameters forced by the phone.
    If a phone accepts 7.5 ms, everything's fine.
    But if the previous phone comes with a range of 10-20 ms, the value it forces will be probably 20 ms, am I correct? 
    Then the result is worse than setting the peripheral's range to 7.5-15 ms and letting the phone choose 15 ms.

    That's why I'm thinking about a way for the peripheral to find out the lowest interval that can be accepted by the phone - but maybe my entire assumption about the negotiation process is wrong, please let me know if so.

  • Hello Tibor,

    Tibor Kakonyi said:
    Thanks for the update!

    No problem at all, I am happy to help!

    Tibor Kakonyi said:
    If a phone accepts 7.5 ms, everything's fine.
    But if the previous phone comes with a range of 10-20 ms, the value it forces will be probably 20 ms, am I correct? 
    Then the result is worse than setting the peripheral's range to 7.5-15 ms and letting the phone choose 15 ms.

    That's why I'm thinking about a way for the peripheral to find out the lowest interval that can be accepted by the phone - but maybe my entire assumption about the negotiation process is wrong, please let me know if so.

    No, not exactly. I think that this misunderstanding is related to my previous comments that modern OS's will choose longer intervals if left to choose for itself. If the OS allows you to specify connection interval all on your own, I would assume that it also lets you handle connection parameter update requests on your own - meaning that you yourself will have to implement the logic behind which interval is chosen, or whether the connection parameter update request should be accepted at all.
    In the case that the OS will choose connection interval for you(i.e there only exists a predetermined range of acceptable connection intervals for your phone application to choose from), then the only thing you can do is to choose the lowest possible interval and make sure that the peripheral accepts this.

    The central does not query the peripheral for its suggested range, then see if it fits with its own range, its the other way around. The central chooses a connection interval, and the peripheral follows. Then, the peripheral may send a request to update the connection parameters, and the central either accepts this (if there is overlap in their ranges, and its programmed to accept this), or declines this. If it is declined, the peripheral may only either terminate the link, or live with the central's choice.

    Therefore, if you want your central to have the lowest possible connection interval, you will just have to set it to the lowest possible interval right off the bat. In the iOS case, that would be 15 ms, and then make sure that your peripheral does not disconnect if overruled.
    By making the peripheral not disconnect if overruled, it becomes entirely up to the wishes of the central to determine connection interval, and you may therefore just choose the lowest that the OS will allow you to.

    In essence, the peripheral holds very little control over what the central chooses - it can only make suggestions. The central could even be programmed to disregard the peripheral's connection update requests entirely, if it wants to.

    I hope that this clears things up.
    Please let me know if any part of this explanation is unclear, or if I've said something ambiguous - in which case I will try to illustrate the explanation differently :) 

    Best regards,
    Karl

Related