New to Zigbee, is it right for me?

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
#1
Posted by petervk: Thu. Sep 8, 2011 - 05:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

I've got some experience with proprietary RF protocols on various uC's, however I'm looking at zigbee on an ATmega128RF for an upcoming project.

I need to support 250-300 nodes, and just so some very simple low speed GPIO on each of them from a central controller. All nodes are quite close together, ie within 10-15m, and low power isnt at all important. I'd like to get this up and running quickly, so I'm looking at pre-made stacks.

Do you guys have any comment on zigbee's suitability for such a network?

Thanks for any advice.

Regards,
Peter

Tags:

Wireless, General Wireless Discussions, ATmega128
Last Edited: Fri. Oct 16, 2015 - 02:27 PM
Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Thu. Sep 8, 2011 - 05:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is likely to be poor without some fine tuning, 300 nodes is a lot for a small room.

But ATmega1281RFA1 is extremely easy to use, so I suggest you to write your own application on top of RF chip itself. I've posted really simple application that checks communication between two nodes, it contains absolutely minimum amount of code required to make this chip running.

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

Top
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
Posted by petervk: Thu. Sep 8, 2011 - 05:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the very quick reply Alex.

How would writing my own application code help? I'm not sure exactly what's provided by the peripheral and what's provided by the SW stack, but are you saying that the stack wouldn't cope with that many nodes, however you could write a simple stack that did?

Thanks,
Peter

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Thu. Sep 8, 2011 - 05:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I suggest you to use direct register access without any libraries. It won't be ZigBee compatible, but you don't care, right?

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

Top
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
Posted by petervk: Thu. Sep 8, 2011 - 06:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm OK I'll have a look at the register set and see what the peripheral provides. And yes, technically it doesnt need to be "zigbee".

Out of interest, if I did use the zigbee stack for 250-300 nodes, what do you mean by the performance would be poor? Poor in terms of node discovery (they are 99% static), or message latency (I can live with several seconds up to a minute or so if realllly necessary).

The packet size I'll need for my app (after everything else has been stripped), is only a handful of bytes...

Thanks again Alex,
Peter

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Thu. Sep 8, 2011 - 06:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

300 routers located in one small room will generate lots of service traffic and depending on the scenario I would expect 5-10 minutes sending period for each node. ZigBee also requires keeping few tables and you will struggle to fit all the tables required for normal operation into the RAM, few compromises should be made and that will result in inefficient operation.

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

Top
MarioRivas
MarioRivas's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 475 View posts
Posted by MarioRivas: Thu. Sep 8, 2011 - 10:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

petervk wrote:
Hmm OK I'll have a look at the register set and see what the peripheral provides. And yes, technically it doesnt need to be "zigbee".

Out of interest, if I did use the zigbee stack for 250-300 nodes, what do you mean by the performance would be poor? Poor in terms of node discovery (they are 99% static), or message latency (I can live with several seconds up to a minute or so if realllly necessary).

The packet size I'll need for my app (after everything else has been stripped), is only a handful of bytes...

Thanks again Alex,
Peter

What type of project could possibly use 250-300 nodes :shock:

Top
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
Posted by petervk: Thu. Sep 8, 2011 - 10:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
300 routers located in one small room will generate lots of service traffic and depending on the scenario I would expect 5-10 minutes sending period for each node. ZigBee also requires keeping few tables and you will struggle to fit all the tables required for normal operation into the RAM, few compromises should be made and that will result in inefficient operation.

OK wowwww yeah that blows way out to what I'd want to bear. Thanks for saving me a lot of pain :)

MarioRivas wrote:
What type of project could possibly use 250-300 nodes

We've got a number of 3rd party systems we want to hold in reset and stagger the boot up process. Also detect when they fall over and kick them in the guts.

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Fri. Sep 9, 2011 - 04:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What kind of traffic do you expect anyway?

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

Top
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
Posted by petervk: Fri. Sep 9, 2011 - 04:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
What kind of traffic do you expect anyway?

The requirements are pretty simple. Its basically a watchdog for 250-300 3rd party systems. Each node is aware of when its system times out, reports that back to a master, at which point master gives permission to reset that system. It will get a little trickier than this but that's what the requirements boil down to.

So I'm thinking I'll do a simple master-slave command-response arrangement, where the master periodically polls each of the slaves for their status, and sends reset commands if necessary. A handful of bytes per packet would be plenty.

Automatic (new) node discovery would be preferable, but the master can be made aware of the slave list through another mechanism.

I just would have preferred not to reinvent the wheel and avoid the hassle of writing the protocol and management code by using something off the shelf.

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Fri. Sep 9, 2011 - 05:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is expected polling period? With 300 devices you are on the edge of available bandwidth.

Your application seems to be very simple, ZigBee is not required here.

This post gives a good example of very simple program that implements two way communication: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=801474#801474.

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

Top
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
Posted by petervk: Mon. Sep 12, 2011 - 12:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup its a pretty simple project. Re polling period, I'd like to get round to each device every 10-20s but I could live with longer. Id be surprised if I couldn't make that timing pretty easily though.

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Mon. Sep 12, 2011 - 08:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using simple direct chip access and implementing few smart retries algorithms it looks possible, but not that easy. With ZigBee it is pretty much impossible.

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

Top
th33lf
th33lf's picture
Level: Hangaround
Joined: Wed. Sep 29, 2010
Posts: 112 View posts
Posted by th33lf: Wed. Sep 14, 2011 - 08:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

petervk wrote:

The requirements are pretty simple. Its basically a watchdog for 250-300 3rd party systems. Each node is aware of when its system times out, reports that back to a master, at which point master gives permission to reset that system. It will get a little trickier than this but that's what the requirements boil down to.

So I'm thinking I'll do a simple master-slave command-response arrangement, where the master periodically polls each of the slaves for their status, and sends reset commands if necessary. A handful of bytes per packet would be plenty.

Automatic (new) node discovery would be preferable, but the master can be made aware of the slave list through another mechanism.

I just would have preferred not to reinvent the wheel and avoid the hassle of writing the protocol and management code by using something off the shelf.

You might want to give zigbee a chance in case you are not very stringent about timing and you want to use the routing capability of Zigbee. I have seen up to around 200 ZigBee devices (non-atmel) in the same room work fine with a neighbour table size of 16. We used to miss some unicasts but later that ended up being a stack bug rather than a deficiency of the protocol. We used source routing and retries with random back-offs above the APS layer.

You could make the coordinator send a periodic broadcast and then wait for response from the devices. The devices should wait for a random time, say between 15s to 2min after receiving the broadcast before they start sending out responses which they will retry after a smaller random wait (0 to 10 seconds or so) in case delivery fails. The initial delay of 15sec is for the broadcast to die down, which might take awhile in large networks. The coordinator will have to wait for, say 5min or so, to make sure it has received packets from every device. Then, if reset is required, it should be sent as a unicast command to the correct device. Depending on the TX power of the devices and how widely/closely spaced they are, the timings may change but they will still be in minutes - response time is a huge compromise you have to make in large networks.

If timing is a problem, then it would be better to make use of the fact that all your devices will be within earshot of each other and take advantage of the smaller overhead of using a 'bare' MAC like alexru suggested.

Top