XBee byte drop rate

Wireless & IoT
21

Ok, that’s the confusion. Many feel it is better the start a new thread and include a link to an old thread if it has relevance. But then again what do I know about forum protocol. Answering your question here is fine with me.

All asynchronous serial (UART) uses one start bit and isn’t settable. For the PIC set the USART to Async, 8bit and set the baud rate. The mid-range PICs do one stop and no parity by default but check the data sheet for the dsPIC30 (I’ve never used one of these) to be sure.

The XBee is only 8 bit data, no parity, 1 stop (8N1) but do check the baud rate. I’d suggest to leave the XBee baud alone to start and just set the PIC’s baud. There is a bit more than just setting a register in the PIC for baud. Download the Mid-range reference manual for a better description of PIC’s USART then carefully read the dsPIC30 data sheet for differences.

If you have never used a PIC USART I’d also suggest to not use the XBees to start. Wire up a MAX232 to the PIC and connect directly to your PC. Once this works then insert the XBees. It is much easier the debug one set of issues at a time.

good luck and have fun.

22

Yeah, i agree with the new thread thing , though i wanted to ask lupin some questions that’s why i started here.

Looking through the xbee data sheet, i noticed all AT commands expect hex values; so from that, i am wondering what format the xbee transmits data in? Are all transmissions also in hex? meaning if i put in a decimal number from the transmitter-PIc side into the UART, will i get a hex out at the receiver-PC terminal end? or do i have to put in a hex in at the UART and then get a hex out?

I will eventually try to read the PC serial port/usb port with matlab (which is what lupin was already doing) and was wondering about formatting issues with the transmission once i read the port with matlab (what i would have to do to get decimal numbers from whatever format the data received was in). I am simply trying to plot a graph with the received data in matlab

23

Hex and Decimal is just a way to represent a binary value and all digital data is binary. The XBees will pass what ever binary data sent into the serial port (UART) from one unit to the UART output on the other unit in what is called ‘transparent mode’. So the serial interface (UART) is 8 bits of binary per byte that could represent ASCII or raw binary data (PIC’s ADC output) or the bytes making up a floating point number.

The idea of ‘transparent mode’ is way I recommend getting the PIC’s UART working directly to the PC. Then the XBees replace the cable and serial communication works as if the cable was still there. For starting use a terminal program, Hyperterm or Terminal tab of X-CTU since this can show data in hex whereas Hyperterm only displays ASCII.

AT command mode is a person interface and X_CTU does use Hex notation from many of the parameter settings but not all.

24

hi sterling2

In Matlab there are different functions to read data form Serial Buffer enabling different formats.

As long as you (must) know the data format of the sent data of microcontroller there will be no problem since it is very easy with matlab to make data conversion.

the discussion here is irrelevant with BXee drop rate now which is not preferable for forum protocol

25

Right.

When i get to the matlab part of my project, i will start a new matlab-serial-port-read thread or something. I hope you stick around; I will probably have questions to ask! thanks for your help so far.

26

“lupin” Posted: Wed Mar 03, 2010 11:25 am:

Then I chatted with some expert from digi and he told me that with older versions of firmware(embedded software on XBee) it was possible to send bytes from source to sender XBee in 115.200bits/sec. But the sender XBee is only capable of sending bytes in 19200bits/sec in air to receiver XBee continiously. He suggested to update the firmware. With the update, the sender is capable of sending bytes in 80.000bits/sec in air to receiver Xbee.

Then I made the firmware update and changed my code so that it sends data in 57.600bits/sec continuously. In my test application, I send 10240bytes in 57.600bits/sec and checked the received bytes in MatLab and all of the bytes were correct.

Hi lupin, could you please tell me the firmware updates you posted about here? I’m using firmware 1084 on Series 1 module and my timings suggest I’m only achieving 19200bps air speed, which firmware update did the speed increase occur from?

By the way, I was also having problems with baud rates above 38400bps, setting my laptops serial port to use 2 stop bits did work well, but for some applications (e.g. with a microcontroller) this is not always an easy option. Anyone still suffering with problems of baud rate stability at 115200 bps, please look at this thread:

http://forums.digi.com/support/forum/pr … intall,yes

To cut a long story short, set your Xbees to 115200 and your host baud rate to 111,111bps instead and you should be laughing.

Many Thanks,

27

As a follow up, I am using Series 1 Xbee Pro modules (one in an Xbee Xplorer USB unit to my laptop and the other connected to an Arduino that simply time stamps the packet and sends straight back to display on the laptop).

I have tried firmware 1084 (which came pre-installed), 10A5, 10CD and finally 10E6 (currently the latest firmware) and none made any difference in transfer speed whatsoever. After upgrading both units to the same firmwares and testing with each firmware over 100 packets and averaging, an API packet of 32 bytes always takes approximately 24ms to transfer (same in either direction), of which I roughly calculate the following:

Laptop to Xbee - Baud rate 115200 - 320 bits = 2.8ms

Xbee to Xbee over Air - 19200bps - 320 bits = 16.7ms

Xbee to Arduino - Baud rate 115200 - 320 bits = 2.8ms

TOTAL = 22.3ms

This seems consistent with the timing results I’m seeing, but I’m really in need of a speed increase so if it is possible to get these Series 1’s to an air speed of 80,000 bps I’d really like to find out how!

Many Thanks,

28

With software or hardware/CTS flow control, you should achieve at least 80Kbps, in the absence of wireless access delays due to a very busy WiFi on a freq. within 20MHz of the 802.15.4 channel you’re using; these are 2MHz. But you need this flow control so the XBee can double-buffer.

29

Hi, I can’t seem to find much info in the manual about how to implement this, currently I’m not using any flow control. Is it easy to implement this using API2, and if so whats the basic outline you’d recommend for a software protocol?

