Project Logs

Collapse logs

• A W1209 Software for Cooling Food with a Peltier Element

  Thomas • 02/03/2019 at 20:44 • 0 comments

  @paulcrawfordgm turned the W1209 Data Logging Thermostat into a cooling controller with a serial interface:

  The project started here on HaD, continued with an STM8 eForth issue, and was completed in TG9541/W1209 issue #22.

  Paul achieved the following:

  • coping with a non-standard W1209 board variant (Nuvoton chip, 5K NTC pull-up)
  • set-up of Travis-CI for Paul's fork of the TG9541/W1209 repo
  • changed control.fs from heating to cooling
  • menu adapted and simplified, logger.fs removed
  • serial interface for temperature data with counter and CRC-16

  The process of problem resolution and the Forth learning process worth reading!

• Menu problems while using serial console fixed

  Thomas • 02/02/2019 at 23:06 • 0 comments

  Among other things, e.g. using the W1209 firmware for cooling, a problem with the menu has been fixed: transmitting characters quite often resulted in erroneous key inputs.

  Now that has been fixed in the master branch. The discussion inIssue #22 is also quite interesting!
  

• A different type of thermostat: a Solar Heating Controller

  Thomas • 09/26/2018 at 17:57 • 0 comments

  Solar heating controllers need at least two temperature sensors. Such a thing can be hacked using a W1209, but I decided to design a new PCB (mostly because I try to avoid relays in things that I expect to work for more than 10 years unattended).

  To keep a log of my progress I started a HaD project Solar Heating Controller. Maybe it catches your interest!
  

• More-or-Less Compatible W1209 Clones

  Thomas • 02/09/2018 at 20:11 • 0 comments

  A GitHub user documented a W1209 clone with a common anode display. This issue describes how to spot such a clone, and it also contains code patched for using the CA display. This board will be supported in the near future.
  

  I found one more clone with a different PCB layout, and I ordered one for examination.
  
  

• Which W1209 boards *not to buy* if you want to run the code here

  Thomas • 01/31/2018 at 20:11 • 0 comments

  @richard got a couple of W1209 boards, and some of them just couldn't be flashed. It turns out the at least one manufacturer (namely TENSTAR ROBOTS) makes boards with a nearly pin compatible 8051 based µC (a Nuvoton chip in a TSSOP20 package). Details are at the end of the GitHub Issue here.
  

  Mitigation: don't buy boards that look like one of these:
  

  Note that C5, the Vcc capacitor next to the µC, is unpopulated. The backside of the black board is bears the label "TENSTAR ROBOT W1209". The label on the back of the green board is "XH-W1209". The Nuvoton is quite fast, and if you like programming the 8051 it's maybe not the worst choice. However, please don't count on my help for programming it. I'm done with MCS51 ;-)
  

  @BigVulcanDeal let me know that there are boards with a 5k, instead of 20k, reference resistor. That's a good match for measuring temperatures in the range of 30°C to 50°C, but you'll need to replace the linearization table in measure.fs.
  

• Release 0.2.0: improved Data Log, better Sensor Filtering

  Thomas • 12/17/2017 at 10:24 • 0 comments

  I've just release a new, improved version of the W1209 Data Logging Thermostat: now the data logger registers the following data:

  • relay activation cycles per log interval
  • relay duty cycle
  • lowest, and highest temperature in the cycle

  Used properly, this data can be used to improve the control behavior (heating power), or for getting clues on the effects of heat flow & thermal mass, sensor location, or quality of the insulation:
  

  Check out the README on Github for features, source, and instructions!
  

