--- title: "WizFi360 TCP message delay & SoftAP+STA" url: "https://maker.wiznet.io/forum/14121" markdown_url: "https://maker.wiznet.io/forum/14121/md" type: "Forum topic" category: "Wireless" author: "KVLM" created: "2021-01-19T08:24:36+09:00" last_activity: "2022-06-07T09:12:24+09:00" language: "en" views: 2466 replies: 52 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # WizFi360 TCP message delay & SoftAP+STA ## Question Asked by KVLM on 2021-01-19 in Wireless. Hello, We have a problem when using WizFi360 as SoftAP + STA with TCP connections. Certain devices get their messages delayed (from 2 up to 30 seconds delay) when WizFi is sending them while it is connected to an AP with its STA. If the STA isn’t used, then the devices connected to the Module’s SoftAP don’t receive delayed messages, but when STA is connected to somewhere then the delay starts happening. Any idea why this is happening and how can it be resolved? We would really need to use the Module both SoftAP and STA while using the TCP connections too, it is important for our project, but this delay in receiving messages is not optimal for us at all. Thank you for your answer in advance! ## Replies ### Reply 1 by viktor, 2021-01-20 Hello, Would you mind to provide more details? As I understood WizFI360 is running in SoftAP+STA mode and you have TCP server running on the module. Then you are trying to send messages from server to other clients connected to WizFi360 SoftAP, but messages are delayed. Is my understanding correct? Any screenshots, exact command sequences will be highly appreciated. Thanks in advance, Viktor ### Reply 2 by KVLM, 2021-01-20 (in reply to reply 1) Hello, WizFi360 is running SoftAP+STA indeed. WizFi is running a TCP server, and if WizFi is connected to an AP then it is connected to as a TCP client to a server on that AP too, while other devices which are connected to the WizFi SoftAP are connected as TCP clients to the SoftAp TCP server. I’m trying to send messages to the TCP clients with the AT commands of AT+CIPSENDBUF, the exact sequence is this: AT+CIPSENDBUF,0,[len] <wait 10ms> ‘>’ [message] <wait 20ms> AT+CIPSENDBUF,1,[len] <wait 10ms> ‘>’ [message] <wait 20ms> AT+CIPSENDBUF,2,[len] <wait 10ms> ‘>’ [message] <wait 20ms> Waiting happens with delays in the MCU program. The Program sends a message seperately to a device or to all three of them in a manner like I showed above. Even when it just sends one message to one device it can arrive to the device delayed. These messages arrive to the TCP clients just fine *IF* the WizFi360 is not connected to an AP through its STA. But when It is connected, some of the devices get these messages delayed up almost up to a minute in some cases. For example: Device 1 and 3 would get their messages before Device 2, even though in the command sequence Device 2 is getting sent its message sooner than Device 3. This Delay only doesn’t happen if after power up, the WizFi360 does not connect to an AP. If it connect to an AP, the delay happens, even if it disconnects from the AP, until another power up. WizFi360’s Firmware version currently is 1.1.1.2 but it was 1.0.7.2, I thought upgrading firmware would help but the problem still persist even after changing to 1.1.1.2 from 1.0.7.2 . The exact sequence I take when I set up the module is: -ATE0 -AT+CWMODE_DEF=3 -AT+CWDHCP_DEF=0,1 -AT+CWSAP_DEF=“[our ssid]”,“[our password]”,1,3,3,0 -AT+CIPAP_DEF=“192.168.100.1”,“192.168.100.1”,“255.255.255.0” -AT+CWDHCPS_DEF=1,120,“192.168.100.100”,“192.168.100.200” -AT+CIPMUX=1 -AT+CIPSERVERMAXCONN=3 -AT+CIPSERVER=1,5000 -AT+CIPSTO=1200 -AT+CIPSTAMAC_CUR? [To get the MAC address] -AT+CIPSTA_DEF? [To get the IP Address] When trying to connect to an AP: -AT+CWJAP_DEF=“example”,“password” If it connected then trying to connect to the server: -AT+CIPSTART=4,“TCP”,“192.168.137.1”,50000 I hope this will help trying to find a solution, if you need anything else just tell me Thank you in advance! ### Reply 3 by viktor, 2021-01-21 Hello, I am now checking our module performance. By message delay, do you mean that message itself is being delayed or delay for “SEND OK” message? ### Reply 4 by KVLM, 2021-01-21 Hello, Sorry, I might misunderstand your question. Are you asking if SEND OK is being delayed after the message has been sent? Because SEND OK only comes after the message has been sent, in which case, yes it is delayed with the message itself, but after I get the delayed message, I get the SEND OK too. ### Reply 5 by viktor, 2021-01-21 Hello, Yes, that was my question. Base on my tests so far, messages are being delivered almost immediately, while as “SEND OK” messages are being delayed sometimes. But since you are using AT+CIPSENDBUF, it is not necessary to wait for “SEND OK” message. Since you mentioned that you get messages itself delayed, would you mind informing me whether there is any noise in WiFi channel that you are using or any other circumstances that could impact communication? From my side, I will conduct more tests and check Firmware code. ### Reply 6 by KVLM, 2021-01-21 (in reply to reply 5) Hello, There aren’t much wifi hotspots around, so I don’t think there is noise in the WiFi channel. The circumstances I am using is, having three different devices [a phone, a tablet, and a smart watch] with our android program as a TCP client connected to the WizFi SoftAP and communicating like that. When WizFi360 does not use its STA, then the messages what come from the Module arrive almost instantly too, but when the STA is being used to connect to an AP so that the WizFi can connect to a TCP server on that network, then the delays start happening noticably on the devices. It doesn’t have to be even connected to the TCP server only to the AP and the delays can be noticed. I have tested with a TCP Client terminal tester and the delays still happened on that too when WizFi was connected to an AP. What I find weird still, that the delay still remains if I connect to an AP and disconnect from it with WizFi, but if I don’t connect to an AP after power up, the delays don’t happen. I hope this was helpful. ### Reply 7 by KVLM, 2021-01-26 Hello, I don’t want to seem impatient or pushy, but can I have an update on how things are going so far? Thank you! ### Reply 8 by viktor, 2021-01-27 Hi, Sorry it takes longer time than expected. I am still working on this issue, I will let you know the results. ### Reply 9 by viktor, 2021-01-27 (in reply to reply 7) Hello, Would you mind to test with FW v 1.0.7.5? It can be downloaded here: ![](https://github.githubassets.com/favicons/favicon.svg) [github.com](https://github.com/wizfi/Release/tree/master/Binary/1.0.7.5) ### [Release/Binary/1.0.7.5 at master · wizfi/Release](https://github.com/wizfi/Release/tree/master/Binary/1.0.7.5) [master/Binary/1.0.7.5](https://github.com/wizfi/Release/tree/master/Binary/1.0.7.5) WizFi360's Binaries and Tools. Contribute to wizfi/Release development by creating an account on GitHub. Meanwhile I will look for other workarounds. ### Reply 10 by KVLM, 2021-01-27 Hello, I have uploaded the FW v 1.0.7.5 to our WizFi360 as you requested but the problem about the delayed TCP messages sadly is still present. ### Reply 11 by viktor, 2021-01-27 Hello, Would you mind to provide full logs from UART of WizFi360? Preferably with timestamps, I made exactly same settings that you mentioned above, and tested with similar setup (WizFi360 as SoftAP+STA/TCP Server, smartphone and table as TCP client and another Wizfi360 as TCP client), in my case it worked without any delays. ### Reply 12 by KVLM, 2021-01-27 (in reply to reply 11) Hello, I have asked for some logs from one of the devices which has the messages delayed more frequently, and they sent me a log from one session of testing while connected to 2 terminals and one Tablet. TCP link ID was: 0 - Terminal1; 1 - Tablet; 2 - Terminal2; and the messages were sent in this order too. The left Terminal is Terminal1 while the right Terminal is Terminal2, the log file is from the Tablet’s program when it gets the messages. [![msgDelayLogs](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/c/cd415c43f289b8176ace5dfd01fa3413440691a9.png) msgDelayLogs1869×516 83.3 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/c/cd415c43f289b8176ace5dfd01fa3413440691a9.png) As you can see, the Tablet gets the messages delayed compared to the terminals on the Network where the server is found. (Like on line 10, where the message which was sent at 9:54:05 was delayed and so is the two messages after that and they arrived at the same time at 9:54:11) I hope this helps figuring out the problem, if you need more logs just tell me. ### Reply 13 by viktor, 2021-01-27 Hello, Unfortunately based on your screenshot it is impossible to understand which commands were given to WizFi360. That’s why I asked log from UART1 of WizFi360. If possible, please provide me one, so that I would be able to reproduce your setup exactly and find out the reason. ### Reply 14 by KVLM, 2021-01-28 (in reply to reply 13) Hello, If you want to know which commands I used, it’s the AT+CIPSENDBUF one, I only use that for message sending and I already written that down, so now I don’t understand what you would like to know, could you elaborate about it? If it’s about how I use it in code for the Microcontroller then it’s like this: ``` void wizfi_TCPMessageSender(char * tcpLinkID, char * message, uint16_t msgLen) //max len 2048 { uint8_t mesSend[80] = "AT+CIPSENDBUF="; char msgLenStr[5] = {0}; uint16_to_string((uint8_t *)msgLenStr,4,msgLen); strcat((char *)mesSend,tcpLinkID); strcat((char *)mesSend,","); strcat((char *)mesSend,(char *)msgLenStr); strcat((char *)mesSend,"\r\n"); wizfi_sendData(mesSend,strlen((char *)mesSend)); //Sends CIPSENDBUF command into UART sending it to WizFi as an AT command Timing.delay_ms(10); //Waits for > prompt wizfi_sendData((uint8_t *)message,msgLen); //Puts message to UART, sending it to WizFi as a message Timing.delay_ms(20); } ``` And I use it something like this: ``` wizfi_TCPMessageSender("1","Message",7); //Sends "Message" to TCP client on LinkID 1 ``` And as you could see I am sending to three Clients with a message sender like this, just a bit more elaborate to get the desired messages I need, the ones on the screenshot on the terminals. I cannot provide timestamps for when I send the AT commands because we don’t have an RTC for the MCU in this project, the closest time stamp I can get about when the command is sent is when the message arrives on the terminal on the left side on the screenshot since that was on LinkID 0. The Terminals got the messages in time because they were on the AP to which the WizFi was connected. Also, even if I send it only to one client, the delay can still happen. But as I said, it only happens if WizFi’s STA is connected to an AP. I hope this was helpful. ### Reply 15 by viktor, 2021-01-28 Hello, Were there any other commands used for settings except those that you informed before? Can you test with the same setup but without MCU and sending commands directly to WizFi360? ### Reply 16 by KVLM, 2021-01-28 Hello, There isn’t any other commands I use for settings, I have listed all which I use to set the WizFi. You mean directly sending to the WizFi-s UART through a terminal? I don’t think we can do that, since the WizFi is already integrated into the Project, but I will try to ask around if we have a spare one for this. ### Reply 17 by KVLM, 2021-01-28 Hello, Could it be that the delays in the messages to the devices are happening because of the server answering to the keep alive messages which are sent every 2 seconds? Or by sending messages to the server at all? I was focused on the other aspects that I forgotten that there is keep alive communication with the server. AT+CIPSENDBUF,4,[len] [10 ms delay] ‘>’ [Keep Alive message to which the server answers] [20 ms delay] This happens every 2 seconds. Could it be that WizFi isn’t able to send message to the STA-s because of this so the messages get delayed? ### Reply 18 by viktor, 2021-01-29 (in reply to reply 17) Hello, Regarding first question, yes if possible please conduct test on WizFi360 directly without MCU. Regarding question #2. I don’t really think that could be the cause, but is there any specific reason to send request every 2 seconds? ### Reply 19 by KVLM, 2021-01-29 Hello, To answer your second question: We need the Keep Alive function so the server knows that the program is connected to it and so does the MCU knows he is connected to the Server. I could make some logs with reading out what the MCU sends to the WizFi360 and then checking the messages on the Tablet on a terminal program to see the delay with timestamps. [![Screenshot_20210129_111458_com.tetron.packetron](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/f/f573b86a512675c65a994e6e1ca0c1fe02657cfb.jpeg) Screenshot_20210129_111458_com.tetron.packetron800×1657 155 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/f/f573b86a512675c65a994e6e1ca0c1fe02657cfb.jpeg) And here is the log from YAT: > (11:11:13.996) [CR]AT+CIPSENDBUF=0,0006 > (11:11:14.111) 00167[CR]AT+CIPSENDBUF=1,0006 > (11:11:14.111) 00167[CR]AT+CIPSENDBUF=2,0006 > (11:11:14.111) 00167 > (11:11:19.104) [CR]AT+CIPSENDBUF=0,0006 > (11:11:19.104) 00168 > (11:11:19.236) [CR]AT+CIPSENDBUF=1,0006 > (11:11:19.236) 00168[CR]AT+CIPSENDBUF=2,0006 > (11:11:19.236) 00168 > (11:11:24.195) [CR]AT+CIPSENDBUF=0,0006 > (11:11:24.321) 00169[CR]AT+CIPSENDBUF=1,0006 > (11:11:24.321) 00169[CR]AT+CIPSENDBUF=2,0006 > (11:11:24.321) 00169 > (11:11:29.286) [CR]AT+CIPSENDBUF=0,0006 > (11:11:29.420) 00170[CR]AT+CIPSENDBUF=1,0006 > (11:11:29.420) 00170[CR]AT+CIPSENDBUF=2,0006 > (11:11:29.420) 00170 > (11:11:34.394) [CR]AT+CIPSENDBUF=0,0006 > (11:11:34.394) 00171 > (11:11:34.512) [CR]AT+CIPSENDBUF=1,0006 > (11:11:34.512) 00171[CR]AT+CIPSENDBUF=2,0006 > (11:11:34.512) 00171 > (11:11:39.486) [CR]AT+CIPSENDBUF=0,0006 > (11:11:39.486) 00172 > (11:11:39.604) [CR]AT+CIPSENDBUF=1,0006 > (11:11:39.604) 00172[CR]AT+CIPSENDBUF=2,0006 > (11:11:39.604) 00172 > (11:11:44.593) 6 > (11:11:44.577) [CR]AT+CIPSENDBUF=0,000 > (11:11:44.593) 00173 > (11:11:44.700) 00173 > (11:11:44.700) [CR]AT+CIPSENDBUF=1,0006 > (11:11:44.700) 00173[CR]AT+CIPSENDBUF=2,0006 > (11:11:49.685) [CR]AT+CIPSENDBUF=0,0006 > (11:11:49.808) 00174[CR]AT+CIPSENDBUF=1,0006 > (11:11:49.808) 00174[CR]AT+CIPSENDBUF=2,0006 > (11:11:49.808) 00174 > (11:11:54.776) [CR]AT+C > (11:11:54.825) IPSENDBUF=0,0006 > (11:11:54.825) 00175[CR]AT+CIPSENDBUF=1,0006 > (11:11:54.825) 00175 > (11:11:55.007) 00175 > (11:11:55.007) [CR]AT+CIPSENDBUF=2,0006 > (11:11:59.884) [CR]AT+CIPSENDBUF=0,0006 > (11:12:00.005) 00176[CR]AT+CIPSENDBUF=1,0006 > (11:12:00.005) 00176[CR]AT+CIPSENDBUF=2,0006 > (11:12:00.005) 00176 > (11:12:04.976) [CR]AT+CIPSENDBUF=0,0006 > (11:12:05.124) 00177[CR]AT+CIPSENDBUF=1,0006 > (11:12:05.124) 00177[CR]AT+CIPSENDBUF=2,0006 > (11:12:05.124) 00177 > (11:12:10.083) [CR]AT+CIPSENDBUF=0,0006 > (11:12:10.212) 00178[CR]AT+CIPSENDBUF=1,0006 > (11:12:10.212) 00178[CR]AT+CIPSENDBUF=2,0006 > (11:12:10.212) 00178 > (11:12:15.174) [CR]AT+CIPSENDBUF=0,0006 > (11:12:15.305) 00179[CR]AT+CIPSENDBUF=1,0006 > (11:12:15.305) 00179[CR]AT+CIPSENDBUF=2,0006 > (11:12:15.305) 00179 > (11:12:20.266) [CR]AT+C > (11:12:20.282) IPSENDBUF=0,0006 > (11:12:20.282) 00180 > (11:12:20.490) [CR]AT+CIPSENDBUF=1,0006 > (11:12:20.490) 00180[CR]AT+CIPSENDBUF=2,0006 > (11:12:20.490) 00180 > (11:12:25.373) [CR]AT+CIPSENDBUF=0,0006 > (11:12:25.373) 00181 > (11:12:25.503) [CR]AT+CIPSENDBUF=1,0006 > (11:12:25.503) 00181[CR]AT+CIPSENDBUF=2,0006 > (11:12:25.503) 00181 > (11:12:30.465) [CR]AT+CIPSENDBUF=0,0006 > (11:12:30.584) 00182[CR]AT+CIPSENDBUF=1,0006 > (11:12:30.584) 00182[CR]AT+CIPSENDBUF=2,0006 > (11:12:30.584) 00182 > (11:12:35.557) [CR]AT+CIPSENDBUF=0,0006 > (11:12:35.693) 00183[CR]AT+CIPSENDBUF=1,0006 > (11:12:35.693) 00183[CR]AT+CIPSENDBUF=2,0006 > (11:12:35.693) 00183 > (11:12:40.664) [CR]AT+CIPSENDBUF=0,0006 > (11:12:40.664) 001 > (11:12:40.790) 84[CR]AT+CIPSENDBUF=1,0006 > (11:12:40.790) 00184[CR]AT+CIPSENDBUF=2,0006 > (11:12:40.790) 00184 > (11:12:45.755) [CR]AT+CIPSENDBUF=0,0006 > (11:12:45.886) 00185[CR]AT+CIPSENDBUF=1,0006 > (11:12:45.886) 00185[CR]AT+CIPSENDBUF=2,0006 > (11:12:45.886) 00185 > (11:12:50.863) [CR]AT+CIPSENDBUF=0,0006 > (11:12:50.863) 00186 > (11:12:50.988) [CR]AT+CIPSENDBUF=1,0006 > (11:12:50.988) 00186[CR]AT+CIPSENDBUF=2,0006 > (11:12:50.988) 00186 > (11:12:55.955) [CR]AT+CIPSENDBUF=0,0006 > (11:12:56.077) 00187[CR]AT+CIPSENDBUF=1,0006 > (11:12:56.077) 00187[CR]AT+CIPSENDBUF=2,0006 > (11:12:56.077) 00187 > (11:13:01.062) ,0006 > (11:13:01.046) [CR]AT+CIPSENDBUF=0 > (11:13:01.062) 00188 > (11:13:01.184) 00188 > (11:13:01.184) [CR]AT+CIPSENDBUF=1,0006 > (11:13:01.184) 00188[CR]AT+CIPSENDBUF=2,0006 > (11:13:06.154) [CR]AT+CIPSENDBUF=0,0006 > (11:13:06.301) 00189[CR]AT+CIPSENDBUF=1,0006 > (11:13:06.301) 00189[CR]AT+CIPSENDBUF=2,0006 > (11:13:06.301) 00189 > (11:13:11.261) [CR]AT+CIPSENDBUF=0,0006 > (11:13:11.261) 00190 > (11:13:11.402) [CR]AT+CIPSENDBUF=1,0006 > (11:13:11.402) 00190[CR]AT+CIPSENDBUF=2,0006 > (11:13:11.402) 00190 > (11:13:16.353) [CR]AT+CIPSENDBUF=0,0006 > (11:13:16.485) 00191[CR]AT+CIPSENDBUF=1,0006 > (11:13:16.485) 00191[CR]AT+CIPSENDBUF=2,0006 > (11:13:16.485) 00191 > (11:13:21.460) [CR]AT+CIPSENDBUF=0,0006 > (11:13:21.593) 00192[CR]AT+CIPSENDBUF=1,0006 > (11:13:21.593) 00192[CR]AT+CIPSENDBUF=2,0006 > (11:13:21.593) 00192 > (11:13:26.567) [CR]AT+CIPSENDBUF=0,0006 > (11:13:26.567) 00193 > (11:13:26.715) [CR]AT+CIPSENDBUF=1,0006 > (11:13:26.715) 00193[CR]AT+CIPSENDBUF=2,0006 > (11:13:26.715) 00193 > (11:13:31.659) [CR]AT+CIPS > (11:13:31.675) ENDBUF=0,0006 > (11:13:31.675) 00194 > (11:13:31.775) 00194 > (11:13:31.775) [CR]AT+CIPSENDBUF=1,0006 > (11:13:31.775) 00194[CR]AT+CIPSENDBUF=2,0006 > (11:13:36.767) [CR]AT+CIPSENDBUF=0,0006 > (11:13:36.767) 00195 > (11:13:36.900) [CR]AT+CIPSENDBUF=1,0006 > (11:13:36.900) 00195[CR]AT+CIPSENDBUF=2,0006 > (11:13:36.900) 00195 > (11:13:41.858) [CR]AT+CIPSENDBUF=0,0006 > (11:13:41.989) 00196[CR]AT+CIPSENDBUF=1,0006 > (11:13:41.989) 00196[CR]AT+CIPSENDBUF=2,0006 > (11:13:41.989) 00196 > (11:13:46.966) [CR]AT+CIPSENDBUF=0,0006 > (11:13:46.966) 00 > (11:13:47.103) 197[CR]AT+CIPSENDBUF=1,0006 > (11:13:47.103) 00197[CR]AT+CIPSENDBUF=2,0006 > (11:13:47.103) 00197 > (11:13:52.057) [CR]AT+CIPSENDBUF=0,0006 > (11:13:52.185) 00198[CR]AT+CIPSENDBUF=1,0006 > (11:13:52.185) 00198[CR]AT+CIPSENDBUF=2,0006 > (11:13:52.185) 00198 > (11:13:57.149) [CR]AT+CIPSENDBUF=0,0006 > (11:13:57.277) 00199[CR]AT+CIPSENDBUF=1,0006 > (11:13:57.277) 00199[CR]AT+CIPSENDBUF=2,0006 > (11:13:57.277) 00199 > (11:14:02.256) [CR]AT+CIPSENDBUF=0,0006 > (11:14:02.256) 00200 > (11:14:02.388) [CR]AT+CIPSENDBUF=1,0006 > (11:14:02.388) 00200[CR]AT+CIPSENDBUF=2,0006 > (11:14:02.388) 00200 > (11:14:07.348) [CR]AT+CIPSENDBUF=0,0006 > (11:14:07.473) 00201[CR]AT+CIPSENDBUF=1,0006 > (11:14:07.473) 00201[CR]AT+CIPSENDBUF=2,0006 > (11:14:07.473) 00201 > (11:14:12.455) [CR]AT+CIPSENDBUF=0,0006 > (11:14:12.583) 00202[CR]AT+CIPSENDBUF=1,0006 > (11:14:12.583) 00202[CR]AT+CIPSENDBUF=2,0006 > (11:14:12.583) 00202 > (11:14:17.547) [CR]AT+CIPSENDBUF=0,0006 > (11:14:17.704) 00203[CR]AT+CIPSENDBUF=1,0006 > (11:14:17.704) 00203[CR]AT+CIPSENDBUF=2,0006 > (11:14:17.704) 00203 > (11:14:22.654) [CR]AT+CIPSENDBUF=0,0006 > (11:14:22.654) 00204 > (11:14:22.783) [CR]AT+CIPSENDBUF=1,0006 > (11:14:22.783) 00204[CR]AT+CIPSENDBUF=2,0006 > (11:14:22.783) 00204 > (11:14:27.746) [CR]AT+CIPSENDBUF=0,0006 > (11:14:27.866) 00205[CR]AT+CIPSENDBUF=1,0006 > (11:14:27.866) 00205[CR]AT+CIPSENDBUF=2,0006 > (11:14:27.866) 00205 > (11:14:32.853) [CR]AT+CIPSENDBUF=0,0006 > (11:14:32.853) 00206 > (11:14:33.006) [CR]AT+CIPSENDBUF=1,0006 > (11:14:33.006) 00206[CR]AT+CIPSENDBUF=2,0006 > (11:14:33.006) 00206 > (11:14:37.961) [CR]AT+CIPSENDBUF=0,0006 > (11:14:37.961) 00207 > (11:14:38.095) [CR]AT+CIPSENDBUF=1,0006 > (11:14:38.095) 00207[CR]AT+CIPSENDBUF=2,0006 > (11:14:38.095) 00207 > (11:14:43.053) [CR]AT+CIPSENDBUF=0,0006 > (11:14:43.190) 00208[CR]AT+CIPSENDBUF=1,0006 > (11:14:43.190) 00208[CR]AT+CIPSENDBUF=2,0006 > (11:14:43.190) 00208 I had the MCU to send a message every 5 seconds for this. I will try to do this without MCU but I don’t know if I’m able. I hope this will be helpful. ### Reply 20 by viktor, 2021-01-29 Hello, In your log I see only messages to WizFi360 but there are not shown responses from our module. Do you process responses from WizFi360? CIPSENDBUF will return “>”, and then it is possible to enter message to be sent. ### Reply 21 by KVLM, 2021-01-29 Hello, We do get responses from WizFi but we can only read from one side currently, so it’s ready what the MCU is sending. We will try to make it so we are able to read from both sides. Yes, we are waiting for “>” to return, if we didn’t then the message wouldn’t be sent, or it would send something else other than what we needed it to send. The Delay only happens if the WizFi is connected to an AP, if it couldn’t connect to an AP on power up, then the delay doesn’t happen at all and everything works well. But if its connected to an AP then the delays start happening. ### Reply 22 by KVLM, 2021-01-29 Hello, We have ordered another WizFi360 so we can use it to test it without an MCU, but with a serial-USB USB-UART converter to send it the commands. If it ends up working with the same settings but not with an MCU then what would that mean? ### Reply 23 by viktor, 2021-02-01 (in reply to reply 22) Hello, I have conducted many tests and tried to search for anything that could cause these delays, but unfortunately couldn’t find any. In my opinion it might be caused by library from chip manufacturer. I will try to ask them if they had this issue. ### Reply 24 by KVLM, 2021-02-01 Hello, But if it is caused by code, then why does it work properly when Wizfi STA isn’t connected to an Access Point? ### Reply 25 by viktor, 2021-02-01 Hi, It might be caused by library from chip manufacturer too and we are not able to debug it. I am trying to contact them at the moment. Please test without MCU and let me know. ### Reply 26 by KVLM, 2021-02-01 Hello, By that you mean WizFi Firmware Library? I will test it without MCU when the new WizFi360 arrives later this week. ### Reply 27 by viktor, 2021-02-02 Hello, WizFi360 is a module that is built on W600 chip from WInnerMicro. Our firmware utilizes its library to operate with chip. It looks to me like this issue is caused by their library, and we at WIZnet are not able to fix it. That’s what I was trying to explain. ### Reply 28 by KVLM, 2021-02-02 Hello, I understand, than you for explaining. I will wait for more news then, in the mean time I will test it without MCU when the new WizFi360 arrives. ### Reply 29 by KVLM, 2021-02-08 Hello, Have you got any news about this problem? ### Reply 30 by KVLM, 2021-02-23 Hello, I’m still waiting on an update on this. ### Reply 31 by viktor, 2021-02-23 Hi, Unfortunately, there was no reply from chip manufacturer… Were you able to test using WizFi360 without MCU? ### Reply 32 by KVLM, 2021-02-23 (in reply to reply 31) Hello, Yes I was able to test WizFi360 without MCU and the results are the same, the messages still get delayed. (11:04:26.832) AT+CIPMUX=1 (11:04:26.896) AT+CIPMUX=1 (11:04:26.896) (11:04:26.896) OK (11:04:37.039) AT+CIPSERVERMAXCONN=3 (11:04:37.116) AT+CIPSERVERMAXCONN=3 (11:04:37.116) (11:04:37.116) OK (11:04:46.888) AT+CIPSERVER=1,5000 (11:04:46.972) AT+CIPSERVER=1,5000 (11:04:46.972) (11:04:46.972) OK (11:04:49.110) 0,CONNECT (11:04:53.307) AT+CIPSENDBUF=0,10 (11:04:53.414) AT+CIPSENDBUF=0,10 (11:04:53.414) 1,0 (11:04:53.414) (11:04:53.414) OK (11:04:53.414) > (11:04:53.492) 0123456789 (11:04:53.570) (11:04:53.570) busy s… (11:04:53.570) (11:04:53.570) Recv 10 bytes (11:04:53.570) (11:04:53.570) 0,1,SEND OK (11:04:54.211) AT+CIPSENDBUF=0,10 (11:04:54.275) AT+CIPSENDBUF=0,10 (11:04:54.275) 2,1 (11:04:54.275) (11:04:54.275) OK (11:04:54.275) > (11:04:54.381) 0123456789 (11:04:54.391) (11:04:54.391) busy s… (11:04:54.391) (11:04:54.391) Recv 10 bytes (11:04:54.391) (11:04:54.391) 0,2,SEND OK (11:04:55.643) AT+CIPSENDBUF=0,10 (11:04:55.762) AT+CIPSENDBUF=0,10 (11:04:55.762) 3,2 (11:04:55.762) (11:04:55.762) OK (11:04:55.762) > (11:04:55.879) 0123456789 (11:04:56.004) (11:04:56.004) busy s… (11:04:56.004) (11:04:56.004) Recv 10 bytes (11:04:56.004) (11:04:56.004) 0,3,SEND OK (11:04:56.995) AT+CIPSENDBUF=0,10 (11:04:57.165) AT+CIPSENDBUF=0,10 (11:04:57.165) 4,3 (11:04:57.165) (11:04:57.165) OK (11:04:57.165) > (11:04:57.254) 0123456789 (11:04:57.416) (11:04:57.416) busy s… (11:04:57.416) (11:04:57.416) Recv 10 bytes (11:04:57.710) (11:04:57.710) 0,4,SEND OK (11:04:58.663) AT+CIPSENDBUF=0,10 (11:04:58.767) AT+CIPSENDBUF=0,10 (11:04:58.767) 5,4 (11:04:58.767) (11:04:58.767) OK (11:04:58.767) > (11:04:58.943) 0123456789 (11:04:59.108) (11:04:59.108) busy s… (11:04:59.108) (11:04:59.108) Recv 10 bytes (11:04:59.108) (11:04:59.108) 0,5,SEND OK (11:04:59.595) AT+CIPSENDBUF=0,10 (11:04:59.709) 0123456789 (11:04:59.792) AT+CIPSENDBUF=0,10 (11:04:59.792) 6,5 (11:04:59.792) (11:04:59.792) OK (11:04:59.792) > (11:04:59.792) (11:04:59.792) busy s… (11:04:59.792) (11:04:59.792) Recv 10 bytes (11:05:01.604) (11:05:01.604) 0,6,SEND OK (11:05:06.187) AT+CIPSENDBUF=0,10 (11:05:06.291) AT+CIPSENDBUF=0,10 (11:05:06.291) 7,6 (11:05:06.291) (11:05:06.291) OK (11:05:06.291) > (11:05:06.460) 0123456789 (11:05:06.626) (11:05:06.626) busy s… (11:05:06.626) (11:05:06.626) Recv 10 bytes (11:05:13.171) (11:05:13.171) 0,7,SEND OK (11:05:15.509) AT+CIPSENDBUF=0,10 (11:05:15.621) AT+CIPSENDBUF=0,10 (11:05:15.621) 8,7 (11:05:15.621) (11:05:15.621) OK (11:05:15.621) > (11:05:15.710) 0123456789 (11:05:15.877) (11:05:15.877) busy s… (11:05:15.877) (11:05:15.877) Recv 10 bytes (11:05:18.373) (11:05:18.373) 0,8,SEND OK (11:05:19.963) AT+CIPSENDBUF=0,10 (11:05:20.101) AT+CIPSENDBUF=0,10 (11:05:20.101) 9,8 (11:05:20.101) (11:05:20.101) OK (11:05:20.101) > (11:05:20.230) 0123456789 (11:05:20.397) (11:05:20.397) busy s… (11:05:20.397) (11:05:20.397) Recv 10 bytes (11:05:20.397) (11:05:20.397) 0,9,SEND OK (11:05:22.107) AT+CIPSENDBUF=0,10 (11:05:22.291) AT+CIPSENDBUF=0,10 (11:05:22.291) 10,9 (11:05:22.291) (11:05:22.291) OK (11:05:22.291) > (11:05:22.387) 0123456789 (11:05:22.468) (11:05:22.468) busy s… (11:05:22.468) (11:05:22.468) Recv 10 bytes (11:05:22.633) (11:05:22.633) 0,10,SEND OK (11:05:25.131) AT+CIPSENDBUF=0,10 (11:05:25.227) AT+CIPSENDBUF=0,10 (11:05:25.227) 11,10 (11:05:25.227) (11:05:25.227) OK (11:05:25.227) > (11:05:25.394) 0123456789 (11:05:25.560) (11:05:25.560) busy s… (11:05:25.560) (11:05:25.560) Recv 10 bytes (11:05:25.560) (11:05:25.560) 0,11,SEND OK (11:05:29.499) AT+CIPSENDBUF=0,10 (11:05:29.628) AT+CIPSENDBUF=0,10 (11:05:29.628) 12,11 (11:05:29.628) (11:05:29.628) OK (11:05:29.628) > (11:05:29.790) 0123456789 (11:05:29.878) (11:05:29.878) busy s… (11:05:29.878) (11:05:29.878) Recv 10 bytes (11:05:30.085) (11:05:30.085) 0,12,SEND OK (11:05:31.448) AT+CIPSENDBUF=0,10 (11:05:31.632) AT+CIPSENDBUF=0,10 (11:05:31.632) 13,12 (11:05:31.632) (11:05:31.632) OK (11:05:31.632) > (11:05:31.726) 0123456789 (11:05:31.811) (11:05:31.811) busy s… (11:05:31.811) (11:05:31.811) Recv 10 bytes (11:05:32.127) (11:05:32.127) 0,13,SEND OK (11:05:32.260) AT+CIPSENDBUF=0,10 (11:05:32.315) AT+CIPSENDBUF=0,10 (11:05:32.315) 14,13 (11:05:32.315) (11:05:32.315) OK (11:05:32.315) > (11:05:32.324) 0123456789 (11:05:32.334) (11:05:32.334) busy s… (11:05:32.334) (11:05:32.334) Recv 10 bytes (11:05:32.446) (11:05:32.446) 0,14,SEND OK (11:05:41.398) AT+CIPSENDBUF=0,10 (11:05:41.549) AT+CIPSENDBUF=0,10 (11:05:41.549) 15,14 (11:05:41.549) (11:05:41.549) OK (11:05:41.549) > (11:05:41.680) 0123456789 (11:05:41.771) (11:05:41.771) busy s… (11:05:41.771) (11:05:41.771) Recv 10 bytes (11:05:41.771) (11:05:41.771) 0,15,SEND OK (11:05:43.747) AT+CIPSENDBUF=0,10 (11:05:43.888) AT+CIPSENDBUF=0,10 (11:05:43.888) 16,15 (11:05:43.888) (11:05:43.888) OK (11:05:43.888) > (11:05:43.935) 0123456789 (11:05:44.181) (11:05:44.181) busy s… (11:05:44.181) (11:05:44.181) Recv 10 bytes (11:05:44.181) (11:05:44.181) 0,16,SEND OK (11:05:44.779) AT+CIPSENDBUF=0,10 (11:05:44.915) AT+CIPSENDBUF=0,10 (11:05:44.915) 17,16 (11:05:44.915) (11:05:44.915) OK (11:05:44.915) > (11:05:44.964) 0123456789 (11:05:45.122) (11:05:45.122) busy s… (11:05:45.122) (11:05:45.122) Recv 10 bytes (11:05:45.122) (11:05:45.122) 0,17,SEND OK (11:05:46.531) AT+CIPSENDBUF=0,10 (11:05:46.691) > (11:05:46.691) AT+CIPSENDBUF=0,10 (11:05:46.691) 18,17 (11:05:46.691) (11:05:46.691) OK (11:05:46.783) 0123456789 (11:05:46.946) (11:05:46.946) busy s… (11:05:46.946) (11:05:46.946) Recv 10 bytes (11:05:46.946) (11:05:46.946) 0,18,SEND OK (11:05:47.787) AT+CIPSENDBUF=0,10 (11:05:47.882) AT+CIPSENDBUF=0,10 (11:05:47.882) 19,18 (11:05:47.882) (11:05:47.882) OK (11:05:47.882) > (11:05:48.055) 0123456789 (11:05:48.220) (11:05:48.220) busy s… (11:05:48.220) (11:05:48.220) Recv 10 bytes (11:05:48.220) (11:05:48.220) 0,19,SEND OK (11:05:49.267) AT+CIPSENDBUF=0,10 (11:05:49.407) AT+CIPSENDBUF=0,10 (11:05:49.407) 20,19 (11:05:49.407) (11:05:49.407) OK (11:05:49.407) > (11:05:49.537) 0123456789 (11:05:49.705) (11:05:49.705) busy s… (11:05:49.705) (11:05:49.705) Recv 10 bytes (11:05:49.705) (11:05:49.705) 0,20,SEND OK (11:05:50.995) AT+CIPSENDBUF=0,10 (11:05:51.133) AT+CIPSENDBUF=0,10 (11:05:51.133) 21,20 (11:05:51.133) (11:05:51.133) OK (11:05:51.133) > (11:05:51.292) 0123456789 (11:05:51.456) (11:05:51.456) busy s… (11:05:51.456) (11:05:51.456) Recv 10 bytes (11:05:51.456) (11:05:51.456) 0,21,SEND OK And the time stamped messages when they arrived: [![Screenshot_20210223_110604_com.tetron.packetron](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/2/204531ebeea5944f9e15f596d58f6a34a5702392.jpeg) Screenshot_20210223_110604_com.tetron.packetron800×2192 188 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/2/204531ebeea5944f9e15f596d58f6a34a5702392.jpeg) As you can see, the delay is still there in some of the messages. even without an MCU. ### Reply 33 by viktor, 2021-02-23 Hello, What bothers me is that you are getting “busy s…” message every time. It might be caused by CR LF settings in your terminal. Please check if possible. ### Reply 34 by KVLM, 2021-02-24 Hello, I’m not quite sure what you mean by that, but my text settings for YAT is this: ![kép](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/d/d646e40d770ebafb48c10ada64f85154df20b2a1.png) I don’t see how this would cause that. ### Reply 35 by viktor, 2021-02-26 Hi, You have set for Tx EOL sequence. When sending command through YAT, if you have another \r\n at the end, this could cause getting “busy s…” messages. But that wouldn’t be the cause of delay, in my opinion. Have you tried using other CIPSEND commands? ### Reply 36 by KVLM, 2021-02-26 (in reply to reply 35) Hello, I did try the other CIPSEND commands, but CIPSENDEX isn’t good since some of the messages we need to send contains \0 NULL characters, and normal CIPSEND command isn’t good since I have to wait for SEND OK before I can send the next message, so if I have to send more messages in quick succession after each other I won’t be able to do it and I am unable to store the messages to send them later. ### Reply 37 by KVLM, 2021-03-09 (in reply to reply 35) Hello, Is there any news regarding this problem? ### Reply 38 by KVLM, 2021-04-06 (in reply to reply 35) Hello, I guess there is still no answer? ### Reply 39 by viktor, 2021-04-08 Hello, Unfortunately yes, they keep ignoring my messages. I tried to conduct tests for your case with their official SDK provided on their website. However, I could observe similar message delays. I truly believe that this situation is caused by chip manufacturer library. I will continue trying to get in touch with them and will let you know results. Sorry for late reply. ### Reply 40 by KVLM, 2021-04-08 Hello, Thank you for the update. I really hope they will answer and this problem will be solved in time. I will continue to wait for updates on this matter. Thank you, again for your help. ### Reply 41 by KVLM, 2021-04-20 Hello, Is there any updates? Was contacting the manufacturer lead to somewhere yet? ### Reply 42 by viktor, 2021-04-23 Hello Unfortunately no updates yet. I will keep you updated. ### Reply 43 by KVLM, 2021-05-11 (in reply to reply 42) Hello, Is there any news? ### Reply 44 by KVLM, 2021-05-31 (in reply to reply 42) Hello, I presume they still haven’t contacted you guys back? ### Reply 45 by viktor, 2021-06-03 Hello, Yes. I am sending them remind emails periodically. But seems that either i was added to spam or they are just ignoring me… Have you tried disabling keep alive routine that you mentioned before? ### Reply 46 by KVLM, 2021-06-17 (in reply to reply 45) Hello, Like I already said, I tried it without the keep alive routing and it happened even then, even without an MCU inbetween. Have you got any news? ### Reply 47 by KVLZ, 2021-06-17 Hi Viktor, My name is Zoltan, colleague of user KVLM. I would like to ask about possible process we facing. What happens when/if they agree the problem is caused by their library? Is it possible we have to replace our module for a new one? Or Winnermicro make some kind of firmware update, Wiznet also releases one and this could solve our problem. (any other options? ) What is the possible lead time for this? This would be a minimum 600-700 units/ year project with our German automotive partner, so the solution is really important for us. Thank you! ### Reply 48 by viktor, 2021-06-17 Hello, I believe that this issue is caused by vendor library, but I couldn’t get any response from them. Unfortunately, this library is not open-source code, so we at WIZnet cannot fix it. It is also hard to estimate lead time as it doesn’t depend on us. ### Reply 49 by KVLZ, 2021-06-18 (in reply to reply 48) Hi, Thank you! If your vendor solves this problem what could it mean for us? Hardware modification(new W600 chip in Wiznet modules) or just a new firmware? ### Reply 50 by viktor, 2021-06-21 Hello, I believe that this could be solved by upgrading software…but not sure. Have to wait till vendor replies. ### Reply 51 by KVLM, 2021-12-10 (in reply to reply 50) Hello, We are still waiting on updates. Thank you. ### Reply 52 by kreestyahn, 2022-06-07 Hello, Has the vendor replied yet? Is there any update? --- Source: https://maker.wiznet.io/forum/14121