I'm struggling with a project here. I have an Elechomes EC5501 air humidifier that I want to make "smart". When taking it apart, I found out it uses a circuit board similar in most points to this one here. But on mine, there is a 4-pin connector labeled "UART" that connects the humidifier with the display. By measuring I found out there is a 5V pin, a GND pin, and 2 RX/TX pins that enable communication between the user interface (display with touch buttons) and the main unit with ultrasonic + thermal humidification and the humidity sensor. I now built a small connector that goes between those plugs and has all 4 wires go out so I can measure on them. When rigging up my logic analyzer I get the following communication coming up every ~8 ms:

communication example

This should be the communication of the display unit asking for a sensor reading (Channel 1) and possibly what is the main unit's answer (Channel 0). What brings me to this conclusion is the Ch1 line going low just a few µs before the signal on Ch0 starting. Also Ch0 looks like DHT11-type answer code for me - long pulse = 1, short pulse = 0. As you see, there is a significant long low-time on Ch1 in between (see red circle). This makes it nearly impossible for me to fit a UART analysis in in Saleae Logic without it throwing frame errors. What also makes me wonder are two thing: 1.) There are some very short pulses in between with a high-time of 600 ns. I think I can possibly just ignore those (see red circle). 2.) the shortest pulses I can measure besides on this line are 16-20 µs long. This would make a Baudrate between 50000 and 62500 - so possibly 57600? The strange thing is, although the display should just ask for values as I don't do anything on it, the codes seem to change a bit every time:

comparison of requests

Those are 4 adjacent requests. Does anybody have an idea on how to interpret this?

If you want to have a closer look, the file is uploaded for viewing in Saleae Logic right here.

EDIT: Just realized the short pulses might still be important. It seems that there are 9 pulses transmitted on CH0, and then there comes a short pulse on Ch1, followed by a short pause on both channel before CH0 starts to transmit the next 9 (or, in one case, 10) bits. There is a small IC on the bottom side of the circuit board with a SOIC-16 package, but without any labeling. enter image description here

  • \$\begingroup\$ It could be that the signal is being bit-banged on a microcontroller (using gpio and code to send it rather than the dedicated hardware) causing the timing to not be perfect, but just good enough for the decoder to know what it means. What sample rate was this captured at? (software says 24Ms/s but I dont know if its correct). And, this is probably not the case, but worth asking, Do you think anything is getting lost at this capture rate? \$\endgroup\$
    – Miron
    Commented Mar 18, 2022 at 19:09
  • \$\begingroup\$ It could be (really badly timed) I2C, channel 0 is the clock and channel 1 is data \$\endgroup\$
    – Miron
    Commented Mar 18, 2022 at 19:15

2 Answers 2


Ok I think it is in fact I2C, Ch 0 = SCL, Ch 1 = SDA Notable features of the waveform:

  • I2C has 9 pulses for each byte + ACK bit
  • the very short pulse you see might be the ACK bit. The master stops pulling the line low and there is an instant before the servant pulls the line low to acknowledge)
  • the start condition for I2C is SDA goes low, then SCK goes low, which is what we see
  • the stop condition is SCL goes high then SDA going high, which is what we see

Do you see a pair of resistors near the traces of this signal?

Decoding with Logic, the device address is always 0x50, the last byte is a checksum, which is the sum of the first 2 bytes in a burst plus 0xA0. E.g. 0x06+0x66+0xA0 = 0x0C (trimmed to 8 bits) enter image description here

  • \$\begingroup\$ I was bored, so here is a table of register reads and writes that happened during the transaction with a script to generate it from Logic's I2C analyser (under analyzer->data->terminal). Seems only registers 0-7 are used gist.github.com/ElectricPotato/48548ae0c9c37f0cc7cd935d92d3cfbb \$\endgroup\$
    – Miron
    Commented Mar 18, 2022 at 21:28
  • \$\begingroup\$ Hey Miron! Damn, that's a lot of effort you made there for me! Thank you so much! Yeah, I2C makes completely sense indeed. I would never have guessed Ch0 could be a clock line with those bad signal shapes, especially as it is labeled differently, but it definitely appears to be this way. Also a big thanks for the table transcript, that helps a lot! The humidifier indeed nearly always shows a value of 20% which could be the value written to register 2 rounded up (0x11=17, 0x12=18). I will try to get a bit more insight into that by collecting more data. \$\endgroup\$ Commented Mar 19, 2022 at 16:50
  • \$\begingroup\$ I think I can just take the script on the bottom and let that run over any code put out this way by Logic, right? I never used Python (did more C and Arduino), but it seems like all that is really coming out of that small script. Damn, that's impressive. \$\endgroup\$ Commented Mar 19, 2022 at 16:50
  • 1
    \$\begingroup\$ Got it running, it's running brilliantly. Thanks a lot for your work! (: \$\endgroup\$ Commented Mar 19, 2022 at 17:52

That's not UART signaling.

That's I2C.

Assume upper trace is clock SCL and lower trace is data SDA. You can also have the logic analyzer decode I2C.

  • Data goes low while clock high - start condition
  • Data changes only while clock is low
  • Every 9th bit is ACK bit, where one device stops driving the data bus low to release it high and the other device starts driving data bus low for acknowledge. This creates the quick high going glitch.

Transaction seen in the last diagram is:

start - 0xA0 with ACK (I2C write address) - 0x04 with ACK - stop

start - 0xA1 with ACK (I2C read address) - 0x81 with ACK - 0x25 with NAK - stop

That matches basically a register read or I2C EEPROM read of 2 bytes from address 0x04.

  • \$\begingroup\$ Thanks a lot! Yeah, that makes definitely sense. I never guessed Ch0 could be a clock line as it was so unsymmetrical, but yeah... You never stop to learn! \$\endgroup\$ Commented Mar 19, 2022 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.