Download AVR-GCC Code and Hardware Schematics from here Rev 1.3.

Purpose : This controller can be used to control either a heater, cooler or both to maintain a user set target temperature.

Features List (Summery):

- Integrated "User Setup" mode, which is accessed via an RS-232 connection to a PC running any text based terminal program.

- Controls either a heat source, cooling source or both simultaneously.

- High side FET switches used for outputs. Outputs are opto-coupled for mains protection.

- LCD (Hitachi) displays Current Temp, Temp Error and status of relays.

- Sensor Error Checking ensures voltage from sensor is within set limits. Detects open or short circuit on sensor.

- Four LEDs display controller information : (Controller Status, Heater Relay Status, Cooler Relay Status, Temp Locked Status)

- Control algorithm includes hysteresis.

- Sensor measurements includes averaging.

- User settings are stored in internal NVRAM.

- RS-232 Serial Reporting string includes detailed status information about controller.

- User programmable RS-232 Speed.

- Code can be adapted to various types of hardware, pinouts, etc.

- Control algorithm is binary (no PID control ). Target applications are for the control of objects with large thermal mass.

- Requires specific type of support hardware (see Schematics).

- Temperature accuracy is +/- 0.5 deg cel, but is limited by 10 bit ADC and accuracy of voltage reference.
 

When you first program the AVR, the code detects that NVRAM is blank, writes some factory default settings to NVRAM and boots into user setup mode.

From here you can set up the controller for your application. The setup options are more or less self documented. The disadvantage is that this takes up a lot of code space.

Make sure you save all your changes to NVRAM. If you don't type "y", your changes are ignored, even though they remain in RAM.

You can also test your hardware in this mode, and calibrate the sensor if needed.

Once your done, (E) will exit to the control state. ENSURE that (S) Start up state is "1", as if a reset occurs (say due to a power outage), the controller will return to the setup state.

Remember, temperature is displayed and entered in deci-degrees, except on the LCD where it is displayed in degrees.

Application type is only used to select what information is displayed. For the purposes of functionality, it does not matter what you set this too.

When the controller is spitting out report strings, you can at any time, go back to setup state with the characters "C" and "Q" (followed one after the other).

Usage (Hardware) :

Introduction : The schematics supplied represent the hardware I have used for the project. There is nothing special about them, in fact they are more complex than required as the hardware is multipurpose. It will be easier to follow this guide if you have them printed out. There is no reason why you could not use one of the many other demo boards available, or construct the circuit on vero board.
The PCB layout for the hardware I used requires kinsten pre-sensitised artwork and UV photographic methods to make (due to the fine pitch of some of the tracks). If you want the artwork, email me.

Overview:
The main connections of interest are :
    On Motherboard - J1 = +12v DC input power.
                                JP4 = LCD Header.
                                JP1 = AVR In circuit Programming Header (STK-200 Dongle Compatible)
 
    On Daughterboard (Which sits on JP2 and JP3 of motherboard)
                                X1 = Outputs (connected to Relays)
                                X7 = RS-232 Port (To PC)
                                X3 = Sensor Inputs
                                X6 = LEDs on Front Panel
 

Daughter Board Hardware :

Sensor Buffers - R2/D1 form a type of input protection. U1 is configured as a non inverting unity gain buffer some filtering done by R3/C3. Any modern op-amp will suffice here. Just ensure the output voltage can be achieved with a +5v supply.

Sensor Connector X3 may need to be changed to accommodate sensors other than the LM335 type.

LM335 Sensor : I chose this device because it is cheap, easy to obtain, has a very linear (and repeatable temperature curve) and has 10mV per degree/K output. The only downside is the slope offset (or temperature offset), thus it needs to be calibrated. Use the TO-92 package, as it is easy sleeve with heat shrink. To make a water proof sensor, take a stick of hot melt glue, shave off a few slivers, and push them into the heat shrink before you apply heat. This is how all of my sensors are constructed.

In your final application, make sure the sensor has a good thermal bond between the object and the sensor. Sometimes you may need to use thermal paste or thermal transfer gel.

Power Supply (U4) - If your going to use an LCD with a backlight, you a heat sink and a beefy TO-220 regulator. Backlit LCDs draw some 300 ma at 5v.

LEDs - My hardware has 8 LEDs but the final implementation uses only four. It is sometimes useful to have extra LEDs for debugging and timing issues. The LEDs I use are surface mount dual colour LEDs. Using these small devices, it is easy to overlay them with a connector footprint, which allows the mounting of the LEDs (for demo board use) or the mounting of a connector (for the LEDs to be mounted on a front panel).

Outputs - The AVR outputs are protected by some optos which in turn drive high side FET switches. Nothing is special about either type of device, so use what you can get access too. In all of my applications, I use high current relays as well, so the on resistance of the FET is not a huge concern.

