This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE MESH Light Switch Delay in getting data between client and server sending to a group address

Hi,

I am currently using two nRF52832 SDK boards to implement text message exchange with another nRF52832 SDK board via BLE Mesh SDK 3.1.0 and nRF5_SDK_15.2.0.

the data i get from the UART.

The problem i have with the mesh is that when i send data to a group address the first message got by the BLEs subscribed to the group address immediately but the second message that i send after the first one, i got it after a few second(5-7 sec) and sometime the message not arriving .

When we send the same messages directly to ble node over the mesh using his unicast address all goes well.

For example:

Our message packet data for transactions:

generic_onoff_client_msg_data_t  msg_pkt

 

/** Union for holding current message packet */

typedef union

{

    generic_onoff_set_msg_pkt_t set;

} generic_onoff_client_msg_data_t;

 

 

 

typedef struct __attribute((packed))

{

    uint8_t  data[DATALEN];                                         /**< string data  */ /*DATALEN=3*/

    uint8_t tid;                                                      /**< Transaction number for application */

    uint8_t transition_time;                                /**< Encoded transition time value */

    uint8_t delay;                                          /**< Encoded message execution delay in 5 millisecond steps */

} generic_onoff_set_msg_pkt_t;

 

And i send the data using the functions generic_onoff_client_set_unack/ generic_onoff_client_set

thanks

Parents
  • Hi, 

    I would suggest to test using generic_onoff_client_set_unack() instead of generic_onoff_client_set() just to be sure it's not the response being propagated and can cause network congestion.

    You can try  init the log module to print out debug level to find when your message actually sent and when it's received on access layer: 

        __LOG_INIT(LOG_SRC_APP | LOG_SRC_ACCESS | LOG_SRC_BEARER, LOG_LEVEL_DBG1, LOG_CALLBACK_DEFAULT);

    The log "TX:" will be printed out when the message is being sent and "RX:" will be printed when a packet being received. 

    Do you see the same thing with unmodified light switch example ? 

Reply
  • Hi, 

    I would suggest to test using generic_onoff_client_set_unack() instead of generic_onoff_client_set() just to be sure it's not the response being propagated and can cause network congestion.

    You can try  init the log module to print out debug level to find when your message actually sent and when it's received on access layer: 

        __LOG_INIT(LOG_SRC_APP | LOG_SRC_ACCESS | LOG_SRC_BEARER, LOG_LEVEL_DBG1, LOG_CALLBACK_DEFAULT);

    The log "TX:" will be printed out when the message is being sent and "RX:" will be printed when a packet being received. 

    Do you see the same thing with unmodified light switch example ? 

Children
No Data
Related