- Thu Jul 05, 2018 6:42 pm
#199649
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
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 (https://github.com/sparkfun/SparkFun_ES ... no_Library). I also looked through the firmware (https://github.com/sparkfun/ESP8266_WiF ... 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
The biggest is that when you do
Code: Select all
all the read()s include all the AT responses from the ESP8266, like ESP8266Client = server.available(); client.read()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!..\r\n+IPD,0,8,: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 (https://github.com/sparkfun/SparkFun_ES ... no_Library). I also looked through the firmware (https://github.com/sparkfun/ESP8266_WiF ... 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