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

nRF8001 problem with connection interval shoud be 7.5ms but it is 50 ms

Hi, I have a problem with the nrF8001. I connected to STM32F4 and I use the nRF8001 SDK v1.7. I need send several (less then 20) bytes from the device to the phone with the maximum posible frequency. I was based on the example of "my_project" in SDK project exaples. I added myself the 4 byte characteristics of a name "counter" which increases every 1 ms. I wrote android applications which calculates what is the interval between two packets of data ... and here comes the problem, although I have set:

#define GAP_PPCP_MAX_CONN_INT 0x6 / ** <Maximum connection interval as a multiple of 1.25 msec 0xFFFF Means No specific value requested * /
#define GAP_PPCP_MIN_CONN_INT 0x6 / ** <minimum connection interval as a multiple of 1.25 msec 0xFFFF Means No specific value requested * /
#define GAP_PPCP_SLAVE_LATENCY 0
#define GAP_PPCP_CONN_TIMEOUT 0x1e / ** Connection Supervision timeout multiplier as a multiple of 10msec, 0xFFFF Means No specific value requested * /

the interval between two data packets are always 50 ms. When I change the connection interval on the value of such 100ms it is still 50 ms.

For testing I connected the Microsoft LE Bluetooth mouse which is based on the nRF51 chip and there interval between 2 packet is about 8ms!

i try several methods to update variable:

if (lib_aci_is_pipe_available (PIPE_MATTSK_LICZNIK_TX))
    {
    lib_aci_send_data (PIPE_MATTSK_LICZNIK_TX (uint8_t *) &counter, 4);
}

or

services_send_mattsk_licznik (&counter, 4, 1);

But always there were 50 ms. I'm out of ideas so please help :(

  • Hi Mathew, I hope that you managed to get an answer to this problem. If so, could you provide some information ?

    I am seeing exactly the same problem when connecting to an android 4.4.2 device.

    I am using the function lib_aci_change_timing_GAP_PPCP() that will use the following defines in the service.h file:

    #define GAP_PPCP_MAX_CONN_INT 0x6 /< Maximum connection interval as a multiple of 1.25 msec , 0xFFFF means no specific value requested */ #define GAP_PPCP_MIN_CONN_INT 0x6 /< Minimum connection interval as a multiple of 1.25 msec , 0xFFFF means no specific value requested */

    The preferred max and min connection interval parameter are set to the same value that represents the required 7.5ms.

    This should be the same as calling:

    bool lib_aci_change_timing(uint16_t minimun_cx_interval, uint16_t maximum_cx_interval, uint16_t slave_latency, uint16_t timeout);

    with the necessary timing requirements but utilises predefined constants.

    I get a timing event in response that reflects the change in requested timing parameters but my measurements show otherwise. In fact, closer to what you are seeing at around 30ms.

    Hopefully, someone at Nordic will see this as a bump and help provide a solution or a method to diagnose the cause of the problem.

    Thanks, Kirem

  • Is the Phone accepting the new connection parameters or rejecting them? When setting both max and min value to the minimum interval there is a high probability that the master doesn't accept the parameters. In case the parameters is rejected I would recommed sending another request but increasing the max value. Note that you it might also be necessary to increase the timeour value when increasing the max value. Continue to retry using increasingly bigger values, until the master accepts the request. Note that the master is the one deciding what interval to use.

  • Hi run_ar,

    In my case I get a timing change event acknowledging the change request. Surely this is a sign that the master has accepted it?

  • So you are actually getting a TimingEvent with the new connection parameters? What speed are you using for SPI?

  • I would recommend capturing a sniffer log so you can see what is happening on air. this way you will be able to see the connection interval and how often notifications are actually sent (to see which side we need to debug). Maybe UART debugging could help as well. Print timing events and timestamp when you call lib_aci_send_data to see if you are filling the buffers fast enough.

Related