Transmission crashes at 115200 bits/second

XBee & XBee Gateway XBee - 802.15.4
1

Hello everyone,

Something strange is happening to my Xbees. I have one coordinator, plugged on the PC, and one end device linked to the UART of a microcontroller. All of the UARTs are configured to run at 115200 b/s as the baud rate.

I am using the API mode, and my operation is quite simple : my microcontroller sends an API frame (TX request) to the end device Xbee once every 5 ms. The RF Data of the API frame is 20 bytes long, so count 20 bytes + 5 bytes + checksum byte = 26 bytes total frame lenght.

So I’m running my application, and it goes fine in the beginning. But after a (random, more or less) while, the communication stops, and the only way I found out to get it working again is to unplug the Xbee (end device) from its base and to plug it back in : then the transmission starts again, and crashes inevitably a certain time after…

What I’ve tried to avoid this : take back the UARTs’ speed to 57600. At that rate, I haven’t had any problems. Fine, but I have to make it work at 115200, for certain reasons.
I’ve tried to reduce the lenght of the data in my frames. It helps : It does not seem to crash under 10 bytes of RF Data for example (or maybe it would take much more time, dunno).
I’ve tried to introduce micro delays between the UART Tx routines, but it didn’t help that much.

And eventually I’ve wired the CTS/ RTS hardware flow control system, but it didn’t help much either.

So I’m really out of ideas by now, although I am quite new to Xbees…
So if you have any suggestions, debug plans, ideas, if you have ever experienced such problems or if there is a known issue at that level (?!), please, please let me know!

Any help would be really appreciated!

Regards,

Kom.

2

The short answer is to configure the PC to use two stop bits in its transmissions.

The much longer answer is in my fairly recent post “Using the XBee at 115,200 baud”, which you’ll find in this forum.

Hope that helps.

3

Thanks for your answer.
I read the whole poste and I found it very interesting. But it would mean that my problem is located between my coordinator Xbee (plugged on the PC via USB adapter) and the PC. Therefore, the only parameter to change would be the number of stop bits in the PC settings tab of XCTU.

if the problem is here, I don’t get why unplugging/replugging my Xbee (end device this time) solves the problem temporarily.

I tried to switch to 2 stop bits, it didn’t solve my problem. But maybe I misunderstood?

Thanks again!

4

It sounds as though you understood correctly, so it’s strange that it didn’t work.

Are you running a different program to X-CTU when the errors happen? I’d expect changes made to the serial settings from within X-CTU to be reset when it exits, so could that be what’s heppening? A separate application would need to change the settings for itself, and then for nice behaviour towards other programs it would want to undo the changes on exit.

You have the other XBee connected to a microcontroller. What is the clock speed of the microcontroller itself? If it’s 16MHz or a multiple of that, then things at that end should be fine. Otherwise you may also have to adjust settings at the microcontroller end.

As for unplugging the end device (ie at the microcontroller end) that could give added weight to the clock speed question. Alternatively, since the errors would be expected to be fairly random, it might only seem that the unplug/replug is what fixes it. Does unplugging and replugging the coordinator have the same effect?

Another suggestion: if you’re transmitting a packet every 5mS that sounds rather fast. In the 802.15.4 product manual on page 13 it recommends not to go lower than a 20mS interval when sampling I/O lines, so I guess the same could apply to your application. For the sake of experiment, maybe you could see what effect it has if you send packets at a slower rate.

Last question: what firmware version is running on your XBees?

5

Well I came out with two solutions.

My clock on the PIC is 72 MHz, which is pretty fast, but not a multiple of 16M.
So I tried to put the UART on the PIC in 2 stop bits mode, and that did the trick, no crashes anymore.

And I found out that setting it back to 1 stop bit, but increasing the UBRG (the register that generates the baud rate) by one would do the trick, I haven’t observed any problems so far.

I run XCTU, at least on the Xbee side. the terminal is real fast (much faster than docklight for example), so for my 5 ms… About that, I read about the 20 ms, which is pretty surprising sine I have a Xbee with ADC sampling and sending every 5 ms too, and it works fine. ANyway I gotta stick to that kind of rates, so… :slight_smile:
I am using firmware version 10A5.

6

Glad it worked.

If UBRG is the clock divider value, and if (big if) it works the way I’m guessing it works, a value of 39 should be optimal. Is that what you have?

You might also want to consider upgrading the firmware to 10CD, as there have been a number of improvements since 10A5. It could save you some grief further down the road.