Wireless connection drops out

Hi everyone, I have a problem with two XBee pro’s that can initially hold a connection, but quickly drops out and won’t reconnect until I power down the transmitter. I’m using it to wirelessly transmit data from a racecar to the pits.

I have one unit transmitting continuously from the car, this one is connected to a commercial datalogger that continually outputs data onto a serial connection. I then have another unit connected to my laptop.

Initially when I power everything on, the connection will hold, but after a short period of time (which is always of random length), the connection drops out, and I cannot establish a connection again until I power off the transmitting unit and power it up again. This happens even when the units are right next to each other.

As far as I know, the XBee units are operating in transparent operation, and the amount of data coming through the datalogger is around 60kbps.

I’ve only recently bought these units, so bear with me if I have no idea what’s going on. If anyone could kindly help me diagnose the problem, I can provide more details as necessary. Thanks a lot in advance!!

What version of firmware is running on your modules and what are your non-default parameter settings?

Either pancakes is my partner in crime, or he has an application very similar to ours with an identical problem.

We’re running firmware version 10C8 on both modules. The only non-default setting at first was interface rate (set to 115200 instead of 9600 on both modules). After the problem reared its head we changed the pan id on both modules, (just in case the default ID was causing problems with interference in the area). Other than that everything is default.

The modules seem to work fine in the range test mode with the loopback connector at the far end. The modules sit there sending the test string back and forth for ages without dropping out. However with it connected to the datalogger it’ll only run for a short while (repeated tests have it lasting anything between 10s and 1min15s) before it drops out.

The LEDs on the sending module indicate that it has power, and is still receiving data from the logger, however at no point does it show any sign of having signal (neither before nor after the signal drops). The receiving module shows itself to have full signal and power and data out to the computer. Once it drops it continues to have power, however the led indicating that data is being sent to the computer switches off, followed by the signal strength LEDs.

Pancakes’ quoted data rate of 60kbps sounds alarmingly high to me, given that the quoted RF transmission rate for the XBee is only 250kbps. Overheads of packetization and transmission retries etc will reduce the actual data throughput to a much smaller figure.

If I understand correctly, one XBee is being fed from a data source. It transmits the data to the other, which feeds the data on to a host.

My suggestion for testing purposes would be to replace the datalogger with a much slower data source. The baud rate doesn’t matter much, as long as the source is only sending a restricted number of bytes per second. Maybe start at 100 bytes per second. If that works in your setup, then steadily increase the sending rate until things start to go wrong. I’d expect that to happen well before 60kbps. If, for example, you transmit successive values of a 32-bit counter you’ll be able to detect when data starts to get lost.

The fact that the range test works indicates that you do have a good transmission channel. I wouldn’t expect the range test to involve a high data throughput though, so it isn’t testing under the conditions you want.

Another point to note is that some people have reported problems with the 115200 baud setting. The solution seems to be to use two stop bits, but you might want to look at earlier posts in this forum for the background.

If I’m right (big ‘if’ of course), then you may need to reduce the amount of data you’re sending. Does the datalogger have an option to compress the data stream, for instance? Or can you preprocess the data in some other way, to reduce the bandwidth requirement?

Look at the following post. http://www.digi.com/support/forum/viewthread_thread,305#1219