non-beacon broadcast

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

I inherited a ATZB-24 802.15.4 star configuration project. There is a single FFD that talks to all the RFDs. It operates in non-beacon enabled mode. One of the allegedly working features was a group broadcast mode. In reality it was implemented with the FFD sending multiple individual transmissions, but the user is none the wiser.

It had never been tested with more than 6 RFDs connected. Sadly it was first tested with more than 6 on my watch.

In stack_config.h NUMBER_OF_LARGE_STACK_BUFS is defined as 6. So I changed NUMBER_OF_LARGE_APP_BUFS in app_config.h from 0 to 4 and like magic the system worked well with 9 RFDs and adequately with 10 RFDs. But I'm low on data RAM so I can't just increase the buffer count as much as I need.

Does anybody know either a way to get around this limit, or some better way to do this? Thanks.

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

Murdoch (posting in above) and I work together and need a solution to the above. We would be willing to pay some consulting $ to someone that could spend a few days helping us get out of the woods with this problem.
Please contact him or myself. Thanks - Brian

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

I just compiled the default Star_nobeacon application in IAR,
When using NUMBER_OF_LARGE_APP_BUFS is 0 I got
2,024 bytes of DATA memory (+ 29 absolute )

But changing NUMBER_OF_LARGE_APP_BUFS is 4, I got
2,640 bytes of DATA memory (+ 29 absolute )

We have enough RAM left over right? I do not understand the limitation here.

How much RAM is required for your application?

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

Greetings firebee and thanks for looking at this.

My application uses a significant amount of RAM. With NUMBER_OF_LARGE_APP_BUFFS at 0 I'm using over 6000 bytes of DATA memory. When I set it to 8, I'm over 7600 bytes. The nominal limit is 8192 bytes, but I've observed quirky behaviour if I exceed ~95% or about 7800 bytes.

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

From the MAC stack point of view there is only minimal usage of RAM size. Try to optimize at the application level.
If i am not wrong NUMBER_OF_LARGE_APP_BUFFS are used for application requirement only.

So better approach will be to look for RAM reduction in the application

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

In bmm.c the number in question is TOTAL_NUMBER_OF_LARGE_BUFS which is defined as NUMBER_OF_LARGE_APP_BUFS + NUMBER_OF_LARGE_STACK_BUFS. So by adding APP_BUFFs, I effectively added STACK_BUFS.

As far as reducing RAM usage in the application, I was afraid that would be your response. It is one of the things I'm looking at.

Thanks again for looking at this.