ESP8266 completely unreliable

[MikeBolton]

We have been trying to use ESP-01 modules for a project over many months. We have used all SDKs from 0.9.5 to 1.4. We have our own code for interfacing to a microcontroller (PIC). Communication is TCP with a Smartphone (Android) app.

1. When we try to connect the WiFi using DHCP, the phone sometimes connects immediately, sometimes after a while and occasionally not at all. We have also tried the 'touching' of the antenna as reported by others which sometimes allowed connection quicker.

2. When we do get a connection and set up the module for a SoftAP/ TCP server, the Smartphone app connects quickly sometimes, sometimes after several tries and sometimes never. If it takes many tries, it then fails to work correctly. However, if it does connect immediately, it then works correctly, so it is not our code issue.

3. When we do get a correct connection, there are often, (but not predictable) delays between the message being sent from the Smartphone and issuing from the ESP UART. Many times, nothing comes out of the UART at all. Others have reported this apparent TCP delay but it may not even be a TCP issue. This is no use at all for a control application.

Reason for thinking this is the ESP behaviour is different on each power on. It can work fine for weeks then go haywire next time it is powered on. When it is not working correctly, I can power off and on again and it often fixes itself. From my experience, this could be registers not being initialised correctly (at all?) on POR or being corrupted when in use. The relevant routines here are 'hidden' !

As it stands, the ESP8266 in a ESP_01 module is just too unreliable (unpredictable) to be of any use in a 'real-time' control application.

We have wasted too many man-hours on this. The hardware is just what we want. The firmware is in serious need of 'fixing'.

Mike Bolton

[ESP_Faye]

Hi,

Could you please provide the captured WiFi packets for debugging ?

You can capture the WiFi packets by omnipeek, or wireshark, or other tools.

[MikeBolton]

Hi

How can I use Wireshark (which I have) to capture packets when all I have is a Smartphone and the ESP-01? The only comms I have is via the ESP USART lines. I am monitoring the traffic to and from the ESP USART with a PC program. My Wireshark works on an Ethernet connection. Can I set up Wireshark on another PC to act as a sniffer of the WiFi? (I am running out of available PCs for this)

The serious unreliability issues have not gone away. The delay between the Phone sending and something coming out of the ESP USART is between immediate and many seconds. (TCP/IP) and completely unpredictable. No use for a real-time control scheme. Messages getting stuck in the TCP stack?

We are not using the AT command set as this is far to slow and clumsy. We have our own ESP code that communicates with a PIC microcontroller that replaces the AT code. Our objective is to receive TCP info from a Smartphone app and send this to a CAN network and from CAN back to the Phone when needed.

Mike Bolton

[ESP_Faye]

Hi,

You need to capture the WiFi packets.
Could you use PC to communicate with ESP8266 through WiFi, and use wireshark to capture the WiFi packets ?
UART output logs can also help a little, could you provide the UART output logs for debugging ?

[MikeBolton]

As the comms from the Smartphone and its app. work perfectly with other WiFi AP devices (like a TP-LINK nano and a Netgear) the problem doesn't seem to be in the WiFi link. Other members of our development team have had the same issues. It seems to relate to the TCP stack code. The problem is much worse with short messages (of which most of ours are). The messages are reaching the ESP OK. They then get stuck in the stack in an unpredictable manner. Sometimes they don't come out at all until you send another message, then the first one comes out at the start of the second. We need a TCP stack that sends to the SDK as soon as the incoming TCP message has completed, and consistently. There are times when it works fine, sometimes when we wait up to 30 seconds for the message and sometimes not at all. We also get a 'stack' of short messages piling up and then they all come at once. No use for a real-time control system. I think your TCP stack code is in serious need of an overhaul.

A USART dump would mean nothing to you as we don't use the AT code but our own short command version.

Mike Bolton

[ESP_Faye]

Hi,

Please provide your test code, we will have a try.

If there are UART output logs, or WiFi captured packets for debugging, it will be even better.

Thanks for your interest in ESP8266 !

[MikeBolton]

To Espressif_Faye

We don't have 'test code' as such but there is ESP application code that replaces the AT set. We would need to provide a full description of this. Also this interfaces with a PIC microcontroller. With respect to the slow TCP handling, on of our team has found the following:

'Reading through the forums, there does seem to a recognition that the TCP throughput is slow , around an aggregate of 7Kb/sec with TCP interpacket delays of upto 0.8 of a sec, ie random delays.'

Also

'However there seems to be anecdotal evidence that the RTOS version of the SDK results in faster TCP traffic, ( by how much, I can't tell)'

Do you, or anyone else have experience of the TCP operation using the RTOS? Random delays are not acceptable for our application. Imagine your car brake operated with an ESP ! Our application is not so safety critical but does involve real-time control of quite expensive items.

Mike Bolton

[ESP_Faye]

Hi,

Sorry that we could not duplicate your problem.

Here is our sample codes http://bbs.espressif.com/viewforum.php?f=31, could it help ?

Could you please provide your test code, or UART output logs, or WiFi captured packets for debugging ?

Thanks for your interest in ESP8266 !

[George_]

Hey Mike,

I am also having similar problems with getting a reliable TCP data stream, did you find a way to fix this?

regards,