The topology of the output allows for both common ground or isolated ground as well as common or isolated supply. D1 and D4 protect against any back EMF which may happen with relay coils.

Mother Board Hardware :

Supply, Reset Generator and RS-232 Driver are standard.

The voltage reference should have less than 30ppm per deg Celsius change. This equates to about 1 degree error from 0 to 50 deg Celsius (hardware ambient temperature). That's fine for my applications, so choose a reference which suits yours. Other than that, there is nothing special about it.

U7 (External NVRAM) is not used in this project.

Pin 9 of JP4 (LCD Header) suggests this is connected to VinFilt which is normally +12v. This is an oversight since no LCDs run off +12v. I've cut the track and it now runs +5v. Remember, the LP2951 is a low current (100mA) regulator, so don't use backlit LCDs with it. I use the TO-220 regulator (on the daughterboard) for driving the LEDs in the LCD.
 

A few points of interest -

temp.c - TempTable : This is an array of data that is used to map an ADC conversion value to extract a temperature. It takes up more space that doing the conventional conversion mathematics, but it gives you added flexibility. Firstly, it doesn't matter what your reference voltage is, nor does it matter if the math's remain integer. If the sensor you are using is non linear, you can represent this far better in a table than trying to fit a polynomial. Once again, it takes space, but for my application, I don't care.

I mapped my table by knowing that the LM335Z read 10mV deg/K and used a spreadsheet to do the rest.

State Machine Details : The state machine is a case statement that repeats itself in a loop. The micro is only ever in one state at any one time. Each state sets and reads global variables. The machine is actually the case statement. It controls what state the micro is in at any one time. State machine design suggests that no one state can effect another. However, based on some circumstances in a state, you may want the machine to alter the next state executed. This is done by the machine (the case statement) passing the variable of the NEXT state to the current state. If the variable returns unchanged, then we continue as normal. If the variable has been changed, then the machine CAN jump to that state next. I highlight CAN because the machine has control, rather than the state. It's a bit weird, but it makes sense to me.

INITIAL_STATE : This sets up all the port pins, UARTs, timers and RAM based copies of NVRAM variables. After this state has finished, the machine checks to see if the user wanted to start up in the "setup state" or to start up in the control state. Once the controller has been fully setup, you would always want to start up in the control state (due to the potential of resets), but for debugging, setup or whatever, you might want to jump strait to setup first. New code now detects a blank NVRAM and writes factory defaults.

SETUP_STATE : The nerve center of the controller. Here a plethora of options await you. Setup, save and check  is the only safe way. There is not a lot of user input checking, so beware. However, I do check to ensure that the temperatures entered are covered by the table in use. If not, you end up with one or the other extreme of the table. You can also exit this state and jump strait into the control state, but a bug means I need to call the INITIAL_STATE first. Yes this violates state machine rules, but its a work around for the moment.

TEMP_CONTROL_STATE : This is where decisions are made amount turning on/off the relay. Not that complex. Some sensor checking occurs so if the sensor fails, the relay turns off (this is the main feature when compared against unreliable electromechanical thermostats). This state is only executed when the timer for this state has expired.

LED_STATE and LCD_STATE: Both states are strait forward. They only execute when their respective timers expire.

REPORTING_STATE: A useless string of diagnostics information if the controller is standing alone, but very useful if you hook it up to something like Telix or any other terminal program and log the data. Many RF modems are appearing on the market, and could make use of this. Packet radio is another possible application. Do remember however, that the controller is unprotected, and you never know who's listening, so if you do want to do something like this, put some password protection in. Included in the string is a silly little string timer. Actually, it is sometimes useful to see if a blackout has occurred over night. A future enhancement could be to use a RTC, but I don't have the need.

BREAK_STATE : Lets you can break out of the control_state, and jump back into the setup state with the characters "cq". Don't ask why (you should be able to work that out).

TIMER.C : Timer 1 Interrupt Service Routine. My original code had some hard coded timers for updating LEDs, etc. I then found I needed to do the same for the LCD and to slow temperature measurements. It all became so complex I gave up and used an interrupt driven timer. There are four timers - One for the report string (as specified in user setup) and three specified at time of code compilation (LED Update, LCD Update and Temp Update).

That's it. Not much too it really. As mentioned in the release note, it written in a very simplistic C way. I sure all you experts have spotted numerous ways to improve size, speed, reliability, so all comments are welcome. I guess I tried to keep the project as simple as possible, because I'd prefer to complete a job and then refine it than have achieved no objective at all.

Hope this answers a few questions. This project has now been moved into the finished bin, the next application includes a soft start controller for my whopping big linear 13v8 supply.

As always, all comments welcome.
 

Jump Back to the VK3EM Main Page Index