I am using a XBEE-PRO (XBP24-ZB) radio with both an RS-232 XBIB development board and another custom development board that uses a different USB-RS232 bridge. The problem I am describing below occurs on both boards, so I am fairly confident it is a radio issue.
I am having a problem where the radio seems to either be dropping or ignoring bytes when I set the baud rate at certain rates, in particular, to 500,000. For example, when set at this baud rate, X-CTU times out when trying to read the AT parameters. Also, if I enter a frame at the terminal window in X-CTU, I will get a response every time if I send the frame all at once, but if I type the bytes of the frame one at a time, most of the time I will not get a response. This does not happen at other baud rates.
I have bypassed the radio with wires and verified that the bytes are not being corrupted. And I have read the baud rate back from the radio to verify it is exactly 500,000.
Anyone have any info on what this may be? Is there a bug in the radio firmware that I do not know about?
500 thousand baud is an incredibly high rate, and it would be surprising if anything worked at that speed. Why would you want to use such a high baud rate?
Yes 500k is pretty fast, but the documentation purports that the radio supports speeds up to 921k. I am working on a project that requires fairly substantial throughput rates, so the 500k is not extreme for me. And yes, I know the current radio bandwidth is about 250k but we are not designing for that limitation just yet.
Also, I forgot to mention in my first post that the radio works fine at 921,600, that is, it doesn’t demonstrate the problem I am describing.
Have you looked to see what supported baud rates are available for the computer’s UART controller you’re using? Most are maxed out at 115.2k baud (1.8432 MHz source clock), while most USB UART adapters will max out at 230k baud (3.680 MHz clock source). When dealing with UARTs you have to pick the baud rate of which both UARTs connected can communicate with the minimum amount of error rate while at the same time the fastest the two will go.
So in the case of the XBee board it might be at exactly 500k baud, but your PC UART controller might actually be at 460.8k or 691.2k (some round up or down the clock divider registers) baud which is pretty high error rate between the two. This is assuming a 22.118400 MHz clock source.
So, say
Clock_Src = 22118400 [22.118400 MHz clock source]
((Clock_Src / 16) / 500000) = 2.7648
Since most UART controllers can’t take fractions as apart of their clock divider registers (FTDI chips are the only ones I know of that can to a point) then it must either be rounded up or down:
2: ((Clock_Src / 16) / 2) = 691200 [691.2k baud]
3: ((Clock_Src / 16) / 3) = 460800 [460.8k baud]
I looked at the XBee datasheet and it didn’t say what clock source it uses, but I could just assume a 14.7456 MHz for calculation purposes if my math is right for 921.6k max baud rate:
921600 *16 = 14745600 [14.7456 MHz] and cut it in half:
((14745600 / 16) / 2) = 460.8k baud.
That should work perfectly if your UART you’re using for your PC side can support that exact baud rate too.
So, you need to figure out the clock source for both UARTs and figure out the fastest, yet the most error free rate of communication speed. I hope I didn’t confuse you further and gave you the information necessary to resolve your problem.
I am highly confident that the baud rates of my controllers match that of the radio, unless the radio baud rate reported (500k) is not the exact baud rate configured.
You are correct that the standard controllers max out at 115.2k. I have verified this. However, I am using two different USB-UART bridges. One has the Silabs CP2103 chip, which has a maximum supported baud of 1 Mbps. The other is the FTDI FT232 chip, which also has a maximum baud of 1 Mbps.
Having looked at the supported baud rates of both chips, they seem to indicate they support precise baud rates at 500k. And, as I said in my first post, I have verified this by replacing the radio with wires to form a feedback path and verified communication at 500k. And to ensure that they are not in fact configured for, say, 460.8k, I tested one end at 500k and the other at 460.8k and verified communication was not successful. So I have high confidence that the controllers I am using are, in fact, at 500k.
I wouldn’t consider this an issue if the radio presented the same problems at 921.6k. But the fact that the radio communication works fine at that baud rate (with the controllers I have) leads me to believe that this is a radio issue itself, and our target baud rate is 500k for this system. If the radio can not support that rate, that is fine, but the documentation says otherwise, so I’m trying to find out the source of this odd behavior at 500k.
Yes the radio can interface at up to 1mb with a fixed RF data rate of 250kbps. Once you add in the Mesh protocol over head, you are down to a streaming limit of 30kbps at best. So unless you are using flow control, you are most likely having a buffer over run.
My communication is limited to host-radio (for now). The problem manifests itself even if there is no radio-radio communication happening. And, as I said before, there is no problem at the higher baud rate of 921,600.
I loaded the radio with the latest version of the AT firmware and did not have the same issues at 500,000 baud: AT parameters would read using X-CTU (using the Read button on the Modem Configuration page), and using the terminal to input an AT sequence worked fine, assuming I entered everything within guard times. The issue is only apparent with API firmware.
I started a case with Digi Support and the only useful response I have received so far is that the support guy gets ~75% success reading parameters with X-CTU at 500,000 baud, API firmware. Hopefully I started a progression that will have a “bug” fixed for the next release.
Perhaps put it on a storage scope and get a visual on the outputs of both units.
I had a problem with my platform output was lagging and had to up the values that “should work out” with values that were “correct”. The only way I could find this was through an O’scope.
I have tried various rates right around 500,000 with no success. I haven’t looked at it on a scope, but as I said preivously, I have replaced the radio with a simple link to another serial device operating at 500,000 baud and have no dropouts at 500,000. And again, the problem only manifests itself with API firmware - it is not present in AT firmware. I am 99.9% confident the problem is not in my system but in the radio itself. And again, a Digi support technicican reports that he has 75% success with an API firmware load at 500,000. Why is his success rate not 100%? This is a firmware bug, plain and simple.
I just suggested the scope so you could see if the clock ticks were lagging or too fast. Sometimes that is the only way I can find the real problem in the past.