SparkFun Forums

[Rasico]

This problem is a combination of software and hardware, hopefully someone can set me straight here.

Basically I have two XBees, one is a coordinator obviously, the other a regular router/end device. Each of them is connected to their own PIC18f4520 as USART devices. They can transmit data to each other just fine.

What I want is one device to continuously send a stream of data, very very rapidly (they're both configured for 115,200 BPS). This is where the problem comes in however. When one PIC is transmitting data as fast as possible,the other PIC cannot however receive any data. Connecting the XBee directly to X-CTU via a serial port shows the XBee chip is getting the data without an issue. Slowing the rate at which data is sent resolves this issue, but this is not satisfactory.

I cannot explain why this is happening. If the serial transmit buffer on the XBee is getting full, wouldn't it simply drop packets until I've pulled out everything from it? This is the desired behavior as a few drop packets are just fine, but obviously not getting any packets is a bit of a problem.

If my explanation is confusing feel free to ask for clarification, thanks for your help

Edit: I meant, when one PIC is sending data as fast as it can through the XBee, the other PIC cannot receive any data through its XBee. Connecting that XBee to the terminal in X-CTU reveals that the data is getting through however. Slowing the transmission rate fixed that issue, but I need it to still transmit very quickly.

[Franklin97355]

Are you using any flow control between the pic and the xbee?

[Rasico]

WEll CTS flow control seems unnecessary since the XBee on the receiving end is getting the data, the transmitting Xbee is not causing its buffer to overflow. I do not see how RTS flow control would help. Of course I could be completely wrong, but this seems to be the case.

[Vraz]

It sounds like your input processing code may run too slowly for your data rate and you might be encountering input saturation. Questions:

Which PIC are you using?
What is the clock rate?
What language are you using?
Is the serial input function polled or interrupt based?
Did you implement an input buffer?
What processing do you perform after each byte is received?

115Kbps is not particularly fast, but with a low clocked CPU or with code doing extensive processing, you could run into input saturation problems. Essentially, the code does not finish processing the current byte before the next byte is received (which starts the process over again). With more details, we can better advise you.

[stevech]

WEll CTS flow control seems unnecessary since the XBee on the receiving end is getting the data, the transmitting Xbee is not causing its buffer to overflow. I do not see how RTS flow control would help. Of course I could be completely wrong, but this seems to be the case.

at that speed you will need RTS/CTS. The net bit rate after all overhead is less than 100Kbps. And far less yet when (not if) you get errors due to RF interference, etc.

The PIC itself can be overrun - it may have poor buffering strategies.