This project was born out of my fascination with Sharp's memory LCD and my aspiration to showcase three-dimensional visuals on this remarkable display. The software responsible for generating the 3D world displayed on the screen draws inspiration from Tim Clarke's 'Mars Demo' created back in 1993—a revolutionary piece of software that was far ahead of its time.

In my quest to understand the inner workings of the 'Mars Demo,' I dived into research papers and stumbled upon the work of Mark Feldman, who had programmed it in Java. Utilizing Feldman's code as a reference, I started programming it for the ESP-32 S3 microcontroller. However, I struggled a lot trying to run it at high FPS and the program became a trade-off between terrain detail and processing speed.

My first crude test looked like this. Later I switched to the ESP-32 S3 because its a tiny bit faster. 

After spending a lot of time trying to crank out as much frames per second I decided to try to maximizing the runtime of the art piece. This led me down into an interesting rabbit hole of low-power electronics and effecient programming.

There are a few things that I learned through making this project. One of those things is about the different sleep-modes of the ESP-32. When the ESP-32 is in light-sleep mode, the volatile memory responsible for storing the world remains active, ensuring that the generated world is preserved upon waking up. However, when the ESP32 enters deep-sleep mode, the volatile memory is lost so it is necessary to stpre the current world parameters within non-volitile memore  necessitating the saving of current world parameters to non-volatile memory prior to entering deep-sleep.

Here's the interesting twist: saving the world parameters takes some time and uses a bit of energy. Therefore, the decision to save the world parameters becomes worthwhile only when the microcontroller remains in deep-sleep mode for an extended period, allowing the energy savings to offset the cost of saving the parameters. For those who are interested; for my particular program it became beneficial to use deep-sleep when sleeping for more than 4500 milliseconds. 

On the hardware side of things there are only four major parts to the device: It is using the ESP-32 S3 MINI chip as its main processor. The MCP73871 Li-ion charge uses solar energy to charge the li-ion battery. The battery voltage is converted to 3.3v using a ADP2108/AP2112 . Lastly there is the bq27441 fuel-gauge that keeps track of the battery's SOC and feeds that data into the ESP-32. The fuel-gauge chip also provides me with some hand-dandy power measurements and is showing when the battery is being charged by sunlight. 

When doing one frame per second the chip tells me that the whole system is using 14 milliamps at 4.1V which translates to a power consumption of 57 milliwatts. The Li-ion battery that I'm using stores a total of 12.95Wh so it should last for about nine days. I currently have not been successful at measuring the power consumption at one frame per hour since the bq27441 chip can only average its readings for one second so for this we have to do some calculations. When the ESP32 is active I measured its current draw at close to 70mA (at 3.3v). This means its using about 0.23 Watts, or 230 milliwatts. It takes the ESP32 approximately 60 milliseconds, or 1.67e-5 hours,  to execute the code that renders the frame on the display. If we multiply the power consumption (0.23 Watts) by the amount of time using it (1.67e-5 hours) we know that it costs the ESP32 about 3.85e-6 Watt hours to calculate one frame. In light-sleep mode the ESP32 consumes 2.64e-3 Watts so during its almost one hour long sleep it will consume 2.64e-3 Watt hours. This means the power used to render the frame is also negligible compared to the power used to sleep.

To calculate the expected battery life we also need to factor in the power consumption of the fuel-gauge, display, charger-ic...