Is it possible to monitor the MCPS request descriptors?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Is it possible to monitor the MCPS request descriptors?

1,352 Views
btetz
Contributor I

I am using Zigbee 3.0.  When I transmit a lot of commands I get E_ZCL_ERR_ZTRANSMIT_FAIL errors.  I dug a little deeper into the error message and found that I am getting ZPS_XS_E_NO_FREE_MCPS_REQ (0x85) and ZPS_XS_E_NO_FREE_LOOPBACK (0x86) Extended Errors.

The comments from the file zps_nwk_pub.h explain about these errors:

    ZPS_XS_E_NO_FREE_MCPS_REQ,                        // 0x85 There are no free MCPS request descriptors.  There are 8 MCPS request descriptors.  These are only ever likely to be exhausted under very heavy network load or when trying to transmit too many frames too close together.
    ZPS_XS_E_NO_FREE_LOOPBACK,                        // 0x86 The loop back send is currently busy.  There can be only one loopback request at a time.

My question is:

Is it possible to monitor the MCPS request descriptors so that I can see when I am getting to the limit?  This way I could delay sending a new transmit until there is was at least 1 MCPS request descriptor available.

Labels (1)
5 Replies

853 Views
benjaminchang
Contributor V

Hi Brian,

We are facing the same problem, and hope to increase MCPS request descriptor (see my message to Mario).

Can you share your case experience to us? How did you solve the problem finally?

Regards,

Benjamin

0 Kudos

853 Views
btetz
Contributor I

Hi Benjamin,

Mario was correct.  I was broadcasting light level commands to a group of lights rapidly.  Basically, my application closes a loop on a group of lights to a light level sensor. 

To solve my problem of running out of MCPS request descriptors, I stopped sending duplicate light level commands.  Fortunately for me, my closed loop commands changed slow enough that I stopped running out of the descriptors.

Regards,

Brian

853 Views
benjaminchang
Contributor V

Hi Brian,

Thank you!

Regards,

Benjamin

0 Kudos

853 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Brian,

Broadcasting to End Device can easily exhaust resources, packets need to be held in buffers for End Devices to retrieve with their Data Request packets. 


So when a router receives a broadcast for End Device children it uses one buffer per child that packet is kept in the buffer either until it is requested by the End Device child or it times out after 7.5 seconds.

So for a Router with three ED children it has enough buffers to hold two broadcasts but you will begin to get this error from the third (with 8 buffers, example), assuming the packets are not picked up by any ED children in the meantime. Once they have expired after 7.5 seconds then more broadcasts can be handled. 

Broadcasts to End Devices should therefore be used sparingly in a time limited fashion, it is also expected that End Devices will poll frequently to keep buffers clear if broadcasts are used.

Best Regards,

Mario

853 Views
benjaminchang
Contributor V

Hi Mario,

We are facing the same problem. Is there a way to increase MCPS request descriptor?

We can find in code ""#define APP_MAX_MCPS_IND 5",  and "#define MCPS_QUEUE_SIZE 30", but no MCPS request descriptor defined.

Regards,

Benjamin

0 Kudos