rx xbee data always shifts in the middle of whole rx data

Wireless & IoT
1

Now I am testing two xbee communication quality.

So I transmit 6bytes followed by a 1ms rest at 115200 baud from PIC16F877 to TX xbee. And rx data quality is bad. sometime it is fine. And it is always shifting in the middle of rx data not at the beginning. Moreover it shits twice or five times. One byte one time. So i am in despair.

Now I process and judge rx data quality according tx data value. But in final experiment, tx data value is not fixed and always changing. What should I do?

Can you help me to find a way to solve the shifting in the middle of rx data?

About probable way, I think that a clear frame header is really needed and necessary.

But I don’t know what the best frame header.And what should I do?

someone suggested me to add a parity. And XOR calculation to every bytes sent in PIC code. What do you think of it?

Test result

first 115200 is available.

second the result of Test :

PIC output rest 20ms.

5000BYTE , so error rate=0;

17220byte, so error rate=0;

PIC output rest 10ms.

10140bytes, so error rate=0;

11832bytes, er=0;

PIC output rest 5ms.

12000bytes, move forward.

PIC output rest 1ms.

16200bytes, er=0;

32400bytes,er=0;

then it shifts in the middle of received data.(in attachment);

51000bytes, er=0 after I shift whole rx data.

54000bytes, er=0

104940bytes, er=0 after cut the first part and ending according to tx standard data.

160000bytes, shifting happen in the middle of tx data.

2

suggestions

  1. Use slower, like 38400 baud, not 115K. Remember: 802.15.4 is 250Kbps on the air link but, like 802.11, far less after overhead. Perhaps 80Kbps sustained is realistic. Flow control should make this irrelevant but slow down at first, then go faster if you have one slower case that works. Remember too that 802.15.4 was NOT intended for constant fast data flow.

  2. Ensure your PIC is correctly obeying RTS/CTS

  3. Ensure XBee is configured for RTS/CTS flow control

  4. A year ago, XBee’s wireless serial port firmware had a flow control bug. Do you have a relatively recent version? I’m speaking about Series 1 products.

If the data source were a PC setup for RTS/CTS flow control, rather than a PIC, does the problem persist?

3
  1. Use slower, like 38400 baud, not 115K. Remember: 802.15.4 is 250Kbps on the air link but, like 802.11, far less after overhead. Perhaps 80Kbps sustained is realistic. Flow control should make this irrelevant but slow down at first, then go faster if you have one slower case that works. Remember too that 802.15.4 was NOT intended for constant fast data flow.
I used 57.6k baud.but the result is the same to 115.2k. I also heard that 80kbps is realistic. In my project 48kbps is needed. So at first I tried 57.6k. Then I was suggested to add frame header, so I have to try higher baud. Is 57.6k baud realistic?
  1. Ensure your PIC is correctly obeying RTS/CTS
PIC16F877 is not obeying RTS/CTS. So maybe I need change another PIC? I have thought of PIC24hj12gp201 which has RTS/CTS function. How do you think of it? I have used it, so your suggestion is appreciated and necessary.
  1. Ensure XBee is configured for RTS/CTS flow control
Now I choose HARDWARE in X-CTU flow control tag of RX XBEE. I think that it will work. Is it right?
  1. A year ago, XBee’s wireless serial port firmware had a flow control bug. Do you have a relatively recent version? I’m speaking about Series 1 products.
Now I use it.[http://www.digi.com/products/wireless/p ... module.jsp](http://www.digi.com/products/wireless/point-multipoint/xbee-series1-module.jsp)

On X-CTU there is a hardware selection. I choose HARDWARE. And the other selection are software, none.Xon/Xoff.

But I don’t understand what does “series 1 products” mean?

Can you explain it?

If the data source were a PC setup for RTS/CTS flow control, rather than a PIC, does the problem persist?

Oh, I did use two xbees at two PC with choosing hardware flow control in two X-CTU software. I found that one packet biggest size is a little less than 1000. If I try to send a packet bigger than about 960~990, there is data lost in RX XBEE. And the X-CTU software at TX XBEE is closed automatically.

I wish that you can reply when I sent poster this afternoon. Yeah, I am lucky, you did. Thanks for your care and patience. You are a good people.

Happy new year.

:smiley:

4

To get flow control to work (to prevent buffer overflow), you must use either

  1. your own scheme in your software/firmware

  2. Hardware RTS/CTS. Your PIC must stop sending when CTS is false.

  3. Or software XON/XOFF. Stop sending when XOFF is received by a trans mitting device; read up on XON/XOFF, it’s widely used. To use XON/XOFF, you must have data such that XON and XOFF never occur in the user data.

Without flow control, the receiving XBee will suffer buffer overrun and must discard some bytes. Flow control is your responsibility, as above. As I recall, the XBee series 1 have about 1KB of buffer.

Series 1 XBees are the original XBee modules that use the Freescale chipset. Series 2 are newer and use the Ember chipset and are normally used when you need ZigBee.

I think 57.6Kbps is realistic as an average, but not sustained. And of course, imperfect RF propagation or signal strength conditions will cause errors. If you have enabled CRC checking and ACKs in the XBee, the XBee will do up to x number of retransmissions to try to correct errors. While doing so, data stops flowing, so flow control is needed, and the average speed will be reduced. In weak signal conditions, this is common. Again. 802.15.4 was not intended for constant high speed data like a dial-up modem.

Don’t forget too that WiFi and other 2.4GHz signals can cause interference and delays in clear-channel-assessment in the XBee. So try to choose a channel that’s not near a busy WiFi channel. Or cordless phones. WiFi signals are 20MHz wide. 802.15.4 signals are 2 MHz wide. Look at a channel frequency chart that shows both 802.11 and 802.15.4 channels and their numbering schemes; they differ.

5

First, I have a question.

stevech:
Using a destination address = all ones for broadcast does indeed disable error correction ACKs, and that is of course important if your application does no error checking or lost-frame detection.

Correct. Obviously working with ACKs in broadcast mode would raise some real messes. Per the manual:

You mean that I should use broadcast mode!

The reason is to disable ACK for making sure data received quality.

Can you think like this?

Your reply is expected.

6

Ask:

  1. 115200 can not be used.?

  2. 57.6k can not transmit 56k bitstream?

7

ceibawx:
Ask:

  1. 115200 can not be used.?

  2. 57.6k can not transmit 56k bitstream?

As discussed above, you must use some form of flow control.

I think 57.6Kbps is realistic as an average, but not sustained. And of course, imperfect RF propagation or signal strength conditions will cause errors. If you have enabled CRC checking and ACKs in the XBee, the XBee will do up to x number of retransmissions to try to correct errors. While doing so, data stops flowing, so flow control is needed, and the average speed will be reduced. In weak signal conditions, this is common. Again. 802.15.4 was not intended for constant high speed data like a dial-up modem.