Strange UART waveforms at power-up (ESP8266)

I am finishing a new external component that can locally control my Midea MAD50 dehumidifier. Currently I got stuck because the extra UART transmissions and an unexpected low pulse make the appliance not response to UART commands.

I try to dig into this issue a bit more. Here are the three cases that I looked into.

Case 1:
ESP8266 running ESPHome, set the logger to UART1, commands were sent by UART0 hardware on GPIO01 and GPIO03.


As shown in the trace above, there are multiple extra message appeared on the TX pin at power-up. I am not sure whihc section is from ESP8266’s ROM code, and which are belongs to ESPHome code.
On top of it, the TX pin got pull low for some time before my code can send the initial query to the appliance. In this case, the applianc will not response at all.

Case 2:
ESP8266 running ESPhome, logger section was totally removed, rewired GPIO14 as the TX and GPIO02 as the RX. In this case, the software UART is used on GPIO14 and 02.


However, it is not working as well. From the above tracing at power-up, the extra transmissions on the TX went away because it is a software UART. However, the unexpected low pulse is still there which causing the appliance not responding to UART at all. ( I have confirmed with an Arduino, see below)

Case 3:
Arduino hardware UART.


Now, everything works as expected. I also intentionally add a low pulse in arduino code, which confirmed the extra low pulse causes the applicance not responding.

Now, the question becomes why ESPHome outputs extra low level when setting a GPIO for UART output?
This is pretty much a deal breaker for my project. ESP8266 only has one UART, and this UART has been heavily polluted by both ROM code and esphome logger. Software UART also has extra low pulse at power-up. On top of it, the softrware UART’s timing is not that accurate so my appliance has some chance not responing to its command.

I kind of hesitate to try out on ESP32 becuas of the high concern of UART pollution.

Any comments?

This is well known behavior of the esp8266. Use an esp32 with multiple UARTs or look here for a simple HW solution

I guess I came across this page in the last a few days. It is a bit unclear where to add this Serial.swap() ? If it is in the flash code, it is very much unlikely to have any impact to the ROM code output.

On top of it, the ESPhome somehow pull the TX low for ~50 ms before releasing the pin for application’s UART transmission.

The circuit allows you to control when the UART pin (on the ESP8266) can bring the line low (to your other circuit).

You likely do not need the swap, since you are doing that in esphome with setting the logger. You do need an extra GPIO pin (that is okay to pull up on boot) that you then set as a GPIO output (does not need to be a switch). Sometime after boot you need to set the output low (it might work if you just its default to be low, since the bad stuff happens before esphome starts).

if the solution is not limiting to tweaking ESP8266 itself. it can be done with more than one way. I designed the dongle replacement board exactly fits to the original dongle’s casing… If I have to re-design the board, I will get away from ESP8266 for sure. Rpi pico W would be a nice attempt.

Not sure what you mean by that. The esp8266 ALWAYS outputs on its UART at boot. That is BY DESIGN for the chip. Some would argue it is a bad design, especially since they got the baud rate wrong (unusual at least).

If you don’t want to add hardware to what you have to get a different behavior, sure you can replace everything (and get a different set of constraints to get the behavior you want).

Like @neel-m earlier suggested, Esp32 might be preferable. If you want to challenge yourself go with the most exotic chip you find and make sure it doesn’t have sufficient quantity of pins exposed.

1 Like

there is no doubt that targeted application is unhappy about anything extra appears on Tx during power-up. At the same time, the appliance is pretty picky about UART baud rate timing. These baud rate timing constrain almost eliminate the possibility of using ESP8266’s software UART. Let alone the unexplained Tx low pulse before any application UART transmissions.

Adding some hardware to control the behavior of the hardware UART TX pin is a way to get it work. However, it requires a PCB redesign, and 1 month lead time at here. Given the situation that I have to redesign the board, picking another more suitable MCU platform would be a natural choice.

I do not have Rpi pico W on hands, but I did try the same code on ESP32. Form the power-up Tx traces, it looks good. I will have to level shift the signal to 5V to try on the actual appliance. If everything works, the redesign will be with ESP32.

Yep, have tried on ESP32 already. Scope traces look fine. Will post here after trying out on the actual appliance.
I ordered a few Pico W as well at the same time, not holding my breath on it but it is good not to limiting to ESP platform alone.

Interesting enough, the original WIFI dongle is RTL8720C based… which might be directly programmable with ESPhome …

not only EPS8266 spills debug info, I saw ESP32 has it as well. It is not necessarily a bad design but it for sure requires additional consideration when designing with these chips. I guess the unusual 74800 baud rate is a partial mitigation from the chip designer perspective.

On ESP32, I noticed something interesting as well. Whenever I send something to UART1, I saw the same data on UART0 at the same time :slight_smile: I guess this is how ESPhome core deals with UART.

I soldered a few jumper wires to ESP32, and the same code works right away.


There is no extra logging on Tx pin. There is no unexpected low pulse to the TX pin as well. The appliance responses right away after booting up : )

Here is the user interface. I implemented text sensors, switches, selects, and number slides for controlling the dehumidifier. I am new to external component development. This is essentially my first external component :slight_smile: Any suggests to the interface implementation are welcome.

After re-spin the board, I will put the external component code to github.