I’m using a WizFi360-con on a carrier board connected to a microcontroller using the serial uart pins. I’m finding that it appears to be very slow when transmitting multiple data packets, and does not ping reliably.
Firmware: AT version:1.1.1.8(Jun 28 2022 10:20:03)
For example, some packets will transmit in a few milliseconds, while others will take 30-40 seconds before I get the ‘SEND OK’ message.
Pinging the module looks pretty consistently like this, with a lot of non-response and high variability:
ping 192.168.1.102
PING 192.168.1.102 (192.168.1.102): 56 data bytes
64 bytes from 192.168.1.102: icmp_seq=0 ttl=255 time=19.580 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
64 bytes from 192.168.1.102: icmp_seq=8 ttl=255 time=731.938 ms
64 bytes from 192.168.1.102: icmp_seq=9 ttl=255 time=18.313 ms
Request timeout for icmp_seq 10
64 bytes from 192.168.1.102: icmp_seq=11 ttl=255 time=562.146 ms
64 bytes from 192.168.1.102: icmp_seq=12 ttl=255 time=289.984 ms
64 bytes from 192.168.1.102: icmp_seq=13 ttl=255 time=19.025 ms
64 bytes from 192.168.1.102: icmp_seq=14 ttl=255 time=352.667 ms
64 bytes from 192.168.1.102: icmp_seq=15 ttl=255 time=14.003 ms
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 192.168.1.102: icmp_seq=16 ttl=255 time=2525.937 ms
64 bytes from 192.168.1.102: icmp_seq=17 ttl=255 time=1691.789 ms
64 bytes from 192.168.1.102: icmp_seq=19 ttl=255 time=26.040 ms
^C
— 192.168.1.102 ping statistics —
21 packets transmitted, 11 packets received, 47.6% packet loss
round-trip min/avg/max/stddev = 14.003/568.311/2525.937/783.461 ms
Is this normal?
I’m also using the venerable ESP-01s and it does perform better in both cases and in the overall application (a prometheus node exporter for sensor data).
I was able to mostly work around the wizfi360’s slow send/acknowledge response by accumulating the data into a larger buffer, and then sending when the buffer is close to full so that larger but fewer packets are sent. This helped a great deal. However, I would expect it to perform better with regard to packet transmission, and I am still seeing significant delays for the ‘SEND OK’, just not as many.
My apologies - I had a bug in the printing code that said the CIPSEND=0,5310, when it was really CIPSEND=0,53. The wizfi360 got the correct commend, but when I printed it out, the prior string was not null terminated correctly, so the ‘10’ part came from the prior printf().
After fixing, here is the correct sample - and this one demonstrates the very long times I’m seeing also, over 30 seconds for one of them:
wz360_send(): 'AT+CIPSEND=0,943
'wz360_send(): buf=‘AT+CIPSEND=0,943’, response=‘OK’, time=0 ms
wz360_send(): buf= 943 bytes, response=‘SEND OK’, time=8945 ms
wz360_send(): ‘AT+CIPSEND=0,1010’
wz360_send(): buf=‘AT+CIPSEND=0,1010’, response=‘OK’, time=0 ms
wz360_send(): buf= 1010 bytes, response=‘SEND OK’, time=33197 ms
wz360_send(): ‘AT+CIPSEND=0,53’
wz360_send(): buf=‘AT+CIPSEND=0,53’, response=‘OK’, time=0 ms
wz360_send(): buf= 53 bytes, response=‘SEND OK’, time=35 ms
Reporting back on results. @scarlet, the antennas arrived and I’ve tested with the W5E-WO-03L.
In the meantime, I did adjust the antenna I was using (noted digikey part number earlier), and found that I did get much better performance with certain orientations.
I did the same with the W5E-WO-03L antenna.
Both antennas performed about the same. And much better than originally.
However, I do still get the occasional long delay in send, but not nearly as frequently. Average send time is in the 2-5 second range with an occasional send around 600-800 ms.
I do have very similar code running on my microcontroller using the ESP01S and it most of its timing is in the 400-500 ms range, with an occasional in the 2 second time frame.
So I’m still not getting send performance that I tend to expect to be better than the ESP01S. However, if that’s the way it is, then so be it. The WizFi360 has way more capabilities. But I’d still like to figure out if I’m doing something wrong or not (after correcting antenna orientation), or if those numbers are typical and reasonable for the WizFi360-con.
One more question - in another thread, a member noted that the center pin of the wizfi360-con antenna connector is shorted to the outer ring. And I did confirm on my modules - and both are shorted to the GND pin of the module. That may be fully correct, but it seems odd to me - can you confirm that is indeed the way it is supposed to be? Is there a modification that I need to make to the module so the antenna output is not shorted to GND? I’m not an expert or anything on radio and antenna design, it just seems odd that antenna output and reception would be fed through the GND reference. Can you help clarify that?
I checked about your new problem.
First of all, the problem is not a common problem.
No history of receiving the same issue from customer and wiznet developer.
I’ve tried it many times, too.
But I didn’t have the same problem.
(I checked both firmware 1.1.1.7 and 1.1.1.8, but there was no problem with both.)
I am attaching the test results.
Hello, @scarlet. Thanks again for the followup, and for the research into the issue!
I think I may have figured it out - the board with the WizFi360-con and the board with the ESP01S are relatively close to each other - about 10 inches or so. Meanwhile, two other boards with an ESP01S are much further apart.
The Blue and Green plot are the two boards (one a WizFi (green) and an ESP01 (blue)) that are close to each other. The Yellow and Orange lines are boards with ESP01’s much further away - on different floors of the building. (Please ignore the red plot line - that is the prometheus query itself running on a fast computer and is around 27 ms or less, so it’s not a fair comparison.)
So you can see the variability of both of the boards that are nearby. Note that anything above 10 seconds in the graph is a timeout meaning the WizFi didn’t respond within 10 seconds. As you can see, the WizFi doesn’t perform as well as the ESP01 in this case.
However, the two boards with the ESP01 that are one or more floors away all transmitted in around 500-700 ms - and the two plot lines are nearly on top of each other.
So the fact that the ESP01 nearby the WizFi is much more variable than the other two (but still don’t timeout) make me thing that the WizFi and ESP01 - being in close proximity, are interfering with each other.
Does that sound reasonable to you?
On the antenna connector apparently shorted to ground - both the center pin, and the ring, I understand that a DC short is not necessarily an RF short - so that is probably what is going on there. Confirmation would be great, though.
And for reference, here is the thread on this forum where I first saw this noted: WIZFI360-CON ANT pin
Hi @bsd I’m jaden
The short circuit between the GND and the antenna center pin on the Wizfi360-con is normal. When I checked the other modules (ESP8266, ESP8255), the results were the same.
On the module performance, I believe the issue I’m seeing is due to the WizFi360-con sitting nearby the ESP01 on my bench. I can’t move it easily to test but in this situation, both the WizFi360 and the ESP01 do not perform as well as when isolated.
I do have another board collecting data in another room on another floor. It was using the ESP01. I replaced the ESP01 with a WizFi360-con and am running the same firmware as the module on my bench - both the WizFi firmware, and also my board firmware.
That more isolated module performs much better. However, on average, it is still slightly less than an ESP01 that is also remote on another floor.
Here is about an hours worth of data for the scrape times - they are close, and I’m not concerned about the difference. Note the Yellow line is the WizFi360-con and the Red line is the ESP01. So the WizFi is a bit more variable and has about a 100ms higher baseline, which I’m not overly concerned about:
However, when I include the WizFi from my bench that is nearby the ESP01 (interfering with each other?), this is the Green line and you can see that that module has a much higher response time and multiple timeouts within that same hour or so period:
So … I’m satisfied regarding the cause of the module’s performance. Still not quite as good as the older ESP01 in this application, but is acceptable and not all that different.
Thanks to both you @Jaden and @scarlet for helping and answering my questions. Thanks!
