SparkFun Forums

[sterling2]

Well, to tell the truth, I just got started with the Xbee and haven't connected them to the microcontroller yet. From what i understand from the data sheet, you check CTS to ensure that you aren't filling the data input buffer and if it is high, then you should stop sending and wait till it goes low to send data to the Xbee again. I will be sending data from the micro to the Xbee intermittently, maybe a 100 bytes at intervals of 10 seconds - this is just an estimate - so i might not need the cts control, though if you guys think its good practice, it might be advisable to do it.

I had a question about connecting the UARTs of the Xbee and the micro: i am using a dsPIC30F3012 which operates at a voltage range of 2.5 to 5.5 V while the Xbee is 3.3V; do i need a voltage level translating chip in between the Xbee and the micro when i connect them? I have seen yes and no answers on the web so far, and was hoping for something definite. the micro will probably be running at 5V; though if i ran it at 3.3V, then i assume i wouldn't need a translating chip?

I would greatly appreciate it if you could clear this up for me.

[waltr]

If your data rate can ensure that the XBee's data buffer will never fill then CTS isn't needed. I use a XBee with a PIC in this manner with success.

You should never exceed the voltage limits of the XBee on any pin. Therefore if your PIC is running at 5V some sort the level translation or over voltage protection is required.
Look at the schematic of Spakefun's XBee regulated Explorer board for one method.
Also, Microchip has a 3.3V hints & tips for interfacing between IC's with different voltages.

[stevech]

If your data rate can ensure that the XBee's data buffer will never fill then CTS isn't needed.

However, the first post in this thread says the OP is trying to send large volumes at high rates.

[waltr]

If your data rate can ensure that the XBee's data buffer will never fill then CTS isn't needed.

However, the first post in this thread says the OP is trying to send large volumes at high rates.

But in the post above the OP states

I will be sending data from the micro to the Xbee intermittently, maybe a 100 bytes at intervals of 10 seconds

[sterling2]

I think i can clear up the data rate thing - you see, this thread was started by "lupin" who's sending the large data volume; i saw that his interfacing-components were very similar to mine, and so started posting here. i myself am sending much smaller data volume - the 100 bytes every 10s like i mentioned.

I'll look for a level translating chip then, as advised. I do have a regulated xbee board (so that i can breadboard it) already, but i think the regulator is for the Vin/Vcc pin and doesn't apply to the Din pins so those signals still need to be taken down from 5 to 3.3.

Waltr - since you've used a PIC and an XBee, i wonder if you can shed some light on this: I am trying to use a dsPIC30F3012 micro to send data to an Xbee for transmission to a PC. I am very new with both PICs and Xbees, so i am still getting used to all this. I was wondering what exactly needed to be configured for setting up UART communication between the dsPIC and the Xbee? I think i understand the setting up of the UART for transmission ok, but was wondering about any Xbee specific configurations - the baud rate register in the PIC is one i can think of, is there anything else? The number of stop bits maybe? I assume the baud and the number of stop bits have to be the same for the PIc and the Xbee?

Also, this may be a silly question, but do i have to worry about setting start bits and stop bits? or are start bits always 0 and stop always 1 and that is taken care of by the PIc and xbee themselves and i don't have to configure/write to any registers to set those up?

thanks.

[waltr]

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.

[sterling2]

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

[waltr]

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.

[lupin]

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

[sterling2]

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.

[shifter]

"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,

[shifter]

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,

[stevech]

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.

[shifter]

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

[stevech]

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.