RE: how to send large payload(16k byte) using Bluetooth mesh

Mttrinh — Tue, 30 Jun 2020 13:55:49 GMT

Hi,

1. You can find the documentation for the Instaburst feature here, and APIs for Instaburst TX module and RX module.

[quote user="karan patel"]I want to integrate this feature in mesh sdk light_switch example is it possible?[/quote]

Yes, it should be possible.

2. Instead of setting a flag in the NRF_MESH_EVT_TX_COMPLETE event and sending the data in main loop, try sending the data directly after getting the event? Doing it from main will cause interrupt priority issues as you mentioned. I recommend you to have a look at the interrupt priority documentation.

RE: how to send large payload(16k byte) using Bluetooth mesh

karan patel — Thu, 25 Jun 2020 18:02:50 GMT

Thank you for your reply ,

1- I go through the post about instaburst but as mentioned in that post there is no separate api for this feature as the person who ask did not share code or anything,is there any example how to use this feature? I want to integrate this feature in mesh sdk light_switch example is it possible?

2- I got that point so before your answer i keep packet size 350 and tried to send such multi pal packet from server side by modifying below function,

static uint32_t status_send(generic_onoff_server_t * p_server,
                            const access_message_rx_t * p_message,
                            const generic_onoff_status_params_t * p_params)
{
   uint8_t data[500];
  memset(data,'K',498);
  data[499]=0;
    uint8_t lpVar,lpCnt;
    uint32_t rstat=0;
    uint16_t delay,maxDatalen=350;//ACCESS_MESSAGE_LENGTH_MAX-1;
    generic_onoff_status_msg_pkt_t msg_pkt;

    if (p_params->present_on_off > GENERIC_ONOFF_MAX ||
        p_params->target_on_off  > GENERIC_ONOFF_MAX ||
        p_params->remaining_time_ms > TRANSITION_TIME_STEP_10M_MAX)
    {
        return NRF_ERROR_INVALID_PARAM;
    }

    msg_pkt.present_on_off = p_params->present_on_off;
    if (p_params->remaining_time_ms > 0)
    {
        msg_pkt.target_on_off = p_params->target_on_off;
        msg_pkt.remaining_time = model_transition_time_encode(p_params->remaining_time_ms);
    }

    if(strlen(data) % maxDatalen)
      lpCnt=(strlen(data) / maxDatalen)+1;
    else
      lpCnt=(strlen(data) / maxDatalen);
    __LOG(LOG_SRC_APP, LOG_LEVEL_DBG1, "lpcnt is %d\n",lpCnt);
    for(lpVar=0;lpVar<lpCnt;lpVar++)
    {
      txisongoing=1;
        access_message_tx_t reply =
        {
            .opcode = ACCESS_OPCODE_SIG(GENERIC_ONOFF_OPCODE_STATUS),
            .p_buffer = (const uint8_t *)&data[lpVar * maxDatalen],// &msg_pkt,
            .length =(lpVar==(lpCnt-1)) ? (strlen(data)- (lpVar * maxDatalen)) : maxDatalen ,//p_params->remaining_time_ms > 0 ? GENERIC_ONOFF_STATUS_MAXLEN : GENERIC_ONOFF_STATUS_MINLEN,
            .force_segmented = true,//p_server->settings.force_segmented,
            .transmic_size = p_server->settings.transmic_size
        };
        
        /////// below structure is for reliable send//////////////
        access_reliable_t  reliable_send =
        {
            .model_handle=p_server->model_handle,
            .message.opcode = ACCESS_OPCODE_SIG(GENERIC_ONOFF_OPCODE_STATUS),
            .message.p_buffer = (const uint8_t *)&data[lpVar * maxDatalen],// &msg_pkt,
            .message.length =(lpVar==(lpCnt-1)) ? (strlen(data)- (lpVar * maxDatalen)) : maxDatalen ,//p_params->remaining_time_ms > 0 ? GENERIC_ONOFF_STATUS_MAXLEN : GENERIC_ONOFF_STATUS_MINLEN,
            .message.force_segmented = p_server->settings.force_segmented,
            .message.transmic_size = p_server->settings.transmic_size,
            .message.access_token = nrf_mesh_unique_token_get(),
            .reply_opcode.opcode=ACCESS_OPCODE_SIG(GENERIC_ONOFF_OPCODE_STATUS),
            .reply_opcode.company_id = ACCESS_COMPANY_ID_NONE,
            .timeout=SEC_TO_US(59),
            .status_cb=reliableAccessCb
        };
                  __LOG(LOG_SRC_APP, LOG_LEVEL_DBG1, "tx length is %d\n",reply.length);
                 // __LOG(LOG_SRC_APP, LOG_LEVEL_DBG1, "tx length is %d\n",reliable_send.message.length);
        if (p_message == NULL)
        {
            rstat=access_model_publish(p_server->model_handle, &reply);
            if(rstat!=NRF_SUCCESS)
            {
               __LOG(LOG_SRC_APP, LOG_LEVEL_DBG1, "publish fail %lu\n",rstat);
                return rstat;
            }
        }
        else
        {
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "access reply called \n",rstat);
            rstat=access_model_reply(p_server->model_handle, p_message, &reply);
            //rstat=access_model_reliable_publish(&reliable_send);
            if(rstat!=NRF_SUCCESS)
            {
              __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "reply fail %lu\n",rstat);
                return rstat;
            }
        }

        //nrf_delay_ms(1000);
    }
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "publish sucess\n");
}