Many thanks

30

Flow control. To prevent overflowing the serial input data buffers of the XBee. This is the same sort of flow control needed for any communications channel where the speed is sometimes or always less than the speed of the data producer. For example, the use of dial-up modems is the same problem as with the XBee, in general terms.

So with RTS/CTS hardware flow control, just like with a dial-up modem:

On the sending device (data producer), this being the transmit side of a UART-based interface, you connect CTS on the data communications device (equipment) to the sending device (data terminal equipment). The terms are DCE and DTE. These date back to the idea of a modem connected to a data terminal like ye ole VT100. In our case, the DTE is a microprocessor’s UART. When DCE (XBee) can no longer accept data, it sets CTS (clear to send) false. The DTE (microprocessor) must immediately stop sending bytes. Immediately after the one in progress. No more. Nada. When CTS becomes true, the DCE may send 1 or more bytes. Now some UARTs have CTS handshaking built into the UART and you can enable that on out to a pin on the microprocessor, and wire it to the DCE. Paying attention to voltage level standards and data polarity (i.e., “true” means +3.3V versus 0 volts). For this flow control, RTS (request to send) is irrelevant.

With software flow control, instead of or in addition to hardware flow control, we do the same thing but differently. With this, DCE sending data is told to stop using a special byte send by the data consumer - like setting CTS false, but slower. And vice versa for CTS true, using some other special byte. It’s tricky: if all your bytes are ASCII 7 bit, then the XON and XOFF characters in ASCII are normally used. If your data is 8 bit and/or binary not ASCII, it’s more complicated. We’ll not go into that now, but essentially you insert a byte to flag that the user data is user data, not an XON or XOFF.

THE SIMPLEST flow control methods are:

  1. Send data in bursts of n bytes where n is smaller than the buffer size of the DCE. This is hard to know. On the XBee series 1, this is about 100 bytes. After each burst, delay until the 802.15.4 MAC layer ACK has come in and a transmit complete status is produced by the XBee’s API mode messages. Or send a burst and just delay and “hope” the burst was received. Allow time for 3 or so timeout/retransmissions in this blind mode.

  2. Define your own application layer protocol such as: Send n bytes, wait for the receiving device to send a reply, i.e., an application layer “ACK”. Then send the next hunk. Be sure to timeout waiting for this application ACK and deal with failures. Often, one prepends a message sequence number to these burst, so the receiver sends an “ACK for burst no. x”. With this, the receiving application can detect lost and dropped bursts.

So these are data communications 101 topics. You can drill down as much as you wish. In wireless data, such rigor is needed because unlike wired connections, things go wrong, and often.

31

Thanks for the info stevech, I notice both your suggestions for software flow control include using ACK’s. I am wondering, what is the setting that the Xbees check that determines whether they communicate over air at 19,200 or higher. At the moment, my master node sends a packet of 35 bytes the slave node runs code that simply checks for incoming data every 50 microseconds and if present reads the packet from the buffer and then transmits the packet straight back. The master node is set to wait for 25ms in between transmitting and receiving to give more than enough time for this process.

With this set up, I am sure that either buffer cannot be being over-loaded, so I am confused as to why it is defaulting to a slow air comms speed. I have tried reducing the master nodes wait time from 25ms down to 10ms and having a retry loop that checks again for an incoming packet every 5ms, but it always ends up receiving about 25ms later anyway (hence is still always running at about 19200bps over air).

I have disabled ACK’s on my packets because I intend to develop a time-triggered system (for RC helicopter control) where the receiving module needs to maintain a certain number of packets arriving every second to keep stable, which is far more important to the system than every single packet arriving perfectly. So I figured removing ACK’s would help increase the rate of packets sent/received and stop the system slowing down worrying about re-transmitting a packet several times because it hasn’t been acknowledged. The developed system will also only consist of 35 byte packets (just a few servo bytes etc).

Could it be that by disabling the ACK’s is what is causing the slow down? For example, does the outgoing packet stay in the transmitting modules buffer until an ACK is received by the transmitting module, and since I’ve disabled ACKs this is overflowing the buffer? I cannot see why this would be the case because I never drop any packets.

Or is there some other setting that determines whether it can be sure that flow control has been implemented (or at least considered e.g. small packets) so that the modules communicate faster?

Many Thanks,

32

XBee for 2.4GHz, and all other vendor’s 802.15.4 compliant products use a raw bit rate of 250Kbps over the air. The net yield bit rate is, like any wireless system, far less, due to protocol overhead, waiting for ACKs at the MAC layer, delays due to clear channel assessment, etc.

The XBee configuration parameter for baud rate is simply for the input UART that accepts data from the serial port and store that into a buffer for later transmission. And vice-versa. In 802.15.4, like other frame/packet based systems, including 802.3 with Ethernet, bytes are send in frames or packets.

If you disable 802.15.4 MAC layer ACKs, it’s unwise, as there will be no error correction via retransmission. Error direction will be done, and errored frames will be discarded by the receiving radio, with a status note if you use it.

You have ACKs disabled on both radios, I suppose.

I have an application that sends a frame every 10-20mSec without ACKs- it’s sent to the broadcast MAC address destination which, by definition, has no MAC layer ACKs. This works fine, and it’s OK if some of these frames are not received. In using the broadcast address (0000FFFF in the XBee), the PAN ID is used to ignore frames from irrelevant transmitters.

But remember that unicast and broadcast frames do clear channel assessment (CCA), which is listen before transmitting, and this can add delay, esp. if there are 802.11 frames near the same RF channel. If you change channels, look at a chart showing the 802.15.4 channel numbers versus those of WiFi - different schemes.

There is a setting, as I recall, to disable CCA. It’s ill-advised, and not unlicensed spectrum friendly.