Pointless Circuits

Programming, Electronics and Breaking Things

Aug 15, 2015 - Comments - electronics reverse engineering AVR air dehumidifier

Revival of an air dehumidifier

Months ago I got my hands on a faulty air dehumidifier. The output on the display didn’t make sense and it wouldn’t take any user input, let alone start running. It was given to me at no charge and I thought it might be an interesting project to repair the device.

Dehumidifier Overview

The device
The dehumidifier seems to be a predecessor model of the prem-i-air EH1220, sold by CMI Euromate GmbH. Its type is stated to be C-EF 10, I couldn’t find any information about it whatsoever.

The functioning of the device is really not that complicated. Water from the air condenses on cooling fins inside the dehumidifier and drops down into a catch basin. There’s a fan drawing air through the cooling unit and a little compressor to provide the temperature difference. Four sensors (ambient temperature, air humidity, cooling unit temperature and basin full) provide the required information for a microcontroller to decide when to run the compressor and/or fan. Finally, there’s a IO unit to display the status and take user inputs.

Defect Hunting

Main PCB
After a relatively simple disassembly I was left with this main PCB. It contains what you’d expect: Relays for the compressor and fan, a transformer and linear regulator to supply 5V for the logic, some I²C EEPROM and a microcontroller. In this case it’s a SH96P42, that’s 4-bit, 3k words OTP ROM and 69 bytes RAM of raw power. As the ROM is writable only once, there’s no way simple way to test the chip if you don’t know how it’s supposed to behave.

A quick check on the most likely defects (old caps, ripple on Vcc, erroneous reset circuitry behavior) indicated I’d have to dig deeper. In the end I decided to completely replace the microcontroller.

Controller Replacement

Replacement PCB
I wasn’t lucky enough to have a pin compatible micro at hand, so I soldered those 20 pins to the back of a piece of perfboard and arranged some circuitry around an AVR ATmega 8 on it. The additional pins of the AVR were put to use for programming and serial communication. After some tricky soldering and hack-wiring (see, it’s not exactly beautiful), I had a this little device I could just plug into the slot of the original controller.

Reverse Engineering

Only some of the circuitry was really simple to reverse engineer (mainly the relays and temperature sensors), while two particular parts took some more work to understand and get working again.

First, there was the IO board, a (luckily) one-sided, THT PCB, which nonetheless was without any order to cramp all the parts into as little space as possible. You might recognize the shift register on the right, it’s used to reduce the number of wires used for the outputs (7 segment displays, LEDs). To save even more GPIO lines, the push-buttons are also multiplexed using the shift register. It took a while to untangle the circuit mess but the way the lines are minimized is really quite clever:

Multiplexing one channel
There are eight circuits similar to this one, one for each shift register channel. The right combination of shift register output, LED control and DIS1 + DIS2 state turns the desired LED/segment on and allows reading of the push-button. This way, only eight wires are used (2x power, shift register data + clock, 2x display control, LED control and key reading) for four inputs and 19 outputs. The disadvantage is the need for some kind of time multiplexing to allow for all combinations of inputs/outputs.

Temperature + Humidity sensor
The second source of trouble was the little white humidity sensor on this PCB. Having never before worked with devices like that, I treated it as a black box and took some simple measurements, trying to find plausible correlations to the humidity. The capacity (as measured with my multimeter) seemed like a good starting point, it increased when breathing against the sensor. After implementing the measurement on the controller this approach turned out to be completely wrong. I stepped up my googling efforts and found a similar looking sensor, the UPS-500 by Ohmic Instruments.

One of the first things their manual says is: “Never connect the sensor to an ohmmeter.” Great. Seeing how many patents Ohmic Instruments holds on humidity sensors alone, I figured my sensor might very well be closely related to UPS-500. I therefore stuck with their datasheet and after some more fiddling with asynchronous, interrupt based programming of the AVR, I get readings according to the reference. They’re not really plausible (I get around 25% relative humidity in the living room, seems a bit low), but change plausibly with changing humidity. That’s quite enough for my purpose.

Provided Functionality

Right now there is only one very simple mode of operation: Set the reference humidity on the IO panel and the dehumidifier will keep the humidity below that value. I haven’t put it to much use yet, but it seems to work quite well this way.

I still have some ideas how to expand its functionality, especially since I fitted a stereo jack into the casing, connected to the uart. This way I can easily hook up the dehumidifier to my computer, who doesn’t dream of that?! On a more serious note, it does make reprogramming the AVR quite hassle-free, assuming one takes upon himself the installation of a serial bootloader. After choosing FastBoot by Peter Dannegger, I was shocked by how complicated the code generation was (using GNU tools); this is definitely something that could take some dedicated work.

All in all I’m quite pleased with the outcome of this project and can confidently declare the dehumidifier as repaired.

You can find the code and some hardware considerations on github.