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