Xbee is delayed and sending in packets

Replies

Joe Jackson May 20, 2010 at 12:55am

Try the following on both XBEEs
Set RR(MAC retries)=0 ,does not sent ACK or wait for ACK when data sent
AP(API mode)=0 Transparent mode
BD(baud rate)=7 (115200)
RO(Packetization Timeout)=0 ,instant transmit of data
Marc Daniels May 17, 2010 at 3:31pm

Take a look at your xbee buffer settings. I'm not in my lab right now but remember needing to adjust them. Contrary to what most people report, I'm on my 10th or so powered flight using only Xbee Pro's and arduino's for control and telemetry. My setup provides zero latency (or at least no humanly detectable) for control and airborne receiver signal strength to my ground station every second along with all the usual stuff. I found if you keep the data packet size small, and have a good command/confirm loop it works well, so all my data is sent in binary which works out quite well since both the airborne and ground system don't need to do any string parsing, which is a total waste of CPU cycles.

I flew my setup about 20 times at further and further distances in a glider before going to a powered airframe. I had to double check everything last weekend as I had it out to 3/4 of a mile and the RSSI indicator barely moved. These Xbee Pro's are nice. I'm using a Palm Pilot as the ground station display complete with artificial horizon, speed, home, climb rate, fuel etc. indicators.

I use the same software and setup on a test bed in the lab with 2 series 1 xbee 2.4Ghz with the same results.

Also, check whatever serial device/port your sending your message from and make sure it isn't buffering the output before moving it along to the xbee for transmission.

W
David May 17, 2010 at 3:19pm

Have you checked your packetization threshold setting on the xBees in X-CTU? It sounds like your transmitting xBee may be packetizing more than you want them to; if you want each character sent as it comes in, you need to set that threshold to 1, but you may run into overhead bandwidth issues at that rate. Also, there is a setting for the number of character times to wait to transmit (I don't remember the exact name of that param, sorry); check the setting there.
James Turner May 17, 2010 at 2:40pm

Looking a that video I would say you going to have to try a direct cable connection (if you haven't already) to see if Xbee are the problem then work from there. If your Xbee's have power settings then make sure they are on the lowest settings given how close they are together whilst your are testing.
Patrick Mccabe May 17, 2010 at 1:07pm

Here is a video showing my problem https://www.youtube.com/watch?v=KxIuQ77WaAU
David Gitz May 17, 2010 at 11:19am

I had something similiar to me a few years ago with the xbee. I don't know if the firmware has changed to support this, but the problem was that one xbee was set up as a node with its destination address set to the other node, and the other node destination address set to the generic broadcast address. If you are having this problem one way and not the other, I would make sure the destination addresses on both nodes are set to the other radio.

My $.02
James Turner May 17, 2010 at 2:02am

Are you using an FTDI on the computer to talk to the Xbee? I had some problems with the settings within the FTDI drivers through device manager. I was trying to use small packets of data data for an artificial horizon but the lag was so great (somtimes up to a few seconds) it was of no use at all. In the end I discovered there were some extra settings within the drivers which were more than just the usual tx and rx buffer sizes and tinkering with those resolved my problem. I've only had this problem on just one PC.
Patrick May 17, 2010 at 1:37am

Can you try sending a full length 72 byte packet?
(I.E. "hello" with 67 spaces at the end?)

That will force the xbee to send a packet.
3D Robotics

Chris Anderson May 16, 2010 at 8:50pm

That's odd. Try at at slower baud rate, like 38400 and see if that makes a difference. There might be a buffer somewhere that's overflowing.
Greg Fletcher May 16, 2010 at 7:40pm

Could it be your computer? I have never seen this in my Xbee's. If you have access to an oscilloscope you can see the serial data stream and time it. I do this all the time. The serial line will stay at 3.3 v when idle and you will see 3.3 and 0 together when its transmitting. Remember to set the trigger slope to neg on the scope.

New version of Intel OpenBot! This resolves many of the issues with the first version, including a much smoother tr… https://twitter.com/i/web/status/1352395636369313798

RT @Heavy02011: @diyrobocars : A Home-brew computer club* for Connected Autonomous Driving on Jan 23rd, 2021 https://www.meetup.com/Connected-Autonomous-Driving/events/275728684/ #Meetu…

RT @Heavy02011: ⁦@diyrobocars⁩ Autonomous Driving Assembly at #rC3. join us at https://rc3.world/rc3/assembly/diyrobocars-f1tenth/ ⁦@f1tenth⁩ ⁦@DAVGtech⁩ ⁦@DWalmroth⁩…

Discussions

Xbee is delayed and sending in packets

Replies

Activity