espsoftwareserial
espsoftwareserial copied to clipboard
plerup
High bit error rate at 9600 bauds
I've integrated EspSoftwareSerial into ESPHome (https://github.com/anatoly-savchenkov/esphome/tree/espsoftwareserial_uart) seeking for a full duplex SW UART implementation instead of a half duplex native one. Details of what I'm trying to solve / achieve are here https://github.com/esphome/esphome/pull/3657.
UART is configured for 9600 8N1 but I see a high bit error rate for the ingress traffic. Usually errors happen in the first byte of a packet coming from the peer (which is Nextion display in my case). TX part seems to be ok. Platform is ESP8266.
I'm seeking for ideas to try or recommendations what to collect to help with debugging.
If your data is really running in concurrent mode, that is, RX and TX as the same time, software serial is very likely to fail due to timing constraints. If you can swap the HW serial UART(s) for the software one, please do so. Otherwise, your choice of the ESP8266 may need to be reconsidered in favor of the ESP32s, which have more than a single fully featured UART on-board.
I would love to use HW UART or ESP32 but this is a COTS device and I'm trying to bring up an alternative FW for it :)
I don't really understand why approach used in EspSoftwareSerial shouldn't work. I planned to implement exactly the same (collect RX interrupt timestamps and decode a byte after that) before I found this project.
So far I see only ESP8266 WiFi interrupts which have higher priority than GPIO lines and thus can spoil RX IRQ timings. From the experience you have, do you know if this and other factors you know can be mitigated at least to certain extent? Now I see like every transaction has bit errors, even those which are sequential (like TX request / RX response).
@anatoly-savchenkov I would like to point you toward #260 at this time, it is a fix for any CPU frequency changes that the SDK may perform during WiFI activity etc.
@anatoly-savchenkov Please review any of the latest releases, this issues would be closed as stale soon.
I'm eager to try last 2 releases which from the description look potentially relevant for what I was observing. Unfortunately, have been traveling last couple of months while nature of the device I was using requires physical interaction with it (it's a touch screen). I will be able to try new versions of your library in 2 weeks from now once I'm back.
@dok-net I have a good and a bad news for you :) I'm still traveling but I managed to take my device to one of my trips. And it works perfectly with the latest (7.0.0) release. That's a good news. A bad news is that it works with the original version (6.16.1) as well. It seems like you were right saying that WiFi activity influences the behavior. Unfortunately it seems like it's more a dependency on background activity in the air and most probably it was something special with WiFi network which I used at the time of the problem. With the current network I was not able to trigger even a single corrupted byte after couple of hours of testing. Unfortunately, I won't be able to reproduce the original environment where I saw problems as it was WiFi a rented summer house and I don't have plans to return there. So, let's close the ticket.