xbee gets overwhelmed, goes home

Wireless & IoT
1

Hi all,

Yet another example of xbee lost packets here. I’ve looked at all the suggestions made over the past year, and still am a bit at a loss.

So here’s my situation. First hardware: xbee pro series 1 attached to mac via sparkfuns usb explorer. 2 end devices, series 1, non-pro versions. arduinos attached to each end device. All in API mode #1. Baud of end devices = 57.6k to arduinos, baud between xbee and mac is 115.2k, 2 stop bits.

My problem is the controller is getting “overwhelmed” and will suddenly stop passing along packets to the mac for 250-500ms. The pattern repeats 10 seconds, then 20 seconds, then 10 seconds, then 20 seconds, etc. For the tests I am doing now I am sending a 12 byte “payload” from each end device, ideally at 20Hz, but I’m still getting issues even at 10Hz. If I run each of the end devices by themselves, no issues except maybe a dropped packet every couple minutes. In other tests I’ve sent close to the max packet size of ~80 bytes at 20Hz and no issues (i.e. throughput doesn’t seem to be a problem). The problem is when I send data from 2 devices. I’ve been doing math on the payloads and throughput and think I’m well within limits: let’s say each end device is sending at 20Hz, so if we add say ~12 bytes of extra info for the API mode, that’s 25(bytes)*8(bits/byte)*20(Hz) = 4kbps per end device, or 8kbps total (I think the math is right, yes?). If so, that seems well under the maximum of 80kbps. Changing the baud on the controller doesn’t have any impact…I’ve tried 115.2k, 57.6k and 38.4, on down… 1 stop bit, 2 stop bits… without much luck.

Again, the problem seems that the controller just gets “overwhelmed” and stops passing data to my mac. But I’m not sending that much data (am I?). This certainly seems to go against others experiences, so for the moment I am assuming it is still my fault :wink: Could I be missing a setting on the modem? I’ve played a bit with the RN value (random delay slots), but haven’t had any success there either.

Any advice, even if it is to say “you can’t do that” (although that we be very very sad), would be greatly appreciated.

Thanks,

David

2

Do you have flow control? RTS/CTS or XON/XOFF? On the sending unit, CTS will go false a dozen or so bytes before the XBee’s buffer fills. YOU must immediately stop sending. Or you can do the same concept with XON/XOFF if your data is text, not binary.

Is it implemented correctly by you?

with wireless, the channel capacity (speed) varies widely, according to the fleeting delays due to interference, or, in CSMA systems like 802.11 and 802.15.4, there will be delays due to clear channel assessment (CCA) - say, WiFi or other signals are intermittently present. Some non-packet RF can cause lots of CCA delays, such as an analog CCTV camera in 2.4GHz, or a microwave oven very nearby, a cordless phone too near, etc.

No communications channel, IP with UDP or 802.15.4, can deal with an input data rate higher than the channel’s capacity.

Also, older versions of series 1 XBee firmware had a bug in flow control. It was corrected 1-2 years ago as I recall. If you have series 1B, not the original series 1, this may not apply.

Flow control is up to you - it’s isn’t magic.

And check the firmware rev level.

Sending with two devices… this is where A and B send to C and A or B may wish to transmit at any time. If A cannot hear B’s transmission, then they will occasionally have collisions due to CCA failure. This is the hidden node problem. Happens in WiFi too. The solution is to have the application program protocol arranged to prevent this. In WiFi, it’s prevented by enabling RTS/CTS over the air: where A does RTS to C, C grants, A sends and releases. Meanwhile, B heard the CTS from C and does not transmit. This is how WiFi can prevent hidden node failures adn problems with 11b/g/n coexistence. But few products implement it. And with 802.15.4, you can do the same, but in your application - it’s not inherent in 802.15.4.

Even if A can hear B, on occasion, both with do CCA simultaneously but transmit in collision. The 802.15.4 MAC Layer ACK (you should enable this) often but not always sorts this out. But again, your application layer needs to cope with these things. Happens in most wireless systems that use point to multipoint.

