Find a way to control Notify flow to prevent stock notify between device and phone App

[TTN]

Hi

We follow the chart to design our notify flow to control the data in notify queue.

but we face a problem, the data in the queue always get more than 2 when the 9 or 8 mins, then our flow stop to notify,

please reference the code below, s_not_send is the data in the queue.

We what to know how to deal with this issue to make to notify stable.

device information
SDK:14.2

SD:5.1.0 GATTS Handle Value Notification flow chart
Nordic Semiconductor Infocenter.pdf

	  if ( s_device_mode == e_only_data  ) {              
			if ( s_not_send < 3 ) {                          // if notify queue have 2 data， stop notify until under 2 data
	      err_code = ble_cus_custom_value_update( &m_cus, notify_data ) ;                                   
					if(err_code==8){
						SEGGER_RTT_printf(0,"process error err_code=8\n");
						  err_code = sd_ble_gap_disconnect( m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION ) ;
							s_not_send=0;
						  return ; 
					}				
        APP_ERROR_CHECK( err_code ) ;
				s_not_send++ ;
			} // if
		} // if

[Andy]

What is the issue? I'm afraid I don't understand your code, and you should indent it properly btw.

What is that s_not_send variable for? Why less than 3? 

[TTN]

The issue is when connecting to the VIVO 1808(cell phone)the notify flow stop when data in the queue is more than the queue can accommodate in 9 or 8 mins.

the flow is described in the annex above.

the situation is we see the nrf connect log and find the error code is LMP response time out, so we try the LINK_COUNT config to 2(PERIPHERAL)+0(CENTRAL)=2(TOTAL) and still get the same error

list some config in code  and reference link below
https://devzone.nordicsemi.com/f/nordic-q-a/22353/lmp-response-timeout---experimental_ble_app_multiperipheral_pca10040_s1321

in SDK config.h
---------------------
// <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
#ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 2
#endif

// <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
#ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
#define NRF_SDH_BLE_CENTRAL_LINK_COUNT 0
#endif

// <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Maximum number of total concurrent connections using the default configuration. 
#ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
#define NRF_SDH_BLE_TOTAL_LINK_COUNT 2
#endif

// <o> NRF_SDH_BLE_GAP_EVENT_LENGTH - The time set aside for this connection on every connection interval in 1.25 ms units. 
#ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 4
#endif

// <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23
#endif

// <o> NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE - Attribute Table size in bytes. The size must be a multiple of 4. 
#ifndef NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE
#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 1408
#endif
-------------------------
in main

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (10 ms). */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(40, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (100 ms) */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */ // 可否忽略connect event
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds). */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(500)                        /**< 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(100)                        /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAM_UPDATE_COUNT     5                                           /**< Number of attempts before giving up the connection parameter negotiation. */
-------------------------

[Vidar Berg]

TTN said:

I thought that there was a start to notify that the connection interval was accepted by the central.

It depends on your application. The SDK examples will typically terminate the link if the requested parameters are rejected after x attempts. You can check if you receive the BLE_CONN_PARAMS_EVT_SUCCEEDED from the connection parameters negotiation module.  

[TTN]

Yes, I check the event in the "on_conn_params_evt_hanlder" of main.c, I can get BLE_CONN_PARAMS_EVT_SUCCEEDED when use nrf connect to the custom device after I type the passkey to create a bonding connection.

the error is getting from sd_ble_gatts_hvx is 13, after the device start to notify for about 8~9 mins.

uint32_t ble_cus_custom_value_update(ble_cus_t * p_cus, uint8_t * custom_value)
{
    NRF_LOG_INFO("In ble_cus_custom_value_update. \r\n"); 
    if (p_cus == NULL)
    {
        return NRF_ERROR_NULL;
    }

    uint32_t err_code = NRF_SUCCESS;
    ble_gatts_value_t gatts_value;

    // Initialize value struct.
    memset(&gatts_value, 0, sizeof(gatts_value));

    gatts_value.len     = 20 ; 
    gatts_value.offset  = 0;
    gatts_value.p_value = custom_value;

    // Update database.
    err_code = sd_ble_gatts_value_set(p_cus->conn_handle,
                                      p_cus->custom_value_handles.value_handle,
                                      &gatts_value);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

    // Send value if connected and notifying.
    if ((p_cus->conn_handle != BLE_CONN_HANDLE_INVALID)) 
    {
        ble_gatts_hvx_params_t hvx_params;

        memset(&hvx_params, 0, sizeof(hvx_params));

        hvx_params.handle = p_cus->custom_value_handles.value_handle;
        hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
        hvx_params.offset = gatts_value.offset;
        hvx_params.p_len  = &gatts_value.len;
        hvx_params.p_data = gatts_value.p_value;

        err_code = sd_ble_gatts_hvx(p_cus->conn_handle, &hvx_params);
	    SEGGER_RTT_printf( 0, "sd_ble_gatts_hvx result: %x. \r\n", err_code) ;
        NRF_LOG_INFO("sd_ble_gatts_hvx result: %x. \r\n", err_code); 
    }
    else
    {
        err_code = NRF_ERROR_INVALID_STATE;
        NRF_LOG_INFO("sd_ble_gatts_hvx result: NRF_ERROR_INVALID_STATE. \r\n"); 
    }


    return err_code;
}

[Vidar Berg]

Is the error value 0x13 or decimal 13?  0x13 corresponds to NRF_ERROR_RESOURCES and means that the output buffer is full: 

* @retval ::NRF_ERROR_RESOURCES Too many notifications queued.
* Wait for a @ref BLE_GATTS_EVT_HVN_TX_COMPLETE event and retry.

[TTN]

Hi, thanks for your reply, the error code is 0x13,

        err_code = sd_ble_gatts_hvx(p_cus->conn_handle, &hvx_params);
		if(err_code!=0){
			SEGGER_RTT_printf( 0, "sd_ble_gatts_hvx result: %x. \r\n", err_code) ;

so I used "s_not_send(self count data in queue)" to check whether I should call  sd_ble_gatts_hvx again, but the s_not_send didn't cut back so the device will keep waiting, user will feel the bluetooth stock.

	  if ( s_device_mode == e_only_data  ) {              
			if ( s_not_send < 3 ) {          // s_not_send=self count data in queue
	      err_code = ble_cus_custom_value_update( &m_cus, notify_data ) ;                                   
					if(err_code==8){
						SEGGER_RTT_printf(0,"process error err_code=8\n");
						err_code = sd_ble_gap_disconnect( m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION ) ;
					    s_not_send=0;
						return ; 
					}				
                APP_ERROR_CHECK( err_code ) ;
				s_not_send++ ;
			} // if
		} // if

 

how can I get the right available queue element number?
can I clear the queue to reset the available queue element?
is there any flow to handle this situation?

[Vidar Berg]

This error makes more sense, thanks for confirming. Can you try to handle retries in the main context assuming ble_cus_custom_value_update() is called in an interrupt context that will block Softdevice events? You can monitor BLE_GATTS_EVT_HVN_TX_COMPLETE events to determine if packets are being sent. 

[TTN]

Hi Berg,

Thanks for your reply, we end up finding that the ble error is due to the VIVO's(Cell phone) problem, they have working on the issue, thanks!!