I was wondering if anyone had any issues with dropped characters/bytes when sending data from an Arduino to a CPU via xbee? I’m right now doing some tests between xbee and bluetooth, and while I’m lovin’ many of the aspects of the xbee, not so keen on the lost data. Sometimes it’s a space that’s missing, sometimes a line feed, sometimes a digit will be missing. Whatever it is, it ain’t predicable, and it sure ain’t makin’ me happy. If I use the exact same setup, only swap out the xbee for a bluetooth modem (bluesmirf), nothing is dropped.
I’m using 2 xbee radios (series 1, 802.15.4), one set as the coordinator (and attached to my CPU), one as an end device (attached to an arduino). Firmware 1084. Both set up in transparent mode, sleep = 0, packetization timeout = 0. Everything set to 115k baud, but switching everything to 57.6k didn’t show any improvement. Slowing the rate at which I am sending packets from the Arduino down to 10 Hz didn’t help either (not much point in going lower for what I’ll need this to do). Also, for the moment they are sitting only a couple feet apart from each other.
Anybody else experience something like this? It’s obviously not usable like this if I can’t trust the data coming in, which makes me think I have something setup incorrectly! Could this be an indication of RF interference?
Thanks in advance for any pointers. Let me know if providing my saved XTU config files would help.
You might be overflowing the internal buffers on the XBee. I forgot what the actual ceiling is, but at 115K baud, I would think it would be easy to do, especially if the XBee is retrying to send a packet. Have you tried hardware handshaking on the serial line?
Thanks for your input. The max it can buffer is 100 bytes. My packet size at the moment is 29 bytes with lost bytes. I know once I get past this testing phase I’ll actually be sending much larger packets, but am hoping that having set the “packetization timeout” parameter to 0 (meaning it tries to pass along bytes the moment it receives them). Re: hardware handshaking, no I haven’t tried. I need to figure out how to do that on the arduino mini. In all my searches related to the xbee and arduino, there’s never been a mention of hardware handshaking, but will certainly look into now.
Apparently having the most up-to-date firmware also helps (the firmware list I found on digi’s website apparently needs some updating, too). Since updating (version 10CD for those keeping score), I’ve gone from a bad packet every second to none. So that’s quite nice. Other notes from digi’s support included setting the packetization timeout (RO) to 0x03.
I do want to ensure that I always get good packets, so I’m decreasing the baud to 57.6k. And I also want to implement some flow control as per yours (and Ralph’s) suggestion. This can be done on the xbee via the CTS pin (pin 12). When the buffer is close to full the xbee sets the pin high. When things are OK, it sets the pin low. What I don’t know is what to do on the Arduino Pro Mini side. Any advice? Can the CTS pin on the xbee be connected directly to one of the end pins on the mini? Or is this something I need to monitor in software on the mini?
The Pro-Mini needs to monitor CTS and not send any more data to the XBee until CTS goes low. I’m not up to date on the serial support in the Arduino, the library may already do that for you if you specify the pin to use for CTS. Otherwise, you’ll need to poll the CTS input pin and spin your wheels until the XBee is ready for more data.
I have a question for you: Did you have any problems updating the firmware? I’m using the FTDI 3.3v USB to TTL cable. It provides RTS, but not DTR. I had to manually hold the RESET line low on my XBee modules, start the upload, and then release. Otherwise, I would get a “Lost connection with the modem” message. Posts here and on other forums suggest that holding the reset line low shouldn’t be necessary with the FTDI cable. And I did uncheck the RTS on Close option on the driver.
And a question for Steve: I have been using the XBee modules with the wire antenna. I recently received modules with the chip antenna. Is there a preferred orientation of the module for best radiation pattern? With the vertical wire, it was pretty obvious, both radios should be oriented with the wire in the upright position. With the chip antennas, it isn’t quite so clear. My initial take is that the radios should be oriented to provide the maximum surface area of the chip towards the other module (i.e., the XBee module should be vertical instead of horizontal for the wire antennas).
riden:
The Pro-Mini needs to monitor CTS and not send any more data to the XBee until CTS goes low. I’m not up to date on the serial support in the Arduino, the library may already do that for you if you specify the pin to use for CTS. Otherwise, you’ll need to poll the CTS input pin and spin your wheels until the XBee is ready for more data.
That’s really the question that I’ve been trying to figure out, if something is already built into the mini or do I need to roll my own. Seems painless enough to read the CTS pin of the xbee on one of the digital pins of the arduino and implement the control in software. However if it’s already built into the mini somehow…well that would be lovely.
riden:
I have a question for you: Did you have any problems updating the firmware? I’m using the FTDI 3.3v USB to TTL cable. It provides RTS, but not DTR. I had to manually hold the RESET line low on my XBee modules, start the upload, and then release. Otherwise, I would get a “Lost connection with the modem” message. Posts here and on other forums suggest that holding the reset line low shouldn’t be necessary with the FTDI cable. And I did uncheck the RTS on Close option on the driver.
I haven’t had any issues, but since I knew I was going to need another way to connect the xbee to my computer (since I currently use my FTDI cable for uploading new sketches to the arduino mini), I opted for the sparkfun’s xbee explorer, so haven’t tried with the cable. I do have in my notes that some have had success doing the following in order to update the firmware:
RTS (pin 16) << connect to >> 3.3V (pin 1)
DTR (pin 9) << connect to >> GND (pin 10)
but I’ve never tried this, tho, and not really more helpful than your success holding the reset pin low.
Thanks for the info, David. I have some of SparkFun’s XBee breakout boards (not the Explorer), but the boards that I’m talking about are the ones from AdaFruit. DTR is floating (actually pulled up internally, so maybe that is a factor). I’ll have to try pulling DTR low later. RTS is managed by the FTDI cable, and I can see X-CTU toggle it during the programming phase. As I’ve seen a few posts around about this issue without a specific solution, I was hoping to document what is needed to address it.
For what is worth, I checked the Arduino serial code that I have handy, and it seems like polling is the approach that most people take. Check the CTS line before writing to the port, and you should be golden.
riden:
For what is worth, I checked the Arduino serial code that I have handy, and it seems like polling is the approach that most people take. Check the CTS line before writing to the port, and you should be golden.
Sounds like a plan. I just need to figure out a graceful way of stopping the main loop until the pin goes low again, then jumping back in where I left off. Seems easy enough! If nothing else I’m printing a message to the serial port that there is a possible overrun if the CTS pin goes hi…printing the error message once the pin goes low again would probably be useful, too
Usually the UART will raise CTS just before an overflow condition occurs giving the sender time to cease and desist sending data. There is almost always at least space for one more character, so if you check CTS before you write each character, that should work just fine. I know I’m talking in generalities, but if you run into problems, give us a code snippet and I can show you what I mean.
I think im having a similar problem to. I got to Xbee Pro 50mw units on my work bench, one is hooked up a to a USB explorer (not a sparkfun board), and other is hooked up to a sparkfun explorer board, hooked up to a usb serial board.
Anyways, with default configuration, I can send and receive bytes in the terminal, inside X-CTU. My problem is, when my coordinator sends information, the end point will display some of the information sent and maybe 30 seconds later the rest information will be sent. The information I am sending is just text im pushing into the terminal app, and I tried to slowly typing in test bytes which didnt make a difference. I even tried swaping the explorer board with the usb board, that didnt make a differenence, I order 3 xbee units, I tried to set each one up differently, same result.
Funny thing tho, the End point has no problem sending information.
More on whats going on to, im not sure what the leds mean on these boards, I got a blinking led on the USB board, it seems when Im sending data between each unit theres another led RSSI that will come on then turn off randomly. On the sparkfun explorer board same thing happens on the RSSI led…
Sorta lame, not sure what heck im doing wrong, I tried Google this and nothing came up, any suggestions?
30 second delay. Probably not caused by the XBee. But if you think it is, reset the AT register parameters to factory default and reenter the PAN ID, Channel, etc.
The meaning of the LEDs… RTFM.
The blinking LED is probably connected to the Association Indicator function of the XBee. Another LED is likely tied to the RSSI indicator.