Dropped packets: These are inevitable in wireless. YOU must have an application that can recover via ignoring the error or having the sending application re-transmit.

3

Hi stevech,

Thanks for the reply. It is very much appreciated.

Couple questions for you:

For flow control, I am watching the CTS pin on the xbees working as end devices. Is this right? I’ve turned on CTS (D7) and have never observed it go high during these episodes. Am I watching at the wrong end? Wrong pin? Does the controller send a message to the end devices saying it’s near capacity?

Lost/dropped packets I can handle…it’s when the controller xbee just stops for up to a second before resuming…and as I mentioned above, I must not be watching the right pin to know if there is an issue. And the 10 vs 20 second pattern just seems odd to me.

Firmware is most recent 10CD. Hardware version is 1742.

Thanks,

David

4

CTS is clear-to-send. It is an output from the XBee to your microprocessor.

It is an input to the microprocessor, i.e., you can’t alter it. You must have it wired from the XBee to the PC or microprocessor. And the I/O pins programmed properly for this. You need the microprocessor to support in hardware, CTS flow control, in the UART. Otherwise, you have to do so in your own UART handler.

On PCs, you’ll need to choose hardware CTS flow control in MS Windows.

You don’t need hardware flow control if you can control the data volume you send so that the buffering within the XBee never fills. Exception can be when there’s a lot of delay in transmitting wirelessly. This will happen on occasion, e.g., you sent some packets but they cannot be transmitted immediately because (1) the XBee is waiting for an 802.15.4 ACK to a prior transmission (assuming you prudently have enabled use of ACKs in the config), or (2) the CCA is failing due to interference.

Per 802.15.4, when the receiving side gets a bit error, it simply does not ACK (again, assuming you have ACKs enabled). The sendor must time-out and retransmit up to n times. The timeout is programmable. IIRC, the default timeout is a small fraction of a second. But if you keep sending data without using CTS, the buffer in the XBee may overflow.

5

Interesting thread… I haven’t yet tried something like this, but I wanted to run a test with multiple nodes talking to a single coordinator, let’s say 6 to 1. In order for the coordinator to be able to relay all the messages to the computer, we need serious hardware flow control, is what I’m hearing?

6

Hi stevech,

Just wanted to thank you for your replies here. I had ack turned off in an effort to cut back on traffic…and also because I hadn’t written any code to handle the response. Simply turing on acknowledgements in my API packet, even without adjusting my code to act on the response, has vastly improved…in fact almost no dropped packets. Perhaps doing this has activated a feature in the xbee itself?

I now have code that is waiting for the ack before sending the next packet, however with my current setup this has proven to be a bit problematic due to the sensor I am using (Ocean-server digital compass). The system is an xbee series 1, arduino pro mini, and the aforementioned compass (OS-4000T). xbee is connected to the mini’s UART pins, and am using the “newsoftserial” library for the arduino to turn 2 digital pins into serial ports to talk to compass. The setup works fine, however there is competition for the limited processing power of the microcontroller when packets arrive at the same time on the UART Rx pin and the software Rx pin, and this itself is only an issue because the compass cannot be polled…it sends data as soon as it is powered. Anyway…what this means is that sometimes the ack is lost because the mini is busy handling the compass data…meaning I need an ack for the ack. As long as the UART pin is available to receive incoming packets, then acks work great. I only mention my situation just in case someone had any pointers from a similar experience. If I come up with a solution, I’ll be sure to post it here.

Thanks again for the advice!

Best,

David

7

MAC layer ACKs take a tiny amount of air time and improve the frame error rate a lot, but as you know, your app. should deal with uncorrectable lost and errored frames.

Not sure what you mean about the mini and ACKs. You must be speaking about application layer ACKs rather than the MAC layer ACKs done automatically by the 802.15.4 protocol within the XBee.

Good luck!

8

Yes…app layer ACKs wrt the arduino mini. i.e. if something doesn’t get thru, being able to react to it. If I didn’t have this compass in the mix it would be a lot easier.

Thanks again!

David