voidvent

room climate control project that replaces the microcontroller inside a blueair pro air purifier with a transceiver-enabled cc430f5137 devboard from Olimex.

 source:       https://codeberg.org/subDIMENSION/voidvent
 author:       Petre Rodan <2b4eda@subdimension.ro>
 license:      BSD

more images can be found here.

Features

• RF-based remote control of the air purifier via radio commands. the following Intertechno remotes are supported: ITLS-16, ITS-150, YCT-100 and the ML-7100 doorbell
• control remote air extractor via RF signal via an Intertechno CMR-1000
• capture remote sensor data provided by Hama EWS trio (for temperature and relative humidity) generated in different zones inside and outside of the appartment.
• local CO₂, temperature and humidity sensor (SCD30)
• remote display unit
• visual and sound cues for errors and warnings
• act as doorbell

Components

project directory structure

• ./doc - flowcharts, signal decoding, rf parameters used in testing
• ./firmware/base_station/ - source code for the base station (firmware that replaces the old brain of the Blueair pro air purifier) (CC430F5137)
• ./firmware/remote/ - source code for the remote display unit (MSP430FR5994)
• ./firmware/lib/atlas430 - the MSP430 HAL
• ./hardware/blueair_pro_m/ - kicad schematics of the digital subsystem of the air purifier

make sure to pull the atlas430 submodule before trying to compile the firmware:

git submodule update --init --recursive

Build requirements

you will need TI's excelent GCC toolchain or Code Composer Studio.

cd ./firmware/base_station
gmake
gmake install

Code implementation

the entire code is interrupt driven and it uses my msp430 HAL. multiple state machines control the vfd display, the tweeter, a group of LEDs, the low level radio and the communication protocol between base and remote with the added benefit of fallback and retry functions. yEd flowcharts are available in the doc subdir.

the transceiver used in the base_station is an SPI-controlled CC1101 and in the base_station it's internal to the CC430F5137 microcontroller. there are a minimal number of differences between the two and both hit the exact same hardware bug related to sporadic invalid data generated in the RXBYTES register - which was dealt with in firmware. the bug is somewhat related to the known RXBYTES idiosyncracies covered in the chip errata.

all sensor and intertechno signals are merely demodulated by the transceivers (using a set of rf parameters that almost match all the protocols involved) and later decoded asynchronously in firmware. during the communication between base and remote the transceivers are reconfigured to support a faster bitrate and the signal coding/decoding happens in hardware. this communication is based on a custom protocol that somewhat resembles a simplified TCP stack - messages get ACK-ed, retried if no reply is received and everything has a safe fallback in case the signal to noise ratio is overwhelming. these fallbacks and watchdogs make sure that everything recovers in the most exceptional of corner-cases.

this project is 100% free of AI, clouds, subscriptions and even internet.

Testing

the code itself is static-scanned by llvm's scan-build, cppcheck and coverity.

online coverity scan reports for the base_station:

and for the remote unit: