ESP8266 Community Forum

this is really great to know and appreciate the creator, thanks for sharing

250 kbaud? As in 250000 bits per second? That is quite an amount of data. The UART is able to handle that with no problem, but I am not sure the ESP8266 (including software) will be able to shift around those amounts of data around from/to UART from / to network.

Having said that, if you say it has been working for you, I think there must be a method, one way or another to get it working as it did before.

The led pixel I/O is probably not the cause, what is the cause is that I am rewriting the whole network stuff at the moment (as said before). I already found an interesting effect in the TCP code that made all TCP communications very slow. I solved that now. Are you using TCP or UDP for the bridge? This may also be the cause for the slow UART I've been reporting earlier.

If you can have a little bit of patience yet, please wait for the next release and try again. Currently I have been rewriting yet more stuff and I think it's a bit too early to release now, though.

Yes. I can lower the speed to 57600 bps without losing much smoothness if that would lower the load on the esp.
I'm using TCP because i need the packets received in the right order and also i'm planning on having a few robots connected to the same central unit. Another approach would be using UDP with specific ports for each robot but i'm not quite sure i would reach the desired results.

Patience. I has it ! I'll wait patiently for your update . thanks again!

I don't think switching to UDP will help per sé.

Anyway, the whole network code is very much "in flux" (as not to say: "a mess"), when it's settling down, I will have a particular good look at the latency, I am quite confident I must be able to get at least the same numbers as before.

Also I realised the UARTs of the ESP8266 have a "loopback" mode. It will probably help me test this. Let's see if it works like I expect.