zb_zdo_pim_start_turbo_poll_continuous() not working

[maxkl]

I am developing a Zigbee sensor device based on the nRF52840. I have based my firmware on the "Thingy:53: Zigbee weather station" sample. This means it is a Sleepy End Device. To reduce power consumption, I increased the long poll interval to 60s using zb_zdo_pim_set_long_poll_interval(). This works so far, with the disadvantage that it is practically impossible to send any commands (configure reporting, identify, ...) to the device from the coordinator, which only keeps outgoing packets for around 10s before timing out.

To resolve this, I intend to use the button on the device to poll the coordinator manually. From the SDK documentation I inferred that zb_zdo_pim_start_turbo_poll_continuous() should do what I want, i.e. polling the coordinator manually for a few seconds. However, the function call doesn't seem to do anything. Using a Zigbee sniffer in Wireshark I see no packets of any kind being sent upon pressing the button and calling the function.

The Turbo Poll feature is enabled: After joining the network, the ED sends multiple polling packets in increasing time intervals, which I assume to be determined by the "Turbo Poll adaptive algorithm". If I explicitly disable Turbo Poll using zb_zdo_pim_permit_turbo_poll(ZB_FALSE), these multiple polling packets don't happen. Calling zb_zdo_pim_start_turbo_poll_continuous() in the button handler doesn't do anything either way.

This is the part of the documentation that I am referring to : https://developer.nordicsemi.com/nRF_Connect_SDK/doc/zboss/3.11.4.0/zigbee_prog_principles.html#zigbee_data_polling_mechanism

Did I misunderstand what zb_zdo_pim_start_turbo_poll_continuous() is supposed to do? I expected that simply calling this function once sends multiple polling packets over the specified time. Are there any other prerequisites I need to ensure, such as disabling ZBOSS sleep or explicitely sending a packet?

[maxkl]

I just noticed an inconsistency in the documentation for zb_zdo_pim_start_turbo_poll_continuous(). The parameter is described as "turbo_poll_timeout_ms: Timeout in milliseconds." but it is of type zb_time_t, which, according to its documentation, is "Time stored in ticks".

I'm calling the function as zb_zdo_pim_start_turbo_poll_continuous(10000); so an intended 10s timeout. Could this be a problem?

[Maria Gilje]

Hello,

I will take a look at this on Monday.

Thank you for your patience.

Kind regards,

Maria

[Maria Gilje]

Hello,

Did I misunderstand what zb_zdo_pim_start_turbo_poll_continuous() is supposed to do? I expected that simply calling this function once sends multiple polling packets over the specified time. Are there any other prerequisites I need to ensure, such as disabling ZBOSS sleep or explicitely sending a packet?

If the ZED does not expect to receive a packet, zb_zdo_pim_start_turbo_poll_continuous() will not have an effect. Which of the following conditions do you expect to be met?

Please also share your sniffer log so we can take a look as well.

Best regards,

Maria

[maxkl]

Thank you.

I expect none of these conditions to be met. I understood this part to mean that in the cases listed, the turbo poll starts *automatically*. The documentation also says afterwards that “The turbo poll can also be forced for a certain period of time by calling zb_zdo_pim_start_turbo_poll_continuous, […]”, which I interpreted to mean that this forces turbo poll irrespective of the listed conditions.

Is there then any other way to force polling of the parent? Maybe by manually sending a packet that expects an ACK or response?

I will try to record a sniffer log once I am back at the workbench.

[Marte Myrvold]

Hi,

What are you setting as turbo_poll_timeout_ms? Using zb_zdo_pim_start_turbo_poll_continuous() should force turbo poll to start. However, the polling does not start immediately but upon the next scheduled poll.
You can see an example of this here:

I have set the long poll interval to 1 minute. Sometime between packets 1062 and 1069 I started turbo poll. The first poll after starting this was still at the scheduled time, but the polling rate was increased for the subsequent polls.

Best regards,
Marte

[maxkl]

Thanks Marte. Yes, now that you point it out I can confirm that I see the same behaviour.

So I thought the solution is simple, I could just decrease the long poll interval temporarily to a short value, such as 1000ms. But, sadly, even zb_zdo_pim_set_long_poll_interval() only takes effect upon the next long poll event. So it takes up to 60s for the next poll event to happen, but then it continues polling every 1000ms.

My intended way of operation was a regular long poll interval of 60s or longer, but when the user presses the button of the device, it would immediately start polling with a high rate for about 10s. Afterwards it should go back to the slow long poll rate of before. Do you have a solution to achieve this specific behaviour?

[Marte Myrvold]

Hi,

There is no way to directly increase the polling rate temporarily other than when waiting for a response or a fragmented message as with turbo poll.

One option is for the device to send a simple Zigbee command to the parent when the user presses the button. This will make the device poll the parent, and the parent can send the packets it has been keeping for the device. It can be something as simple as an Active Endpoint Request.

Best regards,
Marte