User Tools

Site Tools

This is an old revision of the document!


ISTAtrol

ISTAtrol v0.1 prototype in action. Does its basic duty, some planned features delayed for v0.2.

ISTAtrol v0.1 prototype in action. Does its basic duty, some planned features delayed for v0.2.

The ISTAtrol is a device for controlling temperature of a heating radiator depending on the temperature of the ISTA heating consumption counter and, in a next step, also depending on room temperature. It's easily DIY-able and code is Open Source, so it can be custom programmed without too much effort. It means to replace traditional mechanical thermostats.

It was designed because these ISTA counters measure heating consumption based on the temperature of the radiator, only, which leaves much room for optimisation.

Features

All the planned features. Basic operations work fine, some had to be postponed. See below and the [[#TODO]] section.

All the planned features. Basic operations work fine, some had to be postponed. See below and the TODO section.

Of the shown features currently works:

  • USB.
  • External and USB voltage source (one of both required).
  • 1 temperature sensor.
  • Radiator valve motor.
  • In System Programming (ISP)

All other features require some schematic and PCB layout changes as well as an upgrade to an ATtiny4313. One could operate LEDs or user buttons right now, but then one would have to drop temperature controlling code due to ATtiny2313's tight program memory (2 kB Flash).

Disappointed? Well, at least it's demonstrated that the design principle works and an 20-pin ATtiny is suited for the task. Good preconditions for the next prototype :-)

How To Get It

Firmware sources, schematics and layout can be found at ISTAtrol on Github.

In its current state you likely want to fix some of the issues found during development first. If you do so, don't hesitate to ask for a PCB or two, Traumflug usually makes them happily and for free.

Assembly

Assembly is straightforward, simply solder in all components in order of raising height. Before inserting the ATtiny it's a good idea to connect the device to USB, jumper USB as voltage source and measure all the ATtiny socket pins that none of them receives more than 3.3 volts.

Firmware Upload

Firmware should compile out of the box with a simple

make

For uploading the firmware one needs a programming device, e.g. Pololu's PGM03A. This PGM03A can deliver signals at 5 volts, only, the current ISTAtrol design has voltage dividers built in to deal with this.

Before the first firmware upload, ATtiny's fuses have to be programmed:

make fuses

Then one can upload the actual firmware:

make program

After any firmware change, e.g. a change in configuration, only the latter command has to be repeated.

Connecting to a PC

When connecting the ISTAtrol to a PC, a new USB device should appear. Use lsusb on the command line for checking. There should show up a device named Van Ooijen Technische Informatica Free shared USB VID/PID pair for CDC devices.

That's all, USB communications is working.

Controlling Terminal

As ATtinys 2 kB of program memory is so extremely tight, offering a serial-over-USB connection had to be dropped. Instead there is terminal.py, which does essentially the same.

To fire up the terminal, type

sudo ./terminal.py

on the command line. It should connect to the ISTAtrol and give a temperature readout every minute. That's how one makes visible how the ISTAtrol works.

Valve Actuator

Mounted valve actuator. White and green wire go to the ISTAtrol. Note the knots in the wires, acting as stress relief.

Mounted valve actuator. White and green wire go to the ISTAtrol. Note the knots in the wires, acting as stress relief.

Any controller needs some means to influence the controlled entity, of course. In terms of the ISTAtrol, this is the valve of the heating radiator. For the prototype, this actuator was taken from a EQ-3 Model N.

Red wire of this actuator is plus and goes into the pin closer to the thermistor connectors of the motor connector. Minus goes to the one closer to the user buttons. If the actuator happens to react the opposite way later, like opening the valve if temperature is too high already, these two have to be swapped.

Temperature Sensors

Bad news: there are three thermistor connectors in the layout, but two of them have to be kept disconnected. Third one works just fine :-)

Type of the thermistor isn't crucial. Design was made with a 10 kOhms type in mind. Lower ohms ones will give smaller temperature readouts, larger ohms ones will give a higher readout. This can be adjusted in the configuration by TARGET_TEMPERATURE. Simply attach the thermistor, fire up terminal.py and look what the readings are. Then adjust configuration and upload firmware again.

If readouts happen to be above 32'000, firmware has to be adjusted. Prescaling in temp_init() should be changed to a higher value. For readouts < 1000, doing the opposite is likely a good idea to get better precision.

Very coarsely measured readout of the developers thermistor.

Very coarsely measured readout of the developers thermistor.

For the technical: ATtinys feature no Analog Digital Converter (ADC). But there is Atmel Application Note AVR400, outlining how to get analog readouts by using the Analog Comparator (ACO) anyways. Essentially, a capacitor is loaded starting at time zero, then the time measured (with 16-bit Timer 1) how long it takes to reach a constant comparison voltage. As the loading current goes through the thermistor, higher thermistor resistance ( = lower temperature) leads to a longer loading time and vice versa. This implementation is actually simpler than one using an ADC.

As one can see by the coarse measurements done, this is linear enough for our purposes. The recorded pretty hefty hysteresis isn't a property of the thermistor or the ISTAtrol, it's an artefact of the measurement procedure.

Configuration

Here's a description of the configuration values meant to be user-adjustable. They're at the top of main.c and get in effect by re-uploading the firmware. Runtime ajustments are planned for after the upgrade to an ATtiny4313.

All the values described here are also described in a comment in main.c.

TARGET_TEMPERATURE

This is our main goal, here one sets which temperature the ISTAtrol should try to keep. The actual value largely depends on the thermistor in use. Use terminal.py to see current readout, then adjust gently. On the developers thermistor, a change of 100 resulted in roughly a change of 1 degree Celsius.

THERMISTOR_HYSTERESIS

This is, also in thermistor ticks, temperature is allowed to deviate from TARGET_TEMPERATURE. Too small values result in constant valve movements (more than 20 per hour), a too large value doesn't harm, but may result in unwanted temperature changes.

RADIATOR_RESPONSE_TIME

Temperature response of the developers heating radiator.

Temperature response of the developers heating radiator.

This is a bit a tricker one. Moving the radiator valve usually doesn't lead to an immediate change in temperature on the sensor. There is some dead time in between. Checking temperature and/or moving the valve too often makes no sense within this dead time.

To get an idea about this dead time, connect ISTAtrol, run terminal.py, without mounting the valve actuator, yet. Adjust terminal.py to give readouts more often by changing time.sleep(60) to time.sleep(1) in the last line of terminal.py. Then open the valve with the former thermostat and watch when temperature starts to raise. This is the value which should be entered here. The developers radiator response can be seen in the picture. According to this, a value of 120 was choosen.

PREDICTION_STEEPNESS

This value says how “sharp” the controlling algorithm responds to temperature changes. Too low and temperature will occasionally drop out of the given hysteresis width. Too high and the valve will be actuated too often. 4 has been found to be a good value in conjunction with a hysteresis of 50.

MOT_OPEN_TIME

The radiator valve is moved in increments, absolute position is actually ignored. Such an increment means to run the actuator motor for a short while. This value says how long this short time is when opening the valve, in milliseconds.

MOT_CLOSE_TIME

The same when closing the valve. Both values can be adjusted individually, because in some scenarios exceeding temperature to the top harms more than having it too low for a short while, so close time is usually bigger than open time.

Practical Experience

Quality of temperature regulation was recorded during days of firmware development, simply by running terminal.py and copying its output into a spreadsheet (GNUmeric). These graphs show not only how different algorithms behave, they also give some hints on a sane configuration.

Early Days

First ISTAtrol performance measurements.

First ISTAtrol performance measurements.

As one can see in the first set of graphs, regulation was really jerky in the early days. With a simple Bang-Bang-algorithm (“Temp too low? Open valve. Temp too high? Close valve.”), temperature moved up and down funnily, sometimes more than 10 degC. Part of the reason for this behaviour was certainly not only the algorithm, but also valve close time being 10 times higher than valve open time. Apparently the developer feared a lot to exceed target temperature.

Next step was to add kind of a mild prediction into the algorithm. “If temperature raises already, don't open the valve further. And vice versa”. Eventually, precision became better when distance between valve open and close time was reduced.

Full Predictive

Much better! So much better the temperature axis scale had to be changed. The larger spikes mark room temperature changes, like opening the window.

Much better! So much better the temperature axis scale had to be changed. The larger spikes mark room temperature changes, like opening the window.

As the Bang-Bang thing had turned out to be not very helpful, it was removed entirely. Instead, prediction now scales the last temperature change by factor PREDICTION_STEEPNESS into the future and looks wether this future value is within target bandgap. As one can see, results were much better, a precision of +- 0.5 °C could be kept almost all of the time. This is usable!

But still occasionally an erratic temperature measurement slipped in, exploiting the prediction formula. Readouts aren't exactly noise-free, likely due to all the long unshielded wires. So an exponential moving average was introduced, each new measurement now counts in only 12% of the existing value. Regulation response is still quick, because some 100 averaged temperature readings happen between two evaluations of the regulation algorithm.

And then a hardware issue was found. The temperature sensor was connected directly to the radiator, more precisely to the ISTA consumption counter. But when a blow hushed through the air, the sensor would change a lot more than the radiator. So the sensor was thermally insulated against air with some foam, still tightly connected to the radiator, problem solved.

Now we get away with about 11% valve movements, which is one movement about every 9 minutes. Looks like a good compromise between precision and valve actuator wear.

istatrol.1458916582.txt.gz · Last modified: 2018/05/27 16:10 (external edit)