Maximum data throughput at 921600 baud

Question

Thanks to help received in another post, I have now got 2 of these modules connected and data is transferred between them as udp packets using command mode. The client is AT+SSEND’ing a packet of 1000 bytes of data every 20ms, into the serial port at 921600 baud. The server is receiving the data and writing it out at 921600 baud. It takes about 11.3ms to write the AT+SSEND command (AT+SSEND=0,1000) and the 1000 bytes of data into the client. It takes 17.0 ms for the server to write {0,192.168.12.2,30000,1000} and then the 1000 bytes. I have looked at the serial data and can see that the stop bit in the 11.3ms packet being written in is only 1.08 us. The stop bit in the 17.0ms packet being written out is 6.4 us. I guess the processor in the Wizfi is busying itself with the reading of wifi packets, and it takes over 5 us to get around to filling the transmit buffer each time, slowing down the serial data throughput ? Is that the limit, or is there something I can do to make it shorten the stop bit and increase the data throughput? I need to get a packet of 1000 bytes through every 15ms. I used AT+USET=921600,N,8,1,N to set the baud rate

ssekim · Answer

First, in high baud rate like 921600, it needs H/W flow control(CTS/RTS). Without the H/W flow control, maybe there can be some packet loss or some trouble. When you use , you should issue after confirm [OK] of . Because, if there is some WiFi traffic-jam, it can take 2~3 seconds to return [OK] of . Note that you should issue after previous . And refer to the below link. [url]http://wizwiki.net/wiki/doku.php?id=products:wizfi250:wizfi250pg:appendix[/url] Regards, Steve

anglial · Answer

Thanks Steve, I will carefully test to see if HW flow control is necessary in my implementation. I will only be using UDP, and a few packets lost every now and then are not a problem. I will put in flow control if it needs it. If I only use UDP, how would it be possible for there to be a WiFi traffic-jam ? I don’t think this will happen, but my code could check for the [OK], then ignore it and send the next packet. I intend to set the timing so this is not necessary though. I found that in one test, even though the client end was reading 1000 bytes every 14 ms, it never complained and always sent the [OK] to the AT+SSEND. The problem occurred at the other end where it took 17ms to write the same data back out again, resulting in data being lost over time. I had already read the test results. My results are similar. You did not answer my question however… “Is that the limit, or is there something I can do to make it shorten the stop bit and increase the data throughput? I need to get a packet of 1000 bytes through every 15ms” I guess that there is no way to reduce the stop bit length ? Ok thats fine, the limit has been reached at 921600 baud. Is the answer to my data thoughput requirement to use the serial ports at 1843200 baud instead?

ssekim · Answer

As you said, I guess that it’s not easy to reduce the stop bit length. And, if you want to increase data-throughput, try as below. with 1843200 baud rate UDP instaed of TCP (if possible) Regards