ncs2.7 Using thread SSED and ICD, the message receiving and sending rate is abnormal

Hi All,

I have developed a low-power windowcovering product based on Matter 1.3, and currently, I'm conducting CSA certification testing. However, I've noticed that many test cases are experiencing timeouts during execution. Previously, I also developed a Matter 1.3 smoke detector, which has successfully passed the tests and obtained the CSA certification. Upon comparing the two products, I found that the windowcovering's message exchange speed with the gateway is significantly slower than that of the smoke detector, even though both operate in SED mode with ICD enabled and share similar configuration settings.

CONFIG_OPENTHREAD_MTD=y
CONFIG_OPENTHREAD_FTD=n
CONFIG_OPENTHREAD_MTD_SED=y
CONFIG_OPENTHREAD_NORDIC_LIBRARY_MTD=y
CONFIG_CHIP_ENABLE_ICD_SUPPORT=y
CONFIG_CHIP_ICD_SLOW_POLL_INTERVAL=10000
CONFIG_CHIP_ICD_FAST_POLLING_INTERVAL=200
CONFIG_CHIP_ICD_IDLE_MODE_DURATION=120 
CONFIG_CHIP_ICD_ACTIVE_MODE_DURATION=300 
CONFIG_CHIP_ICD_ACTIVE_MODE_THRESHOLD=2000

I have developed a low-power windowcovering product based on Matter 1.3, and currently, I'm conducting CSA certification testing. However, I've noticed that many test cases are experiencing timeouts during execution. Previously, I also developed a Matter 1.3 smoke detector, which has successfully passed the tests and obtained the CSA certification. Upon comparing the two products, I found that the windowcovering's message exchange speed with the gateway is significantly slower than that of the smoke detector, even though both operate in SED mode with ICD enabled and share similar configuration settings.

The SDKs for the smoke detector and the windowcovering are different. When developing the smoke detector, NCS 2.5 was used since NCS did not yet support Matter 1.3 at that time. To work around this, I replaced the matter repository's commit with the Matter 1.3 tag. In contrast, the current low-power windowcovering development utilizes NCS 2.7, which already supports Matter 1.3.

Interestingly, when I ported the smoke detector code to NCS 2.7, it exhibited the same issue as the windowcovering, with slower message exchange speeds with the gateway, resulting in test case timeouts. Furthermore, using the NCS 2.7-provided window_covering sample directly also replicated the same phenomenon as my custom-developed windowcovering. I've attached two OLG comparison images from the testing process.

Additionally, I'm attaching a typical test case, ACE2.1, which iterates through all attributes and is required to complete within 5 minutes. While NCS 2.5 with Matter 1.3 meets this time requirement, NCS 2.7 consistently exceeds the time limit.

I would like to know if Nordic is aware of the above issues with ncs2.7 and if there are recommended configurations for ICDs in low-power devices

Thanks in advance.
Best,
Tao

ACE-2.1-ncs2.7-window-sample.txtACE-2.1-ncs2.5+matter1.3-smoke.txt

  • Hello,

    Sorry for the late reply. I did forward this question to our Matter Team on Friday, and I saw that there were some discussions there both Friday and today, but no conclusion yet. Let me ping it tomorrow, and I will keep you updated. 

    Best regards,

    Edvin

  • Hello,

    Sorry for the late reply. I will ping my internal ticket for updates. Sorry for the inconvenience.

  • Ok, so our Matter team asks if increasing the timeout works, if so, they will probably add a section in the test certification in the NCS documentation. They have not looked into why the time consumed has increased between 2.5.0 and 2.7.0. They say that it generally depends on the number of clusters/attributes, and what the poll period on the device is. When you tested the smoke detector developed in 2.5.0 in 2.7.0, and it failed, Did it change the number of clusters/attributes? And how about the poll ratio? Do you specifically set the poll period, or is it the default value (which may have changed, I have not checked).

    Best regards,

    Edvin

  • I already know how to modify it, which is related to the configuration of sed. In ncs2.7, I referred to the configuration provided in the sample, CONFIG_CHIP_THREAD_SSED. During the development of ncs2.5, I used CONFIG_OPENTHREAD_MTD_SED. The difference between the two is that when initializing matter, CONFIG_CHIP_THREAD_SSED sets the thread device to SSED mode, while CONFIG_OPENTHREAD_MTD_SED sets the thread device to SED mode.

    After setting to the ssed mode, the rate of sending and receiving packets is significantly slower, and it cannot be adjusted by modifying the parameters of the ICD.

    You can also try it as I said. If the effect is the same as what I described, can you tell me why it happens?

Related