here i am using mesh sdk 4.1 light_switch server and client example and function is from server side.i am trying to do like when ever i press switch from client server get notification and send 16k data(something like master-slave).

i found that if i back to back send two packet of 350 byte than first is succeed and latter is failed.so i debug that i have to wait for NRF_MESH_EVT_TX_COMPLETE event in static void mesh_event_cb(const nrf_mesh_evt_t * p_evt) which is in config_server.c.(as keeping delay in status_send function is not wrking if i put delay in that function,NRF_MESH_EVT_TX_COMPLETE event will not generate).so i am seting some flag from that event and try to send data from main loop using something like,

//        if(tx_ack_receive==1)
//        {
//        
//          hal_led_pin_set(ONOFF_SERVER_0_LED, !hal_led_pin_get(ONOFF_SERVER_0_LED));
//          
//          app_onoff_status_publish(&m_onoff_server_0);
//          tx_ack_receive=0;
//        }

but if i initiate data send from main than got error "error:app_error_weak.c, 105, Mesh assert at 0x0002C96C (:0)" after searching i found that it is due to some interrupt priority and try also some work around suggested on online platform but it didn't work.

so how to initiate next packet transmission once NRF_MESH_EVT_TX_COMPLETE is received ?

as you can see in function i also try to send reliable message in status_send function but in that case even during first packet i got error NRF_ERROR_INVALID_PARAM i try to debug also but not find clue.

RE: how to send large payload(16k byte) using Bluetooth mesh

Mttrinh — Thu, 25 Jun 2020 16:08:50 GMT

Hi,

1. You will need to split up the data into smaller packets. Sending packets of smaller size and reassemble after it has been received on the other end.

You can consider using Nordic Advertiser Extensions (Instaburst). It will increase your payload (498 bytes) but just note that Instaburst is a Nordic proprietary feature that does not adhere to the Bluetooth Mesh Specification. It will break compatibility with other Bluetooth Mesh implementations.

You can read more about this in this post.

2. Yes. any packet with size larger than 11 bytes (including header) will be split into segmented messages automatically. But the maximum possible segmented payload size is 380 so it will fail if you have a higher payload.

3. Mesh is not optimal for sending/streaming a lot of data. In the Mesh documentation from our Infocenter:

"Bluetooth Mesh primarily targets simple control and monitoring applications, like light control or sensor data gathering. The packet format is optimized for small control packets, issuing single commands or reports, and is not intended for data streaming or other high-bandwidth applications."

The throughput in a Mesh network is highly dependent on several factors. How many nodes do you have in your network, are you sending reliable or unreliable messages, how many hops to you need to reach the receiver node etc.

For one hop we have seen 3.46kbps ( ~54 Bytes/s) with 20ms advertising, 100% scanning with 11 bytes payload, Non-Acked, i.e. unreliable.

4. Unfortunately, we don’t have an example for sending large payloads in a mesh network.