A comparison of some of the various types of low-power displays that can be used with hobby electronics projects for outdoors. Emphasis is on battery powered usage, but utility and functionality are important too.
I'm doing this because I was surprised recently by just how low-powered some LCD technologies can be, competing well with e-ink for power and sunlight visibility, and MUCH better in terms of refresh rate. I thought maybe I should do some research and comparisons.
The takeaway message:
Some transflective LCDs might compete well with e-ink in the power stakes and are a shipload easier and faster to use. The Sharp memory display in particular. There's a 1.5" and a 2.3" version available from Adafruit. There's supposed top be an 8 color version too, by Japan Display Inc (JDI) but I can't find a supplier. Digi-key have them on back order. Search JDI MIP Color display.
Things to ponder
Considerations that I can think of immediately are:
Power, refresh rates, color, ease of interfacing, availability of driver code, memory requirements, size, resolution, weight, cost, robustness, availability, water and dust proofness, visibility in bright daylight, visibility in torchlight.
The context is that I want a display for a handheld hiking GPS that is larger than the usual offering (i.e. about 4 inches on diagonal), doesn't eat batteries, is usable for maps, can be controlled by a microcontroller that also doesn't eat batteries, has driver support for Python or Circuitpython or Micropython or even the C/C++ of the Arduino world. Java maybe as in an Android phone? Not so much, but possibly.
So I need to think about anything that would have an impact on a small, rugged, long-lasting battery powered device, built and programmed by someone prepared to do the hard work of making the code work, but not willing to put up with extreme lack of information. (e.g. some epaper displays have very demanding and obscure interfacing requirements. I like FPGAs but don't want to have to use one for this project).
Some displays of the type that interest me come bare, some come with interface electronics, some come with their own controllers, some of which are even capable of being the main controller in the project. Those features could be useful, but they can also limit flexibility, i.e. lock me into a code regime I don't like or am unfamiliar with. Coding flexibility is a major consideration as the whole reason I am bothering with making my own GPS receiver is that I don't like what is available off the shelf, even considering phone-based apps. They don't handle map text labels in a way that suits me. So something like Micropython would be more attractive to me than the C/C++ eco-system of the Arduino because I can more easily code up database-oriented stuff in a Pythonesque environment. Java as per Android I am less familiar with, though it's no doubt very powerful. Maybe Python on Android might be interesting. I have been impressed with how far you can go with a smartphone if you turn off all the power-demanding stuff and manage what is really required carefully. I can imagine a phone (maybe a tablet would be better) with a less hungry display, radio stuff like cellular, wifi and bluetooth all off (or not there to begin with), and good 'go to sleep now' management of the GPS and display and user interface might work very well... Hmm. A rugged low-power Windows or Linux tablet that can be user-programmed in Python? There are a shipload of them actually, though not necessarily low-powered, not necessarily outdoors-proof. That could be fixed, however, if the price is right e.g. Low-Cost Tablet Runs on Three Watts of Power | MIT Technology Review. Another advantage of a phone is that sometimes I have to carry one as mandatory gear during running events for contactability reasons. However, generally I hike in areas where phones are out of network reach.
Something that can be turned off and on quickly and get a GPS fix quickly, display a map quickly, zoom, scroll, change map, see labels, there I am, there I want to go, that's how I get there, now go to sleep. See E-ink GPS device project (terrycornall.wixsite.com) for more meanderings on the subject.
WARNING:
A major hassle with the e-ink displays is knowing what driver chip they use and knowing if it is one of the supported ones in Circuitpython or Arduino or even Python. The sellers pretty much always pass on the example code from the manufacturer/distributer but it might be depending on raspi or particular Arduino libs and that might not suit you. If you want to use it, check out what display driver chips Circuitpython displayio supports and then try to make sure that the display has one of those. Also, not sure about the Adafruit eink breakout friend (which is an adapter for eink displays and provides the SPI and 32k sram) Is it supported by circuitpython displayio or just the Arduino GFX? I think it very much depends on which display driver chip is on the actual display. Another thing is that even if supported by someone like Adafruit, a library may or may not implement all that the display is capable of. I've come across a display that is actually capable of 8 distinct shades of black, grey, pink, red plus white but the code examples threated them like 1 bit black/white, 1 bit red or not and that was it. At the same time, the example code that the supplier gives may not show you how to get all the features of the display either. Be prepared to have to hack the code!
E-ink driver chips (there are more not mentioned)
Driver chip | Display size and color. There may certainly be others | color | Partial refresh? (No ctricolor supports partial refresh, only mono) | displayio supported | comment |
|---|---|---|---|---|---|
IL0393 | I think up to 2.13 tricolor and 2.9 BW adafruit display plus breakout | yes and no depending | no if tricolor | yes | |
IL0398 | I think this is used in Good Displays 4.2" and maybe Waveshare sell on. I think this would work with Adafruit epaper friend breakout | yes, tricolor red or yellow, black and white. Not sure about grayshades | no | yes | my favorite if i can find a seller for the display panel. I can use Adafruit e-ink 'friend' as the interface but they don't sell the actual display above 2.3" |
IL0376f | The 1.5" tricolor I have. NOT supported by displayio because 2 bit shades of grey in the black. Had to hack adafruit EPD code to make it work. | yes, tri plus grayshades eventually, even pinks | no | NO | too small though good 200x200 res |
SSD1608 | 1.54" Monochrome by Adafruit | no | maybe | yes | too small |
SSD1675 | 2.13" mono by adafruit | no | maybe | yes | |
SSD1681 | 1.54" tricolor Adafruit | tri | no | | too small |
SSD1680 | 2.13" tricolor Adafruit | tri | no | | |
IL91874 | 2.7" Tricolor Adafruit | tri | no | yes | |
SSD1619 | 4.2" Tricolor element-14 | | | NO | element-14 sell a 4.2" Midas one RWB |
Anyway, here's what I have so far re displays. I give some columns a weight according to the importance assign to it. e.g. 10 for power has a bigger impact than 5 for refresh rate does because for this application refresh rate concerns me less that power. (If I needed video, that would be different)
model/ manu/ supplier | comment | color 10 | type/tech | interface 5 | power 10 | refresh rate or period 5 | visibility in sun 10 | code/support/doco 10 | size/res 10 | cost AUD /avail 10 |
|---|---|---|---|---|---|---|---|---|---|---|
Duinotech 1.5" tricolor il0376F chip Jaycar | slow, small good look, good res, low power | bl/wh/red 2 shades grey 7 | e-ink | SPI 5 | uA when off but mA-ish when active 8 | 5s 1 | Very good 10 | Arduino, Python, CircuitPy modded IL0393 5 | 1.5" 200x200 light 5 | $50, local shop 8 |
Sharp memory LCD mono 2.7" Adafruit breakout Digikey? | Fast but mono. Low power. | mono, no shades 3 | transflective lcd | SPI 5 | very low. uA-ish even when active 10 | video fast 5 | very good 10 | Arduino, Circitpython displayio 10 | 2.7" 400x240 8 | $60 AUD Online Adafruit 7 |
Sharp/JDI memory color 2.7" Digikey | Great but not available! | 8 colors 10 | transflective lcd | SPI no breakout 3 | very low. uA-ish even when active 10 | fast 5 | very good 10 | Arduina and hope Circuitpython 4 | 400x240 8 | $100 AUD-ish. Digikey list them but none available 3 |
Waveshare 4.2" tricolor epaper | Good size, lousy refresh rate | r/b/w maybe gray 7 | e-ink | SPI Adafruit ram breakout available 5 | | 15s 0 | very good 10 | Yes, if using IL0398 chip 10 | 100x78mm 4.2" 400x300 10 | Good Display? Waveshare? |
waveshare 5.8" display | too big for adafruit friend (max 4.2" 2 bit) | r/b/w 2 shades grey 7 | e-ink | SPI dunno about drivers | uA when off but mA-ish when active 8 | 20s 0 | | | 648x480 5.8" | |
I can imagine a combination of tech. Say use a tricolor epaper for the map that doesn't refresh quickly and a sharp memory for text or map overviews/zooming/panning that can be redrawn and scrolled thru quickly but doesn't have color or shades. Hmm. Might work...
Something to think about is, could a 2.7" 400x240 Sharp Memory display work for me as the main map even though it has no color and only 1 bit? (I.e no shades) Size is ok-ish. Res is ok-ish, refresh rate is fantastic, low power is fantastic, Circuitpython displayio code support is fantastic-ish (esp given no palettes to get my head around, being 1 bit) Cost is OK, availability is OK.
Other things to consider are that the larger the display and the more bits per pixel, the larger the memory required. Some come with memory built-in (the Adafruit 'friend breakout' has SPI sram for up to 4.2" 2 bit epaper display with 24pin connector and other Adafruit displays have SPI sram built in) Also, takes longer to draw the map for a larger display, just because more bits. (depends on zoom level and if urban) Something like the 640x400 7 color display referenced below might require too much memory for an ItsyBitsy (my current MCU board)
Now that I think about displayio, one of the reasons I couldn't use it for the IL0376f chip based e-ink I have is that it didn't appear to support tricolor AND multibit black (i.e. shades of grey) I need to check on that.
Another idea is to use e-ink as a fairly static map and put a transparent OLED on top of it for the more active layer.