sensor_server with 5 Property IDs always failed in getting configuration (compositon_data_get) step using nRF Mesh (Android)

Hi,

My development setup:

HW:  nRF52840 DK
SDK: nrf5_SDK_for_Mesh_v5.0.0_src + nRF5_SDK_17.0.2_d674dde + s140nrf52720
Provisioner: nRF Mesh Android app (Ver 3.1.0)

-----------------------------------------------------------------------------------

I modified sensor_server example (nrf5_SDK_for_Mesh_v5.0.0_src\examples\sensor\server) to support multiple Property IDs (2 to 5)

Below are the Property ID I used in the modified sensor_server app: 

#define SENSOR_MOTION_SENSED_PROPERTY_ID (0x0042)
#define SENSOR_PRESENCE_DETECT_PROPERTY_ID (0x004D)
#define SENSOR_PRESENT_AMBIENT_TEMPERATURE_PROPERTY_ID (0x004F)
#define SENSOR_PRESENT_AMBIENT_RELATIVE_HUMIDITY_PROPERTY_ID (0x0076)
#define SENSOR_PRESENT_AMBIENT_VOC_PROPERTY_ID (0x0078)

I have tried adding UP TO 4 Property IDs (and up to 4 descriptors), everything is working fine, i.e. able to get through provisioning and configuration successfully and work fine with sensor_client app to send the descriptor msg for all property ids and other test (per the sensor example)

   

Problem statement:
When the number of Property ID is increased to 5, during provisioning (using nRF Mesh Android app) process,  even though sensor_server is able to go through provisioning successfully (Note: On nRF Mesh mobile app: "<- Provisioning complete received" is shown) but it consistently failed/stopped at the "composition data get" step (Pls see nRF Mesh's  screenshot below)

I have repeatedly tried with 4 and 5 Property ID builds for several times and verified that the build with 4 Property ID is always OK in all aspects but for the build with 5 Property ID, the nRF Mesh always failed at the " -> Sending composition data get .." step. 

Some debugging info:
1. I have put in some log message in handle_composition_data_get in handle_composition_data_get() (in config_server.c) and noticed that the function runs ok all the way till the end (i.e. app_evt_send(&evt). 

2. The handle_config_default_ttl_get() is not invoked for the case of 5 Property ID

This is unclear to me the issue lies with nRF52840 firmware or with the nRF Mesh mobile app.

Pls advise what needs to be done to make the sensor_server_model capable of supporting 5 Property IDs (for 5 sensors).

Another side issue:
When the sensor_server model supports only 3 sensors (3 Property IDs and 3 descriptors), I am able to click "Get Sensor" on nRF Mesh app to get the 3 sensors info showing up (under Sensor Information section). However, when testing with sensor_server with 4 sensors (4 Property ID and 4 descriptors). Upon clicking the "Get Sensor" on nRF Mesh, the nRF Mesh app will either has no response or exit from Sensor Server model screen. 

  

 

Parents Reply Children
  • It seems like the access layer couldn't allocate the packet using mesh_mem_alloc as it returned NRF_ERROR_NO_MEM.

    I suggest you to increase PACKET_MGR_MEMORY_POOL_SIZE.

  • Ok, I will try to increase it from 4096 to 5120 and see if it helps to solve. Thanks

  • Hi,

    Question: The warning regarding the max size of packet manager memory pool does not seem to reflect the current values used. Pls see text highlighted in red below.

    Can you advise what value of PACKET_MGR_MEMORY_POOL_SIZE should I use?

    In mesh\core\api\nrf_mesh_config_core.h: 

    /**
    * Size of the packet manager memory pool in bytes.
    * @warning The value of the memory pool cannot currently exceed the value of
    * PACKET_MGR_PACKET_MAXLEN, due to the current design of the memory manager.
    */
    #ifndef PACKET_MGR_MEMORY_POOL_SIZE
    #define PACKET_MGR_MEMORY_POOL_SIZE 4096
    #endif

    In mesh\core\include\packet_mgr.h

    /** Maximum length of the packets that can be allocated. */
    #define PACKET_MGR_PACKET_MAXLEN    (NRF_MESH_SEG_PAYLOAD_SIZE_MAX)

    In mesh\core\api\nrf_mesh_defines.h

    /** Maximum possible segmented payload size (octets). */
    #define NRF_MESH_SEG_PAYLOAD_SIZE_MAX (380)

  • It seems to be a legacy warning and can be ignored. From our developer:

    I think I realised why the number of properties breaks configuration:

    The memory pool size is common for the whole stack. app_sensor_utils.c uses it to allocate cadence for each property id that is defined for the sensor (see app_sensor_utils.c::sensor_initialize and app_sensor_utils.c::cadence_new). Usually, the default value in PACKET_MGR_MEMORY_POOL_SIZE is enough and this problem won't occur. I think, analysing the memory size allocated by app_sensor_utils.c::cadence_new can help them to understand how big PACKET_MGR_MEMORY_POOL_SIZE should be.

  • Hi Mttrinh,

    I tried with increasing PACKET_MGR_MEMORY_POOL_SIZE by 512 bytes to 4608 (in view of the cadence bytes needed ranges from 184 to 212 bytes) but the problem is still there. Pls see attached log that was taken with build with PACKET_MGR_MEMORY_POOL_SIZE of 4608 bytes.

    Pls help to investigate again and advise what else needs to be modified. Thank you.

Related