The first version WeatherStation Color was a big success and I got a lot of feedback of hackers all around the world who enjoyed putting it together. While this was great there were still quite some issues which I wanted to resolve. The first issue was the flickering of the screen when you would change the screen or update the time. As an additional side effect there would be sometimes pixel artifacts close to the time where I had not been careful enough to delete the previous image. The second frequently mentioned problem was that the icon downloader which downloaded the icons from my web server sometimes would fail to actually download images to a plethora of reasons. And the third problem was that my implementation was a bit lazy when it came to daylight saving time (DST); I just ignored it and assumed the user would be OK to reprogram the WeatherStation once the DST would change. In this post I will focus only on the first problem, the flickering.

Flickering

Getting rid of the flickering was the problem which consumed the most part of the last few months. I decided to write a whole new library to address the issue. In order to understand why I thought this step was necessary we first have to look at the problem I tried to solve. After all you might think that even wasn’t such a big issue!

The  Adafruit GFX library which I used for the first version of the WeatherStation Color writes every pixel you alter directly to the display, in my case a 240×320 pixel TFT screen based on the ILI9341 chip. While this is reasonably fast it is not fast enough to keep your eye from seeing an in-between frame when you delete the screen before drawing the next one. Let’s say you draw some weather icons to the screen you want to remove all traces of the old icon before you draw the next one. So you clear the screen and fill it for example with black. Once this operation has finished you continue by drawing the new icon. Since all operations are directly drawn to the screen your eye can see a very short phase where the whole screen was black. You see a flicker! So how could this problem be addressed?

Color Palettes

It turns out that I wasn’t the first one to face this issue. This problem is usually addressed by drawing first to a memory-online (virtual) screen. Once all drawing operations of a iteration have been completed you write everything at once from the virtual screen to the physical screen and your eye will not see the clearing of the screen as a separate step. This virtual screen is often called “frame buffer” or “double buffer” and it has one big drawback: it consumes a lot of memory. When I first set out to rewrite the OLED library I wrote for the classic WeatherStation I quickly realized that the available heap memory of the ESP8266 would not be enough to accommodate a frame buffer with 240x320x2 = 150kb. Each pixel would require 2 bytes of memory since the ILI9341 has a 16 bit color scheme. 5 bits for red, 6 bits for green and 5 again for blue would together build up for the 16bit color information. Internally the ILI9341 uses a palette to expand this 16bits to the full color range available on its TFT screen and this brought me to the solution of my memory problem. If I could somehow reduce the memory consumption per pixel to a few bits the ESP8266 would have enough RAM to hold my frame buffer!

Reducing the bit depth per pixel is commonly implemented with color palettes. Instead of describing the pixel colors in values of red, green and blue you use a limited set of colors and give each of this color a alias number. So when changing the color for drawing you don’t say r:127,g:55,b:255 as you would to in a HTML file. You just tell the graphics library to use color 5 from the palette.  Which color represents index 5 is defined in a data structure called the palette. Before the graphic library writes the buffer to the screen it looks up the real color for each index and replaces the index with the RGB value.  This is actually a very old trick. I just recently read this article by Aaron Bell which nicely explains how the Commodore C64 and other 8bit computers used this trick to get 16 colors onto your CRT screen and how some games used fast color switching to create colors beyond the hard wired palette. If you are interested please read his article. I can recommend it!

So now I had my concepts together: frame buffer plus a palette color scheme would solve the flickering problem and still leave enough memory for the program code and the weather information.. Well, it was still a long journey from the concepts to a actually working implementation. I didn’t just want to write a graphic library which could only be used with one type of display. I wanted to write a versatile and easy to use library which would use some kind of hardware abstraction layer (HAL) to separate drawing routines from the hardware commands. It should also be possible to adjust the bit depth (or bits per pixel) depending on the used display or availability of heap memory.

So I had to do some heavy bit math in order to get it all right. The first real demo was a cube rotating with ~17 frames per second (fps) and using the frame buffer with 16 colors or 4 bits per pixel (2^4 = 16):

I think this is quite impressive for a micro controller! If you like to try it out it is part of the MiniGrafx library as a demo.

Memory problems

Once again I thought: almost done, now I “just” have to port the old WeatherStation Color code to the new MiniGrafx library. Turns out that I hadn’t realized how bad the WeatherStation library, which fetches the weather data from Wunderground, was in respect of memory consumption. The WundergroundClient class had become a big monolith which would reserve a lot of memory no matter if the application would use all available methods.

