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 :(

Parents
  • 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

Reply
  • 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

Children
No Data
Related