• Temperature Logging with the W1209

  Thomas • 12/10/2017 at 09:45 • 0 comments

  By default, the firmware exploits the fact that the Value Line STM8S003F3 µC is just a STM8S103F3 with relaxed specs, and with only 128 bytes of EEPROM memory specified. All the chips I tested hat the full 640 bytes of the "Access Line - Low Density Devices" available, and I decided to use all but 64 bytes as a ring buffer, enough for more than 24 hours at a rate of 10 samples per second.
  

  The ring buffer requires a single head pointer, which, for practical reasons, must be in the EEPROM. The number of EEPROM write cycles of Value Line devices, however, is specified with 1x10^5, in the full temperature range with nominal data retention, that is. At a rate of 10 log entries per hour a 20ct µC is still good for 10.000 hours, more than a year.
  

  I have little doubt (not "little doubts", like my Indian colleagues usually say when the strongly disagree) that the number of write cycles at room temperature, and with random data, is more in the range of 1x10^6, more than 10 years. The "electrical life" of a Chinese low-end relay in a thermostat application is most likely much shorter.
  

• Minimal Viable Product

  Thomas • 11/26/2017 at 16:41 • 0 comments

  There is finally the the first (pre-) release of the W1209 $1.50 data logging thermostat!

  It's based on the latest STM8 eForth (pre-release 2.2.20.pre.1), and the binary was automatically built in uCsim, and deployed, by Travis-CI.

  Features are:

  • heating thermostat, e.g. for building chicken egg incubators
  • basic sensor failure detection
  • parameters for set-point, hysteresis, and trip-delay
  • easy to use parameters menu (no need to search for a manual!)
  • temperature logger with 0.1h to 10h interval, and a 288 entry ring-buffer
  • logger access through a serial console
  • fully programmable in Forth, even while the thermostat is running!

  Although it's feature-complete, it's work in progress.

  For the future, the following feature are planned:

  • Improved logger with min/max temperature, and heating duty cycle
  • Field-bus feature for thermostats
  • more fail-safe features (parameter integrity, maybe a buzzer)

• Dependencies up-to-date: the Makefile now installs STM8 eForth

  Thomas • 11/04/2017 at 18:57 • 0 comments

  It's been a while since I last worked on this little project. The reason was that I concentrated on the STM8 eForth foundations:

  • development framework with a Forth library
  • e4thcom support
  • codeload.py with emulation of the e4thcom features #include, #require, and \res
  • automatic generation of "aliases" for unlinked words in STM8 eForth words
  • Continuous Integration/Test/Deployment with Travis-CI

  The GitHub W1209 repository now also uses these goodies, and the Makefile automatically installs the specified revision of STM8 eForth from the binary release.
  

• A scripting language for a thermostat

  Thomas • 08/10/2017 at 06:28 • 0 comments

  This project builds a scripting language for W1209 thermostats. The scripting language is Forth based, but that doesn't mean that you need to know much Forth to get something done (the goal is that you don't need to know it's Forth).

  To do achieve this, I'm experimenting with a simple "processing" pattern: chained steps.

  \ background task with temperature control
  : task ( -- )
    measure            \ measure temperature
    control            \ temperature control
    logger             \ data logging
    menu               \ menu and display code
  ;

  The trick is that, like in jQuery, one can chain "filters" if the data type of "output" matches the "input". In the case of a thermostat that's easy: it's all about temperature.

  The other part is that chainable filters are self-contained units. To do this I use basic modular programming techniques, and a chained init function:

  \ chained init - starting point
  : init ( -- )
  ;
  #include measure.fs
  #include control.fs
  #include logger.fs
  #include menu.fs

  In a module, e.g. measure, the initialization looks like this:
  

  \ chained init
  : init ( -- ) init
    \ init LPF state with max. value
    dig2temp2 DUP @ 1- 2* 1+ + @ LPFDIG !
  ;
  

  The word init first calls the init word of the previous module, and the complicated part, e.g. filter initialization, is nicely hidden.
  

  The next thing is the file include hierarchy, a design feature of e4thcom. The file search path is: "cwd:cwd/mcu:cwd/target:cwd/lib" (cwd = current working directory). The standard filter words for an application are in the target folder. In an application, library words can be transparently replaced with a modified version without the need to change the library.
  
  

View all 12 project logs