Close
0%
0%

Newt: Always On, Low Power Digital Assistant

An always-on digital assistant that fits on a desk/nightstand/mirror/wall/fridge. Weather, alarm, timer, calendar, habit tracker, to-do list

Similar projects worth following
I'm tracking the build of a low power hackable display. The goal is to build an always on display that can be powered for 1 year (with typical use) before replacing batteries or recharging. The display should be able to quickly provide relevant information (weather, timer, alarm, calendar, todo lists, habit tracker, etc). Think of it as a mix of a between a Dak Board, an Adafruit Magtag, an Alexa-enabled display. I've been toying around with the idea for the last 6 months, and decided to post my progress - from ideation to (fingers crossed) manufacture.

10/1/2021 Update:

The Newt was selected for Crowd Supply! So soon, you'll be able to have your very own! Check out the Pre-Launch page for more details! 

---------------------------------------------------------------

9/8/2021 Update:

Last revision of the PCB works as expected! I uploaded my sample code and made a video overview of what the Newt can do!

-----------------------------------------------------------------

Running Summary below:

(as of 3/19/2021)

I'm in the process of building a low-power, always on smart display. I wanted something that I could easily affix to a wall or mirror, or put on a nightstand (which means it has to be battery powered).

An "always on" display was important because I wanted to get key information (weather, time, remaining time on a timer, upcoming meetings) at a glance, with minimal "clicks".

Finally, I wanted to make sure my project was (a) manufacturable (b) easily hackable and (c) open-source.

I'm just finishing the breadboarding phase, and am moving to a "looks like" and "acts like" prototype: I've got 3 boards from OshPark waiting for assembly, and I've got a GlowForge and Prusa Printer waiting for designs.

So far, the major components in my BOM include:

  • ESP32s2 W-Rover (Espressif)
  • 2.7 in Memory Display (Sharp)
  • RV-3028 Real Time Clock (Micro Crystal)
  • AP3602AKTR Charge Pump (Diodes Inc) - for the Memory Display
  • LDL212PV33R Linear Voltage Regulator (STMicroelectrinics)
  • CMI-1295IC-0385T Surface Mount Buzzer (CUI)

I've yet to test the actual deep sleep current - the goal is to get under 50uA on deep sleep. 

I'm using Arduino code for development. So far, I've coded the following functions:

  • Alarm
  • Timer
  • Weather (Current, Daily, Hourly)
  • Habit Tracker/Calendar

Here's a quick video of the alarm functionality:

----------

Update as of 7/23

