The Beginnings

A few months back I had already built and published a PlaneSpotter project for the tiny OLED screens. It was quite useful but could only display text information about the nearest plane. How much cooler would it be to have a tiny and affordable device displaying a map with airplanes on it, just like the apps you have on your smart phone? The idea kept coming back to me but one important puzzle piece was missing: the TFT library could only display raw bitmap files (BMP) and I didn’t know of any mapping service which would let you download bmp images. Of course, I could have built a web service which would have converted JPEGs and PNGs to BMPs on the fly but that wasn’t really my goal. So I was stuck with the idea until I recently found Frederic Plante’s fork of the JPEGDecoder library with adaptations for the ESP8266. This suddenly changed the game and I started working on the PlaneSpotter Color project.

The JPEGDecoder library

It seems that this library has seen several iterations and forks. It is built around Rich Geldreich’s picojpeg library which is very good on embedded devices with limited memory. The library was wrapped by Makoto Kurauchi 3 years ago for Arduino. Then Bodmer created a new repository and added more samples until Frédéric Plante ported it to the ESP8266. There might have been too much forking and copying but it is still a very good example for how open source works. Since this library is currently not available in the Arduino IDE library manager you’ll have to clone Frédéric’s repository or download the zip file.

While the maps from MapQuest were displayed without issues I had problems with other JPEG files. The splash screen which I had ordered from a Fiverr designer didn’t display properly on the TFT. I had opened it in GIMP and exported it with the proper dimensions but on the TFT it would always show up with artefacts. I first suspected compression but the artefacts did even shop up with 0% compression (or 100% quality). Another open source tool had to help: ImageMagick’s identify showed me that images which worked at a sampling factor of 1×1, 1×1, 1×1 while my Gimp export had 2×2, 1×1, 1×1. So keep in mind if you want to display your own files.

From what I could tell the library currently cannot decode data from PROGMEM. What does that mean? When you mark a variable or array with the PROGMEM keyword it will not be loaded into your memory after startup but stay packed in your firmware. With a special read command you can then read this data and do what you need with it. Usually font files also use this little trick. This is quite cool since you don’t have to upload images to the ESP8266 by using an additional Arduino IDE plugin. In the WeatherStation Color I had worked around this problem by downloading the moon phase images from my web server. But having the images in the source code is much better. You can create your own images on a Linux/Unix system like this:

xxd -i image.jpg | sed "1s/.*/const uint8_t image[] PROGMEM = {/" | sed "s/ [a-zA-Z_]*_len/ image_len/" > image.h

Explanation: the xxd command creates a hex dump of image.jpg but it doesn’t contain the PROGMEM keyword. So the first sed command replaces the first line with a new one. The second sed replaces the name of the variable that holds the length of the array. Then the file is written to a header file.

I mentioned that the library is currently not capable of loading data from PROGMEM. I therefore wrote a little routine which copies the PROGMEM data onto the SPIFFS file system of the ESP. From there the JPEGDecoder library can read it.

The Wifi GeoLocator

I’m most probably not the first one to do this but I still think it’s worth mentioning. Did you know that your ESP8266 has a GPS device built-in? Well, it is not exactly a GPS device but under certain situations can be even more precise. It works by scanning visible access points and sending them with the signal strength to a web service. If your database is good enough and contains the necessary SSIDs you will get a pretty decent location fix. This only works if you are connected to the internet and if you can call the webservice but hey, it basically comes for free.

Alexandar Mylnikov is running such a webservice which is fairly easy to use:

https://api.mylnikov.org/geolocation/wifi?v=1.1&data=open&bssid=00:0C:42:1F:65:E9

which returns a JSON object:

{"result":200, "data":{"lat": 45.21981301815, "range": 125.417, "lon": 16.54716187303, "time": 1483362238}}

There is also a beta version which takes a base64 encoded list of multiple bssids and the rssi (signal strength) which in theory should result in even higher precision.

Drawing on the TFT

