Using XBee Pro (fw 1084, hw 1842), what is the best way to send messages that exceed 100 bytes? I thought maybe the transmitting XBee would packetize the long message I was sending it after each 100 bytes, coming out the receiving XBee in the same long stream I started with, but I don’t get anything. I’m running at 57600 bps in API Mode 2 (with escapes).
Any ideas on how to get the XBee to do it, without resorting to breaking up and reassembling the message myself in software?
I’m trying to use XBee to control Christmas lights, and the serial protocol is one of a nearly constant streaming nature at 57,600kbps. I’m seeing a lot of dropped data – even though the RO is zero. Anybody know if XBee can be configured to work reliably with a streaming protocol such as this?
Were you able to get anything on the receiving end when experimenting with packets under 100 bytes? That would be a good place to start, to see if packetization is even the issue in this scenario.
If you don’t get anything on the receiving end, ensure that the DH/DL of the sending unit matches the SH/SL of the receiver, and vice versa if this is a point-to-point scenario.
If point to point-to-multipoint, one side would be set as mentioned above (point), whereas the multipoint end would be set to broadcast.
Results of my testing show that payloads of 100 bytes work, while payloads greater than that do not work. This is in API Mode 1 or 2. The payload is the actual message content, not counting API headers, frame character, length and checksum bytes.
Yes, I’ve been sending and receiving short messages in API Mode 2 just fine for almost two years. I limited them to be short because of what I initially interpreted the manual to say.
But there are two bytes that define the message length, which implies a capability to deal with >255 bytes. When I send the much longer message to the XBee (over 100 bytes) I don’t even get a Tx Status response back.
When using the API (mode 1 or 2) The maximum data payload for the 802.15.4 module will be 100 bytes per packet. If you use the API, you are in effect telling the radio that you want to packetize your own data. Thus, if the payload happens to be larger than 100 bytes in length, the host will be required to break up the message into multiple API frames.
When using the API frame, since the host will dictate how the data is packetized (with the appropriate API frame restrictions of course), other packetization paramters, and even addressing parameters (like RO, DH and DL) will be ignored, as only the options and addressing etc, will be set in the API frame that you send.
For more questions regarding the limiations on packet size of the API frame, please refer to API tx frame in the product manual.
Just a thought.
Does your serial interface to the Xbee use RTS,CTS?
If not then you could be over running the Xbee buffer.
I second waltr’s thought: you’ll certainly want flow control (either RTS/CTS or XON/XOFF) if data can arrive at a high rate.
If I understand your description correctly though, I don’t think flow control will be enough. You seem to be saying that the average data rate is a significant fraction of the 57600 baud rate - the XBee is actually quite a low bandwidth device, so I’d be surprised if that was sustainable.
Still, you should at least see an improvement if you set the value of RO to something other than 0. The zero value tells the module to transmit every byte as a separate RF packet, which is a very large overhead. (Check out the command in the product manual.) The default value is 3 and this suits most purposes, but you could also experiment with higher values. With any value other than 0, a packet will be transmitted when 100 bytes have been received or when the RO delay has elapsed between received characters.
Perhaps you could tell us a bit more about the application? The Christmas lights that I deal with every year are a lot less sophisticated than yours sound to be (heck, in our town we just hang 'em up and plug 'em in), but I find it hard to see how any but the most elaborate of installations can need such a high data rate unless maybe we’re talking remote-controlled laser light-shows. What I’m trying to get at is that maybe it’s the protocol that needs examining.
All good thoughts – thanks. I have about 10,000 lights this year, all computer controlled using a Windows app called Vixen. (www.vixenlights.com) I’m one of thousands of hobbiests around the world who mess with this stuff, and we all seem to converge at www.doityourselfchristmas.com where we trade ideas, stories, problems, etc. I’ve been working on designing a wireless adapter for some of our light controllers, and am trying XBee because part of our goals are to keep the hobby affordable. One of the popular light controller systems we use is called the “Renard” system. Renard controllers use multiple cascading PICs to decode the serial signals and assign them to the designated “channels.” It allows dimming, blinking, and daisy-chaining from one to the next so that potentially hundreds of different channels can be controlled individually. A single channel could be one light, or a single string of lights, or 5 or 6 strings of lights etc.
The Renard uses a serial protocol (at 8,N,1) run through through Cat5 wire, and while space doesn’t allow completely explaining how it works, to be able to fade (dim) lights up and down slowly, or quickly, or flash, etc. each channel gets refreshed multiple times per second, hence the 57,600 or 115,200 bps rate is required. Because the lights are also usually synchronized to music, the refresh rate really needs to be timely. When designing the light displays in the Vixen software, a common timing interval used is 50ms, which means that for a single string of lights (e.g. one channel) to be lit for one second, that channel needs to be refreshed 20 times. Multiply that out by a couple hundred channels and, well, it’s a lot of continuous data…
The Renard’s protocol works fine with standard RS-232 or RS-485 (for long cable runs) because the PICs on the controllers are plenty fast enough to keep up with the data stream even at 115,200. Consequently there’s no need for flow control and the Renards don’t use one. Therein lies the problem. The transmit/receive mechanism built into the XBee radios just don’t seem to be able to handle the throughput – or at least, I haven’t figured it out yet. I firmly believe it’s a buffer overflow issue, causing dropped packets at (probably) the transmitting radio but perhaps at the receiving end, too. While the baud rate is programmable in the assembly code the Renard PICs use, going slower than 57,600 severely limits the functionality and smoothness of the light effects and is really not acceptable.
I’ve considered overclocking the processor on the XBee, but I haven’t yet inquired to Digi how (or if) that can be done. The clock may be preset via hardware instead of using a multiplier in the microcode, and I really know very little about the processor the XBee uses.
I have experimented with the RO – tried various settings from zero all the way up to 20. Makes no real difference – that tiny XBee buffer just has to be overflowing something fierce. I’ve tried all manner of different settings but the typical result is lost packets, lights that blink or flicker when they’re not supposed to or don’t come on at all anywhere near the exact moment they’re supposed to.
Message was edited by: dirknerkle
Message was edited by: dirknerkle
Message was edited by: dirknerkle
I’m going with re-thinking the protocol.
The Renard seems to depend on a continuous ‘real-time’ stream of data whereas the Xbee (and many other serial protocols like USB) is a packetized protocol. This means the data is collected in a buffer, then packetized for transmission, then send over the RF link, acknowledged (and resent if the ack was not received), disassembled then out the serial port.
The MAC and physical layer in the XBee is 250kbs but is less on real through-put due to overhead. If the RF link is solid (no retransmissions needed) then I would not expect a through-put higher than 115k baud and much less if retransmissions are required.
Also due to the non real-time reception a straight serial protocol would have timing jitter. A protocol with timing information may be needed.
I think that Blue-Tooth may be better for your application. It has a higher through-put (2Mbps).
Check the Blue tooth devices at SparkFun
http://www.sparkfun.com/commerce/categories.php?c=115
Yes, I agree - this sounds well beyond what you can expect an XBee to reliably deliver. Since it’s coupled to the Vixen system, I guess a change of data protocol isn’t really an option. That leaves a change of transmission medium - eg Bluetooth, as waltr has suggested.
I’d suggest that a chat with the fine folks at Digi support would be a good idea at this stage. First for them to confirm or deny the opinions we’ve given, and second because they may be able to suggest an alternative solution. I’m not familiar with their non-XBee products, but it has to be worth a go. In your shoes I’d still try for a Digi solution first, because their level of support really is rather good.
Edit: I wrote the word “c h a t” above, and the forum software changed it to **** for display. Puzzling.
Message was edited by: johnf
Thanks so much for your guidance. I’ve considered bluetooth, and that may eventually be the direction I’ll have to go.
I know XBee wasn’t originally designed to carry this level of streaming data – one of my friends in the DIYC community has created a light controller system he’s named “Helix” and it uses XBees also at 57,600bps. However, he’s also included some flow control in his code whereas the Renard has none. He still runs into dropped packets when he tries to go beyond 64 channels, so it’s looking more like XBee won’t be quite the right solution for us. Some of our members get along fine on 64 or fewer channels, but the majority of our folks have well more than 128. I myself have 380, and some have more than twice that.
I have contacted the Digi tech support folks about the issue and have found their help to be quite extraordinary. They’re responsive and complete in their assistance. The documentation is a bit wanting (at least the considerable amouht that I’ve read) but all things considered, it’s okay.
Thanks again for taking the time to review my postings and making sound recommendations. It’s much appreciated.
-d
I think I added c h a t to a list of catch-words on here, because it was showing up in adult-site spam adds which were getting posted on here. That’s likely why it got the ****.
@admin - thanks! That clears my puzzled brow. In future, I’ll try to be very careful to suggest a conversation instead of a [French for cat]… 
@admin (2) - more seriously, maybe this is a good point for a public thank you for your efforts in keeping this forum clean. I’ve never seen a dodgy post here, which I think speaks volumes for your work.
@dirknerkle - you’re very welcome!
Progress update…
One of the tech support reps told me the XBee can accommodate up to 80kbps of streaming data, and he suggested to use the MM 1 setting that uses NO ACKS to get the “most” performance out of the radio. I coupled this with an RO setting of zero and two stop bits and the radio seems to perform a LOT better. It’s still not “perfect” but far fewer packets are being dropped to the point that there’s still hope that XBee might be a viable solution.
However, I’m encountering a different problem – the transmitting radio just stops – it locks up and becomes completely unresponsive, and the only solution is to reboot it by removing power. There doesn’t seem to be any common reason – it might operate fine for 2-3 minutes, or sometimes 15 seconds, or sometimes a half-minute or more. My testing includes sending exactly the same data each time, and I’ve verified it’s not a power/current drop issue.
Just a wild guess: what are the serial voltage levels to the Xbee? From what I’ve read they should be 3.3V but have found 5V works. I just did this forgetting that the XBee’s are not 5V tolerant. Lucky not for long before my poor memory kicked in and no damage resulted.
Thanks for posting the tech support suggestions and results.
I thought about that. Here’s an interesting thing – 3.26v doesn’t trigger it to transmit at all but 4.37v does! Like you, I found that 5v works, and I’ve been scaling it down from 5v by bits and pieces to get into the suggested range, only to have it fail to transmit at all when it’s virtually dead perfect. I am TOTALLY baffled. BTW… have tried 8N1 and 8N2 – work about the same and it still locks up. Running at 57600bps.
Added comment
I just looked at the 90000976 doc and valid logic high is 0.8 * Vcc or 2.64V.
However in my case, and this is embarrassing, I’m using the SparkFun XBee regulated break-out board. Just looked at the schematic and there is a diode in series with DIN on the XBee. Anode to the Din pin and cathode to the serial in (from a PIC). This would only allow the PIC’s output to pull Din low and block a high. Maybe there is an internal pull-up in the XBee but there is no mention of this in the doc. Just know it worked at 57.6kbaud.
Curious!!!
Maybe someone at Digi can shed some light on this.
I have a pair of the SparkFun USB boards, too – I use their USB programming board.
I’ll bet that diode is a zener and is being used as a voltage limiter/regulator. Interesting.
There is a config setting in the Serial Interfacing section of the XCTU software to set an internal pull-up on the i/o lines, and mine is set to FF, which should turn all of them on. FF is the default. The AT command is ATPR and XCTU says the following about it when the field has the focus:
Set/read bitfield to configure internal pull-up resistors status for I/O lines. 1=internal pull-up enabled, 0=no internal pull-up. Bitfield map: Bit 7 - DIN (P3), Bit 6 - DI8/SLEEP_RQ (P9), Bit 5 - DIO6/RTS (P16), Bit 4 - DIO0 (P20), Bit 3 - DIO1 (P19), Bit 2 - DIO2 (P18), Bit 1 - DIO3 (P17), Bit 0 - DIO4 (P11).
BTW, I’m using XBee firmware version 10C8, for what that’s worth…
Thanks for the continued feedback. I’m a relative neophyte at messing with this XBee gizmo, but am learning fast. I’ll continue to play with this for a little while yet, but I’ve already started a bluetooth version, and when the modules come from Mouser, I’ll probably abandon the XBee. I just don’t think it can handle the task.
I checked the diode on the break-out board. It is not a zener but a silicon diode with 0.45V (47k Ohm pull-up) forward drop and no current flow reversed.
Yep, I do have the pull-ups (30k) enabled on all lines (PR=0x1FFF). This explains why the serial worked. SparkFun was smart to install that diode so I wouldn’t burn out the Din with a +5V signal.
Digi’s XBIB-U & R Dev boards have a 10k pull-up on the Din line. A pull-up on that line makes sense in that it will prevent noise from triggering the XBee UART into sending garbage.
I’m also rather new to the XBees but learning fast. Much is from this forum by interacting with other like yourself. Everything seems to be in the document but its not easy finding what you need.