Hackaday Prize Entry: WiFi ePaper

[Frank Buss] designed an electronic version of a sticky note: a WiFi enabled, solar-powered ePaper, with magnets embedded in the casing. It’s based on the new ESP32, and the idea is that you can update it via your smart-phone or over the internet via a cloud app to show any message you want. Being an ePaper display, the power consumption is greatly reduced, at least if you are cautious using the ESP32.

The final version plans to poll a server once per hour to get a new image to display. Depending on the final size and battery constraints, our guess is that it could probably poll often. Of course, that depends on the available charging light, which is usually reduced when you are inside the house. The project also has 3 buttons to provide user input, which can be customized for a wide array of actions, as [Frank Buss] notes:

For example install it on the fridge of your grandma, who might not be very proficient in using modern internet connected devices. Then you can send her birthday wishes, or remind her of schedules. And the buttons could be used as a feedback channel, like confirming a date. Or when installed at a public place, it can act as a bulletin board. Or it can be used for a modern form of internet connected graffiti or other art projects. The possibilities are infinite.

This project immediately reminds us of the recent SHA2017 badge we covered some days ago, with a bigger display and solar panel or the e-ink wifi display project from last year.

The latest version is being tested with a black/white/red ePaper display, as we can see in the video:

32 thoughts on “Hackaday Prize Entry: WiFi ePaper

        1. The waveforms are normally stored in a flash memory on the display itself. Even if you get deeper access into the display’s controller you wouldn’t be able to change the waveform. Also I can assure you, it would not be fun. Waveforms are black magic even to the people tuning them at the display’s manufacturer.

  1. I thought of something like this, but ruggedized, as a replacement for parking signs, instead of half a dozen signs saying when you can and can’t park, no stopping, etc… you could have one e-ink sign that could be updated over the net, says “PARK” when you can and “NO STOPPING” when you can’t. Frank this might be an application you could look into.

    1. And then the sign suddenly changes unexpectedly while you stand there and you get fined. No good idea. And at least it has to say who is allowed to park and until what time.
      So that would be a quite useless application. A parking sign has legal implications and so it has to be stationary.

      1. Many parking signs have hour/day restrictions in many areas so changing would not be an issue. It doesn’t matter that it changes if the time it will change is indicated. If anything‚Äčit makes it clearer.

    2. Good idea. I guess because of the legal reasons to show the time and weekdays etc. in advance, there has to be a normal written sign, but in addition the ePaper can show the current state. But the wireless connection would need something like GSM, in areas without WiFi. The Pervasive displays I’m using have also a broken display status register which can be read, to check if the display still works and with the network connection it can send back status signals if it is working and get the current time from a time server to synchronize with a local clock.

    1. Exactly – RF power consumption. What about these LoRa/LoRaWAN (etc.) things? They seem to offer low intermittent power consumption at low/mid data rates with quite long range over RF, even in half-duplex – ideal for this application? The cited “HaD Prize” hackaday(dot)io project page (ugh) IMO seems to offer really nothing new.

      1. The bandwidth of LoRaWan would be too low to transfer images. But I think this Nordic nRF24L01 module might be a good idea. New is the solar cell. I don’t know a device which combines an ePaper with solar cell energy source and wireless connection, except some research projects, like this one, which looks cool:
        But you can’t buy it or build it yourself, which will be possible with my open source hardware project.

        1. That thing is counting on a lot of office light for operation. Office level is on average more than people use in their homes.
          NRF BW is better than LoRa, but has smaller range. In between you might like RFM69.

        2. @Frank Buss,
          You miss my (IMO) obvious point. We do NOT want to transfer the image information over wireless, we want to transfer what the image should display over wireless. For example: A display of the time in HH:MM:SS format sent asynchronously to the display, which has the “smarts” to display the time locally. A very low information is needed to simply transfer the six time of day digits to the display. The display and it’s local drivers update the display. To reduce battery drain at the display device, the time would be updated only (for example) once an hour, or even once per day. This low “reference” time update would require a reasonably stable (typically) crystal oscillator/module to drive it while still maintaining a reasonable “Human” usable level of sub-second accuracy as disciplined by the transmitting reference.

          1. Yes, this is possible. But my plan was to create all images on the server side. This would be easier to change and customize for different applications. But I’m going to send them compressed with zlib, so should be not too long, if it is not all graphics.

        3. I guess I should have been more explicit. I’m thinking low data rate that displays only the “change” in data since the last update. A simple example might be a clock display that updates once per second based on disciplining a local oscillator reference once per hour (for a high drift local reference) or even once a day (for a more stable local reference, e.g. TCXO). I guess what I’m interested in is Epaper displays that update once per second maximum connected over very low-rate (hence low power) RF connections over long ranges, so something like LoRa (more “open” architecture) or something like LPWAN (seems proprietary locked down). The Epaper display offers the advantage of near zero power consumption between updates, significant even if the low data rate updates happen once per second. Anyway, just thinking as I type (FWIW, which is often not much). Of-course the power consumption advantage would scale to displays that need infrequent updates. The point is dump power hungry RF link parts for low rate differential data. Regards, David

  2. I thought about doing something similar for the HAD prize, as it would fit right in my home automation project. But instead i would use cheap LCD touch screen and motion sensors to activate only when around. The touch is there so you can input data and interact with it.
    In the end i realized that recycling some older phones is much better in terms of time/money/appearance/features combination.

    1. I’m thinking about to modularize the design: the ePaper part is one module, with SPI interface, the microcontroller with the receiver is another module, which could be just an ESP32, or for lower power, one of those 10 mA Nordic chips (nRF24L01, 10 mA when sending), with an attached low power microcontroller, and the third module would be the solar cell power supply, which could be replaced by a battery or wall wart, if someone wants to use it in the dark or with higher poll frequency. The ePaper part could be replaced as well with smaller displays, or black/white only displays. Would need a bit more work on the firmware side, but should be possible, if the software modules are cleanly separated as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s