I have 2 xbees that are set to 115200 baud. I am just sending the word "hello" from my arduino over a xbee to a xbee plugged into my computer with the arduino serial monitor open. I send the word "hello" every second. It shows up on my computer screen correctly a few times, but then nothing. After a few seconds of nothing showing up on my screen, The word "hello" shows up on the screen a few times. So it seems like it sends every hello that it did not send the few seconds when nothing was happening. This is not good for what i want to do. I have the packet time out set to 0. I just want a continuous stream of data.
You need to be a member of diydrones to add comments!
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
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.
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.
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.
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.
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.
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.
Replies
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
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
My $.02
(I.E. "hello" with 67 spaces at the end?)
That will force the xbee to send a packet.