The current setup shows an ugly flickering with the update of the data every few seconds. Sadly I couldn’t find a way around that issue yet and this is for a good reason. In the OLED display library I could just build a frame buffer, do all drawing operations there and then write the whole buffer to the display. But 128*64*1 bits don’t consume so much memory like 320*240*16 . (2 bytes per pixel with a resolution of 320×240). There are certainly some tricks you can use to work around this issue but they would currently consume time I don’t have. If you have suggestions or even pull-requests on github, please let me know.

You might also notice that the flight tracks are not working 100% properly yet. Sometimes they seem to forget their past and start over again.

PCB design, Fritzing and KiCad

In this project I tried out a lot of new things. One of them was designing my own printed circuit board. The board is actually quite simple and only needs to connect the 14 pins of the Touch screen/ TFT with the Wemos D1 Mini. I had used Fritzing to create a wiring diagram so it was easy to turn it into a PCB. After a bit of renaming files I was able to send the Gerbers to http://dirtypcbs.com/ and after about 10 days I had my first ever self-designed PCB in my hands. I soldered the TFT and the Wemos D1 Mini onto the board and everything fit nicely. How big was my disappointment when nothing would light up? I first was afraid that had designed a short between two pins which Fritzing hadn’t warned me about but the connectivity test revealed that I simply had forgotten one connection between the ESP8266 and the display. That could be solved quickly by adding a bodge wire as you can see on the photo:

Even before I had received the Fritzing PCB from dirtypcbs.com I had worked through a great KiCad video tutorial by Chris Garmel (Contextual Electronic). With the help of the tutorial I had a PCB design ready in no time. But I have to say that KiCad is not the most intuitive tool;-). I sent them off to https://oshpark.com/ and received 3 wonderful boards. Sadly I had made a mistake again. The Wemos pins were so far inside of the PCB that I only could attach the USB connector if the Wemos board was soldered with a gap to the connector board. This defied the goal to have a design as flat as possible:

I updated the KiCad file and I’m currently waiting for a new delivery.

OpenScad and the 3D printed enclosure

The last piece of the puzzle was to design an enclosure for the hardware. I like to use OpenScad for that since it lets you “program” the objects which is a good thing for a programmer;-).

First you’ll have to install or update the library and make sure that you have at least version 1.1.1 installed. Then you can simply go to

Files > Examples > ESP8266 Weather Station > PlaneSpotterDemo

And you’ll have a template for your own PlaneSpotter project. Read the original article for more detail.

Bethsalem presented a nice and simple enclosure for the PlaneSpotter over at RadarSpotting. Thank you for sharing!

BTW: this project is also mentioned in my new eBook: ESP8266 Weather Station: Getting Started Guide

Adapting the code

So how do you get those displays working with the WeatherStation or the PlaneSpotter? The OLED library makes that really easy: you just have to change two lines of code. The include for the SH1106 driver has to be included and then the instantiation. Find the line

#include <SSD1306Wire.h>

and replace it with

#include <SH1106.h>

The next step is to replace the instantiation of the driver:

SSD1306Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);

and replace it with:

SH1106  display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);

Done! Easy, wasn’t it? The OLED library supports other types of displays or communication protocols. You kind out more about them here:
https://github.com/squix78/esp8266-oled-ssd1306

Summary

With changing just a few lines you can get the WeatherStation and the PlaneSpotter working on the bigger 1.3″ screens. The cost a little bit more but depending on your casing they are worth the money. By the way: the pixel density (DPI) is actually worse with the 1.3″ displays since both types have the same resolution of 128×64 pixels. You can find the displays on AliExpress, eBay or on Banggood and support the Blog by following this link.

References

• https://github.com/squix78/esp8266-weather-station
• https://github.com/squix78/esp8266-oled-ssd1306
• 1.3″ OLED display on Banggood
• 0.96″ OLED display on Banggood
• WeatherStation Project Post
• PlaneSpotter Project Post