I am trying to work with a project where multiple devices will be communicating with each other over XBees. For example, device 1 may be sending data two device 2 and 3 over XBee. The problem is that communication can happen at any time and between anyone. This means that device 2 may "possibly" send data at the same time, resulting in device 3 getting two messages, while device 1 and 2 are supposed to be receiving a message while sending.
Is this even a possibility with XBee? If so, would it require something like synchronization of communication one the devices, or is there a way to configure the XBee devices to do this? I am mainly using XBee Pro's, but I can switch to anything if needed.
There should be no problem, but incoming messages should be read and processed ASAP as XBees have limited buffer space. Keep messages small for the same reason. Specifically what kind of XBees are you using, 802.15.4 (fka S1) or ZB (fka S2) or something else? Are you using transparent (AT) mode, or API mode?
The XBee I am using is the XBee XSC. I am not sure exactly what standard they use as for communicating beyond 900MHz communication. Currently I am communicating in AT mode and handling the parsing myself (no API Mode).
I do process the information as soon as it comes in, but do you know of any information in regards to the buffer space. I would like to do some calculations as to how fast the parsing absolutely has to be so the buffer does not get filled up.
If there shouldn't be a problem, how does device 3 know that one message came from device 2 and the other from device 1 if they come in at the same time?
LoveTesting:
The XBee I am using is the XBee XSC. I am not sure exactly what standard they use as for communicating beyond 900MHz communication. Currently I am communicating in AT mode and handling the parsing myself (no API Mode).
I do process the information as soon as it comes in, but do you know of any information in regards to the buffer space. I would like to do some calculations as to how fast the parsing absolutely has to be so the buffer does not get filled up.
I haven't used the XSC models, I'd have to check the User Manual. How large are the messages, and what is the rate, i.e. how fast do they come in.
If there shouldn't be a problem, how does device 3 know that one message came from device 2 and the other from device 1 if they come in at the same time?
Either that will have to be part of the information in the message, or use API mode, which will have the sender's address as part of the frame header. For anything other than trivial networks, I strongly recommend using API mode.
I haven't used the XSC models, I'd have to check the User Manual. How large are the messages, and what is the rate, i.e. how fast do they come in.
I did review the manual, but must not know what to look for when trying to get the information we are discussing. I have some messages that may be 100 bytes long sent at 1 to 2 times a second. Messages occasionally may be larger.
Either that will have to be part of the information in the message, or use API mode, which will have the sender's address as part of the frame header. For anything other than trivial networks, I strongly recommend using API mode.
When looking up the model (mine specifically is an XBee XSC Pro (S3) not (S3B)) in X-CTU, I am unable to find anything about placing in API mode. I would not have a problem with purchasing newer XBees with API mode if I can understand how it would benefit my system.
Messages are sent in the form: who from, who to, a tag for the type of data, and then the data. The who to part may be a "to everyone", so then in AT mode, everyone listens to it. I understand in some systems that it can be seen from the XBee who the message came from, but in API mode, how do I send to only one or many (since messages acknowledge). Basically, I made my own API since the XBees I used did not seem to have one and because I wasn't sure if an XBee that did would work for me. If you have direct answers that would be great, but if not, advice is also appreciated.
Well for the 802.15.4 and ZB model, API mode is enabled by loading different firmware via X-CTU. Assuming the XSC model is the same, go to digi.com's support page, make sure you have the latest firmware version downloaded and installed, then you should see the various options in X-CTU. For the ZB modules, there are six different firmware options, coordinator, router and end device, then for each, AT or API mode.
The other benefit with doing the communication the way I am doing it is that I do not need to have a list of device names before starting. The message itself includes who the device came from. If XBee API uses a special code to represent a device, I would need a parser on the code side to say that code = device.
Huh, don't know what to tell you. It's in the user manual, table 5-08, under serial interfacing commands. Assuming I got the right manual. Maybe there is alternate firmware?
The special code that API mode uses to represent a device is just it's address, so not sure how much overhead that would represent to deal with. API mode is so much more powerful and flexible that it outweighs minor little inconveniences like that. IMHO. At any rate, there is no reason you could not continue to encode the device name as part of the message in API mode, just as you do now.
So, in API Mode, what are the major benefits. I know that it handles re-sending a set number of times if the message does not get acknowledged. I also know that it handles to and from components. I am not sure how to set it up to broadcast? I can handle to From component if the benefits outweigh as you suggest.
Also, back to another question. How does the XBee handle the buffering part we were talking about earlier. Do they give details on size of the buffer? You mentioned in reference to my question "what happens if device 1 and 2 talk to 3 at the exact same moment:
Either that will have to be part of the information in the message, or use API mode, which will have the sender's address as part of the frame header. For anything other than trivial networks, I strongly recommend using API mode.
Does this mean that API mode can handle telling the difference between two messages that occur at the same time? How is this possible in RF, to the point that they aren't merged and then thrown away since the checksum doesn't match?
Sorry for so many questions. I have been reading up on XBees a lot lately, but there are a few questions that I just don't seem to find concrete answers about.
AT mode can be considered to just be a replacement for a serial link. Bytes go in one end, they come out the other. Period. Actually it is built on API mode under the covers but basically all the functionality and information is abstracted away.
So in AT mode, you get to design your own protocol if you want a message- or packet-oriented interface. With API mode, that is already there. Send a packet, you get an acknowledgment back that tells whether the packet was transmitted successfully or not. On the receiving end, you are notified when a packet arrives, and you can treat it as a single message unit if so desired. You get the address of the device that sent it. Addressing multiple devices is simply a matter of inserting the destination address into the packet. Broadcast messages are just a special address. No fumbling with escape sequences to send AT commands to the XBee. And on and on. There really is no comparison. If you're serious, use API mode.
Not sure on the specifics as far as buffer size. You are reading the User/Product Manual for your device, correct?. Always remember, XBees are low-bandwidth devices. If in doubt, implement flow control to avoid overrunning the buffers.
On the RF level there is collision detection and automatic retries. Again, an advantage of API mode, you get packet-by-packet feedback regarding whether the transmission was successful.
As ever, the proof is in the pudding. Design and run tests to prove your particular configuration.
Thanks. I did read a lot of this information when reviewing the differences between AT and API, but it is more promising when hearing it from a second person. I would like to use API mode, but now I have to figure out how to get it on my device (if possible - looking a documentation now).
I did see something about collision detection, but wasn't sure. I will definitely test that to see how the results look.
I use Andrew Rapp's library for API mode, he did a really fine job on it. I think it is only meant for the 802.15.4 (S1) and ZB (S2) modules, however. Good luck!
Thanks for all of your help previously. Through research I am looking at the XBee-Pro 900HP models. There are two versions, Digimesh and Point to MultiPoint. I am looking up differences between the two and believe I understand the difference, but I was wondering if you (or anyone else) has a second opinion on which is best for a system such as this.
Digimesh is similar to ZigBee, but is Digi proprietary. Mesh networks can be more robust (self-healing features, can route around failed nodes) but can also be a bit slower, at least at times due to things like route discovery. Unless you're pushing throughput to the max, it shouldn't be noticeable, and if you are you're likely to have other issues anyway. I use the XBee ZB modules, the mesh networking works fine for me.
Is there a particular reason why one would go with ZB versus a DigiMesh device? I have definitely been leaning towards using something with mesh healing. What ZB device would be comparable to the XBee Pro 900HP (if you know, if not I will be looking at them)? Thanks again.
Okay, so from what I am seeing, DigiMesh devices allow for more throughput and further range, where both are very useful for my purposes. They also have no need for specialized components like a "coordinator" in the zigbee setup, which I really do not want to require. From this is seems as if the XBee DigiMesh may be my best option. Now I just have to see if there would be a reason to go with Point to MultiPoint instead.