I’m using the series 2 xBee modules, with the ZB AT firmware (one coordinator and two end devices). I just want to do a simple experiment for now: each end device has the coordinator’s address as the address they want to talk to, and then each end device sends data to the coordinator.
What does the data look like on the coordinator’s end? Are the two data streams from each device “mixed” and then the data coming out the coordinator is just from both of them? Is there any way to differentiate between data coming from each module?
Thanks for your help,
Cesar
edit:
From some reading on this forum, it seems like I want to use API mode, since the “Transparent mode” is really more of just a one-to-one serial line replacement thing. However, do I still have the same problem with API mode? As I understand it, I’m still going to be receiving streams of bytes in API mode. Will the xBee firmware take care of making sure the individual API mode packets don’t intersect each other?
you can use AT commands to set the destination address (DH:DL), then send some data, then use AT to change DH:DL and send data to some other node. And vice-versa.
The API mode is no different, you still have to set DH:DL.
in peer to peer networking DH:DL are the MAC address of the addressee (destination). There need not be a PAN Coordinator or beacons.
In other topologies, the PAN Coordinator is not “the gateway” or “router”
stevech:
you can use AT commands to set the destination address (DH:DL), then send some data, then use AT to change DH:DL and send data to some other node. And vice-versa.
The API mode is no different, you still have to set DH:DL.
in peer to peer networking DH:DL are the MAC address of the addressee (destination). There need not be a PAN Coordinator or beacons.
In other topologies, the PAN Coordinator is not “the gateway” or “router”
Hi stevech, thanks for your reply, I think you slightly misunderstood my query. If I have two end devices simultaneously talking to one coordinator, for example one device writes “Cat” and one device writes “Mouse” repeatedly, then the coordinator might see stuff like CaMouset or something like that, with the characters interfering with each other. I’m wondering if API mode will fix that.
As far as your original reply goes though: is there a way to change to peer-to-peer at will? It seems like the ZB firmware I am using just has COORDINATOR, ROUTER and END DEVICE…
for peer to peer - it’s very clearly described in the user manual from Digi.
Configure all the XBees the same.
for messages to the coordinator. You need your own high level protocol. For example, put in the data you send a node ID or name. Then you don’t care how the transport layer works. The receiving node looks at the payload data to see who sent, is it a re-transmission for error detection, etc. Communications 101 stuff.
I prefer peer to peer if I’m not going to use meshing. Much simpler to get rid of PAN coordinators if your links are all one hop.
If you purchased XBee series 2, you are limited by the fact that this is intended to be ZigBee mesh only, versus using series 1.
Ok, let’s say end device 1 sends a packet with a header that includes node address, like API mode does by default. End Device 2 sends a packet with another header. Both are addressed to the coordinator.
The coordinator, does he see the two packets interfere with each other? That’s all I am asking. I.E. if they’re both sending roughly at the same time will the packets arrive in pieces at the coordinator? If so, then I don’t see how to stitch them back together.
Graphically:
End Dev 1 sends: AA BB CC DD repeatedly, assume AA is the node address and the rest is data, checksum, etc
End Dev 2 sends: 11 22 44 88 repeatedly assume 11 is node address rest is data, checksum, etc
API mode will solve your problem. In API mode, each ‘packet’ of data is tagged with the source address. i.e. you’d get this:
‘Address 01, 4bytes: AA BB CC DD, checksum’, ‘Address 02, 4 bytes: 11 22 44 88, checksum’
Obviously thats not literally what is sent over serial (it’s binary for a start, read the manual, it’s very well documented)
Note that in API mode there is no need to send the ‘node address’ as data, it is intrinsically sent along with the payload data (as the source address)
There seems to be a workaround solution to do it with transparent mode which I want to try.
I think that I can send one byte data as 2 bytes.
For example:
to send 0x41 from End Point 1,
send 0x14 0x11 (the first 4 bits identifies the node)
to send 0x4A from End Point 2,
send 0x24 0x2A (the first 4 bits identifies the node)
That way I can encode 16 nodes.
Also I assume that the order of received bytes from one node doesn’t change. But the bytes from different nodes may interfere with eachother. The receiving node (coordinator) is responsible for decoding the bytes by seperating the node identifying 4 bits, and the data bits.
There seems to be a workaround solution to do it with transparent mode which I want to try.
I think that I can send one byte data as 2 bytes.
For example:
to send 0x41 from End Point 1,
send 0x14 0x11 (the first 4 bits identifies the node)
to send 0x4A from End Point 2,
send 0x24 0x2A (the first 4 bits identifies the node)
That way I can encode 16 nodes.
Also I assume that the order of received bytes from one node doesn’t change. But the bytes from different nodes may interfere with eachother. The receiving node (coordinator) is responsible for decoding the bytes by seperating the node identifying 4 bits, and the data bits.
yeah, i was thinking of doing something like this. it's a cool idea but doubles your bandwidth. then again so does API mode unless you write the packets yourself? i think. i'm unclear as to how the coordinator packetizes the data. that is:
i have two end devices in AT mode just sending data, and the coordinator has API firmware. it correctly packetizes the data, putting anywhere between 2 to 10 or so bytes of data per packet, kind of randomly. if i were to instead put the end devices in API mode, and create my own packets, with say 50 bytes of data per packet, i’m not clear as to whether that will actually increase the number of data bytes per packet in the coordinator (i wouldn’t think the coordinator would know exactly what full packet the end devices are sending, it would just keep track of the data?)
I will be sending 4 or 5 bytes every 10 minutes. So I think doubling the data traffic wouldn’t be an issue in terms of traffic load or speed.
On the other hand, my endpoints are battery powered and transmitting a byte is a high cost operation in terms of power consumption. So I need to be careful to form a data packet.
I will be sending 4 or 5 bytes every 10 minutes. So I think doubling the data traffic wouldn’t be an issue in terms of traffic load or speed.
On the other hand, my endpoints are battery powered and transmitting a byte is a high cost operation in terms of power consumption. So I need to be careful to form a data packet.
The XBee Series 1 (non-PRO) consume about the same power in transmit as receive.
In most applications, the transmitter duty cycle is so small that the battery life is always constrained by the time spent in receive mode.
As to coding who sent the packet, without using the binary API (don’t attempt the binary API if you are a beginning programmer) …
Can you arrange to put the node ID as a one or two byte value into the data packets you send, followed by the data per se? Of course, then the receiving end can simply look at the incoming data content.
Don’t forget that in peer to peer mode, any node can send to any other node and there need not be a coordinator, or association.
Use AT and add a header to the data to say where it came from (in other words make packets of your own design).
Use API and use their packet structure, which is complete but you have to implement. API has advantages, but is more complex. I am working on a simple interface for sending short AT commands and data.
It is basically an AT replacement for a terminal. There is also a Java implementation for API if you know Java somewhere on google code.
I’m writing in .net C#, I might publish a library in C (for AVR 8 bit) at some point. For now what I want is a Windows program and C# is quickest.
i implemented API mode and everything works great as expected.
about using AT mode – does this not result in interference unless we use the method of tagging every single byte with a pseudo-header? (i.e. use the upper 4 bits for the node ID). i thought of using my own packet format for AT mode originally but even then unless the bytes are all together it will be impossible to tell which byte comes from which node.
I don’t think the type of collision you are worried about is likely to occur.
From the manual (transparent AT mode):
"Data is buffered in the serial receive buffer until one of the following causes the data to be
packetized and transmitted:
No serial characters are received for the amount of time determined by the RO (Packetization
Timeout) parameter. If RO = 0, packetization begins when a character is received.
Maximum number of characters that will fit in an RF packet is received (72 bytes).
The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the serial
receive buffer before the sequence is transmitted.
RF modules that contain the following firmware versions will support Transparent Mode:
1.0xx (coordinator) and 1.2xx (router/end device)."
So basically there is a timeout, then it sends up to 72 chars. So if you had a single byte header you’d get the header then the other chars up to 72 all at once. If you send more than 72 chars you’d need another header. It isn’t really possible probably for the coordinator to get two packets at once (collision probably means you have to retransmit). They call it transparent but probably there is some structure you aren’t seeing, get an antenna a mixer, a microwave source and look :-D…
Yeah but seriously, I think the packetization would make AT transparent mode confusion minimal, if you have a header of some kind.
I think I understand what you are saying. I never actually tried AT mode with multiple senders. However I did find some posts by people who DID and were having this collision problem, and API mode was suggested there too…