SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By hypnokevin
I've spent a few days messing with this board and its library. It seems to me now that it's not typically used as a server! I've found a number of issues:

The biggest is that when you do
Code: Select all
ESP8266Client = server.available();
all the read()s include all the AT responses from the ESP8266, like
Code: Select all
prefixing 8 bytes of TCP data. \r\n0,CONNECT\r\n and \r\n0,CLOSED\r\n are also common, and I'm sure other responses leak in. Luckily, I'm using a super-simple TCP protocol that sends 8 bytes at a time, where I'm only interested in the first byte's value and then having 7 bytes of 0. I was able to parse for that. But!..

The ESP8266 seems to drop tons of packets, and my best guess is that it's trying to sleep to conserve power. Under the most optimal wifi conditions (more on this later), I found that a new connection would drop tons and tons of packets until it started to react normally. In my case, I was dragging a slider up and down to send 8-byte packets where the first byte represented the 0-255 slider value. After 5+ seconds, the Arduino felt like it was reacting in real time, and it would continue to do so until I paused for a bit.

I tested it on 2 wifi networks -- one, my office's very busy main Aruba AP, and the other, a fancy consumer Netgear Nighthawk router with only the ESP8266 server and another client connected. Surprisingly, the Aruba performed better overall -- sometimes my slider-dragging updates felt real-time (low latency, high bandwidth) to the Arduino! Other times, latency and bandwidth were worse. Many packets were dropped, and latency was all over the place. I can't rely on it at all.

All in all, with TCP, no packets should be dropped! That's the whole point. I suppose the ESP8266 firmware chooses to drop packets to support the lousy 9600 baud software serial connection to the Arduino...???

I learned a lot by reading the Sparkfun ESP8266 Arduino library source code ( ... no_Library). I also looked through the firmware ( ... r/Firmware) and found no evidence of code that drops packets... but I'm just a software engineer who dabbles in hardware. I could be wrong!

Also, if this helps anybody, I found that calling client.connected() was often very very slow. I think for a long-running installation, you might want to call that verrrry rarely to make sure you're connected. And for me, it almost always reported as disconnected, even if my connection still worked... so... YMMV
By paulvha
I have spend also a lot of time on the ESP8266 and have updated the driver (fixed bugs and extended features). The existing examples can still be used (backward compatible) but new ones have been added to show the new features, including a subroutine to parse the received TCP message in an easy way. It has extended documentation for help and can be downloaded from ... no_Library.

The issue of dropping packets is because of Softserial. The standard buffer is 64 bytes and once that fills up, the receive buffer is completely cleared. it is described in workbook_server_walkback or talkback.odt in the "extra" directory, also what you can try to do about it: extend the receive buffer.

That said the buffer handling has been changed on some places for resilance as well as the original way to check client.connected(), couple of the many bug fixes).