Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Still getting crunchy performance from Xbee

  1. #1

    Still getting crunchy performance from Xbee

    The Xbees are doing OK when doing single-direction communications, but as soon as I want to periodically send data back (like servo temperature and battery voltage,) the cadence from the transmitter becomes chaotic, intermittent, and jerky.
    This goes for Pros as well as regular, and for my own designs as well as the Arbotix / Commander / PhantomX setup.
    I'm not sending a lot of data back, either -- three stanzas of 10 bytes per second.
    And, when this happens, of course packets get cut in half and it takes even longer for the receiving end to re-synchronize.

    Anyway, so I'm going to try something different -- push an ESP8266 into service. I sketched up the following adapter, which I'll be trying out when it arrives from OSH park:

    https://oshpark.com/shared_projects/rCVkThMB

  2. #2
    Join Date
    Jul 2012
    Location
    Richmond, IN
    Posts
    652
    Rep Power
    41

    Re: Still getting crunchy performance from Xbee

    What are your settings on the Xbees?? I never got those kinds of problems, only range due to lack of antennas at the time.

  3. #3

    Re: Still getting crunchy performance from Xbee

    How much information did you send back? How often?

    I've had this pretty consistently with various versions of the Xbee for multiple projects :-(

  4. #4

    Re: Still getting crunchy performance from Xbee

    Here are my settings for the commander:
    Code:
    ATMY3
    ATIDF00
    ATDL4
    ATDH0
    ATCHE
    ATRO1
    ATRR1
    ATA10
    ATCA2C
    ATBD5
    And here for the phantomx:
    Code:
    ATMY4
    ATIDF00
    ATDL3
    ATDH0
    ATCHE
    ATRO1
    ATRR1
    ATA10
    ATCA2C
    ATBD5

  5. #5

    Re: Still getting crunchy performance from Xbee

    I'm playing a quick click from the 'bot when it receives and decodes a packet from the commander.

    Here is the reasonably smooth receive stream when not sending any data back:
    https://www.amazon.com/clouddrive/sh...br4g0-AXJ0agJs

    Here is the non-smooth receive stream when sending 10 bytes back every 300 milliseconds or so:
    https://www.amazon.com/clouddrive/sh...KKuAwOJDNDwPDY

  6. #6

    Re: Still getting crunchy performance from Xbee

    Are you in serial replacement mode or using packets? My gut tells me you are running into collisions on the XBees. I also use bidirectional communications and have also run into issues where it stops sending for a bit. Unfortunately I never did track down why. I know with my DIY XBee stuff, even when sending data one way you are actually doing bidirectional communications, as the XBees send ACKS (unless you turn it off) for the packets.

    Also it has been awhile, but I think you can query for things like error or retry counts. Have you tried this and if so, was showing high numbers? Again I don't remember the details as I have not played much at the lower levels of xbees for awhile.

    Edit: I believe the diagnostics I was playing with before was the EA and EC values.

    Kurt
    Last edited by KurtEck; 01-31-2015 at 04:40 PM.

  7. #7
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,313
    Images
    27
    Rep Power
    279

    Re: Still getting crunchy performance from Xbee

    Not much practical experience with Xbee (going only from the manual), but every lost ACK from the receiving module in unicast mode will trigger the 802.15.4 MAC to perform up to 3*(1+RR) packet resends. So, lose one ACK packet and the retries/timeouts (200ms for each ACK timeout + some random value <48ms to resend) will probably lose you several subsequent packets intended to travel in the other direction.

    If I am reading the manual correctly, matching the PAN IDs and channels of the modules, setting RR=0, and setting DL=0xFFFF and DH=0x0 will cause the modules to send broadcast packets to all others without any responses/ACKs or retries. You will absolutely lose a few packets because of interference or corruption, but may lose fewer overall by not delaying/dropping later packets during the retries.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  8. #8
    Join Date
    Jul 2012
    Location
    Richmond, IN
    Posts
    652
    Rep Power
    41

    Re: Still getting crunchy performance from Xbee

    I don't see anything the would be the cause. I was sending back constant voltage and temperature data.

  9. #9

    Re: Still getting crunchy performance from Xbee

    Are you in serial replacement mode or using packets?
    I'm using serial-replacement.

    I also believe that the problems come from dropped/re-tried packets, but I'm disappointed in the apparent design of the on-air protocol. It could easily have 10x better performance, especially in the sometimes-dropped case! Re-tries can include more data.

    Also, I have been assuming that the return data (voltage/temperature) would be piggy-backed on top of the ACK packets, so there would be no difference based on sending data back or not, but there is a very clear difference, which makes me believe that my assumption is somehow wrong. But I can't figure out in what way, or what to do about it.

  10. #10

    Re: Still getting crunchy performance from Xbee

    I trust your instincts on things, but my assumptions here are slightly different.

    With the DIY remote code I decided to go to Packet mode as it gives me more control over things, like when things are sent. Also before that I was generating my own packets, which had a length field, plus a checksum, which I then output, which the underlying system put into it's packet (or packets) with it's own lengths and it's own checksums. So I decided to make use of their stuff. Also liked the idea of the robot being able to quickly talk with multiple destinations. My main example was the remote control for commands and the like and my PC which was running a program to log data to. Could also do that in serial replacement mode as well, by switching into command mode, change the DL... But then had to know when it received data who it came from, which in packet mode this data is part of the packet...

    My assumption about retried packets, is that it is completely handled internal to the XBee modules and as such same data. That is when it fails it does not see if more data, alter packet and retry.

    I am assuming that when in serial replacement it internally sends packets. So when the queue is full or timeout, the system will send probably a TX 16 bit address packet (1), which when robot sees it, it will automatically send an ACK. Not sure of the actual over wire ack structure, but probably similar to the TX status message (89) that you receive back in packet mode, which only contains the frame id and status. likewise the same things happen in reverse when you send data back from robot, it generates a TX packet, which is received on the other side (RX ), which sends back the status.

    Note: even with packet modes, I was/am running into same issues where transmitting will stop for a period of time, which I assumed was due to collision processing. What I have been meaning to do is to try some more explicit control over the timings of messages, to see if that would help.

    That is assume your controller is sending 20 commands per second. What I was thinking of trying was when I want to send data back, wait until you receive the next packet and then send after some delta time. This way hoping that there should not be any conflict. I have not tried this yet, but I did something similar to this with the AX servos, that I only query for Voltage and the like when I know the buss will be free for enough time. This helped remove some issues I was seeing.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. XBee, GPS, ? Help!
    By blenz in forum Robotics General Discussion
    Replies: 2
    Last Post: 05-18-2013, 08:56 PM
  2. Kinect+PC performance thread
    By tician in forum ROS - Robot Operating System
    Replies: 1
    Last Post: 12-14-2012, 09:30 PM
  3. Question(s) Arduino- xbee -xbee-arduino - stepper motors
    By Icemonkey in forum Arbotix, Microcontrollers, Arduino
    Replies: 7
    Last Post: 06-04-2012, 12:35 PM
  4. How to performance test servos?
    By billyzelsnack in forum DYNAMIXEL & Robot Actuators
    Replies: 32
    Last Post: 03-25-2011, 10:23 AM
  5. Question(s) Which microcontroller is best in terms of price and performance?
    By DannyDeth in forum Robot Computers
    Replies: 13
    Last Post: 03-30-2010, 11:54 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •