My man cave over the garage has a mini split installation. In case you are not familiar with mini splits the DOE has an article.
These AC units are common all over the world, except the USA where central air dominates. They are more efficient and easy to install (no ductwork) but tend to be more expensive per BTU.
Through a connection that my father in law has, I bought ading and dent unit for an eighth of the normal price. The unit is a Mitsubishi MSZ-FE18NA with 18k BTUs of cooling/heating capacity. I figured 18k BTUs was ample capacity to stave off the intense Texas summer heat.
Turns out it may have been a bad idea to get a unit this powerful. Apparently these mini split systems never “turn off”; they always run at a percentage of ther capacity so they can allegedly be more efficient by eliminating the powering on and off overhead. Don’t ask me how this ends up working out in the end! Once the set temperature is acheived the indoor radiator is always about the same temperature as the air. So there is hardly ever any condensation that forms on it. Even worse, any condensation that does form quickly re evaporates. So my cave potentially has a humidity of +20% the outside since the temperature is usually cooler.
In Houston Texas this is bad news because the humidity is high enough!
I researched the issue online. Tons of people are having the same problem. One solution is to downgrade to a smaller unit. Well my unit is already installed, I would have to trade units with someone else and a reinstallation would not be cheap. I had to think outside the box. A temporary fix seemed to be turning the AC off and on manually. When the AC unit detects a significant temperature difference between the set temperature and room temperature it goes into a turbo mode where then the radiator part is significantly cooler and humidity is rapidly pulled out of the air.
The AC unit is controlled with an infrared remote. So that got me thinking, using a simple microcontroller, assuming I could reverse engineer the digital codes the remote were sending to the AC, I could create my own remote that turns the AC on and off every half hour, or even make it temperature based. This way, the radiator part of the AC was always going to be pulling out humidity.
So after doing a little bit of research and looking around the house, I had found I had all the parts I needed. I had an infrared receiver circuit from a broken HDMI switch. For the infrared LEDs I had a pile of old Comcast remotes (they give you a new one every time you get a cable box), so dismantled one and got a few LEDs. To do a proof of concept, I hooked up my infrared receiver circuit to my oscilloscope, set a trigger and then saw the waveform (square wave) of any infrared remote I fired in the vicinity on the screen of the
scope. Great, this is possible so far!
For the controller, I wanted to use an Atmel ATMega as with my other projects, but I had never tried to use a Raspberry Pi before and figured this was a good opportunity to learn some cool stuff. My first goal was to get the codes for on, off, temp up, temp down etc. I needed to write a program that would listen to the waveform output by the receiver, record it and interpret it. Hopefully the data would be like any other transmission and would have a baud/clock rate to make the values easy to determine
I decided to write all my code in C after starting in python and being unsatisfied with the performance (see paragraphs at the very bottom for details). I wrote code to record the time in clock cycles when the input changed. The times were not completely uniform. To completely eliminate that error I apparently needed to write a kernel module. I did not want to open that can of worms yet for this project, so I just figured I would run like a few samplings to eliminate the error. I collected the data in Excel for analyisis. I figured out the time value that must be the baud rate.
I still need to write a program to decode it into digital values. I did this in C# because it was quick in easy. The C# program took the recorded times en mass via a text file and output a header file that I could compile into my C program for retransmission.
When designing my output circuit I had to be careful: the pins on the Pi are logic level 3.3V. In addition the pins are current limited to low double digit mA. I could not properly drive the LED directly from the Pi so I needed a low gate threshold MOSFET.
I wrote some code to output a 38 kHz carrier wave which causes an active low on IR receivers. This modulates the values. It was tricky getting a PWM output on the raspberry pi because of the software layers. An AVR microcontroller would have definitely been easier to work with at this point. I was very careful to write code that had as few delays as possible. And even then still it was tenouos because the OS could interrupt at any time and skew the outpit. An interrput based solution would have worked better but this was very difficult to do to on the Pi. Again, would have been better off with the AVR at this point