I realized this after my first attempts to run the WeatherStation color. Even before reaching the setup() method the ESP8266 would crash with a strange memory access error message. After a while I figured out that a part of the ESP framework tried to allocate memory and couldn’t do that because the frame buffer had already allocated too much. So I had not only to reduce the color palette from 16 colors to 4 but also re-design the Wunderground client. I broke it up into one class per method (current weather, forecast, astronomy and alerts) and more importantly changed the way the fetched data was stored. The old WundergroundClient class allocated all memory when it was instantiated for all methods. It stored the data as members in the class. After the redesign you have to allocate the structs in your own code and then pass in the objects by reference. This way the application code can control much better how much memory it can and needs to allocate.

The Result

I am quite happy with the new version of the WeatherStation color! Even if it only has enough memory to display four different colors (black, white, yellow and blue) it looks very colorful. Sadly I had to kick out the photos of the moon phases and replace it with a font based approach. The moon phases are now icons rather than photos but I think that is not a huge loss for the weather station. On the plus side the WeatherStation Color can now display a 6-day forecast on a side scrolling slider (or carousel), which is quite cool (IMHO).

The ESP8266 WiFi Color Display Kit

When I first published the WeatherStation Color many of you approached me since they had problems to find the right display. To make things easier for you my friend Fred helped me to put together a starter kit containing a Wemos D1 Mini Pro (with 16MB!), a ILI9341 with resistive touch screen and a PCB to connect the display and the Wemos module. I am very happy to offer you this kit for a reasonable price in my shop. It will be shipped from a warehouse in Dongguan (Perl delta in China) to almost all countries in the world. By buying the kit you are also supporting further development of the WeatherStation and other applications running on this platform.

Order it now!

Touch screen demo

The Lego House

Thomas Arlitt from Germany built his Weather Station based on a 2.6″ display from Drigole. His daughter said that it needs a house so they made one out of Lego. Thanks a lot for sharing and sorry that it took so long to publish it. If you are interested in his code please leave a comment on this page.

3D printed Case

My good colleague Peter Kohler (@hb9tvk) gave me the first introduction on how to use a 3D printer. He has done some cool projects like a morse code trainer for another colleague or a digitizing his analog water meter with a 3d printed sensor lid. And he also recently designed a wonderful case for the WeatherStation color. If I remember correctly he designed it with a latch so there is no need for screws on the enclosure. Thank you a lot for sharing Peter and for your constructive feedback about the code!

WeatherStation with Traffic Info

Olly Klassen (@NemosNautilus, http://olly.ch/) is living also in Switzerland and he is famous for his home theater  which is a detailed steampunk reconstruction of the interior of the Nautilus, you know, the famous submarine of captain Nemo from 20.000 Leagues Under the Seas by Jules Verne. But Olly is not only good with mechanical tools, he can also program. He added another frame to the OLED WeatherStation and is displaying the current time it would take for him to drive home from his office. On top of that he included an RGB LED which is displaying the current traffic situation with one color: green means everything fine, with yellow he has to expect about 10 minutes of delay and red tells him to stay in the office and to wait for the traffic jam to disappear. The enclosure is a pretty little jewelry box he repurposed for the traffic indicator. He wrote me that he plans to build a nice little steam punk case. I’m looking forward to the update once he is finished with it. He loads the traffic information from the Google Maps API for which you need to acquire an API key

Adafruit’s take on the WeatherStation Color

If you are into DIY electronics you must have come around Adafruit Industries (@Adafruit) and their founder Limor Fried AKA LadyAda. They are an open source hardware company and also contributed a lot of open source libraries for all kinds of devices. Shortly they are doing what I would love to do for a living. So you can imagine how happy I was when I found my WeatherStation Color project being presented on their page with detailed building instructions. Thank you Adafruit for sharing!
Detailed build instructions: https://learn.adafruit.com/wifi-weather-station-with-tft-display/overview

You  can find it here: https://github.com/squix78/esp8266-weather-station-color

Since it was sometimes complicated to find the right parts I created a kit which contains all the parts including the connector PCB:
https://blog.squix.org/product/esp8266-wifi-color-display-kit-2-4
By buying the kit from me you are supporting future development. Thank you!