Here we can all chat about fixing the AT+ command structure and the associated responses.

User avatar
By jwatte
#16401 I'm using an ESP8266-01 module to remote control a walking robot (it's on the robot, and spits out serial data to the robot controller board.)
The firmware identifies itself as: [Vendor:www.ai-thinker.com Version:0.9.2.4]
(The "ATE0" echo-turn-off command works, and it defaults to 9600 baud, if that helps date/place the firmware.)

I'm running the serial port at 230400. I'm receiving UDP packets on a particular port; each packet is 13 bytes long.
I'm currently sending 5 packets per second from the other end; I'm intending to get this to 30.

However, the ESP8266 seems to aggregate multiple packets into a single +IDP notification.
My guess is that it buffers for a little bit before sending on the serial port for "efficiency" reasons.

This is bad for two reasons:
1. It is actually incorrect -- UDP packets are individual units of transmission, and cannot be merged (unlike TCP streams)
2. The latency makes the remote control bit hard to achieve correctly.

Is there a command of some sort to turn off the incoming-data-buffering, and just get each packet immediately as it's received?
User avatar
By jwatte
#17907 The default AT firmware is not suitable for this kind of use.
I ended up using the Arduino IDE to write a custom firmware that establishes the appropriate ports/listening, and then sends a simple packet-based protocol over the UART.
(This also solves the problem with the AT command set not being 100% deterministically parseable)

Also, when writing that firmware, I found a bug in the handling of UDP sockets, and a fix is going into the next arduino release.
The main issue was that a bound server socket would be un-bound and re-assigned some other port number when you tried to send a UDP packet out over it.

I'm doing at least 20 packets per second, in and out, and it's working great with the custom Arduino sketch for me.
User avatar
By matkar
#19732 I stumbled across the same problem. It is impossible to send data more than 5 times per second using official firmware (at_v0.20_on_SDKv0.9.3) because it takes about 200ms before SEND OK response is received after the data is sent over serial connection to ESP. It seems it doesn't matter how long the packet is (tried with 1byte and 80byte UDP transmission) .
In the official documentation 4A-AT-Espressif AT Instruction Set_020.pdf under the CIPSEND command they claim:
Enters unvarnished transmission, 20ms interval between each packet, maximum 2048 bytes per packet. .
Did they forget to place another zero behind "20"?

I'd prefer to use the AT command set and avoid developing a custom firmware for ESP. Has anybody found a solution to this problem?