10 xbee’s sending 200 kilobit data packets to an xbee base station
PANID 2:
10 xbee’s sending 200 kilobit data packets to an xbee base station
…
PANID 10
10 xbee’s sending 200 kilobit data packets to an xbee base station
Clarification, there are 10 PANs and 10 base stations in this example.
Due to the fact everything is on the same frequency, and each of the group of 10 xbee’s are sending periodic packets. Sometimes they send at the same time, sometimes not. They just send when a sensor event happens.
If at 2.4GHz, the air link bit rate is 250Kbps. Your net yield, excluding delays in your app, will be about 80Kbps, ASSUMING you are not using ZigBee, but rather, just Series 1 with 802.15.4.
If you have a weak signal, you’ll see timeouts and retransmissions that reduce net throughput.
Consider using peer to peer mode, not end-device to coordinator. Disable coordinator mode. Address packets by MAC address of the desired destination - no “base stations” per se. This will speed up and simplify things.
I would not attempt a constant stream at these rates with more than one transmitter. PAN ID matters not - it’s how many packets per second per channel. 802.15.4 was not intended for high packets (frames) per second. For multiple channels, use a guard of 1-2 channels, to avoid adjacent channel interference. Avoid channels which map to places in the 20MHz spectrum of a very busy 802.11 WLAN; see channel number plans for both '15.4 and '11.
You said “200 kbit packets”. 802.15.4 frame payload is about 100 bytes = 800 bits. If you use ZigBee, it’s much less due to overhead bytes.
If you enable/use CCA (clear channel assessment via CSMA/CA) which is the norm, radios do listen-before-transmit, to reduce chance of collisions and resultant retransmissions for error correction (after a random backoff delay, exponentially increasing; you set the exponent if you wish). 802.11 does the same thing.
lots of XBees per channel is not a problem. It’s the aggregate frames per second per channel that matters.
Sorry, when I say packet, I mean my little bundle of data I’m sending, which takes a fair number of xbee packets to get there.
Ok, modified example.
Say I have a data stream…say a paragraph of text. This data stream will send at random intervals out of an xBee.
I have 10 of these xBees, each with a different paragraph of text, each sending at a random interval.
All of these xBees want to get their paragraphs to a receiver xBee that is connected to a computer where it outputs to a microcontroller where it is processed.
How does this work? I get how packets will get from source to destination, and how collision detection will keep the different xBees from talking over each other, but I don’t get how I can get a full paragraph to the destination xBee without one of the other xBees trying to throw some of their paragraphs in between.
I totally get how a one to one xBee relationship works. I understand how a many to one relationship works if each transmitter just needs to get one xBee sized packet across. But I don’t get how to get a bunch of data streams across all at once.
My bet is in my example I’ll get whole packets into the receiver xBee, but they’ll be from lots of various transmitter xBees. If I want to do what I’m talking about, then I’ll need to basically include a packet number in each of my transmitted packets, and once they reach the destination the microcontroller can handle the task of putting all the data stream sequences back together.
And yes, I’m using 802.15.4 with no coordinator and point to point routing.
The XBee connected to the PC should be running in API command mode. It will send to the PC a ‘frame’ that contains the address of the device that sent the data, the data fragment and other information. Download the data sheets on the XBee modules from Digi Int and look up the API frames.
Then write a program that runs on the PC to receive and decode each ‘frame’ that then puts all the data from each sender into the proper ‘bin’.
the Digi API mode, as said above, allows you to know who sent you the packet (sender’s MAC address).
I have seen donated API processing code. I’ve done it in C.
Sending packets from source to destination, using MAC addresses, in 802.15.4, is just like doing that on ethernet with MAC addresses, and a bit more abstractly, it’s like sending an IP packet with TCP, since 802.15.4 has ACKs for a reliable datagram. Unlike TCP, there’s no flow control or windowing in 802.15.4. That’s a network layer if you need it. Most do something simple in their applications to avoid a complex network protocol like ZigBee or 6LoWPAN.
if you turn off ACKs in 802.15.4, you have something like UDP datagrams - unreliable - you do error correction.
Receive the entire frame and save the entire frame…which includes the sender mac
post process the group of frames and put it all back together.
cool. thx.
You only need to receive at the PC end in API mode.
In the RF link layer the packet already includes the senders MAC even when the sender in running in AP or transparent mode. This is easiest as at the remote modules you just pipe your data in the XBee’s UART (DIN pin) and the protocol takes care of creating the packet for RF transmission.
So if my transmitting end uses transparent mode to send my big fat chuck of data. And I have multiple transmitting ends running at once all going to this one receiving end…
Do I capture all these frames in API mode and then do the post-processing reassembly as we’ve already talked about?
Since I’m putting together so many frames into one big chunk of data in this manner, I should put a checksum in my data so I made sure all the frames come across. And I should put a nice delimiter to show that the last frame has been reached.
Thanks for all the advice so far, this is very helpful.
Ok, I understand everything up to here. But let’s throw out a case which may not be best practice, but just an academic…what would happen.
If my sources are sending out 170 byte packets at random intervals using transparent mode. And my receiver is receiving them in transparent mode. What happens when one of the sources tries to send their packet while the other source is sending?
Does the receiver ignore the 2nd receiver and continue receiving the first packet? Meanwhile, the second source’s buffers get filled up and it starts ignoring the serial stream that is being pushed at it. If this is the case, and the first source’s packet finishes and the second source has already ignored some of teh buffer overflow, the receiver will now receive a partial packet from the second source (and a full packet from the first source).
So in other words, for these larger data streams, using transparent mode will leave me with good data if there is just one source and one receiver. It will leave me with bad data for the second source if two sources try to transmit at once.
Does that seem pretty accurate. I’m trying to not only gauge best practices, but the limitations of the various modes.
If I can get my job done using transparent mode then all the better! It’s really easy to use. Plus, the microcontroller that is receiving this (a parallax propeller) is already busy doing all sorts of other things and reassembling packets is yet just another job to put it through.
API mode will give you one API packet on the serial port for each received 802.15.4 frame. That frame can hold at most 100 bytes, per the IEEE standard.
As to two nodes sending at the same time: IEEE 802.15.4 like 802.11 uses clear channel assessment (CCA). List before transmitting. Delay if channel is occupied. The problem arises if A and B want to transmit at the same time, and A cannot hear B due to RF blockage or distance. This causes a hidden node collision. This happens in 802.11 as well. Such a collision causes uncorrectable bit errors at the receiving end and thus, no ACK frame is sent. The sending units fail to get an ACK, so they retransmit. Hopefully, they do a random backoff delay to prevent syncopation. This hidden node condition might be irrelevant to your use case.
No matter what you do, YOUR application needs enough of a protocol to detect and deal with (ignore or ?) uncorrectable errors, lost packets, duplicate packets and so on. The radio MAC layer won’t fix everything. 802.15.4 does a lot, but it can’t be near perfect as is wired Ethernet or WiFi with the benefit of TCP/IP.
A conservative approach is to give the radio about 90 bytes or less per hunk, then use hardware CTS or delays to avoid overrunning the channel’s capacity.