I've made quite a bit of progress over the last month, and finally have an assembled and working PCB. There are still problems.... but it's close to being ready for "primetime"!

  • Why an external RTC is needed with the Newt

    Darian Johnson10/02/2021 at 14:36 0 comments

    As I mentioned in an earlier post, the Newt uses an external Real Time Clock (RTC), specifically, the Mirco Crystal RV-3028. Some people may wonder why an external RTC is needed for an ESP32s2, since those microcontrollers come with an internal RTC. Well, there are a few reasons:

    Need to add a crystal for accuracy

    The internal RTC looses seconds when a crystal is not used. I could have added a crystal to the PCB, but that would have (a) reduced the number of available pins and (b) made use with Arduino or Circuit Python slightly more complex (I wanted to create a device that was "accessible" to a novice developer).

    The internal RTC can operate without a crystal, but it looses seconds. This loss is exacerbated when the device goes into deep sleep. I ran a test with my ESP32s2, comparing the internal RTC with the external RTC. The device sleeps for 60 seconds, prints the time from the internal and external RTC, then returns to sleep.

    Comparison at start: 22:46:31.453 -> Sunday, March 14 2021 22:46:31

    Comparison 23 hours later: 21:18:00.583 -> Monday, March 15 2021 21:47:18

    As you can see, we lose 13 seconds in a day... that's a minute in week, and a 4-5 minutes over a month.

    Of course, you can always sync the time - but that takes a wifi call. The Newt is built for low power, so we want to minimize any unnecessary wifi calls.

    Timezone craziness

    The other reason an external RTC - and specifically the RV-3028 - is useful in this build is around timezone management - especially when it comes to daylight saving time changes. The RV-3028 is able to store the UNIX time separate from Local time. For example:

    The Unix time at this moment is 1633184251 (this represents the number of seconds since Jan 1, 1970 in UTC). The local time equivalent (for Dallas, TX) is Saturday Oct, 02 2021 09:17:31 GMT-0500 (Central Daylight Time).

    Unfortunately, in 2 weeks, Dallas will be in Central Standard Time, and the offset from UTC will be 6 hours, not 5 hours. So if I hardcode an offset in my code, then my time will be off.

    However, using the UNIX time with the ESP32 "setenv" command allows me to adjust the time based on the specific month/day/time. ESP32 use the POSIX format to define the timezone. Here is the format for Dallas, TX (America/Chicago): CST6CDT,M3.2.0,M11.1.0.

    Here's the breakdown of the format (from IBM developer website):

    • CST6CDT is the name of the time zone
    • CST is the abbreviation used when DST is off
    • 6 hours is the time difference from GMT
    • CDT is the abbreviation used when DST is on
    • ,M3 is the third month
    • .2 is the second occurrence of the day in the month
    • .0 is Sunday
    • /2:00:00 is the time
    • ,M11 is the eleventh month
    • .1 is the first occurrence of the day in the month
    • .0 is Sunday
    • /2:00:00 is the time

    So, in short, I can use the UNIX time from the RV-3028, calculate the local time with the ESP32 "setenv" command, then save that local time in the Local Time register of the RV-3028 - all without making a series of wifi calls!

  • Introducing the Newt!!!

    Darian Johnson09/05/2021 at 21:48 0 comments

    So, I've been playing around with a lot of names for the smart display. I first called it the SmartSlate; then the SlateMate. I even toyed around with calling it the Tabula Rasa (latin for "clean slate" and more importantly, the name of one of my favorite Justice League episodes).

    None of those names resonated with me. I wanted something simple, that was inspired by the device, but not a "on the nose" name. I started thinking through the characteristics of the device, and decided to focus on one of my expected use cases: sticking the display on a wall, mirror, fridge, dry erase, etc.

    From there, newt just kinda stuck. I liked it for a few reasons:

    • the word "newt" is short and sweet
    • newts are cute
    • "Newt" is also subtle nod to the Apple Newton, one of the first PDAs.

  • Choosing a Real Time Clock (RV-3028)

    Darian Johnson08/01/2021 at 13:46 0 comments

    My smart display will have a number of time-based functions, so I knew that time management needed to be a key part of the solution. The best way for me to manage time, with minimal calls/updates from an NTP server, was to integrate a Real Time Clock (RTC).

    RTCs are integrated circuits that - very simply - keep time. Hackaday did a write up last year on choosing the right RTC (https://hackaday.com/2020/09/30/choosing-the-right-rtc-for-your-project/). I used this guide as a starting point for my research.

    I had four requirements for the RTC:

    • Must operate at low power
    • Must be able to set and trigger alarms
    • Must be able to set and trigger timers
    • Must have a clock out feature (needed for the Sharp Memory Display)

    I pretty quickly zeroed in on MicroCrystal's RV-3028 and RV-8803. Both operate at low power, are extremely accurate, and come in small packages.

    I was able to get samples of both from MicroCyrstal (huzzah for samples!!) and I got to work.

    After a week of testing, I landed on the RV-3028, for the following reasons.

    1. Insanely low power - 45nA!!!
    2. Ability to set a periodic timer (interrupt every minute or second), countdown timer (e.g. countdown from 5 minutes), and alarms - AT THE SAME TIME
    3. Separate clock out and interrupt pins
    4. Separate Unix and "Local" time tracking


    The last two points are the post important, so I'll go into more detail.

    Clock Out and Interrupt Pins

    The Sharp Memory display requires an "refresh" command every second or so. This can be done with hardware or software - and a HW refresh command was going be better from a battery perspective. I toyed with using the ESP32s ultra low processor as a refresh "engine", but decided against it because (a) I would lose a valuable GPIO and (b) programming the ULP is difficult to do with Arduino or MicroPython. 

    So, with the RV-3028, I can use one pin to control my alarm/timer/countdown interrupts (each with separate registers, so that I can have all three running at the same time) and I can have a separate line for the a 1HZ pulse on the clockout pin. This ultimately means that my microcontroller can spend more time in deep sleep.

    Separate UNIX and and "Local" time tracking

    Unix time, or epoch time, is typically calculated as the number of seconds (or milli/micro seconds) that have passed since January 1, 1970 (UTC). The RTC allows you to store UNIX time (separate from local time). This allows me to have a "time" value that can be used for local representation (stored in a separate register). In short, I can store a UTC time and a local time. This is extremely important when it comes to Daylight Savings Time; twice a year (usually), at 2AM (usually), the local time needs "spring forward" or "fall back".

    In the past, I've hardcoded very specific daylight savings offset rules for my projects. This works for an individual maker, but doesn't work for a potential commercial product (that could sit in any number of time zones with arbitrary rules). Fortunately, having the epoch, and using the  "setenv" functionality in the ESP32, gives me the ability to dynamically change the local time (based on DST or timezone) without complex logic or repeated calls to an NTP server.

    Running BOM (@250 units)

    ComponentFunctionDeep Sleep (uA)Costs (USD)
    Sharp Memory Display (LS027B7DH01A)Display10-35$20.00
    ESP32-S2 WROVERuC20$2.40
    RV-3028RTC0.045$1.75
    TOTAL~30-5524.15

  • Next iteration of the Display with Touch Pads

    Darian Johnson07/24/2021 at 01:10 0 comments

    I got a great suggestion about switching the physical buttons to touchpad, and finally got the PCBs a few weeks ago... they look beautiful. Now to assemble them!

  • Habit Calendar

    Darian Johnson06/08/2021 at 04:37 0 comments

    Slow but steady progress... wrote some code for a Habit Calendar. I'm still not happy with the number of clicks needed to navigate. I might need to consider capacitive touch (for a better user experience).

  • Choosing a Microcontroller

    Darian Johnson05/19/2021 at 02:38 0 comments

    Using an ESP device was a no-brainer for my design, as the ESP family of microcontrollers come with wifi (without a secondary chip). 

    An ESP8266 wasn't an option, given the lack of pins and the security gaps. So, that left me with the ESP32 and the ESP32-S2. Both have plenty of IO and operate at low power. Cost is roughly the same as well.

    I ultimately decided on the ESP32-S2 for a few reasons:

    1. Native USB - which means no USB to Serial chip is needed for programing
    2. Ability to run Circuit Python (checking another box in the "hacker friendly" category)
    3. Lower power consumption during wake and wifi usage
    4. Slightly lower cost

    Running BOM (@250 units)

    ComponentFunctionDeep Sleep (uA)Costs (USD)
    Sharp Memory Display (LS027B7DH01A)Display10-35$20.00
    ESP32-S2 WROVERuC20$2.40
    TOTAL30-5522.40

  • Trade offs to get to low power: The Display

    Darian Johnson03/20/2021 at 05:19 0 comments

    The largest power draws on an always on smart display are:

    1. the display
    2. the microcontroller 
    3. the internet connection method

    This Log entry focuses on the display

    Adafruit's breakout for the Sharp 2.7 in Memory Display


    Given the desire for low power, TFT displays were out. The backlights would drain any battery in a matter of days.

    OLED displays are better (from a power consumption perspective), but they still require 20 mA of power.... fine for a periodic display, but no good for what I wanted.

    After looking around, there were really only two viable options

    1. a eINK display
    2. a Sharp Memory Display

    E-Ink is all the rage these days. They can retain their screen image without any power (ultimate low power) and they aren't too expensive... but, there's one big drawback: the process of updating the screen - which can take 1-3 seconds and is somewhat jarring (here's a great video on the process). The sequence wouldn't allow a user to quickly toggle between screens, so eInk was a no-go.

    That left the Sharp Memory Display as my only option. Sharp Displays are low power (the 2.7in version only requires 10-35 uA). They look as sharp as an OLED (without the current burden). They are relatively easy to use (SPI).

    The drawback: they are  just plain ol' expensive... $20/each to purchase 250 (per Digikey).

    Running BOM (@250 units)

    ComponentFunctionDeep Sleep (uA)Costs (USD)
    Sharp Memory Display (LS027B7DH01A)Display10-35$20.00

  • Initial List of Required Functions

    Darian Johnson03/20/2021 at 01:12 0 comments

    In software systems design, we typically split requirements into two camps:

    • Functional requirements - what a system should do ("display the current weather")
    • Non-Functional requirements - how a system should perform ("data should be encrypted on transmit")

    There is sometimes debate on what is Functional vs Non-Functional.... so I didn't bother categorizing my requirements. That being said, I want to be sure that my requirements were true requirements and not design decisions. For example, I need to be able to connect to the internet to get periodic weather updates, but that doesn't automatically mean that Wifi is a requirement.

    Anyway, here's my initial list of requirements

    Must Haves Functions

    • Alarm
    • Timer
    • Calendar
    • Habit Tracker
    • Weather
    • To Do List


    Nice to Have Functions:

    • Heath tracking
    • To Do List
    • Shopping List
    • News

    Stretch Goals

    • Alexa integration
    • Multi-user
    • Music control

    In addition, there were a few non functional requirements that I captured:

    • Easily hackable
    • Open Source
    • Low Power (go 9-12 months between replacement or recharge of batteries)

  • Why Build a Smart Display When There Are So Many...

    Darian Johnson03/20/2021 at 00:48 0 comments

    I'll admit it: I'm lazy. I appreciate hard work... but I don't want to work hard when I don't have to (which is why I don't like eating crawfish... but that's another story). 

    More simply put, I want information as quickly as possible with as little effort as possible. Let me explain:

    When I wake-up, I usually like to understand the weather before I get dressed. To find the end of day temperature, I have to

    1. Find my phone
    2. Unlock it (either with facial recognition or a passcode)
    3. Find the "weather" button in a sea of icons
    4. Click the button
    5. Scroll to find the weather at the end of the day

    That's 15 seconds of work for 2 seconds of reading.

    And through I love my Alexa devices (I have 10+ on my home), they aren't much better; it's a 20 second exchange to ask for the weather and have Alexa respond.

    What I wanted was a device, centrally located, where I could, with a simple click, get key information (weather, calendar, etc.). 

    So, I started looking into existing devices and found that nothing fit exactly what I was looking for.

    The DakBoard is a great device, but it's not battery powered... which would restrict it's locations (I couldn't attach it to a bathroom mirror or a fridge door).

    Adafruit's MagTag is another great alternative... and was the inspiration for my own design. My only issue with MagTag was the refresh cycle for the eInk display... which would limit the ability to quickly toggle between screens.

    Finally, I looked at standard displays on Amazon... and I felt that they weren't as extensible as I wanted. 

    So, that lead me to building my own... but before I could start, I needed to understand what the display would do.

  • Yes, it's another ESP32 Display....

    Darian Johnson03/20/2021 at 00:19 0 comments

    "Not another display!!!!"

    Wait - just hear me out.

    I've been a practicing "maker" for the last 5 years. I don't make a lot of projects - however, the ones I make are pretty feature-rich. I've built some cool things like an automated cat feedera smart candle, and a compost making assistant.

    However, the items that always get the most comments/likes/views are my displays. I made an Alexa-enabled smart display in 2015. Last year (2020), I made a Star Trek display. So, when I decided to make something that could possibly be manufactured and sold, a display made sense.

    I'm not a hardware manufacturer, but I've worked as a technology consultant for the last 20+ years, so I decided to tackle this project like I would handle a large software implementation, which means:

    • Understand the market (for price comparison, market gaps, and saturation)
    • Start first with functional and non-functional requirements
    • K.I.S.S. Design ("Keep It Simple, Stupid")
    • Understand your buyer to keep manufacture price in line with expectations 
    • Fail fast (learn as much as you can, with as little cost as possible, as fast as you can)
    • Get real feedback from potential customers/end-users
    • And finally - tell people about it ("If you built it, they will come" only works in the movies).

    So, we'll see how things go!


View all 10 project logs

Enjoy this project?

Share

Discussions

Max.K wrote 09/12/2021 at 14:38 point

Really nice project! It shows that a lot of effort went into the UI and features. Have you though different input methods? Those buttons take up a lot of space :D

If you want to measure the standby current I can recommend using a regular multimeter and a diode like this: https://electronics.stackexchange.com/questions/340330/measure-wide-range-of-current-800-%c2%b5a-1-5-a/340353#340353

  Are you sure? yes | no

Darian Johnson wrote 09/12/2021 at 16:59 point

I actually ended up buying a Current Ranger to set the current during deep sleep. Works well... though I will I could write the readings to a file. I'm entering deep sleep with a wake up on a capacitive touch... this means that the sleep current cycles as a "reading" is made to determine if a touch even exists. Rough test range deep sleep from 30uA to 300uA. 

https://lowpowerlab.com/guide/currentranger/

  Are you sure? yes | no

Darian Johnson wrote 09/12/2021 at 17:03 point

And I thought about adding a touch screen, or smaller buttons on the front, but ultimately landed on the cap touch pads (partially because I hadn't seen cap touch as an input done on other boards).

I could probably remove the large buttons on the right and make the wake button on the left... that would reduce the board size by about 20%.... though I'm pretty happy with the size; it doesn't feel too big - especially once I put it on a wall/mirror/fridge

  Are you sure? yes | no

Dan Maloney wrote 03/22/2021 at 18:23 point

Funny, I was in Kohl's last night with my wife looking at all the LCD price tags they have on the shelves and thinking that they'd probably be handy for just this sort of thing.

  Are you sure? yes | no

marazm wrote 03/21/2021 at 16:00 point

calculator

lora communicator

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates