How to implement BT Mesh event handle to catch NRF_MESH_EVT_TX_COMPLETE or read current state

[RSA]

Hi guys, i can't figure out how to create an event handler in my Mesh Client.

The functionality of this handler should be to set a flag on the 'NRF_MESH_EVT_TX_COMPLETE'.

I need to know this, because i will be running a timer just before transmission and want to stop it when finished.  I also want to know when the NRF_MESH_EVT_TX_COMPLETE has been thrown, to prevent sending a new message and getting a wrong state error.

To be frank, i'm not sure if making an evt handler is the right move, but is sounds logical, unless there's a register/attribute i can read that shows the current state.

This is how far i've come:

static void mesh_evt_handle(const nrf_mesh_evt_t * p_evt)
{
    switch (p_evt->type)
    {

        case NRF_MESH_EVT_TX_COMPLETE:

        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "state: NRF_MESH_EVT_TX_COMPLETE");
        
        //do this and that
        break;
        }
}

it's a rough copy of a handler reacting on the same state in the config_server.c

I think one of my roadblocks is not knowing how to assign the handler to catch the events. .

[RSA]

Okay so implementation was easier than i realised, all i needed was

static void mesh_evt_handle(const nrf_mesh_evt_t * p_evt);
static nrf_mesh_evt_handler_t m_mesh_evt_handler = { .evt_cb = mesh_evt_handle };

//and call
nrf_mesh_evt_handler_add(&m_mesh_evt_handler);

But now something weird is happening.

I never mentioned that i actually recieve the error 8 NRF_ERROR_INVALID_STATE  , but i sometimes do.. by waiting for NRF_MESH_EVT_TX_COMPLETE  i don't get this anymore.. but the NRF_MESH_EVT_TX_COMPLETE  is first received several secounds after receiving the message on the server.  This doesn't make sense to me.

[tesc]

Hi,

From what function call do you get the NRF_ERROR_INVALID_STATE?

Note that the time needed for publishing a message depend on the Publish Retransmit Count and Publish Retransmit Interval configuration settings on the model. When publishing a message, it is sent Retransmit Count number of times, with Interval interval. For instance, even if the recipient gets the message on the first publication, there may still be several retransmissions every a few tens (or a few hundred) milliseconds, before the sender considers the message sent.

Regards,
Terje

[RSA]

i get the error from: " access_model_publish() " You mention that the timing is dependent on the "Publish Retransmit Count" but this is model dependant right? I'm using a custom mode, and only send the message once.

uint32_t test_model_client_set_unreliable(test_model_client_t * p_client,
                                          tx_type_t             value,
                                          uint8_t               repeats)
{
    test_model_msg_set_unreliable_t set_unreliable;
    set_unreliable.msg_value = value;
    set_unreliable.tid = m_tid++;
    access_message_tx_t message;
    message.opcode.opcode = TEST_MODEL_OPCODE_SET_UNRELIABLE;
    message.opcode.company_id = TEST_MODEL_COMPANY_ID ;
    message.p_buffer = (const uint8_t*) &set_unreliable;
    message.length = sizeof(set_unreliable);
    message.force_segmented = SEG_STATUS;
    message.transmic_size = MESSAGE_LEN_CUSTOM;
    uint32_t status = NRF_SUCCESS;
    
    //this loop?
    for (uint8_t i = 0; i < repeats; ++i)
    {
        message.access_token = nrf_mesh_unique_token_get();
        //__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "just ran nrf_mesh_unique_token_get()  \n");
        status = access_model_publish(p_client->model_handle, &message);
        //__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "exited access_model_publish()  \n");
        if (status != NRF_SUCCESS)
        {

          __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "status not successfull in  test_model_client_set_unreliable()  \n");
            break;
        }
    }
    return status;
}

is suspect that you're talking about the for loop that is implemented in my example. If this is the case, i would expect the NRF_MESH_EVT_TX_COMPLETE  to be called  n=repeats times, since i understand that access_model_publish is responsible for the event.

[tesc]

Hi,

Actually there are two layers of repeats going on. The for loop that you refer to can be seen as an outer loop that sends the same message contents several times, but as a number of separate messages. Each message still conforms to the configuration set for the particular instance of the model, which means several packets may be sent.

Regards,
Terje

[RSA]

Where would i be able to change the configuration set for the particular instance which determines the amount of packages? (speaking of the inner loop)? After som digging i found "config_publication_state_t.retransmit_count" in config_client.h. sounds like this is the struct that i'll have to modify.

[tesc]

Hi,

The configuration is (usually) performed by the provisioner.

If you use the nRF Mesh smartphone application for provisioning and configuring the nodes, then you can set the configuration from there.

If you use a provisioner based on the light_switch provisioner, then that is done by the provisoner in configuration steps in node_setup.c.

There may also be some default values set in nrf_mesh_config_app.h or a similar configuration file, for the node itself. (That is, the node that has the model.)

Regards,
Terje

[RSA]

thank you, i appriciate the help