Downlink messages not reported immediately to the application

[PascalBod]

Environment

• NUCLEO-L476RG board
• SX1261MB2xAS shield
• LBM 3.3.0

The example application is modified as follows:

• The nb_downlink (smtc_modem.c) variable is printed:

uint32_t smtc_modem_run_engine( void )
{
    uint8_t nb_downlink = fifo_ctrl_get_nb_elt( lorawan_api_get_fifo_obj( ) );

    if( nb_downlink > 0 )
    {
        SMTC_MODEM_HAL_TRACE_INFO("nb_downlink: %u\n", nb_downlink);
        increment_asynchronous_msgnumber( SMTC_MODEM_EVENT_DOWNDATA, 0 );
        set_modem_event_count_and_status( SMTC_MODEM_EVENT_DOWNDATA, nb_downlink, 0 );
    }

    return modem_supervisor_engine( );
}

• The sleep_time_ms (main_exti.c) variable is printed:

    while( 1 )
    {
        // Check button
        if( user_button_is_press == true )
        {
            user_button_is_press = false;

            main_handle_push_button( );
        }

        // Modem process launch
        sleep_time_ms = smtc_modem_run_engine( );
        SMTC_HAL_TRACE_INFO("Sleep time: %lu\n", sleep_time_ms);

        // Atomically check sleep conditions (button was not pressed)
        hal_mcu_disable_irq( );
        if( user_button_is_press == false )
        {
            hal_watchdog_reload( );
            hal_mcu_set_sleep_for_ms( MIN( sleep_time_ms, WATCHDOG_RELOAD_PERIOD_MS ) );
        }
        hal_watchdog_reload( );
        hal_mcu_enable_irq( );
    }

The application is built with the following command:

$ make sx1261

The cloud application replies to every uplink message with a one-byte message containing a counter incremented for each received uplink message.

The blue button is pushed periodically at a frequency of around 2 pushes per second.

Symptom

For some messages, the application is not immediately informed of the reception of a downlink message. Some of the delivery delays are between 5 and 11 s. Some other delays may be infinite, if the application does not poll the LBM stack, by calling smtc_modem_run_engine.

More information

The attached log file provides more information about what happened:

• At 14:20:56.179940, a downlink message containing 0x2F is received, with a LINK ADR REQ command. The message is not returned to the application
• At 14:21:00.765042, a downlink message containing 0x30 is received
• At 14:21:01.074554, the 0x2F message is returned to the application
• At 14:21:06.406773, a downlink message containing 0x31 is received
• At 14:21:11.625514, the 0x30 message is returned to the application
• At 14:21:14.488792, a downlink message containing 0x32 is received
• At 14:21:14.925967, the 0x31 message is returned to the application
• At 14:21:14.929914, the application enter sleep state
• At 14:21:34.922879, it wakes up. Then LBM returns it the 0x32 message

20231205-1420-main_exti-downlink2.txt

[PascalBod]

Would the new version (4.3.0) correct this behavior?

[lbm-team]

Hello,

Have you tried with the new version? Best

[PascalBod]

Yes. As I was not getting any feedback here, I created a support case on the Semtech website. There, I was asked for information about the client project I'm working on. As this project is currently still confidential, it was not possible for me to provide this information. Consequently, I did not get an answer to my question :slightly_frowning_face:

[opeyrard]

Could you please check with latest version of SWL2001 and let us know if issue remains ? Many thanks

[opeyrard]

No update, so issue is closed. Please reopen a new one if needed.