Let's say I wanted to send 2K of data as fast as possible from the Xbee on Uno to PC in transparent mode. I've got it working using a short delay between each byte at 115Kbaud. I arrived at this thru trial and error. I'm getting 10.8KB/sec. All the data goes without any errors or lost bytes. Until you put some distance between them. Now my delay is too short because of a few retries. I'm trying to send a byte before the last one was sent.
Can I use the hardware CTS pin from XBee to fix this? My plan is to wait when the CTS line from XBee says it's full, until it's ready.
I tried increasing my delay between every byte, even the ones without retries, but then I only get 1/2 the speed.
The distance is variable. I have the 60mw model. I'd like it to go full speed at 50m. Slower at 1/4 mile in the woods. Already this is working if I choose the appropriate delay in advance. I want it to figure it out by itself as the conditions change. Each byte delay should be different depending on if the XBee buffer is near full. Not a constant delay between characters.
In other words, I want to pause then the buffer is full. Using CTS pin?
I didn't say I was storing 2K of data. I'm sending audio data in real time as it's being sampled. But only sometimes in blocks of 2K or 4K. Should be able to send 8K if I can keep up. It works great at 1/2 the speed. This means sampling at 4khz. I'd like 8khz. This full speed works at a close range only. So I've got everything I need already working. Except I don't want to decide in advance which configuration to use. How do I know when to slow down?
For example, I could send small 100 byte buffers at full speed without losing any data because of the Xbee transmit buffer. If I can't keep up because the distance is too great, send the next one at 1/2 speed by averaging each pair of bytes. Maybe 1/4 speed instead. All I need is to be able to read CTS from XBee. How do I wire this? Is it already connected to Reset? I have the Sparkfun shield.
XBees aren't terribly high-bandwidth devices, they're meant for short transmissions. End-to-end throughput has nothing to do with the local serial interface speed used to communicate with the XBee. Get the product manual, and look for the "throughput" section. Your results seem to be roughly consistent with the estimates from the S2 manual below.
Throughput in a ZigBee network can vary by a number of variables, including: number of hops, encryption enabled/
disabled, sleeping end devices, failures/route discoveries. Our empirical testing showed the following throughput
performance in a robust operating environment (low interference).
Data Throughput*
Configuration Data Throughput
1 hop, RR, SD 35kbps
1 hop, RR, SE 19kbps
1 hop, RE, SD 25kbps
1 hop, RE, SE 16kbps
1 hop, ER, SD 21kbps
1 hop, ER, SE 16kbps
4 hops, RR, SD 10kbps
4 hops, RR, SE 5kbps
RR = router to router,
RE = router to end device (non-sleeping),
ER = end device (non-sleeping) to router,
SD = security disabled,
SE = security enabled.
4 hops = 5 nodes total, 3 intermediate router nodes
Data throughput measurements were made setting the serial interface rate to 115200 bps, and measuring the
time to send 100,000 bytes from source to destination. During the test, no route discoveries or failures occurred.
I understand. The local serial speed is always the same 115. The end-to-end changes with distance. That's why I needed CTS. My results 12KBytes is much faster than 35kbits so I can't complain! To me that's fast. I was stating it slows down with distance. This is a good thing, not a complaint. It's better than the alternative: Lost data.