PDA

View Full Version : Still getting crunchy performance from Xbee



jwatte
01-30-2015, 11:56 PM
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

ArduTank
01-31-2015, 09:55 AM
What are your settings on the Xbees?? I never got those kinds of problems, only range due to lack of antennas at the time.

jwatte
01-31-2015, 11:29 AM
How much information did you send back? How often?

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

jwatte
01-31-2015, 11:30 AM
Here are my settings for the commander:

ATMY3
ATIDF00
ATDL4
ATDH0
ATCHE
ATRO1
ATRR1
ATA10
ATCA2C
ATBD5


And here for the phantomx:

ATMY4
ATIDF00
ATDL3
ATDH0
ATCHE
ATRO1
ATRR1
ATA10
ATCA2C
ATBD5

jwatte
01-31-2015, 12:10 PM
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/share/-pDFPq77Lq-i31fCCsS9vZxBefjnkbr4g0-AXJ0agJs

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

KurtEck
01-31-2015, 03:01 PM
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

tician
02-01-2015, 01:02 AM
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.

ArduTank
02-06-2015, 03:21 PM
I don't see anything the would be the cause. I was sending back constant voltage and temperature data.

jwatte
02-06-2015, 05:45 PM
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.

KurtEck
02-06-2015, 07:11 PM
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.

jwatte
02-06-2015, 07:36 PM
That might be worth trying; thanks for the suggestion!

I've previously tried the "only send after receiving an ack, or after a long timeout" effort on my other robot (Onyx,) but that got into even worse delay loops than the current approach based on the commander "Just Send" structure...

My other alternative is to try using a ESP8266 serial wifi module. I'm awaiting adapter boards from OSH Park that will adapt them to the Xbee footprint... If that works, that would be quite excellent, as those modules are like $2.50 each :-)