Go Down

Topic: XBEE quits working after while <Mostly resolved> (Read 1 time) previous topic - next topic

smeezekitty

Jul 15, 2012, 07:11 am Last Edit: Jul 17, 2012, 08:42 pm by smeezekitty Reason: 1
I have having some problems with making two XBEE Series 1 stay in communications.
I am running them at 115200 baud rate to transfer real time audio across the link.
I have it setup to run without 802.15.4 ACKS to make the latency very low.
One Xbee is connected to an XBee USB explorer and the other is connected to an Arduino.
The audio quality is pretty good but then it suddenly stops playing after between 5 and 90 seconds and I need to unplug and reconnect the TX XBee and restart the sender application before it will link up again until it stops working again.
Here is the sender code (very ugly):
Code: [Select]

#include <stdio.h>
#include <fcntl.h>
#include <windows.h>

int main(){
// Open the serial port.
HANDLE hPort = CreateFile ("COM6", // Pointer to the name of the port
                     GENERIC_READ | GENERIC_WRITE,
                                   // Access (read-write) mode
                     1,            // Share mode
                     NULL,         // Pointer to the security attribute
                     OPEN_EXISTING,// How to open the serial port
                     0,            // Port attributes
                     NULL);        // Handle to port with attribute
                                   // to copy


DCB PortDCB;

// Initialize the DCBlength member.
PortDCB.DCBlength = sizeof (DCB);

// Get the default port setting information.
GetCommState (hPort, &PortDCB);

// Change the DCB structure settings.
PortDCB.BaudRate = 115200;              // Current baud
PortDCB.fBinary = TRUE;               // Binary mode; no EOF check
PortDCB.fParity = FALSE;               // Enable parity checking
PortDCB.fOutxCtsFlow = TRUE;         // No CTS output flow control
PortDCB.fOutxDsrFlow = FALSE;         // No DSR output flow control
PortDCB.fDtrControl = DTR_CONTROL_ENABLE;
                                     // DTR flow control type
PortDCB.fDsrSensitivity = FALSE;      // DSR sensitivity
PortDCB.fTXContinueOnXoff = FALSE;     // XOFF continues Tx
PortDCB.fOutX = FALSE;                // No XON/XOFF out flow control
PortDCB.fInX = FALSE;                 // No XON/XOFF in flow control
PortDCB.fErrorChar = FALSE;           // Disable error replacement
PortDCB.fNull = FALSE;                // Disable null stripping
PortDCB.fRtsControl = RTS_CONTROL_ENABLE;
                                     // RTS flow control
PortDCB.fAbortOnError = FALSE;        // Do not abort reads/writes on
                                     // error
PortDCB.ByteSize = 8;                 // Number of bits/byte, 4-8
PortDCB.Parity = NOPARITY;            // 0-4=no,odd,even,mark,space
PortDCB.StopBits = ONESTOPBIT;        // 0,1,2 = 1, 1.5, 2

// Configure the port according to the specifications of the DCB
// structure.
SetCommState (hPort, &PortDCB);
CloseHandle(hPort);
char buf[32];
long x;
FILE *snd = fopen("C:\\thq.wav", "rb");
FILE *ser = fopen("COM6", "wb");
while(!feof(snd)){
fread(&buf, 32, 1, snd);
fwrite(&buf, 32, 1, ser);
for(x = 0;x < 2000;x++){asm("nop");}
}
}



and the receiver code:
Code: [Select]

void setup(){
 Serial.begin(115200); //Begin serial link to XBee
 pinMode(11, OUTPUT);
 TCCR2B = TCCR2B & 0b11111000 | 0x1; //Enable fast PWM
}
void loop(){
 if(Serial.available()){analogWrite(11, Serial.read());} //Play samples as we get them
}

I really do not understand why the Xbee keeps needing to be reset.

Thanks in advance.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

johnnyonthespot

I'm not sure I understand your first code-snippet. Could you explain what its supposed to do? It looks like it is eventually supposed to stop sending, since I dont see any sort of 'loop' function to keep it going indefinitely.

smeezekitty


I'm not sure I understand your first code-snippet. Could you explain what its supposed to do? It looks like it is eventually supposed to stop sending, since I dont see any sort of 'loop' function to keep it going indefinitely.

Ooops... I should have clarified. The first code is Windows code that is run on a computer to read a .wav file and send it over the XBee. The second is the Arduino code the reads from the XBee and converts it to PWM audio.

It does have a loop though
Code: [Select]

while(!feof(snd)){


These XBees seem to be a bit finicky to get to work correctly...

Thank you for the reply though.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

Jack Christensen

XBees are pretty robust IMHO but they are basically low-bandwidth devices. How big is the .wav file being sent? Could easily be overrunning the XBee's buffer. I might try implementing flow control.
MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

smeezekitty


XBees are pretty robust IMHO but they are basically low-bandwidth devices.

I know they are not quite up to the task but it is an interesting challenge and works pretty well when its working.
Quote

How big is the .wav file being sent?

Fairly large around 1 MB. 11100 Hz 8 bit audio and several minutes long.
Quote

Could easily be overrunning the XBee's buffer.

I thought that could have been the problem but I couldn't figure out how to implement flow control properly.
Quote

I might try implementing flow control.

That would be helpful since I don't know much about flow control on serial ports.

Thanks again.

Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

smeezekitty

In case it helps, when it stops working the TX light stays on on the computer side but the RSSI light goes off on the remote side.
Also the TX Xbee will not respond to X-CTU queries until it is reset.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

mauried

The problem is the 115200 kbs speed rate.
If you read the specs on the Xbee series 1 , its only capable of a sustained thruput of 80 kbs.
http://www.digi.com/support/kbase/kbaseresultdetl?id=2213

You will be overrunning the Xbees transmit buffer.
You either need to drop the speed to 80 kbs or less, or implement flow control.

smeezekitty

#7
Jul 17, 2012, 02:52 am Last Edit: Jul 17, 2012, 02:59 am by smeezekitty Reason: 1
I think I fixed it!
I noticed when I send audio over an XBee link, it needs to be sampled at 11100 to play at the right speed but at 115200 baud, the audio should be sampled at 11520 to play the correct speed (115200 / 10 bits). I concluded the XBee is running somewhat slower then 115200 baud! So I set the baud rate on the Arduino and the TX program to 111000 instead of 115200 and so far it hasn't stopped working.

----edit----
So basically even though the XBEE may work ok for short communications at 115200, the true baud rate is somewhat lower and long communications may get cut off.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

Go Up