Xbee transmission over serial Trouble

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An Xbee is a wireless communication module which can communicate with micros over USART (serial).

 

I am having trouble with some of the communication between my MCU and the XBEE.

 

My setup looks like this

 

ATMEGA328p -> USART -> Xbee -> Wireless -> Xbee -> serial over usb -> python script

 

Sometimes in odd circumstances the data get corrupted

 

My current configuration for the xbee and the mega are as follows.

 

XBee ->

    Baud Rate - 57600

    Stop bits - One stop bit

    Parity - No Parity

 

 

ATMega ->

    Baud Rate - UDR0 = 8 (55556 bps)

    Parity - No Parity

    Stop Bits - 1

    Character Size - 8

    Asynchronous USART

 

I have been told previously that the UDR0 value and the 57600 values are a bad match since they are kind of far apart.

I tried changing the values to 51 on the mega and 9600 on the xbee but this actually made the problem worse.

 

 

Here is the problem:

 

When the following lines of code get executed (in a bootloader) the transmission behaves weirdly

 

boot_xb_tx(0x05);
g_state = 0x01;
jump_to_application();

and later

void jump_to_application (void){
	asm("jmp 0000");	
}
void boot_xb_tx (uint8_t msg) {
    while(!CHKBIT(UCSR0A,UDRE0));
    UDR0 = msg;
    while(!CHKBIT(UCSR0A,UDRE0));
    UDR0 = '\r';    
}

Obviously g_state shouldn't matter but its there so i posted it.

 

I am getting rather eratic results when I try to do this communication.

The strange thing is that earlier in the bootloader I am doing Thousands of bytes of communication all without a hitch 

 

(BTW when i switched to 9600 it only transmits one character which can be either 0xFC or 0xFB)

 

Here is a table I made for the transmitted verses received values when i played around with the number transmitted.

 

0x00 -> 0x00

0x01 -> 0x01

0x02 -> 0x00

0x03 -> 0x01

0x04 -> 0x02

0x05 -> 0x03

0x06 -> 0x02 (or 0x82)

0x07 -> 0x03 (or 0x83)

0x08 -> 0x04

0x09 -> 0x05

0x10 -> 0x02

0x50 -> 0x28

0xFF -> 0xFF

 

This only happens at the end of the bootloader and is pretty dependable.

 

UGGGGGGH.

 

Last Edited: Wed. Nov 5, 2014 - 07:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

are your Xbees linked point to point? ( you set the destination addresses ) or are you running them broadcast?

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xbees are linked point to point with the addresses (Broadcast generally introduces less predictable transmissions) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XBees are pretty dang reliable.

RF isn't.  Just because you can see the other radio doesn't mean the radio can. It's pretty easy to swamp a radio with a noisy wi fi router.

 

I think it's either an RF issue or a code issue

probably a code issue if it changes when you change your code

 

You did change the XBee serial frequency too right?

 

Which XBee

Which frequency

What power

whats the RF configuration?

 Antenna

 Distance apart

 Whats around them

 

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an xbee series 2.

Around them is a pretty busy wireless network a few computers and a battery testbed.

They are about 1m apart.

 

I want to reiterate that this almost certainly not a wireless issue since I have run this experiment ~ 100 times and gotten the same results

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Series 2, so you're running Zigbee.

Shouldn't matter in transparent mode however.

 

I've worked with XBees a LOT. Not ever in serial pass through mode, usually api mode.

Serial mode sends each character in a packet, more if you send then fast enough.

 

Do you have an XBIB or any other serial adapter so you can run this from your PC?

It really looks like software corruption of data

I can't think of any setting that would affect the values of 6 and 7.

If it was 7E, 7D then I'd say it's in API mode

 

But something is setting bit 7 un necessarily

 

Wait you say when you switch to 9600 it only sends one byte??

How are you changing the baud rates in the xbee?

are you sure your micros baud rate is right?

 

I think it's a baud rate issue

 

 

 

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am changing the baud rates on the xbee using XCTU.

 

I used the formula F_CPU/(16*(UBRR0 + 1) = Baud Rate (and got 51 for 9600)

 

Pretty sure that I am setting everything correctly. I think I have a dev kit for the XBee but im not sure how it would help debug the situation.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if you can send from the PC and not from your project, you know where the issue is.

 

I'm pretty sure you are NOT setting something correctly, cause it's not working.

 

Another test is to connect the serial port to your pc and see if it's close.

Just remember PC serial ports are very very good at handling crappy data. 8 bit avrs and XBees are much more sensitive. baud rate errors matter.

 

A digital logic analyzer is how I would look at your data.

there's a timing issue there.

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:

if you can send from the PC and not from your project, you know where the issue is.

 

 

Can you explain what you mean by send it from a PC. (I dont understand sorry)

I can send from PC=> PC without issue. Further how can i run the code from the atmega on the PC. 

The serial port is open, remember this only happens after long successful transmissions of data.

 

I don't have access to a logic analyzer but I will ask a lab near me. 

Last Edited: Wed. Nov 5, 2014 - 09:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Treesrule14 wrote:

 

keith v wrote:

 

if you can send from the PC and not from your project, you know where the issue is.

 

 

 

 

Can you explain what you mean by send it from a PC. (I dont understand sorry)

 

I just mean connect the xbee from to your PC, through a RS232 level converter of course, and send the same data from the PC to the other XBee.

You'll need to write a small C program ( or python etc ) to actually send the same data.

 

Quote:

I can send from PC=> PC without issue. Further how can i run the code from the atmega on the PC. 

The serial port is open, remember this only happens after long successful transmissions of data.

 

Oh so it's not just the short sequence you showed... Hmmmm

You really need to verify the data being actually sent from the atmega is what you expect it to be and at the timing it has to be.

 

you need to eliminate variables until there's only one left. Then you found the problem :)

Though if you can send the exact same sequence from a PC.. then it's your atmega code...

By exact I mean the same sequence of all data before the error occurs. Not just merely close to the same.

All of the boot loader or what ever it was you sent

 

what code do you have calling the xb transmit function?

 

Quote:

I don't have access to a logic analyzer but I will ask a lab near me. 

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using python on the computer (actually wrote my own instead of using the python xbee library)

 

I will look at this more tomorrow!

 

Thanks for all the help so far