Handling of errors in access_model_publish()

[Gerry]

Hi,

like described in this post I sometimes get an error = 4 (NO_MEMORY) when calling:

error = access_model_publish(m_clients[0].model_handle, &msg);

How should this be handled? (Ignore, retry with delay, etc)

Is there a way to find out, wether the softdevice is still sending a message and therefore is not ready for the next one?

I'm using the mesh SDK 2.0.1 

Regards

Gerry

[Hung Bui]

Hi Seger, 

When access_model_publish() throw NRF_ERROR_NO_MEM this means there isn't enough buffer for your message and you have to wait for a NRF_MESH_EVT_TX_COMPLETE event before you continue. How often do you call publish command ? Was it a reliable message? 

[Gerry]

Hi,

I call access_model_publish()  as an unreliable message 10 times per second when I get NRF_ERROR_NO_MEM in about 50% of the calls. When using Mesh SDK 1.0.0. I was able to send 20-30 messages per second with the same code without a problem. Is there a signifficant drop in speed using SDK 2.0.1.?

I didn't check the return value when using SDK 1.0.0 but now I get an assert sometimes like described here, so I thought, this could be related to it. What do you think?

Kind regards

    Gerry

[Hung Bui]

Hi Gerry,

What was your advertising interval ? Usually it's defined as BEARER_ADV_INT_DEFAULT_MS and equal 20ms.

Do you do any proxy role or BLE ? Could you reproduce the issue with the light switch client&server (not the proxy ones) ? 

[Gerry]

Hi Hung

BEARER_ADV_INT_DEFAULT_MS is set to 20. I didn't change any settings in nrf_mesh_config_bearer.

GATT_PROXY is set to 0, so proxy.h is not included in my project. There's also no changes made to nrf_mesh_config_code. I use standard values and I don't use BLE.

I only changed the settings in nrf_mesh_config_app.h. Could there be the problem?

Here are my settings:

SERVER_COUNT = 20

CLIENT_MODEL_INSTANCE_COUNT = SERVER_COUNT + 1

#define ACCESS_DEFAULT_TTL (SERVER_COUNT > NRF_MESH_TTL_MAX ? NRF_MESH_TTL_MAX : SERVER_COUNT)

#define ACCESS_MODEL_COUNT (1 + /* Configuration client */ \
1 + /* Health client */ \
1 + /* Simple OnOff client (group) */ \
2 + /* remote client */ \
SERVER_COUNT /* Simple OnOff client (per server) */)

#define ACCESS_ELEMENT_COUNT (1 + CLIENT_MODEL_INSTANCE_COUNT)

#define ACCESS_SUBSCRIPTION_LIST_COUNT (ACCESS_MODEL_COUNT)

#define ACCESS_FLASH_PAGE_COUNT (1)

#define ACCESS_RELIABLE_TRANSFER_COUNT (ACCESS_MODEL_COUNT)

#define DSM_SUBNET_MAX (1)
#define DSM_APP_MAX (1)
#define DSM_DEVICE_MAX (SERVER_COUNT) //(SERVER_COUNT)
#define DSM_VIRTUAL_ADDR_MAX (1)
#define DSM_NONVIRTUAL_ADDR_MAX (ACCESS_MODEL_COUNT + 1) 
#define DSM_FLASH_PAGE_COUNT (2) 

[Hung Bui]

You are having 21 element (21 client model) on one device ? I would suggest to test using less number of models/element on one device. Do you really need to have one client for each server ? If you have large number of server you want to control, I would suggest to use one single client and change the publication address instead. 

Please test and verify you see the issue with stock light switch example.

[Gerry]

Thanks for your answer Hung

I think we don't really need one client per server, so I will eliminate this first and then set CLIENT_MODEL_INSTANCE_COUNT = 1. I only have to change the address using access_model_publish_address_set() when talking to the servers right? Does this affect the callbacks when receiving messages on the client also? 

[Hung Bui]

No it shouldn't affect when you have the reply from the server. The server replies to the unicast address of the client, so should always receive it, doesn't matter which public address you currently pointing to.