WiFi ePaper

For lower power consumption, I got some NRF51822-04 BLE4.0 modules modules. Bluetooth has the additional advantage that it can be used from a smartphone, so no extra server hardware is required (but optionally possible, with WiFi or ethernet connection). To test everything with the displays, I created a test board:

This is how the board looks like:

You can find all KiCad files and the CubeMX test project for the last test with the Crystalfontz display in the github repository. The board is 10 cm x 10 cm and would cost $76.25 at OSH Park, so I ordered it at seeed studio, for $4.90 for 10 boards. This means each board costs only $0.49, nice price. But for smaller board, OSH Park is less expensive because of the free shipping. The shipping cost at seeed was $12 with the "US GB DE AU Post" shipping option. But a board price of $1.69 is still very good.

The new microcontroller on the breakout board is working, this is the test setup:

All these wires are just for VCC, GND, and for the programmer and boot configuration:

The 100 nF and 4.7 uF capacitors are directly soldered on the back between the pin headers. I configured the clock for the maximum allowed frequency with the internal oscillator, 80 MHz, and the power consumption was only 10 mA. The capacitors C1 and C2 depend on the crystal. I've used the ABS07-120-32.768kHz-T crystal from my RTC test for my Nixie tube clock, but omitted the capacitors and looks like it works, because they are in the picofarad range and my test setup might have already enough parasitic capacitance.

