Acknowledged transaction status callback in Mesh SDK

[Pegah]

Hi,

I am using the reliable message communication to measure Round-trip time based on the Light switch example. 

I noticed that in high traffics, some packets are not acknowledged and the log on the client side is "Acknowledged transfer cancelled".

However, I am not sure when this situation happens exactly?

Is it possible that the packet is arrived and processed by server but the acknowledgment is lost?

Or can I use this as a metric to show the packet loss percentage? 

Thanks in advance!

[Hung Bui]

Hi Pegah, 

It's pretty strange to receive "Acknowledged transfer cancelled". This should only happen if access_model_reliable_cancel() is called. 

Could you check in your code where it's called ? In our light switch client example it's called when button 0 or 1 is pressed. 

If there is a timeout due to packet loss (retransmitted 3 times with no ACK), ACCESS_RELIABLE_TRANSFER_TIMEOUT ("Acknowledged transfer timeout") should return instead. 

[Pegah]

Hi Hung, 

Thank you for you reply.

I am using mesh SDK v2.2 and proxy client and server. I modified the light switch example to setup an application timer in client which starts by pressing the button number 0. 

Then in the handler of the timer in client, I send on off messages the same as it is done in the original client button event handler.  I attached the my timer handler code where I am sending the messages. 

static void repeated_timer_handler(void * p_context)
{
  bool flag = hal_led_pin_get(BSP_LED_0);
  
   uint32_t status = NRF_SUCCESS;
   generic_onoff_set_params_t set_params;
   model_transition_t transition_params;
   static uint8_t tid = 0;
   if(flag == false)
       set_params.on_off = APP_STATE_ON;
       else
        set_params.on_off = APP_STATE_OFF;
    set_params.tid = tid++;
    transition_params.delay_ms = APP_CONFIG_ONOFF_DELAY_MS;
    transition_params.transition_time_ms = APP_CONFIG_ONOFF_TRANSITION_TIME_MS;
    NRF_LOG_INFO("Send msg\n");
   (void)access_model_reliable_cancel(m_clients[0].model_handle);
   status = generic_onoff_client_set(&m_clients[0], &set_params, &transition_params);
   hal_led_pin_set(BSP_LED_0, set_params.on_off);

   
    switch (status)
    {
        case NRF_SUCCESS:
            break;

        case NRF_ERROR_NO_MEM:  NRF_LOG_INFO("Client no mem\n");
        case NRF_ERROR_BUSY:  NRF_LOG_INFO("Client busy\n");
        case NRF_ERROR_INVALID_STATE:
        NRF_LOG_INFO("Client cannot send\n");
            hal_led_blink_ms(LEDS_MASK, LED_BLINK_SHORT_INTERVAL_MS, LED_BLINK_CNT_NO_REPLY);
            break;

        case NRF_ERROR_INVALID_PARAM:
            /* Publication not enabled for this client. One (or more) of the following is wrong:
             * - An application key is missing, or there is no application key bound to the model
             * - The client does not have its publication state set
             *
             * It is the provisioner that adds an application key, binds it to the model and sets
             * the model's publication state.
             */
            NRF_LOG_INFO("Publication not configured for client \n")
            break;

        default:
            ERROR_CHECK(status);
            break;
    }
    
}

As you said, I checked and I see that

in the original light switch, access_model_reliable_cancel is called right before calling generic_onoff_client_set(). That's why I did the same thing. 

Could you please let me know what is the use of this method? And what are the impact of removing it?

[Hung Bui]

This is only for demonstration that you can cancel a pending transaction to start a new one. 

If you want each transaction to be transmit and retransmited X times before it's timeout, you should not call that function.  In that case generic_onoff_client_set() will return NRF_ERROR_BUSY until either you get an ACK or there is a ACCESS_RELIABLE_TRANSFER_TIMEOUT.