OK, I'm a programmer, but rarely dealing with lower-level communications, so I have some questions. I've researched most low-power networks, and Zigbee seems like the most appropriate, but first, I'll go over my requirements.

• Low Power consumption on the nodes. Hoping for something like 1-AA(A) battery to run for XXXdays?


• One-way communications. What I need is actually the opposite of most Zigbee apps I see. I want my controller/gateway to send orders to the zigbee devices, and that's the only communication that will occur (more on that later).


• 100-200 nodes on the network, all within about 100 feet. Each node will have 4 small LEDs on them (kinda like the one on your DVD player when it's on): Red, blue, yellow, green

Those are really my only requirements thus far. Here's a high-level idea of what I'm hoping for. Basically, a PC must be able to send a signal to a quantity of zigbee nodes and tell them to turn on a specific color light for a pre-determined duration (30 seconds).

It's a bit more complicated than that, but a user will push a button on a remote the size of your TV remote (or they could use a blackberry with web app, etc), that will query a local database, and that database will return information that designates which zibgee node(s) to light up, and which color. Then that locally running app needs to light up the yellow LED on a specific 20 of the 100 nodes.

With Zigbee, am I dreaming, or is this do-able? I'm guessing I need a Zigbee IP gateway to communicate with the Zigbee devices...that's a given. How physically small of a device could I design for the zigbee nodes (within reasonable budget)? Any idea on an estimated cost for the parts for each node (minus R&D, that kinda stuff)? If you tell me I can do the zigbee part of the device for $5/device in quantity 1000, that's the kinda tips I'm looking for.

As you can tell, I'm way over my head, but this is why I came here If you have any other questions, please let me know.

Hi.
I see your plan is quite ambitious. A Zigbee network with 100-200 nodes would be a bit of a challenge. I think a network of 50 nodes is already very large. However if you partition your network carefully so that each router does not have too many end devices, then I think it might be possible.

The price point of $5 for a complete node is probably a bit difficult now. If you buy an SOC like a CC2430, those run for about $6.50 in quantities of 1000. A discrete solution is probably the better way to go, where a radio costs about $3.50/1000 and for an end device, you can usually get away with an MCU that with abou 16k-32k flash. Chips of that size run about $2 right now.

You may want to try and do a proof of concept with a handful of Zigbee modules first to get a feel for the protocol and stack behavior. After that, you may want to work with a semiconductor vendor directly if you are going to do such large networks. Debugging stacks in those types of situations will be a big pain in the ass because of the number of nodes trying to interact.

Not sure if I helped much...

A big issue I see with this is the need for the gateway to send messages out to the end nodes, not the other way around which is the traditional Zigbee use case. The issue with this is that the end nodes essentially have to be Zigbee routers and be always listening for a command from the gateway - this has significant power implications if you are using batteries.

The other possibilites are some sort of network time synchronization, with the nodes all waking up occasionally to listen for messages from the gateway. I'm not a Zigbee expert so I'm not sure what support Zigbee has for something like this. There are other time synchronized mesh networks out there for industry that would work, but these are probably overkill and would be out of your cost target.

Are you planning on using the mesh capabilities of Zigbee? You mention that all the nodes are within RF range of the gateway, so if you don't need mesh the problem becomes much easier. You could implement a much simpler protocol which just has the gateway blast out the data over and over many times, and have the end nodes turn on every so often (like every few seconds) and listen for a message. Not elegant at all, but pretty simple to implement.

Thanks guys, you've helped immensely...these are the kind of tips I was looking for. I've got to run, but I'll pop back in tomorrow once I'm a bit more awake and have more time to answer your questions.

take care,
Mike