Weather calendar: Feather Huzzah

The Adafruit Feather range is a very nice set of development boards from the NYC company. They are a good form factor (approx. 5x2cm) and stack using appropriate headers. I particularly like the Feather Huzzah and initially went for these in a big way as they fulfil a number of criteria:

  • they can run MicroPython,
  • the processor boards are wifi-enabled,
  • and some added benefits like lots of additional addons (RTC, OLED, 7-segment displays) plus great tutorials on their web site.

Initial and ongoing experience proved that they were very easy to work with, and they worked as expected. However, the ESP8266 wifi-enabled board does not go into a really low-power mode, consuming about ~70mA normally and the deepsleep mode requires manual intervention. That will most likely mean that I can’t use it longer term for the driver on the display, but it will prove useful as a learning exercise on the way down the power ladder.

Using Arduino IDE

I initially started by loading MicroPython onto the board using the esptool flasher, but ran into an issue that I could not seem to find the correct pinout for the Tx/Rx. Using the ones marked on the board interferes with the USB – serial controller and you see spurious things on the link. So I backed off and re-flashed it with the Arduino IDE and a neat little bit of example clock code which works well, proving that the Tx pin works at least, and the battery powered Feather Huzzah can indeed drive the e-ink display.



However, using micropython proves more difficult, as I cannot seem to find the correct Tx pin for UART 1.  Having flashed the 1.8.4 code level onto it using the instructions I initially tested UART(0), but as this is connected to the USB-serial chip you get all the USB traffic on those pins and so I looked to the write-only UART(1). I could not find which physical pin this was attached to even after trying all the pins one by one.

Weather calendar, part deux!

Whilst some of my systems have worked, some have not. First up, I have no problem in getting a display on the e-ink displays which I have (a Pervasive Displays, Waveshare) using their demo programs and using either a USB connection or an Arduino.


Simplest is the Arduino code and communicating to this via a USB connection, using the Arduino GUI on a Linux machine. This works!


Second easiest is talking to the display directly using a UART connection from a PC, such as the CP2102 chip and driving the display via the USB cable:

  • Using a Python library works well.
  • Using the C code supplied by Waveshare themselves as a library – not tried but I assume it would work like the Python code.

Adafruit Feather Huzzah

  • running MicroPython did not work and gave a memory error
  • running the NodeMCU?

Eventually the memory error helped realised that I may have been approaching it like it was a large system, is there a way I can keep the memory requirements much lower and get the display working? The Huzzah is a good system, although it is a little power-hungry for my liking.


Using a WiPy running MicroPython also did not work. I was a little disappointed with this as I think the system is a good one.


I’ve one of the little systems and have played with it, but as the programming was not in Python not taken it further. It could be a possibility but I want to push the MicroPython boards to see if one can handle what I want to accomplish.


I have one of the v1.0 Pyboards from the Kickstarter campaign, and got this working driving the Pervasive Displays display. Mostly because someone else wrote the code and gave a great walkthrough for the wiring and soldering needed.


I’ve ordered a ‘raw’ ESP8266 as one Youtube video shows that working okay as an endpoint, with the Python code running on a backend laptop. I can get one of my small SBCs to do the driving. More on this later…


Logic voltages have changed over the years since the Arduino first came out, and modern chips are largely based around the 3.3V compared with the 5V of the early Arduino systems. Of course this varies and some are 1.8V and so on. I wondered if I were driving the display with the wrong voltage. The Waveshare site claims that the display can handle 3.3-5V okay, although I note that they say you feed it 5V when using their demo program to talk to a PC.

I tried to use a level shifting chip – the TXB0108 – which will either up-shift or down-shift the logic levels on the control lines (and not the voltage! – that I had to realise, so you still must supply 5V somehow). Whilst the results were tantalising, they were inconsistent when only supplying 3.3V to the display as often the updates would not come through and the screen looked ‘broken’.  Feeding 5V worked perfectly. Learning about level-shifting was fun, and may come in handy for later projects, but I’ve assumed that I need a 5v feed to the Waveshare display with 3.3V logic levels on the TX/RX and

Weather calendar

I have been thinking and tinkering around creating a home weather calendar. The background is that we have a variety of hand-held devices such as mobile phones, PCs and tablets as well as a reasonable in-house network, both wired and wireless.  I’ve also a number of local sensors such as weather stations and temperature sensors, and some level of automation with programmable lighting. I’d like to create a weather calendar to display the local weather forecast, plus upcoming calendar entries from our joint shared Google calendars.

Some simple requirements:

  1. High contrast display that can run from battery – LCD or e-ink.
  2. Low-powered system that can run a long time from a battery.
  3. Wifi connected so that I can work on it remotely.
  4. Preferably coded in Python as I am happiest working in that language.
  5. Preferably all local to the display.

To do this I am going to assemble some components:

  • e-ink displays
  • Embedded systems
  • Single-board computers

… of which I have a couple of e-ink displays (Pervasive Displays and Waveshare models), a handful of embedded systems (Pyboard, Photon, Feather Huzzah, WiPy) and any number of SBCs (Raspberry Pi, Beaglebone Black, Odroid, Arduino).

I rejected powering this off a SBC like the Raspberry Pi as the power requirements for those are bad as even the Pi Zero will only run for less than a day with AA batteries! The vast differences between those chips that run a full Linux stack versus the embedded world that have negligible power draw on sleep mode. In addition a lot of those embedded systems are wifi-connected, and wifi itself is power hungry and needs careful sleep modes.