This page may have too much content for a small screen.
Air Conditioning
In this project I have converted a defective split air conditioning system into a working air conditioning system with wifi.
I have achieved this by replacing the original microcontrollers with new ones and by writing custom firmware for them.
Table of contents
Disclaimer
I am not an expert in air conditioning systems whatsoever. Things I mention here are not meant to be an instruction. If you are not an electrician you should definitely ask an expert for help. Mains voltage can lead to fatal injuries or death.
Some air conditioning systems (not this one) have controlled valves. Controlling them the wrong way can cause severe damage to the system. Replicate at your own risk.
This is not a beginner project. So if you attempt to recreate some parts or the whole project you should have experience in programming and electronics.
Initial Problem
The basic problem which started this journey was that we have bought a used, but stated as working split air conditioning system. After a technician helped us to install the device it did work for five minutes, but only if either of the two indoor units was connected to the communication bus. After that time the device turns off and is stuck in an error condition.
It turns out that both indoor units "think" that they have the same ID (1). This way always the same cooling cycle will be activated and the missing messages from the other ID (2) get detected as error.
Overview
The image above show the basic components of our system. If you want to know how it works there are great tutorials on the subject. For example a great explanation of the working principle of the reversing valves (which allow the system to cool and heat) can be found here.
Reverse Engineering
Indoor unit
The pcb quality of the indoor PCB is not really great. It is only a one layer PCB that is just waiting to delaminate when soldering a pad. It also feels like the designers used the cheapest set of components they can get away with legally.
Supply
The 220 V AC input is connected to the AC output (through a fuse) which goes to a Transformer. The transformed voltage (14 V AC) gets rectified and buffered. Then a 12 Volt linear regulator provides the voltage for the swing motor. These 12 volt also feed a 5 volt linear regulator that provides the current for the microcontroller and optocoupler.
Actors
As can be seen by looking at the traces and the silkscreen there is also a variant of this system that uses resistive heating additionally or instead of being able to heat by reversing the flow direction of the coolant.
The capacitor and triac are for the three phase blower fan. The triac (BT136-600E) gets controlled by an optocoupler (MOC3021). The fan control will get explained in more detail in a following chapter.
The swing motor is driven by a darlington transistor array (ULN2003A). This chip is also responsible for driving the fan optocoulper and the buzzer.
Sensors
There are two temperature sensor inputs. One for the air intake temperature and one for the evaporator temperature. The first one is obviously needed for regulation and the second one likely a safety measure. There is also an input for the blower fan tachometer which is also covered in more detail in the fan control chapter. The last sensor is an infrared detector on a little daughter board.
Communication
The communication is explained in it's own segment since it is one of the more interesting parts of this system.
Original Daughterboard
New Daughterboard
Since I was about to change the brains of the operation I thought I might as well update the UI a little.
Especially on such an experimental project I like to have more information about what the devices are doing than what two LEDs can comfortably provide.
Processor Pinout
For reference this image shows the original functions of each pin of the original controller and what function they perform now.
Outdoor unit
The pcb quality on the outdoor PCB is as bad as the indoor PCB. For the onboard supply the same components are used.
Supply
The 220 V AC input is connected to the AC output (through a fuse) which goes to a Transformer. The transformed voltage (14 V AC) gets rectified and buffered. Then a 12 Volt linear regulator provides the voltage for switching the relays. These 12 volt also feed a 5 volt linear regulator that provides the current for the microcontroller and optocoupler.
Actors
The silkscreen on the PCB clearly suggests that the same board is used for a 4-channel air conditioning system. Although for our system only two beefy relays for the two compressors and three smaller relays are populated. One of the smaller relays is for the fan of the shared evaporator, the other two relays control the reversing valves for either channel. Since the software currently does not support heating, they will stay off.
Sensors
For every channel of the system there is a temperature sensor input. The temperature sensors are located on the pipe before the condenser. Since the system does not have electrically controllable expansion valves, the sensors are likely just a safety measure.
Communication
The communication is explained in it's own segment since it is one of the more interesting parts of this system.
Processor Pinout
New Outdoor UI
There is no indoor unit connected in this image. This is why there are no temperatures and both cycles are in an error state. The missing communication is also indicated by the small boxes in the bottom left corner (they are connected with lines when the communication works).
PCB
ESP32 Based
vs
STM32 Based
winner
Originally I wanted to use an ESP32 as the new microcontroller for its wireless capabilities, but since it was my first project with it I had a lot of problems with kernel panics and reading analog inputs.
During the development of the software I got so frustrated that I created a new STM32 based board. Since I have worked a lot with these microcontrollers, I quickly had everything up and running except for Wifi.
Then winter came and the priority of this project quickly dropped. While the project was on hold I discovered a really great one wire temperature sensor (DS18B20) and got more comfortable with the ESP32 world.
Finally after some tests I got a stable version of the software running on the ESP32 that even has the Wifi connectivity built-in.
In the end using the ESP32 was a great choice since thanks to awesome libraries it now supports everything I could ask for with acceptable effort.
Fan Control
The fan of the system is a three phase fan that is intended to be used in single phase ac systems (the recommended start capacitor is printed on the fan itself). For monitoring it also features a tachometer output that outputs about 3 pulses per revolution.
It is being controlled by a triac, so it will stay on (until the next zero crossing) once a enable pulse has been sent. In order for the microcontroller to switch the triac at the correct time there is a zero crossing detection circuit. The waveforms of the fan related in- and outputs are shown in the screenshot below.
Fan Signals
The oscilloscope screenshot shows the tachometer output which is in the order of 14 ms for one cycle so ~71 Hz at full speed. Given that there are 3 pulses per revolution the fan spins at just under 24 rpm.
The zero crossing detection gives a nice short pulse on every zero crossing of the ac line.
This pulse triggers an interrupt and causes the control pin to enable the triac. Since the fan is running at full power there is no programmed delay between the zero crossing and the triac enable pulse.
This way the triac is conductive all the time.
Full Power
Reduced Power
Originally I had planned to change the speed of the fan according to the current mode (cooling, fan only) using leading edge control. But if I delay the triac enable signal by more than 5 milliseconds the fan no longer runs smooth even though the waveforms (voltage, current, power ) look good.
It would be interesting to see the signals of the original system. This way I would know if I am doing something wrong or if the engineers just didn't care about the bumpy fan at slow speeds.
Anyway I decided not to decrease the fan speed. This means turning on the triac immediately after the zero crossing interrupt.
Communication
Hardware
The communication happens using an open collector approach.
In this specific case the BUS line gets pulled high through the optocoupler U6 (idle state). When the microcontroller pulls the TRANSMIT pin low (sending a "0"), the BUS line will get forced to GND by the optocoupler U7.
If two nodes accidentally communicate opposing bits (0 and 1) at the same time, the 0 "wins", so the BUS gets pulled low and the communication likely fails. Other than the packets not getting transmitted correctly, nothing happens or gets destroyed. This way only one data line can be used for receiving and transmitting.
I have replicated the schematic using a great online circuit simulator if you are interested in seeing this circuit in action.
Protocol
At first I tried to reverse engineer the protocol of the original system and simply build a translation device similar to a router. This way it would have been ok if both systems still "think" that they have the same id, because the router in one of the indoor systems could change that id for all incoming and outgoing messages.
But whatever I tried I could not get the outdoor unit to believe that my microcontroller is one of the indoor units, even though I think I have reverse engineered most of the protocol (maybe I forgot a parity bit or something). Nevertheless I noticed some aspects about the original protocol and implemented them in the new one. For example the indoor units only send out data when requested by the outdoor unit. This way there is no need for checking if the bus is empty like in multi master systems.
The image shows the data packet that gets transmitted from the indoor unit to the outdoor unit. Instead of a CRC or any other compact check every packet gets transmitted twice with a different stop byte. This way it is really simple to check the packets for errors. The transmission speed is 4800 baud which is really slow. But the bus is still far from being overloaded, because the master only requests data once per second from each indoor unit.
For completeness this is the structure of the packet that gets transmitted by the master to each of the indoor units.