Hello all, I’m new to this forum and to XBee/ZigBee, but I have read all of Faludi’s Wireless Sensor Networks book as well as the entire XBee manual from Digi. I’ve also scanned this forum and haven’t seen this addressed anywhere else-- apologies in advance if I missed it somewhere.
I’m in the early stages of designing a consumer system that will have multiple endpoints (likely XBee routers as they will be line powered)-- I’d like to design the system to have up to 100 nodes. All nodes will be smart as they will have a uC attached (Arduino or PICAXE), so I do have logic at my disposal in each end node.
The system needs to be easy to configure for consumers yet still maintain PAN boundaries (you don’t want someone on another PAN controlling your devices, and these may operate in environments with multiple PANs).
Here’s what I’d like to be able to do (feedback much appreciated):
Coordinator will have two rotary selectors (1-9 on each) that will set the PAN on startup (PAN will default to something like “MYPAN” + 2-digit number as selected on the rotaries. This will be set at startup by the software on the coordinator.
End devices will also have two rotary encoders allowing for them to be set to one of 100 nodes on the PAN. All end devices will likely be routers, and all are likely to be one or less hops away from the coordinator.
System needs to be able to automatically accept new end devices (when the customer buys a new one and adds it to the network)-- how to configure auto-join from the end device, so the device joins the unique PAN once and remains bound to that PAN without any user entry beyond the setting the two encoders on the end device?
To keep things simple, can I use all broadcast messages? I really don’t care about the 64-bit or 16-bit addresses in the XBees, and these are not consumer friendly anyway. I do need to have a simple way for customers to address and communicate with specific devices on their network-- again, this is where I was planning to use the two encoders on each device to set the device ID. Can I just use broadcasts and have each end device interpret (uC software to analyze based on a custom endpoint adress ID I send in the payload) whether the packet applies to it? I’m trying to avoid complex Many-To-One or Source Routing if at all possible. If most/all devices are within one hop of the Connector (or able to contact it directly), do I need to mess with routing tables? I need to minimize network chatter as can happen with default routing in a large network, and I’m hoping to handle node addressing in software vs. on the XBee.
I know this is a long post and that I’m asking many different questions. I haven’t been able to find any documentation that goes into depth about large-scale and advanced XBee network configuration-- are there any whitepapers or design docs that go into great depth on Many-To-One and Source Routing? The write-ups I’ve found thus far (in the book, the manual, and on the wiki) are lacking in detail.
Thank you very much for any commentary and advice you can provide for my scenario above!
DIP switches would be fine as long as your uC would manualy force the correct fixed PAN into the XBee - would you really need 2? Would one hex with 0-15 offset be enough?
If you really don’t want to mesh & want to broadcast, then don’t use ZigBee, use 802.15.4. ZB won’t handle broadcasts unless:
you NEVER send more than say 1 request per 10 seconds
your uC can gracefully handle seeing the same message more than once.
802.15.4 not only handles broadcast flawlessly (without any mesh discovery delays), but it has very low latency in the 50msec range.
Thanks Lynn, this is great advice. I appreciate it. Some additional questions:
When you say “if you don’t really want to mesh” I wasn’t necessarily picking ZB because of any need to mesh. I assume mesh is typically most useful when you need routers between the coordinator and the end devices (i.e., when you have multiple hops in your network)-- is that accurate? If so I don’t anticipate needing to maintain a robust routing table in my network-- I was drawn to XBees initially because of their intelligent topology features but I don’t think I’m attached to ZigBee vs. 802.15.4.
While I don’t anticipate needing to send large amounts of data over this network (i.e., no video, voice, images, etc.) I do need to send messages more frequently than every 10secs. So ZB broadcasts look like they won’t work for me.
If I go with 802.15.4 instead of ZB, what am I giving up (i.e., what is the downside)? I’m assuming I’ll lose self-healing and mesh capabilities, but in my network (with one coordinator and up to 100 end devices that will be in close proximity to the coordinator), what ZB features do I lose that would be helpful in my specific situation?
When you talk about 802.15.4 modules, are you really just talking about Series 1 Xbees? I’m having a challenge sorting out all the Digi product options and pros/cons of each. Are you suggesting something like the XB24-ACI-001 (assuming chip antenna)? I read the whitepapers “Demystifying 802.15.4 and ZigBee” and “Untangling the Mesh” on Digi’s website.
Do the 802.15.4 modules support the same API featureset as the ZB modules? I’m just diving into the XBee product manual…
If you’re new to XBee, then you have a learning curve to go through. I’ve been using them for a few years, and I’m still going through it…
IMHO, if you don’t see a real need to use the series 2 XBees you could do far worse than to start with the series 1, using the 802.15.4 firmware.
Reasons?
The series 1 chips are much less complicated.
If you don’t need routers (ie if at the early stage all your XBees will be in direct contact with each other) then the series 1 modules will work perfectly well.
Because of (1) above, the learning curve for series 1 should be a lot shorter. And if you then decide you need series 2 after all, you’ll have a transition to make but all the previously acquired knowledge will still be useful. So you’ll have two smaller learning curves in series, as opposed to one big one.
You mentioned broadcasts: I think you probably don’t want to go down that road. They have their uses, but they don’t get acknowledged so if one is killed by interference it disappears without trace.
You asked what you would give up if you went to 802.15.4, and you mentioned self-healing and mesh capabilities. Those are both true: you’d lose them. For any other items we’d probably have to know more about your specific situation.
And you asked about series 1 and 802.15.4 versus other options. If you hop over to the 802.15.4 forum and check out the pinned posts, you’ll find my thoughts on these things.
And for your question 5: there are both overlaps and differences between the API feature sets.
If you’re a masochist, you could read the source code of my packet-check program to see the differences.
Alternatively, if you’re a masochist you could read all the product manuals and compare them. (Yes, I did!)
Note: there is no “if you’re not a masochist” option here
LOL John, that’s ok-- I think we all are in some way agreeing to be masochists by diving into the depths of wireless networking, aren’t we?
Thank you for the great info-- I’ve spent much of the day today reading up on 802.15.4 and agree this will be the easier place to start.
One last question: do we know Digi’s committed support path for Series 1 radios? Right now they appear to have at least three overlapping (though also somewhat distinct) product lines: 802.15.4, ZigBee, and DigiMesh. Can we expect that they will conitnue to support all three for the forseeable future? “Series 2” makes “Series 1” sound like it’s only a few firmware updates away from the “no longer supported” list. Just wondering…
Now, back to the giant cup of coffee and product manuals!
I had the same problem as you are before. Basically, you’d want a ‘server’ and a bunch of ‘clients’ and communication is limited between server and clients but not between clients.
For a simple setup like these (no meshing and one hop link between client and server), I’d think xbee would be an overkill. Since you are including a uC at each end device, you can have it in a way that addressing is handled at an upper layer.
Think about broadcasting a message to every node and let the node decide if the message is intended for them. This is where your addressing scheme come into play. For the setup I did, I made it just like how computers communicate in a local area network (MAC address/IP address). The MAC address/hardware address is hardwired to be always a broadcast and every node gets to see it. On the message itself is where the recipient address is located. With a simple processing by the client (checking if the destination address is the same as its address), it can decide to respond or ignore the message.
The downside to this is you have to implement acknowledgement at a higher layer (most RF transceivers have built in ACK mechanism so you have to disable it as you would get ACK from every node).
The base “rubber meets road” reason you can’t broadcast painlessly in Zigbee is since the nodes have no clue how far away (or hops) their peers are, EVERY NODE must repeat all broadcasts - 5 times in fact! And since they all share a single frequency, consider your situation with 101 nodes (1 master, 100 clients), you need to make RF ‘room’ for 505 broadcasts. In truth, they will hit the 5 second limit and abort the repeats before all 505 are sent, but I hope you can see why broadcast is not an ideal plan on a self-healing mesh.
That is also why on occassion 2 or more copies of the same message may dump out the serial port at a node.
So with S1, the ‘master’ broadcasts - 1 RF packet, every node within RF-sight of the master hears it. You are read to go.
With S2, the ‘master’ broadcasts - 500+ RF packets later your mesh is finally ready to get back to work.
The S1 has the same API form as the S2, but some of the parameters (like end-point) can be ignored/left zero. So you could start with S1 and if you are careful still evolve to use mesh in the future.
You asked about Digi’s future support. As far as I know, the series 2 isn’t intended as a replacement for the series 1 - each has a different application area so you can think of them as two different products rather than predecessor and successor.
But I’m not Digi. If you want an answer you can rely on, I’m sure the excellent folks at Digi support will provide one.
Thanks, all for your advice! I have a batch of Series 1 radios on the way-- much “fun” ahead as I work to put the rubber to the road as Lynn said.
I’ll likely ask any future questions on this topic in the 802.15.4 forum and keep an eye on this forum in case I have a need for mesh and self-healing.
Again, thanks for the great advice-- although I’m a newbie, I can already tell this is a forum with a strong community behind it.
I would add that the S1 is NOT likely to go away because there is a whole application space where ‘mesh’ isn’t useful and/or ‘variable latency’ is a killer. So many S1 users would NOT migrate to S2 if Digi tried to force them that way.
Example users of S1 which can’t use S2:
I/O echoing - as example, digital inputs here are output over there with 50msec latency or less. They will never be able to match that predictability with a self-healing mesh.
Sensors on a pallet wrapping machine. Controller is a few feet away from a rotating bed. Low latency is of course important, but more importantly the distance between all devices is a dozen feet, and will never be more. RF problems caused by rotating metal things are ‘solved’ by more rotation & retries, not reconfiguring the mesh constantly.
