- Mon Apr 01, 2019 9:12 am
#81478
this is really great to know and appreciate the creator, thanks for sharing
- Mon Apr 01, 2019 1:29 pm
#81482
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.
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.
- Wed Apr 03, 2019 6:03 pm
#81546
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'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!
- Fri Apr 05, 2019 3:02 am
#81571
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.
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.
