Reduce number of retries in Bluetooth stack

[nordicdev]

FWLog (1)_formattedByTC.txtHi, I am sending data to one of the characteristics from nRF51 to the App(the problem happens in both iOS and Android). This is what I am observing: I send data to a characteristic once in 30 seconds. But, instead of sending data once in 30 seconds, the nRF51 sends data once in 30 seconds, then sends data 60 times in the next 30 seconds, then, once in the next 30 seconds, then, 60 times in the next 30 seconds, etc.

I think this is happening: If the App does not ack back to the nRF51, then, the nRF51 retries the send and that's why it is sending 60 times every 60 seconds (which is undesirable).

Is there a way to reduce the number of retries in the nRF51 side? Thanks.

[Håkon Alseth]

Hi,

Bluetooth low energy handles retransmissions lower in the stack, and it is not possible to override this. Q1: Do you have a sniffer log showing this issue?

Q2: What is your connection parameters? Note that if your connection parameter is 500 ms, the nRF will send a empty packet on-air to maintain the link.

Cheers, Håkon

[nordicdev]

Hi Hakon, Thanks for the reply. My connection parameter time is 1 second. #define APP_ADV_INTERVAL 1600//1600*0.625 = 1 second /< The advertising interval (in units of 0.625 ms. This value corresponds to 40 ms). */ #define APP_ADV_TIMEOUT_IN_SECONDS 180 /< The advertising timeout (in units of seconds). */

#define APP_TIMER_PRESCALER 0 /**< Value of the RTC1 PRESCALER register. */

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(20, UNIT_1_25_MS) /< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */ #define MAX_CONN_INTERVAL MSEC_TO_UNITS(75, UNIT_1_25_MS) /< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */ #define SLAVE_LATENCY 0 /< Slave latency. */ #define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */ #define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER) /< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */ #define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(30000, APP_TIMER_PRESCALER) /< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */ #define MAX_CONN_PARAMS_UPDATE_COUNT 3 /**< Number of attempts before giving up the connection parameter negotiation. */

Please find the attached log got from the App end (meaning, the App has found these packets to be transmitted from the nRF51). You could see that the charactertistic with uuid 0x14 is sent many times in a row with a data value of 0x04. This is the characteristic I was talking about (sorry about the formatting ). You could find the attachment of the log at the start of the initial question (right at the top).

[Håkon Alseth]

Have you tried taking a sniffer log of the connection to see what is going on-air? This can be done using a nRF51-Dongle or DK using the "nRF-Sniffer": www.nordicsemi.com/.../10270189

Cheers, Håkon

[nordicdev]

Hi Hakon, Thanks for the reply. There was a bug in my firmware - actually, I was sending those 60 updates in someother place. Sorry my bad. But your answer did answer my questions, which is, it is not possible to change the number of retries(as this is handled by the lower stack levels). So, marked this as an answer. Thanks again.