I have working code, but it is too slow because of the needed delay. Without the delay 100's of bytes in a row get lost, the data is corrupted. 1000's out of 128k are gone. I know this because the file is shorter by a repeatable amount, nearly the same each time. I wonder if this is true of FTP only or any protocol over Wifly? I found the value of the delay using trial and error. How can I send data faster? Can anyone explain what is going on? The data looks like this when you uncomment LINE A, without the delay:
//code snippet
MS.print("ftp put fname.txt");
//wait for *OPEN*
for(long i=0;i<128000;i++){
//LINE A if(i%20==18)MS.write(13);if(i%20==19)MS.write(10);if(i%20<18)
MS.write((i%20)+65);
//get comm (flushsize) is 1000 at 230k baud
if(i%1000==999)delay(200); //200 effected by set wlan rate 2 above
}
I thought about creating another buffer in Arduino RAM to fill instead of delay(200). Or using a smaller flushsize buffer. But this won't help, the maximum throughput is still the limiting factor... Please help!
I'm sorry to be unclear. I'm sure it's WRITING exactly what I want and expect. It works perfectly with the delay. The above output is the contents of the file on the FTP server, without delay. Notice it sometimes starts again at A, this time after G, skipping H-R and a few more lines. Do you see the problem? Without the delay I'm sending more data before it is ready, so it gets lost. How can I go faster without the delay? It should go 10x faster without it.
Currently it's working at only 3K/sec. With hardware flow control it might get to 10k, depending on the signal strength and internet. Why can't I go 30k?
sbright33:
Currently it's working at only 3K/sec. With hardware flow control it might get to 10k, depending on the signal strength and internet. Why can't I go 30k?
Do you mean 3K/10K bits per second, or 3K/10K bytes (characters) per second?
What protocol does this device use? UART?
I have a similar problem trying to send a lot of data back and forth using udp. I have been trying and trying to figure out a solution to no avail. I bought a TTL USB cable so I could use the hardware serial port on the UNO to talk to the wifly. It was an improvement but still has issues.
The maximum throughput appears to be limited no matter what we do. To reach the maximum, hardware flow control is needed because the time it takes to send each buffer is variable. You cannot use a fixed delay because sometimes it is too slow, you could have sent it sooner. Other times it is too fast, and you lose data. The improvement gained by using CTS/RTS is only marginal. Maybe twice as fast or so. It's easier to use a conservative fixed delay. This number depends on external factors like internet usage in your neighborhood. Bummer!
Maybe it is a "weakest link" thing. The transfer will only happen at the speed of the slowest interface. You are using hardware serial, and that is limited to 115,200 bits per second. Considering 1 start bit, 8 data bits, and 1 stop bit, that is ten bits total per byte of transfer. The most you could possibly get is 11,520 characters per second transfer.
Actually I'm using 400k baud. That is not the limiting factor as you can see. That rate appears to be reliable using the hardware UART, but of course not SoftSerial. It appears that I could go 10x faster without the delay.
It's working at 3K/sec with a fixed delay as in my original code snippet. >10x slower than I wish for at 400kbaud. I had some success with hardware flow control, but the improvement is only marginal, and it's difficult. The code is much more complex.
