Follow me down the optimization rabbit hole

  The "CO2" Project By Larry Bank Environmental sensing and air quality have always been fascinating to study. I've tested various sensors over the years that, until recently, cost next to nothing. The COVID pandemic increased my curiosity (and concern) about indoor air quality, CO2 levels, and shared air. In the past, I tried to save some money and use the "eCO2" value from several inexpensive sensors, but the results were unreliable and unsatisfying. eCO2 is an "equivalent CO2" value generated by some VOC ( volatile organic compound ) sensors. The idea is that human breath contains lots of VOCs and if you detect them, you're also detecting CO2. The flaw in this thinking is that a lot of other things generate VOCs and have nothing to do with CO2. A good example of a false positive is food preparation. Bring your VOC sensor into the kitchen when you're cooking and it will tell you that the air has a toxic level of "eCO2". I've bee

Background In addition to code and power efficiency challenges, I occasionally find other challenges that attract me. Not long ago I started working with Aaron Christophel on his various electronic shelf label and e-paper projects. One of the ideas I had was to put more autonomy in the MCU boards controlling price labels so that they could do more than just receive images wirelessly from a server. The original project used a price label with an ARM MCU and plenty of RAM. I was able to run my TIFF G4 decoder on it and have the entire resulting image in RAM before sending it to the e-paper display: The MCUs in Aaron's more recent (and larger) collection of devices contain an 8051-type CPU with limited FLASH space and a much more limited amount of RAM. I thought it would be a good challenge to see how much independent functionality (text/GFX) I could run on those 8-bit CPUs. The Problem Let's start with an example e-paper display - a 2.9" black and white with 128x296 pixels.