go_away

Author Topic: strange XBee problem (fixed, sorta)  (Read 2101 times)

0 Members and 1 Guest are viewing this topic.

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,665
  • Helpful? 169
    • Society of Robots
strange XBee problem (fixed, sorta)
« on: October 11, 2010, 08:38:58 PM »
Maybe my Xbee is defective, or the Parallax Xbee adapter is whack, or maybe I damaged my Axon when I accidentally applied 6.3V on the regulated line, but I have the strangest problem.

For some reason, sometimes it outputs the '8' character as '' and sometimes the '0' character as ''. It is very inconsistent when this happens, but when it does, it makes my serial strings go crazy. It actually took me about ~12 hours to figure that out :-X :-[ :'(

Anyway, if anyone else has the problem, here is the fix:

Code: [Select]
data = ZigBeeGetByte();//get the data from your UART
if(data=='')
data='8';
else if(data=='')
data='0';

Offline madsci1016

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,450
  • Helpful? 43
Re: strange XBee problem (fixed, sorta)
« Reply #1 on: October 11, 2010, 08:45:12 PM »
What are the ASCII codes for those characters? Could it be a single bit flip in the same place for both?

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,665
  • Helpful? 169
    • Society of Robots
Re: strange XBee problem (fixed, sorta)
« Reply #2 on: October 11, 2010, 09:32:44 PM »
What are the ASCII codes for those characters? Could it be a single bit flip in the same place for both?

Hyperterminal prints these characters out correctly, but they don't show up the same here or in AVR Studio (probably a font issue).

That said, '8' looks like #184 and '0' looks like #176:
http://www.asciitable.com/

I was honestly really surprised its this consistent . . . but it didn't always mess the 8 or 0 up, quite often it was correct.


edit: correction on #184
« Last Edit: October 12, 2010, 09:16:57 AM by Admin »

Offline madsci1016

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,450
  • Helpful? 43
Re: strange XBee problem (fixed, sorta)
« Reply #3 on: October 11, 2010, 10:53:22 PM »
0 in ascii binary is 00110000; #176 is 10110000

8 is 00111000; #187 is 10111011 (are you sure it isn't 184? then it would be 10111000, and more consistent, same single bit flip. they look very alike)

So it looks like some bit flipping, but don't know why it's just those characters.

On a side note, judging from the last posting, are you trying to run the Xbees at 115200 baud? I have never been able to go over 19200 without errant bit flips. I do ascii checksums on all messages and keep track of how many fail on the receiving end. I did through tests and anything over 19200 would start failing. A few others have reported the same issue running over 19200.
« Last Edit: October 11, 2010, 10:55:34 PM by madsci1016 »

Offline KurtEck

  • Robot Overlord
  • ****
  • Posts: 217
  • Helpful? 12
Re: strange XBee problem (fixed, sorta)
« Reply #4 on: October 12, 2010, 07:07:57 AM »
I actually run most of my XBees at 62500 and not at 115200.  It makes very little difference to the XBees.  The baud rate you choose does not effect the speed the data is sent over the air only effects the communication between the xbee and the host. So you can actually have two xbees communicate at different baud rates.  Of course if you have a higher baud rate on one that is sending at full speed it could overrun the one at a lower speed.

Now back to baud rate. The AtMega USARTS do not generate every baud rate. But instead are limited to the bit speeds to being divisible by 16 in normal mode or by 8 in double speed mode.  My understanding is double speed mode is vary unforgiving.  So the actual speed that the USART is working at when you ask for 115200 is probably 111111, which is off by -3.5%, which is out of the typically acceptable range.  Some of the other processors I use divide the clock by 32 and actually generate a baud rate of 125000...

So I use 62500 as there is 0% error, but is an nonstandard baud mode for the xbee.  You can issue it by the command: "ATBD F424"


Other baud modes that work 38400 appears to work OK (.2 error).  

FYI - When I now run into issues like this, I now hook up my Logic Analyzer by www.saleae.com), which helped me track down the first time my XBee and processor were not reliably communicating.  That was one of the best $150 I have spent...

Kurt
« Last Edit: October 12, 2010, 07:19:54 AM by KurtEck »

Offline AdminTopic starter

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,665
  • Helpful? 169
    • Society of Robots
Re: strange XBee problem (fixed, sorta)
« Reply #5 on: October 12, 2010, 10:00:14 AM »
Quote
8 is 00111000; #187 is 10111011 (are you sure it isn't 184? then it would be 10111000, and more consistent, same single bit flip. they look very alike)

Oops, yea I meant 184. Interesting how that first bit is occasionally flipped . . . I guess the logic analyzer would be perfect to narrow down which device in the loop is confused between a high an a low voltage . . . hence my new thread:
http://www.societyofrobots.com/robotforum/index.php?topic=12347.0


This problem was occurring no matter the baud setting - including the 9600bps default. Both XBees are about 5" apart.

On a [non-damaged] Axon, all basic baud rates, up to 230400, work fine without error.

Offline madsci1016

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,450
  • Helpful? 43
Re: strange XBee problem (fixed, sorta)
« Reply #6 on: October 12, 2010, 11:39:45 AM »
Actually, come to think of it, i'm willing to bet it's SFE's bad designed Xbee boards causing errors for me over 19200.
 :-\ :-\ :-\ :-\

Offline KurtEck

  • Robot Overlord
  • ****
  • Posts: 217
  • Helpful? 12
Re: strange XBee problem (fixed, sorta)
« Reply #7 on: October 12, 2010, 12:54:32 PM »
On a [non-damaged] Axon, all basic baud rates, up to 230400, work fine without error.
As I mentioned in the above thread, when you ask a 16MHz Axon to output at 115200 you will not be outputting at that baud rate.   If you look at the Atmega640/1280/2560 document under the USART section at the baud rate table/errors.  The PDF I have this is table 22-12 page 231, you will see which baud rates work.  I have been told by a couple of sources that you may work OK with up to a 3% error, but that is combined for both sides, so you should try to limit it to about 1.5%.  Obviously if the other side you are talking to is one of the same, then the will both have the same error and work.

This is why some board manufactures use a 17.7456MHz clock instead of the 16MHz clock (The SSC-32 servo controller, BDMicro gave this as an option...).  You will see in the ATmega document (previous page) that with this speed all of the standard baud rates work with 0% error.

Kurt

 


Get Your Ad Here