After this I added a 32.768 kHz RTC crystal to pin 3 and pin 4 and configured the clock for 48 MHz and one pin for PWM output with timer 1 in CubeMX (don't forget to add a line like "HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1)", otherwise there is no output), and I could measure a very accurate 24 MHz signal, better than 0.1 % accurate, the resolution of my scope.

Usually you can't use the slow RTC clock to generate such a high frequency, but the internal high speed RC clock can be configured to get calibrated automatically by the low frequency RTC clock, which is a neat feature and eliminates the need for another external high speed crystal, even if you want to use the USB interface.

Then I tested the new 128x296 3-color ePaper from Cystalfontz, 2.9". The website provides datasheets for the display, the breakout board and sample code for an Arduino. Unfortunately the naming of the pins different is different, but similar enough to guess what is meant:

Would make life easier if they would use the same name everywhere.

The bus selection pin was always low in the source code (for 4 wire SPI mode), and on the breakout board is was soldered to GND anyway, so you can control the display with 6 pins from a microcontroller (and VCC and GND connected).

This is how it looks like, with the demo code ported to the STM32 microcontroller:

As you can see, the black fades to grey when the red image is updated, doesn't look as good as the 4.2" display from Pervasive Displays. But the image with the cat was the same grey when I got it, so I guess there is nothing wrong with my source code. I'll contact Crystalfontz, maybe they have better lookup table (LUT) data, because unlike the examples from Pervasive Displays, with this display from Crystalfontz the LUTs are sent from the application.

As tested in the last log, the ESP32 needs a lot of power. With not too big solar cells, it might only update the display once every two hours. This is the reason I tested another wireless transceiver module, the nRF24L01+.

I got some modules from eBay for or EUR 1.45 each and tried to test it with the example program with two Arduino nanos, as explained in his tutorial.

But it didn't work. After what felt like reading all of the 122,000 Google search results for "nrf24L01+ not working", soldering extra SMD capacitors to the power supply pins, using an external power supply etc., it turns out the GettingStarted script doesn't work. But it works fine with the pingair_ack example. Power consumption was about 15 mA, with some short spikes when sending, much less than what the ESP32 needs. Was no problem to send to the next room, 5 m distance through one wall, with highest transfer power setting and 1 Mpbs. With 10 m and 2 walls sometimes there were (recognized) transfer errors, but it still worked.

Unlike the ESP32, there is no programmable microcontroller on these modules. I plan to use a STM32L433CCT6 microcontroller for it. The 64 kB SRAM is sufficient to buffer a whole image for the 4.2" black/white/red display and it has very advanced power saving modes. While testing the LTC3106 power supply IC, it didn't work when starting from 0 V. With this new microcontroller it should work: The power good pin of the power supply IC can hold reset down until the voltage has reached a good level, and when the microcontroller starts, I can further measure the voltage of the backup capacitor and the solar cell, while running in low-power mode, to determine if there is enough power to do the wireless transfer. I already soldered it to a breakout board:

This would allow a use-case that @Acube asked for: a slim and compact wireless ePaper display with a 2" display, which can be updated from a RF24L01+ module that is connected to a RaspberryPi (or to an ESP32). The RPi can be powered somewhere central in the house with a wall wart and it could update multiple displays as well, or read many sensors over the low-power wireless connection.

I also got some cheaper and smaller displays from Crystalfontz to play with:

This allows to build very compact wireless display modules.

So the plan for the next steps is to modularize the design: The display modules will have a common interface to use whatever display is best for a given project. Then either an ESP32 can be used to control it, or an nRF24L01+ with the STM32L433 microcontroller and a sender module somewhere. The power supply can be a solar cell with all required voltage regulator chips, which I will build as a separate reusable module, or simply a battery or a wall wart, depending on your project.

So I bought this shiny LTC3106 power supply IC (costs EUR6.69 at Digikey) and it looks like it has all I need: peak current 650 mA, more than enough for my ESP32, and goodies like Maximum Power Point Control (MPPC) to get the most out of my solar cell. I soldered the IC on a breakout board, this is the final test setup:

But it didn't work. The ESP32 module started but restarted all the time shortly after starting. There were many problems. First I used the solar cell at the Vin pin, as an example in the datasheet says, and a 15 F super cap for Vstore. But in the fine print of the datasheet you can see that the peak current for Vstore is 200 mA, so should be no problem, right? But the valley current limit is only 70 mA for Vstore. It is 400 mA for Vin, but no way I can get this from the solar cell and I can't add the super cap to the Vin input, because then the MPPC wouldn't work.

And there was another problem: Even if I could have managed somehow to get the full current from the super cap, it has an ESR of 30 ohm, so e.g. at 3 V the max possible current would have been 100 mA.

This was a fail, I guess I can't use the LTC3106. The only nice thing about it was the MPPC function, which worked as expected. I connected 1.5 meg ohm to GND from the MPP pin and the MPP voltage was about 2.5 V, the best voltage for my solar cell as you can see in my previous log, and it could charge the capacitor at Vstore to 5 V.

Next I measured the current of the ESP32 while downloading an image and showing it on the e-paper, because I was suspicious why it resetted. The datasheet says 160 - 260 mA when sending with high data rate and max output power, and for receiving only 80 - 90 mA. But looks what I measured:

I used the μCurrent, 1 mV is 1 mA. As you can see, there are spikes of more than half an amp! I guess the datasheet averaged the current consumption, or maybe I did something wrong when measuring it? But no way that I can do this with the LTC3106 or the super cap with the high ESR.

But the solar cell charging part worked, so I changed the circuit: Now the LTC3106 charges only a different super cap, 5 F and 130 mOhm ESR (this one), which now is connected to Vout and I wired the programming pins of the LTC3106 to charge it to up to 5 V. For testing I added a linear regulator from this output (an MCP1703), to create the 3.3 V for the ESP32. Now it was possible to charge the new super cap and the ESP32 could load a new image and then go to sleep again. This is the charging curve with the solar cell and about 300 lux:

As you can see, it charged the 5 F capacitor with more than 0.3 V in about 2 hours. When I clicked the reset button on the ESP32 to wake it up from sleep and load a new image, the voltage dropped to 3.58 V. So with this setup it is possible to update the display once every 2 hours.

But this wan't the last problem: it didn't work from 0 V. When I discharge the capacitor and it starts charging it, the ESP32 starts drawing more current then the charging current at about 2.1 V and the voltage stays there. But the ESP32 module doesn't start at this voltage, it draws only current. When I hold down the reset button, the charging continues, so looks like this is a problem of the ESP32: it doesn't really work with slow rising supply voltages.

Next I'll try to build my own voltage regulator circuit, using a low power PIC microcontroller to do all the controlling in software, and external FET switches and inductors. The reason for this is because the LTC3106 is too expensive, and it doesn't even fully work as I need it. And then I would need another expensive switching regulator to create the 3.3 V from the 5 V (the linear regulator I used now is just for testing, it wastes half of the energy). I stored the solar cell energy in a 5 V capacitor, because then the stored energy is higher and it needs longer to drop below what the next stage gets needs for minimum voltage, but this might change when I build my own regulator, because there are more good 2.7 V rated super capacitors than 5 V. With the PIC I can also measure all voltages and control exactly when to release the reset line of the ESP32 etc.

Conclusion: my estimation for the number of updates (one per hour) with the solar cell from my last log was a bit optimistic, but I'm sure now that it is possible to do at least a few updates per day, even when the light is not perfect.

I got the breakout board for the new 4.2" black/white/red ePaper display, thanks to @jarek319 for the initial Eagle circuit and initial layout. I did the layout again, using all 0805 components. If you want to build your own, this is board from @oshpark and this is the Digikey cart to populate 2 boards, and including one display.

The firmware for the new ESP32 is in the github repository of the ePaper project. It is based on the http_request example project and the Arduino script from this project, ported to the ESP32 framework. Some sample images are also there, together with the convert.py script to convert your own PNG files to the BIN file format used by the firmware. To compile the project, you need to install the IDF framework and toolchain first, as described here. After starting, the firmware loads image.bin from a webserver, then goes to deep sleep mode and waits for a reset.

This is how it looks like:

The new firmware doesn't use the NodeMCU project for using Lua with the WiFi module anymore. There is a development branch of the NodeMCU project for the ESP32, but still many libraries missing and not much RAM left. Even after reducing RX and TX buffer etc., I get a out of memory error if I try to allocate a 50 kB string or more in Lua. The reason might be that the new IDF framework needs more memory than the old for the ESP8266, and Lua needs memory, too, even when only loading the libraries, because they are not in flash, but loaded to RAM. And probably because of the reduced RX and TX buffers, I got timeout messages and canceled transfers for larger files (the 30 kB binary image files). The Hello World IDF example app, I could allocate up to 280 kB and with the new firmware, using just C and the IDF library, the image is loaded always, without timeouts.

High resolution photo of the test setup:

@morganrallen suggested an interesting application for it, for showing how fresh coffee is. After 3-4 hours coffee tastes pretty bad, even when on a hot plate. The idea is to press a button when new coffee is brewed, which then will display the current time on the display. When someone gets coffee, it is visible when it was brewed. The server application can notify interested people when new coffee is ready, or when it is time to make new coffee, and the server could trigger a new image on the display to show this as well. Different strengths could be displayed as well: Press one button for light and another button for strong, and the display shows different images. Probably the cheaper 2.9" display would be sufficient for such an application, which means the cheaper ESP8266 could be used as well instead of an ESP32.

For the solar cell, I bought this one, optimized for indoor use. The datasheet says max power is 714 mW. Of course, this is in full sun light with 100,000 lux. I tested it in my living room with not very bright artificial light for worst-case condition (my lux meter shows 200 lux). With this I can get get about 5 mW out of it.

The interesting thing about solar cells is that they have a max power point. If you use a lower resistor as a load, the current increases, but the output power measured in watt gets lower below some resistor value. But if you increase the resistor too much, the output power gets lower again. There is a sweet spot for the maximum output power. For determining it I used my decade resistor box:

Together with my multimeter, I tested it for different loads and noted the measured values in a spreadsheet (see here in Libre Office format). This is the result:

As you can see, the maximum power is at about 2.6 V, with about 5 mW output power. I tested it for a brighter light, about 700 lux, and the maximum output power point was at the same voltage. Output power for this light is 6.2 mW. I used a LED flashlight for it, and looks like the solar cell couldn't use the wavelength of it as good, I would have expected more.

I found a nice chip, which is designed to be used with solar cells and other such renewable energy source, the LTC3106 ( https://www.digikey.de/short/3nzcm2 ). With this chip it is possible to configure the voltage at to get the max power from the attached solar cell. This is called maximum power point tracking, MPPT, see here for details. It can also charge an attached battery or storage capacitor and use this automatically, when the light goes off. The efficiency is about 90% at 2.6V input voltage. If we assume even worse lights, e.g. 100 lux, we might have 1 mW available power, at a regulated output voltage of 3.3 V.

I plan to use a bigger display than the 2.7" display of my first test, this 4.2" ePaper display. The ESP8266 doesn't have enough memory to buffer a frame, so I bought an ESP32 for it. I can already compile NodeMCU from source for it from the dev branch of the github repository and it runs. With WiFi activated it needs about 110 mA at 3.3 V. In deep-sleep mode I measured about 5 μA. The LTC3106 needs 2 μA quiescent current.

Let's say worst case would be 10 seconds to start the module, connect to WiFi, download a new image and update the ePaper. The ePaper needs about 8 mA max current (of course, only when updating, it doesn't need any power for displaying content), so this would be 118 mA total, which means 390 mW. If we have always light, it would therefore be possible to use a duty cycle of 1:390. This means 3900 seconds off and 10 seconds on, which means we can update he display once per hour. When in deep sleep mode, together with the voltage regulator, the circuit needs less than 10 μA, which is 0.033 mW and can be ignored for the calculation, because the solar cell provides more than 1 mW.

The ESP32 could measure the output voltage of the solar cell, so that the display doesn't get updated at night, but the battery or super capacitor can be charged, for maybe even shorter update rates. Or the update rate can be adjusted, depending on the charge state of the storage capacitor. But the conclusion is, that the project is feasible.

Now I'm waiting for the breakout board to test the new ePaper, already ordered at OSH Park:

I finished the port of the Raspberry Pi source code for the ePaper, as a module for the nodemcu-firmware project. I forked the original repository and added it as the Lua module "epd", see here:

https://github.com/FrankBuss/nodemcu-firmware

Then I installed the Mosquitto MQTT broker and wrote a Lua script for the module, that subscribes to the topic "display". The messages are interpreted as links to binary files which are loaded from a webserver and then displayed on the display, see init2.lua for the details in the new github repository for this project:

https://github.com/FrankBuss/wifi-epaper

With the Mosquitto test client I can send messages to the module from the PC, for example to load the image wifi-epaper.bin:

mosquitto_pub -t "display" -m "wifi-epaper.bin"

See the instructions on this website for details how to setup your own MQTT broker and for some explanations how to use it from Lua. The bin files are located on the webserver and are created with the test.py Python script from PNG images. The nodemcu_float_master_20170414-2230.bin file is the precompiled firmware image for the NodeMCU module, with the new epd Lua module.

You can see the connecting scheme in the LibreOffice spreadsheet pins.ods on github. It gets quite complicated with all the different internal and external names. A spreadsheet is very useful for such a task so that you don't get lost.

This is how it looks like when it is running:

The current consumption in idle mode is still quite high with about 22 mA and some peaks from time to time, maybe I can find some sleep mode for the module, it doesn't need to react immediately. When receiving a new image and updating the display, it needs up to 80 mA (at 3V) for some seconds. But it is possible to run the NodeMCU module with less power, if you don't need immediate updates of the display, but poll it like every minute.

So I ported the C code from the Raspberry Pi library for the e-paper to the NodeMCU firmware. The source code didn't look very nice, I refactored and cleaned it a bit. I'm using strings for the binary image data, because this needs less memory than arrays in Lua. But I get "string length overflow" error.

Turns out the default max string length in Lua for NodeMCU is 4096 bytes, and of course Murphy says I need 5808 bytes to store an image for my e-paper. But at least it can be changed with collectgarbage("setmemlimit", kilobytes) at runtime. Too bad there is only about 40 kB usable SRAM. I guess sooner or later I need to buy an ESP32, which has 520 kB.

So I dug up the display which I used 3 years ago, and the test image I uploaded with my Raspberry Pi project for another project I was planning, is still as clear as on the first day, and there was no power for these 3 years. That's amazing!