With the circuitry defined, prototype tested and schematic drawn, it was time to turn my attention to something a little more permanent than a breadboard and some snippets of test code. My usual go-to software for PCB design is KiCAD and On-Shape for 3D modeling. However, with Autodesk combining both into a single application (Fusion 360), I decided to see if the combination was helpful.
I am impressed with Fusion 360 - especially since it has impressive surface modeling tools along finite element analysis, flow modeling and 3-axis milling and lathe CAM built in. Eagle is great too, although the interface is still as clunky as I remember it being before Autodesk acquired as it doesn't conform to the current day "standard" of interfaces (eg right click doesn't always open a context sensitive menu, it rotates a part).
But Fusion 360 also has its quirks; every save creates a new version. And as someone who was taught to save frequently in case of a crash, some of my designs had upwards of 100+ versions. It seems that in a rush to compete with OnShape's cloud solution, Autodesk was a little clumsy in its implementation.
The comparators are at top; with the mode knob encoder on the left and thermostat encoder on the right. While not a mistake, it's a minor annoyance that I swapped the position of the stepper drivers: thermostat on the left, mode on the right.
While Eagle's use does seem widespread, finding reliable component libraries (especially that have 3D models) is quite difficult. I imagine support is better if you're a commercial customer who is about to buy hundreds of thousands of parts. While I have dreams (and most of the parts) to build my own pick-and-place, the quantity of PCBs hasn't yet warranted the investment. So I'm left with creating my own component libraries that cobble together custom schematic symbols, layouts and 3D models. And I don't always get those correct.
PCBs from OSHPark (left-to-right) (1) First revision with many of the through-holes too small to fit the component pins. (2) Using headers, I was able to populate some of the first version board enough to test the circuitry. (3) Second spin of the board, with the hole sizes being the only needed change. And (4) fully populated, along with its enclosure.
For all of Fusion 360 and Eagle's quirks, it was super helpful to design the enclosure based on the 3D model that it derived from my PCB layout. It definitely prevented extra manufacturing revisions for more complicated assemblies like the encoder and stepper mounts.
Another 3D printed project prototyping board and a working design that bridged the Nest to the pycom microcontroller.
All AC circuitry to the left of the orange line, isolated from the digital logic to the right.
Here's the full schematic which includes two-stage cooling and heating.
I originally had assumed that in order for the Nest to believe it was controlling an actual HVAC system, it would need equivalent 24V AC outputs. Note that the base plate has 10 wire inputs for HVAC connections but the Nest-to-base-plate is a 20-pin connector. As it turns out that to detect what kind of HVAC system that its being used to control, in each HVAC connection is a mechanical switch which determines if there's a wire that's been inserted into the location. Instead of actually running AC HVAC signals, it could be possible to insert wires into the appropriate locations and then leverage the Google Home API to know if the state of the thermostat.
Since I had the Nest already, had become fairly enamored with its great design and liked its ability to learn my schedule, the next step of this project was to figure out how to use it to control my HVAC stepper motors. A 24V AC power supply was an easy find.
Next was turning the AC control signals from the nest into a digital 3.3V signal. In previous projects, I had used optocouplers to isolate a digital control signal from a triac to control an AC signal. But this was the reverse of using an AC signal to drive a digital input.
As it turns out the HCPL-3700 is great because it can isolate either AC or DC inputs from its logical outputs with a fairly straightforward design of a diode-bridge rectifier powering an optocoupler. The datasheet by fairchild, avago or hp/agilent are very similar, differing only in some of their operating voltages at various temperatures.
All of the datasheets also include an AC threshold-voltage-to-external-resistance chart. [0033mer]'s youtube video shows a version of this chart, however, which I couldn't find in any of the datasheets. When using an AC input (pins 1 & 4), it recommends using a capacitor on pins 2 & 3 to smooth out the bridge rectifier "output". With this application, the resistance for 24V AC is low and in that range, the capacitance variance is negligible.
In my previous apartment, a mid-70s honeywell bi-metallic thermostat controlled the 24V circuit connected to the oil-filled baseboard electrical heat. And like many systems of that era, it consisted of only a two-wire configuration - red and white wires.
For many HVAC system installation, only the R & W wires were run from the heating unit to through the wall to the thermostat.; and since it wasn't needed by mechanical thermostats, the common wire wasn't. It probably also saved on building construction costs. However, it was a challenge for thermostats with electronics that required a power source.
Two techniques have been used to circumvent this limitation. If the resistive load of the electronics is placed in parallel with the thermostatic switch (left), it could provide enough current to power the electronics as long as it wasn't sufficient to trigger the heating relay. The other possibility is if the resistive load of a battery charging circuit is in series with the thermostatic switch (right) then during the heating cycle enough power could be stored to run the electronics while not heating. Neither are great solutions as the former solution is challenging given that the relay's current draw is not known. And the latter relies on enough heating cycles to charge a large enough battery to sustain the electronics in between heating cycles.
I imagine that manufacturers decided to avoid this kind of challenge and focus on home automation in newer construction where common wires are more often available. For older constructions, the recommendation is to supplement the two-wire system with an external 24V AC power supply.
The one exception is the Nest thermostat; it is based on the in-series battery charging design with a micro-usb charging port as a backup in case the battery dies between heating cycles. And with its simple user interface, I've always been a fan of the Nest thermostat so I was happy to install it.
From research, this seemed like a more "modern" (after 1980s) wiring for a combined hot-air and A/C unit that shared common ductwork:
If the heating and A/C units were separate -- such as a baseboard water heater and A/C ducts -- the wiring configuration might have two 24V AC transformers with an RH from the heating system and an RC from the cooling system. Other systems also offered a second heating or cooling stage. For common setups, check out this extensive guide.
A single breadboard is great when prototyping with a microcontroller and a couple of small DIP packages. And the wonderful, little 5V/3V breadboard power supplies definitely help keep the project organized. And with breadboards that snap together, expanding is definitely possible.
But needing to move the project from one workspace to another is a recipe for breadboards separating and countless connections needing to be mended. Coupled with a growing number of projects that also need multiple voltages or multiple power supplies for servos and stepper motors, decided to "design a better mousetrap".
More information on building can be found on thingiverse.
Lots of progress has been made but have fallen behind in posting...
With the encoder more or less figured out and the basic circuitry understood, I set out to build a fully working breadboard prototype.
Once again, not the prettiest of prototypes but workable to develop the software.
The green boxes each represent the 3-bit encoders needed for the thermostat knob and the mode selection knob. Two DRV8255 stepper drivers are in blue. Since the pycom has an onboard voltage regulator, it likes to run above the 3.3V recommended for its own inputs. The dc-to-dc step downs that are on the prototyping board are lousy at maintaining a constant voltage (I tried several manufacturers too!) if there is any sort of load; if set to 3.3V, there is enough of a voltage drop (~50-150 mV) under load that the pycom won't run. To avoid an issues of having the IO pins being driven above their safe limit, pycom's input voltage is 4.5V and then the LM393s are powered off of the pycom's 3.3V regulated output. Vmot for the stepper motor drivers are regulated separately at 12.5V.
To verify that the encoder disc design would work, I started with a single-bit of the eventual 3-bit encoder and just the one stepper motor.
In this first pass, I didn't have any LM393s in my parts bin. So while I awaited delivery, I used an op-amp (LM386) and a 2N2222 transistor to get the digital input needed for the microcontroller. Above the pycom microcontroller is a DRV8825 for the stepper motor.
DEFAULT_SPEED = 100
enc0 = Pin('P3', mode=Pin.IN)
step_pin = Pin('P11', mode=Pin.OUT),
dir_pin = Pin('P12', mode=Pin.OUT)
# turn the stepper motor n degrees
def turnKnob(degrees, cw=True, speed=DEFAULT_SPEED):
# set direction
dir_pin.value(0 if cw else 1)
# adjust for the 5:1 planetary gear reduction
steps = int(degrees * (1036/360))
delay = 1 / speed
# create a pulse for each step needed
for i in range(0, steps):
# time between pulses sets speed
# short delay, faster rotation
# longer delay, slower rotation
# run until the encoder hits a slot
def runUntil(cw=True, speed=DEFAULT_SPEED):
while enc0.value() != 0:
turnKnob(1, cw, speed)
This snippet turns the stepper motor until a slot in the encoder disk triggers the IR/photodiode comparator
The photodiode (in reverse bias) acts as the upper half of a voltage divider. When exposed to the IR LED, the voltage increases. The other leg of the LM393N comparator input is another voltage divider with a variable potentiometer. Usually used to adjust the sensitivity of the circuit and change reflected distance, it is less needed in this case; the distance between the two diodes is fixed and the diodes face each other thereby removing any IR loss due to the not-perfect-reflective surface.
Since this is this board schematic, it doesn't include the IR LEDs and photodiodes as they'll be off-board.
It'd be nice to have the skill (aka patience) to design this as an SMD board but for this project, I'm going to do a through-hole PCB. Three of the dual comparator LM393s will take a fair amount of real estate on the final board; but there isn't a size constraint and the low-volume (there are only three HVAC units in the apartment) won't make the the extra PCB board real estate cost prohibitive.
Next step: creating a mount to hold the IR LEDs and photodiodes.
The middle plate attaches to the stepper motors and holds the photodiodes. Once assembled, the encoder disks are friction fitted to the shaft of the stepper motor. Followed by the IR LEDs held opposite the photodiodes on a raised "tab". I had hoped to make this more compact but the LEDs needed to clear the stepper motor housing so the disks ended up being ~2.5" diameter.
Here is the first working prototype. In lieu of small PCB boards to hold the photodiodes in place, a little CA glue did the trick with a very clumsy soldering of the leads to a flat, multicolored cable that was lying around.
A side view of the prototype. Even more clumsy underside with some electrical tape protecting the LEDs from shorting out against the metal case of the planetary gear casing on the stepper motor.