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

BLE Mesh LPN communication with friend node

Hi,

MESH sdk: nRF5 SDK for Mesh v3.2.0

Example: "experimental_lpn" and "light_switch server"

Hardware: PCA10056 Board (nrf52840 Dev kit)

Question 1)

I want to calculate round trip delay(Latency) between LPN and Friend Node, (I am using "light_switch server" example as a friend node)

For that i need to transfer some data from LPN to Friend node and Friend to LPN (Min 10 Byte to 30 Bytes).

so how can i transfer data and what will be the possibility.

which API/Function can be useful.

Question 2)

Also i want to send some sensor data(10 Bytes) from LPN Note to Friend node and after getting data at friend node,  friend node will replay back to LPN with some data(20 Bytes).

Please provide appropriate solution. 

Thanks in advance,

Sandip

  • Hi Sandip, 

    1. The LPN was designed so that it's transparent to the application make it easier to develop your application. So if you want to send data from a LPN to a friend node (or to any other node in the network) you simply send the data as normally, for example calling access_model_publish() like what we have in the LPN example. 

    If you want to calculate the round trip time you can actually use our LPN example. Have a look here. When you press button 1/2 on the LPN node it will send a set command and the server will send a reply. You can measure the time it take to get the reply. 

    2. I don't see any difference from your question 1. Please study the LPN example. 

  • hi Hung Bui,

    Thanks for your reply.

    From RTT Log, I have observe that LPN send Payload data(4 bytes) using access_model_publish() and getting data(4 bytes) at "light_switch server" successful without any change.(Example: "experimental_lpn" and "light_switch server")

    Now i want to send more data from LPN to light_switch server,

    for sending 10 bytes of payload i have make changes in following function "generic_onoff_client_set_unack"

    uint32_t generic_onoff_client_set_unack(generic_onoff_client_t * p_client, const generic_onoff_set_params_t * p_params,
                                            const model_transition_t * p_transition, uint8_t repeats)
    {
        uint32_t status = NRF_ERROR_INTERNAL;
    
        if (p_client == NULL || p_params == NULL)
        {
            return NRF_ERROR_NULL;
        }
    
        if (p_transition != NULL &&
            (p_transition->transition_time_ms > TRANSITION_TIME_MAX_MS ||
             p_transition->delay_ms > DELAY_TIME_MAX_MS))
        {
            return NRF_ERROR_INVALID_PARAM;
        }
    
    //    uint8_t server_msg_length = message_set_packet_create(&p_client->msg_pkt.set, p_params, p_transition);
    //
    //    message_create(p_client, GENERIC_ONOFF_OPCODE_SET_UNACKNOWLEDGED,
    //                   (const uint8_t *) &p_client->msg_pkt.set, server_msg_length,
    //                   &p_client->access_message.message);
    
        // Temp added buff (TODO: remove after testing)
        const uint8_t lu8_TempBuf[10] = {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
    
        message_create(p_client, GENERIC_ONOFF_OPCODE_SET_UNACKNOWLEDGED,
                       (const uint8_t *) &lu8_TempBuf, 10,
                       &p_client->access_message.message);
    
        // Temp Added print (TODO: remove after testing)
        __LOG(LOG_SRC_ACCESS, LOG_LEVEL_DBG1, "generic_onoff_client_set_unack\n");
    
        for (uint32_t i = 0; i <= repeats; ++i)
        {
            status = access_model_publish(p_client->model_handle, &p_client->access_message.message);
            if (status != NRF_SUCCESS)
            {
                break;
            }
        }
        return status;
    }

    but problem is at 'packet_tx' function

    1st time: Data sending OK and NO Error occur.

    2nd time: I am getting error '8' in "nrf_mesh_packet_send" function.

    please refer attached rtt log image.

    What am I doing wrong?

    Is there any other way to sending more payload data(Minimum 10-20 bytes) from LPN to "light_switch server" then please suggest.

    Thanks,

    Sandip

  • Hi Sandip, 

    When you see an error return from a function, you can check the function's description to find the issue description. 

    Error 8 means NRF_ERROR_INVALID_STATE and it's described : 

    There's already a segmented packet to this destination in progress. Wait for it to finish before sending new segmented packets.

    If the packet payload's (including the opcode and company id) is less than 11 bytes it will be sent as unsegmented message. If it's about 11 bytes, it will be split to multiple messages. You can't send 2 different segmented message at the same time. You would need to wait until it finish to send again. You can wait for the NRF_MESH_EVT_TX_COMPLETE event to start sending again. 

  • hi Hung Bui,

    Thanks for your reply. i can transfer payload data(16-112 bytes) from LPN to "light_switch server" and "light_switch server" to LPN. but it takes around 500msec to  4000msec.

    As per this case

    In advertisement we can transfer payload of 8 Bytes ONLY...

    1) Now question is we have 31 bytes is in advertisement packet then why 8 Bytes left for payload???..

    2) what is the format of BLE Mesh Advertisement???.. Can you provide advertisement packet detail description so i can get idea about whole ADV Packet of BLE Mesh. and why 8 bytes left for payload.

    One more Question is,

    3) Can I transmit more Bytes instead of 8 Bytes payload in single ADV packet?? if yes then what will be the changes  required, or any other solution?

    Thanks,

    Sandip

  • Hi Sandip, 

    You would need to have a look at the Bluetooth Mesh Profile spec to know the packet format. At section 2.3.3 you can find it's mentioned that only 11 bytes left for the application. The reason for that is the overhead needed, for example addresses, flags, MIC, etc. The network PDU format can be found at 3.4.4 

    3. Yes you can transfer more than 8 bytes payload. Then the packet need to be segmented (SAR). And that's when it can take longer to transmit the whole packet. 

Related