My intention was to replace an RS-232 interface. While operating in transparent mode, and playing with a few configuration parameters, and with even the smallest message size, I can only achieve message rates of 10Hz. Is it possible to achieve higher rates?
If possible, within the modem configuration tab in XCTU please save the profile of the firmware and parameters you are using, then attach that file to a post. The first question that comes to mind is are you using broadcast mode or unicast? Next question is, have you changed the “RO” parameter? Once I have a look at the firmware profile I might be able to help.
Thanks for the quick response! I think I’m sending unicast, but I suppose you can confirm that. I’ve messed around with RO quite a bit. I tried 0, the message length, half the message length, etc., and got about the same results. The RSSI looks really good.
I also noticed some large latencies, depending on the configuration.
What kind of rate could I expect?
Please see attached.
I thought you were using the Series 1 since you posted under 802.15.4 but you are actually using the ZB firmware which is Zigbee compliant mesh. What this means is that some of your overhead is toward meshing. The RF data rate is static at 250Kbps but you can only use a portion of it for your data transmission. The baud rate that you can set in the firmware is only used to interface to your device and will not change the rf baud rate. If you were using the series 1 xbees then you could achieve a much higher data rate since it a true point to point and is not mesh capable. One suggestion that will help you out dramatically is to change your end device to a router. With the firmware you are using the end device has to sleep. Currently it is set to be in cyclic sleep (sm=4) and sleeps for 320 ms (sp=20, 0x20 x 10ms), but if you send data to the radio the radio will stay awake based off of the “ST” parameter. I suspect what you might be encountering is that the first packet of data you are sending is being buffered until the “end device” radio wakes up. After it wakes, then it stays awake until the “ST” timer expires. Using the router firmware you are not able to sleep the radio but you might have better luck with it. If this still does not help much I would suggest getting the series 1 Xbee to do the job. Also, you do have the parameter set to unicast.
Topic moved to correct forum…
Thank you for you timely responses. Sorry, I just returned to this issue.
I understand the difference in data rates.
It looks like the end device was sleeping for 100 ms, thus my 10 Hz limit. Changing the end device to use router firmware helped with this problem.
I’m still having trouble reaching a more desirable rate of 50 Hz.
I conducted a test where I removed the two modules and hardwired my two devices together, to rule out the rest of the system again. I’m using an FTDI chip which creates a 2 ms latency when receiving data, but otherwise, latencies are low and a 100 Hz message rate performs very well.
When returning the two modules to the system, and running at 50 Hz, latencies become very erratic. I see 23% missed messages, and the ones that do make it are on average 20 to 60 ms old. Is there anything else I can do? Are these modules backwards compatible with other firmware, such as the point to point?
Message was edited by: chrispalo
Message was edited by: chrispalo
.
Do you have the DH and DL commands set to UNICAST data? The DH and DL commands on the coordinator are default to 0 and 0xFFFF respectively, which sends broadcast transmissions. Broadcasting in a mesh network is slow and bandwidth intensive and should be avoided. The DH and DL commands on the coordinator should be set to match SH and SL on the router in order to send unicast data. What are your DH and DL commands set to on the coordinator?
(DH and DL on the router default to 0, which is defined as an address of the coordinator, so the router sends unicast data to the coordinator by default.)
Yup! Coordinator addresses router, and router addresses all zeros for coordinator.