THAT Control Software, v0.6.4
The current version of THAT Control Software, version 0.6.4 can be downloaded from the link below:
THAT Control Software is built using a combination of Python, XML, HTML, and CSS and is designed to be as modular as possible. The block diagram for the software is shown below
The gray blocks in the software block diagram represent the core parts of THAT Control Software, which consist of Python code spread across multiple files (See Appendix E for source code.)
The blue blocks represent files which would be provided to the end-user by the manufacturer of a specific THAT module. The most important manufacturer-provided file is the Module definition XML file. This file contains, in XML format, a listing of all of a THAT module’s controls, settings, and identification information. Using this file, THAT Control Software can “learn” everything it needs to know about a THAT module, without having any prior knowledge of the module’s existence.
The blue blocks are files containing HTML and CSS code which tell THAT Control Software how to design the web interface for a specific THAT module. This allows a manufacturer of a THAT module to customize the section of the web interface that the end-user sees when they access each module’s controls and settings.
The yellow blocks represent HTML and CSS files which are provided with THAT Control Software. These files create the “default” web interface which is seen by the end-user. These files could be modified or replaced by the end-user to customize or replace the default web interface with one better suited to their needs.
Lastly, the green blocks represent XML files which are dynamically generated by THAT Control Software. These XML files represent a running “database” of information about the currently-configured THAT Modules. Additionally, these files are used by THAT Control Software to store all user preferences. Thus, the software could theoretically be upgraded/removed/installed without altering or losing any of the current settings or system configuration.
The gray blocks in the software block diagram represent the core parts of THAT Control Software, which consist of Python code spread across multiple files (See Appendix E for source code.)
The blue blocks represent files which would be provided to the end-user by the manufacturer of a specific THAT module. The most important manufacturer-provided file is the Module definition XML file. This file contains, in XML format, a listing of all of a THAT module’s controls, settings, and identification information. Using this file, THAT Control Software can “learn” everything it needs to know about a THAT module, without having any prior knowledge of the module’s existence.
The blue blocks are files containing HTML and CSS code which tell THAT Control Software how to design the web interface for a specific THAT module. This allows a manufacturer of a THAT module to customize the section of the web interface that the end-user sees when they access each module’s controls and settings.
The yellow blocks represent HTML and CSS files which are provided with THAT Control Software. These files create the “default” web interface which is seen by the end-user. These files could be modified or replaced by the end-user to customize or replace the default web interface with one better suited to their needs.
Lastly, the green blocks represent XML files which are dynamically generated by THAT Control Software. These XML files represent a running “database” of information about the currently-configured THAT Modules. Additionally, these files are used by THAT Control Software to store all user preferences. Thus, the software could theoretically be upgraded/removed/installed without altering or losing any of the current settings or system configuration.
Firmware version 0.1.8
Posted by Nick in Digital Thermostat Module (COPTA), Software on May 14th, 2010
The latest firmware for the Digital Thermostat Module (COPTA) is accessible from the link below. This is version 0.1.8.
Physical User Interface
Posted by Nick in Digital Thermostat Module (COPTA) on May 14th, 2010
A brief overview of the physical user interface elements of the Digital
Thermostat Module is shown below. The pushbutton switches all serve multiple functions. Primary
functions are shown in black. Secondary functions, such as when in a menu or settings
mode, are shown in [Blue]. Finally, functions which are executed when a button is held
down for 5+ seconds are shown in (Red). Also note that the five LEDs are programmable in software to indicate different states and functions, but they default to indicating the functions listed in the diagram.
The user interface currently has 3 discrete modes. First is the “home” screen which shows the current date and time, temperature and humidity, temperature setpoint, and current operating mode. Second is the scheduling menu which shows the current schedule. Third is the settings menu which lists the memory registers and allows changes to be made to the thermostats configuration. A photo of the current “home” screen, as displayed on the prototype device, is shown below.
Updated Block Diagram
Posted by Nick in Digital Thermostat Module (COPTA) on May 14th, 2010
The updated hardware block diagram for the Digital Thermostat Module is shown below.
Mainboard 0.3 – MCU
Posted by Nick in Digital Thermostat Module (COPTA) on April 19th, 2010
The latest version of my mainboard prototype is hardware version 0.3. The schematic for this hardware is large so I’ve split it up into 3 separate schematics, titled “i2c”, “lcd”, and “mcu”.
The mcu schematic contains the microcontroller, the temperature and humidity sensors, the pushbutton switches, and other components and connections which didn’t explicitly fit into the i2c or lcd schematics.
The mcu schematic is shown below. Note that the arrow-shapes which have text in them are not physical components, but rather symbols meant to link the wiring between the mcu, i2c, and lcd schematics. More notes are listed below the schematic.
Notes:
- Q1 and Q7 are MOSFETs which are used to dim the LEDs and LCD backlight, respectively. The gates of these MOSFETs are controlled by hardware PWM signals generated by the microcontroller. The PWM has 8-bit resolution, providing 256 brightness steps.
- X1 is the Atmel In-System Programming (ISP) header. It is used for writing the firmware to the microcontroller, without having to remove or disconnect the microcontroller or any part of the circuit.
- L1 and C4 form a low-pass filter. This filter is used to help prevent high-frequency noise (created by the digital circuitry) from entering the microcontroller’s Analog to Digital Converter (ADC).
- The switches are debounced in software, using a hardware timer in the microcontroller. After a switch is pressed, the timer is started and all switch-pin interrupts are disabled. During this time all bouncing or presses of the switches are ignored. After the timer expires, switch-pin interrupts are re-enabled.
Mainboard 0.3 – LCD
Posted by Nick in Digital Thermostat Module (COPTA) on April 17th, 2010
The latest version of my mainboard prototype is hardware version 0.3. The schematic for this hardware is large so I’ve split it up into 3 separate schematics, titled “i2c”, “lcd”, and “mcu”.
The LCD schematic includes the external capacitors required for LCD contrast voltage creation, and the connections to the LCD. In addition, it includes a boost converter that outputs 15 Volts DC from a 5 Volt input, for powering the actual LCD screen.
The LCD screen I selected actually does contain an on-board 15 Volt power supply, which is integrated into the LCD’s ST7528 controller IC. Unfortunately, the on-board 15 Volt supply has a very weak output, and is incapable of providing adequate voltage to the LCD when more than about 1/2 of the segments are lit.
To resolve this problem, I had to implement an external 15-volt power supply for the LCD driving voltage. I chose the MIC2141 IC for this task because it has a wide input and output voltage range and requires few external components. The typical application wiring diagram from the MIC2141 datasheet is shown below
The MIC2141 is an IC that implements a boost converter, which is a type of switch mode power supply (SMPS). The MIC2141 supports a wide range of input and output voltages. In my configuration, I am using it to produce 15 volts from a 5 volt input.
A list of inductor values and flayback diodes which are recommended for use with the MIC2141 when the input voltage is regulated are shown in the table below (from the MIC2141 datasheet). A table listing the minimum inductance required for various configurations is also shown below. I chose a 10uH inductor since it is a very common size and meets the minimum inductance value for a 5 volt input and 15 volt output.
The mainboard LCD schematic is shown below. Some notes subsequently follow the schematic.
Notes:
- C2 through C6 are used to stabilize the LCD driving voltages which are created internally by the LCD controller IC. Each capacitor has a varying percentage of the LCD contrast voltage (15 Volts) across it. For example, if even distributed, the capacitors would be at 3,6,9,12, and 15 Volts, respectively.
- IC1, L1, and D1 create a switch-mode boost converter which outputs 15 Volts from the 5 Volt input. This output is used to provide the LCD driving power.
- C7 is used as a buffer / stabilizer for the 15 Volt rail.
Mainboard 0.3 – I2C
Posted by Nick in Digital Thermostat Module (COPTA) on April 8th, 2010
The latest version of my mainboard prototype is hardware version 0.3. The schematic for this hardware is large so I’ve split it up into 3 separate schematics, titled “i2c”, “lcd”, and “mcu”.
The i2c schematic includes the i2c devices (the I/O Expander and Real Time Clock ) and attached hardware. I decided to use an i2c I/O port expander because I was running out of I/O pins on my microcontroller.
Rather than having to reduce the number of LEDs and switches used by my thermostat module, I opted to use the inexpensive MCP23008 port expander from Microchip. Using the port expander, I now have a couple extra pins to work with, as well as having the ability to toggle the status LEDs independantly from the HVAC relays.
The i2c schematic also includes the 4 HVAC relays and 4 of the 5 status LEDs. The crystal shown is the 32.768kHz crystal used by the DS1337 real time clock IC. 32.768kHz is desireable for generating a clock signal when using a chip with a 16-bit counter since the count to 32,768 will occur exactly once per second. The i2c schematic is shown below.
Notes:
- R1 and R2 are pullup resistors for the I2C bus lines. The criteria for their selection is listed in the Atmel Atmega324 datasheet, shown below.
- MOSFETs Q1 through Q4 are used as buffers so that the relays can be driven without exceeding the current limit per I/O pin of the AVR microcontroller.
- D1 through D4 are flyback diodes to prevent large voltage spikes from appearing across the MOSFETs’ drain-source junction when the relay coils are de-energized.
Power Supply with PoE Testing
Posted by Nick in Digital Thermostat Module (COPTA), THAT System on April 7th, 2010
Recently, the Silver Ag9405 Power over Ethernet (PoE) modules I ordered arrived. I populated a PoE module into version 0.3 of my Power Supply board.
For testing I connected the input PoE header of the power supply board to the output PoE header on the Ethernet Interface board. I then connected an ethernet cable from my Ethernet Interface board to a D-Link PoE network switch. Using a Fluke 87 multimeter, I checked for 5 Volts at the power supply output. Photos are shown below.
I noticed during the initial power up that the output from the PoE module was not only not 5 volts, it was much lower, being about 4.2 Volts DC. After reviewing the PoE module’s datasheet as well as my schematic and PCB layout, I discovered my mistake.
Resistor R2 (100k ohm) in the schematic is used to pull the output of the PoE module up from 5.0 to about 5.3 Volts DC. This is done so that when the output is passed through the diode D8 (whose voltage drop is about 0.3 Volts), it is still a true 5 Volt output.
In order to increase the output voltage of the PoE module, R2 is supposed to be tied between the ADJ pin and VCC (5 Volts). However, I accidently tied R2 between ADJ and Ground when I created my PCB design.
Thus, I was actually reducing the output voltage instead of increasing it. I de-soldered R2 from its pads on the PCB and instead soldered it from ADJ to VCC. The output voltage then showed up to be almost exactly 5 Volts when I subsequently powered up the module.
Thermostat Settings
Posted by Nick in Digital Thermostat Module (COPTA) on April 5th, 2010
I have begun the process of building up the firmware for my Digital Thermostat module to include some advanced features and settings. In order to help me organize this process, I have created a “memory map” that lists all the settings I plan to implement. It is shown below.
The map lists the expected values or states associated with each setting, and the default state or value. Each setting has two numerical identifiers. The first, listed under the column “Name,” is the identifier that will read out on the module’s LCD screen. Thus, this is the number that will be seen from the built-in interface menu(s), used for programming the thermostat.
The second numerical identifier is listed under the column “#”. This number is used to identify the settings when it is accessed throught the Ethernet interface from a remote client. Both identifiers are numeric and short in order to minimize memory usage. (Textual names would require a lot more memory to store).
The two left-most columns identify which settings can be read (R) / written (W) by whom. The thermostat will have two “log-in” modes, one for a “user”, and one for an “administrator”, which are both different from the standard mode, in which nobody is logged in (the default state.) Although not required, these two special log-in modes will be used to restrict access to certain settings and adjustments on the thermostat by non-authorized users. More on this later…
Ethernet Controller 0.3.2
Posted by Nick in Digital Thermostat Module (COPTA), THAT System on April 4th, 2010
I modified my initial Ethernet Controller board (aka Network Interface Card) to create the current version 0.3.2. This NIC version is currently being used as I continue development of my Digital Thermostat Module
Schematic
This version is almost identical to the previous one. The main exception being that I added standard (2.54mm pitch) pin headers to the schematic for the external connections to/from the board. The schematic is shown below.
One note worth mentioning here is the component used for the inductor, L1. The datasheet for the ENC28J60 ethernet IC barely mentions anything about the part requirements for L1. However, It does suggest that L1 must be rated to carry at least 80mA of current. I ended up using a 10uH, 228mA inductor from API Delevan, Inc. (Digikey Part number: DN42077-ND). The ethernet controller has been found to work correctly with this inductor. With that said, it is somewhat overkill for this application, and cheaper options exist.
Printed Circuit Board
Using the Eagle layout editor by CadSoft, I designed a Printed Circuit Board layout for this version of the ethernet controller and had several prototypes produced by BatchPCB. The PCBs are standard, 2-layer boards with through-hole components. They measure 70.1 x 43.2 mm. The PCB design layout is shown below.
The boards arrived and I stuffed them with the appropiate parts (which are listed in the original Ethernet Controller Design post). The top side of the board after being stuffed (except for part L1) is shown below.
Connectors
The small, 3-pin female header is for the Power Over Ethernet (PoE), and it connects to the PoE input header on my Power Supply board. The Large, 8-pin header is for data and power for the Ethernet Controller. It is designed to connect to the mainboard of a THAT module, in this case my Digital Thermostat Module.
I chose the pinout of the 8-pin data header myself. I defined it so that the constant power signals (VCC) are near one end, with ground at the opposite end. The data lines then are oriented so that the higher-frequency data lines are close to ground, while the lower-frequency lines are closer to VCC. I expect that this will reduce radiated electrical noise somewhat, but am not convinced that it makes much of a difference in this application since the wires are long and the distance between them is large.
The pinout of the 8-pin data header is as follows:
- Pin 1: 3.3 Volts (VCC2)
- Pin 2: 5 Volts (VCC1)
- Pin 3: Interrupt Signal
- Pin 4: Ethernet Chip Select Signal (CS)
- Pin 5: Serial Peripheral Interface Slave Out (MISO)
- Pin 6: Serial Peripheral Interface Slave In (MOSI)
- Pin 7: Serial Peripheral Interface Clock (SCK)
- Pin 8: Ground


















