Everyone I describe this to says exactly what I said, "What! No hysteresis?". Nope, aparently not -- but we intend to fix this by adding a dead band rule. In other words when the motor turns on, it stays on for at least N seconds. And when it turns off, if stays off for at least M seconds. Most likely N = M = 60 seconds.
So now my goal is to augment (or replace) the control module with something with a more intelligent algorithm. The first trick is to learn enough about this thing to figure out how to modify it.
A quick look at the control panel shows that the 3 wires are labelled Tx, G, and B. A meter on these shows 3.38 volts on both the Tx and B. So G and B are ground and power respectively. And as I hoped, all the smarts must be in the control panel since it can only send commands (so it must run open loop as far as motor and pump status). If we can determine the protocol on the Tx line, we can replace it with almost anything we like.
Inside the control panel is a PCB that consists essentially of one component, a Holtek HT46R64 chip. This is some kind of oddball 8 bit RISC controller in an OTP version, and in a 52 pin QFP package.
I guessed that the slave unit ( the power controller ) would turn everything off if it did not get a message regularly, but this is unfortunately not the case. I remove the control panel and the fan keeps running indefinitely. It just goes to show, never assume the engineers had a clue.
The message being sent is simple enough. It is a uniquely encoded serial byte sent at 1000 baud, i.e. each bit time is 1 ms as shown in this second scope capture:
We have a "start" sequence where the line is held high for two bit times (2 ms), followed by 8 data bits. Each of the data bits is 1 ms long, and like any good bit, comes in two flavors.
For each bit, the line is always first low, then high. In one state the line is low for 300 us, then high for 700. In the other state the line is low for 700 us, then high for 300. I call these states L and S respectively (for "long" and "short" refering to the high state time).
Messages look like SLSLxxxx, where "xxxx" are the bits of interest. The "SLSL" is a constant "prolog" that never changes. There is a 4 bit payload in each message. In the message shown above, the payload is "LLLL"
We can label the payload fgpx, and the 4 bits control:
Note that we should never turn on both f and g (I don't know if the slave unit will guard against this or not, but I don't want to find out). Activating both relays to power both the fast and slow windings on the blower motor is almost certain to cause damage.
All the above was sorted out by using the buttons on the control module to put it in every possible state and making a chart of the different commands being sent.
As an aside, I find it hilarious to compare the ESP8266 to the Holtek (and consider that the Holtek is still doing the bulk of the work). We have an 80 Mhz 32 bit RISC processor on one hand and an 8 Mhz 8 bit processor on the other. The ESP8266 has 64K plus 96K of ram, the Holtek has 192 bytes, and so forth.
There are some other good reasons to use the ESP-12. It is tiny. I measure 0.65 by 0.95 by 0.135 thick. It is also dirt cheap (about $2) and I have several just laying around. This will fit nicely inside the control panel box (It has 0.2 inches of clearance). I can just epoxy it (or use double stick tape) to a handy empty area on the PCB, bug wire it, and cut one trace to patch it in.
One consideration is driving the 100+ feet of cable to the slave unit. I don't want to do this directly from an output pin on the ESP8266. The existing board has a transistor to drive the cable as a buffer and I would be wise to cut the trace that drives this transister and retain it as a signal buffer and line driver.
The above image shows where I intend to mount the ESP-12. The trace I intend to cut is the one from the Holtek chip to "R3". It is important to note that this signal is inverted from the one shown in the scope capture above (the buffer transistor Q0 inverts the signal, which is to be expected actually).
I added a header with 5 pins. Two are to install a shorting jumper to ground GPIO-0 to be able to run the boot loader convenients. The other three are Tx, Rx, and Ground for a Uart.
Also a bare ESP-12 needs to have a couple of other signals taken care of. One is to pull CH_PD up. I used a 5K resistor, but was certainly tempted just to pull it to Vcc directly. Also GPIO-15 needs to be grounded. I did nothing at all with GPIO-2. This pin drives the on-board LED, but also is checked on bootup. The LED serves as sort of a pullup -- at any event it works fine with GPIO-2 just left alone.
Tom's Auto repair pages / tom@mmto.org