[BitCloud] Pending bit control

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

Does someone know what this new feature of BitCloud means (or how to use it):

Quote:
[ZIGBEEODC-1791] - 2.4GU: Implement pending bit control and improve empty data frame mechanism.

AFAIK previous BitCloud releases didn´t use frame pending flag at all. I thought this new feature could be motivated by the behavior described in section 7.5.6.3. of the IEEE802.15.4-2003 (i.e. "On receipt of the acknowledgment frame with the Frame Pending subfield set to zero, the device shall conclude that there are no data pending at the coordinator"). In this regard, I have observed (with a protocol analyzer) a polling sequence in the new WSNDemo app and I have seen that frame pending flag is 'on' in every 'MAC Ack' sent by the Coordinator after an End Device 'data request', regardless whether the Coordinator has data or not for the End Device.

Any clues? Thanks!

Last Edited: Fri. Oct 16, 2015 - 02:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

2.4GU is ZLL Golden Unit. Pending bit behavior is the same as in previous releases. Next stack release will have proper control of Pending Bit.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your response alexru!

alexru wrote:
2.4GU is ZLL Golden Unit. Pending bit behavior is the same as in previous releases. Next stack release will have proper control of Pending Bit.

So, can I understand it will be accessible in Bitcloud without Profile Suite? (My current design is based on ZigBit modules).

My interest for frame pending bit is due to the fact that I have designed a kind of end-device node powered with a coin cell (CR2032), so I am trying to reduce the power consumption and maximize its autonomy. At the moment, the main problem is the maximum wait time (about 30 ms for my current poll rate period) that the end-device's receiver is ‘on’ waiting for a (nonexistent) data frame from its parent. AFAIK there is no way to change the aforementioned time.

The specification provides a way to overcome this problem with transmission of an empty data frame (zero length frame) to any end-device that doesn't actually have any data pending. But I have not found a way (if any) to implement this behavior.

Any idea?

Thanks again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the next release it will be available in all SDKs. Zero length frames are currently disabled as well, and there is no way to implement them from the application.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much alexru. Your responses had been very enlightening. Now I can focus on more productive things until the next release of the stack.