E-ink calendar and ToDo list

Il 16/12/2021 15:00, Giangi72 ha scritto:

thanks again Giangi

On Thu, 16 Dec 2021 15:00:37 +0100, Giangi72 snipped-for-privacy@invalid.net declaimed the following:

What voltage/amperage? That may have a limitation on what type of power source you can use.

UPS is "Uninterruptible Power Supply" -- a system that uses wall power most of the time, but can switch to battery backup when the wall power fails -- and can do this in a way that the attached device does not notice a power glitch. If it is a good one, when the wall power comes back up, it will recharge the battery. It may also (via monitoring software and GPIO or such) signal to the R-Pi if both wall power has been lost, AND the battery is running down -- so the R-Pi can perform a clean shutdown.

Obviously needs a power adapter for normal operation.

In contrast, a plain battery is just that... a battery that can run down. Linux systems do NOT like having the power pulled -- it can lose unwritten data (at best) requiring a journal rebuild of the file system on next start-up, up to corrupting the file system beyond recovery.

I'm tempted to suggest you develop on one device using a full desktop if you require any graphical editor/development environment, and then install the application on a device without a desktop system. Your application sounds like it could run using the smallest WiFi enabled R-Pi, but for development (especially if using C/C++ or other compiled language) might be better on a larger/more powerful R-Pi model.

Does a library already exist for the display, or do you have to create that too?

Actually, have you even done a search to see if this has been done already? The first page of a search on Google found two implementations (the first having way too many reviews/references on the page <G>)

Il 16/12/2021 17:21, Dennis Lee Bieber ha scritto:

It SHOULD be powered by raspberry, the power consume of display during NOT refresh should be 0 (it is an e-ink, the consume should be only during refresh). During refresh, I read on datasheet Typical operating current 6.6 mA

Perfect, but are there any battery hats (cheaper) that can tell to raspberry how many remaning charge they have? e.g.

If I'm able to understand how many charge remains I can send a visible warning: mail, notification, ...

This could be a good idea, or develop on a full OS sd card and the swap to a liter SD card. But in terms of power consume: what happens if I use a full desktop OS and the switch off the desktop environvent?

No, no everything already exists

I know this project, but it is in pyton, some informations are very useful but not the whole project

This is new to me. Also this is interesting, I think I'll steal the button to refresh idea but ...pyton again.

My problem is now mainly on power and power duration: which cheap hat use to power the raspberry. And then my later question to reduce the power consume

Many thanks Giangi

Maybe use an ESP32 instead of an RPi?

On Thu, 16 Dec 2021 17:58:30 +0100, Giangi72 snipped-for-privacy@invalid.net declaimed the following:

Taking your previous statement of 48mW and this 6.6mA, that yields a

Did you look at the documentation for that unit?

"""

1. Discharge time is based on current capacity of battery. 800mA could power Raspberry Pi 3B+ (The consumption of Pi 3B+ is larger than Pi 3B) for about 50min, power Pi Zero W for about 2~3h. (no-load state) """

An R-Pi Zero with NO LOAD, can manage less than three hours!

Most 14500 LiIon batteries run around 800mAH at 3.6V, and are sized like a AA battery.

Contrast with

Even this only states "Battery Life 7 Hours" for 3B 3B+ 4B sized units -- that's a 5000mAH battery, 6 times the capacity of a 14500.

It may not be that easy (especially with that nasty systemd start-up logic, in place of easily understood initd -- with initd you'd have to change the run level to a straight shell/console only mode [I'm not sure exactly how you specify the boot run-level -- my experience shows systems booting in operator console only, then shifting to a multiple console mode where function keys toggle between consoles, and finally shifting to X-window mode]).

X-window systems are client server, originally the concept was that a mainframe (or mini computer) ran user applications as "clients" and the remote graphical terminal ran the display server. The desktop is a client (that runs other graphical clients) sending display instructions to the server -- which in many computers these days is also running on the same system. You'd have to shut down both the server software, AND the client (desktop) system.

So what is wrong with Python -- it IS the language the R-PI foundation targeted for users <G>

For an hourly/half-hourly (or whatever rate you want to refresh) you don't need the speed from using a compiled language. And the easiest way to set up that timing would be to have the application merely do one refresh and exit -- and invoke it using a crontab entry specifying how often to run.

Not easily -- Some of the R-Pi is always powered (notice that if you do a "shutdown" the red power LED still is lit, and there is no button/input to trigger a clean shutdown (Beaglebone Black has a momentary contact power button which does a clean shutdown, and initiates a boot from the Off state

-- the only circuit drawing power when "off" might be the voltage/power regulator chip; it gets a signal from the power button to start the power-up sequence [this is implicit if one is plugging in a power supply]. I don't know if there is a way to tap into the power button to allow an external circuit to start boot-up.).

While you can easily program a shutdown (especially on an R-Pi where using "sudo" doesn't trigger a prompt for login password; Beaglebones are configured by default to need the password when invoking "sudo"); you'd need an external circuitry to drop the power to the R-Pi, and then reapply power to start a boot up.

You'd also have the problem of making sure the application isn't run until the WiFi link is active (to get calendar updates), and that the time-of-day is valid (without a battery-backed RTC for time-of-day, R-Pi and BBB both make use of a fake clock; that is, they periodically write the current time-of-day to a file, and initialize the software time-of-day clock on boot by reading the last saved time-of-day).

WiFi is likely the biggest power drain you have on an R-Pi.

That was my first thought. Although it depends how complicated the Google Calendar API is, and whether it's something the ESP software can handle. If it's basic JSON or something it'll probably be fine, but if it needs lots of stateful stuff (OAuth etc) that could be harder. Something like CalDav looks quite complicated.

But maybe you could run that part on a server/a RPi and have the ESP poll it with simpler requests?

I quite like the M5Stacks as neatly packaged ESP32 boards, with batteries and displays:

I don't know ESP32, what I see is that it is an arduino-like board. From what I saw I'm not sure it is able to support complex software as google calendar as mentioned in another message, but I'm not an expert Some addtional informations here

ESP32 is a wifi microcontroller. Being a microcontroller, low power is part of its DNA. Microcontrollers can enter a low power state until something happens - for example your device sleeping until the next update is required. You can be sure that the device is actually going to idle for that time.

An application class processor can't really do that, because there's too much other stuff going on. Maybe you could if you ran bare-metal, but not with a full Linux OS. Smartphones are a good example - you might get a week of idle, but once you have wifi and notifications and and... the battery life starts to drop.

If you're going to run an e-ink screen to save power, it would be unfortunate if the CPU wasted most of it.

On the other hand, e-readers are good examples of basic application-class cores (often comparable with the original Pi Zero) with e-ink, micro SD and wifi, but which aggressively turn those things off when not needed. An e-reader might be an interesting starting point for such a project - eg I have a Nook Simple Touch that runs Android (2.1 I think - despite being released in the Android 4 era, later Androids got more resource hungry so they went with an older version).

Theo

Il 16/12/2021 22:51, Dennis Lee Bieber ha scritto:

The display is directly connected to raspberry's GPIOs and use 3.3 V. But you are right, I checked the datasheet and I found different values than 48mW written on amazon.

There are 2 datasheets: V2 and V3 and I don't know the differences

V2 page 12:

V3 page 9:

Sigh, no, just now. It was under "View More" then "wiki ...", then manual

:-) you are absolutely right, simply it is not the language I usually use. I have a very low knowledge in pyton and I don't want to loose time learning it well. Additionally I would like to also implement a sort of ToDo list so I need to change the application.

This is absolutely correct and wonderful suggestion.

Thanks for your detailed explanations, I surrender: no battery. If I connect it to a power source all my problems are washed away. Many thanks Giangi

This is a good idea, I can create a mini service on my web site and the application should only read the result

Just to let you hate me better :-): what about power consumes? Is it possible to power it by battery and let it last for one week or more?

Thanks for your suggestions but the display is too small and I would like to put it in a beautiful frame. Thanks Giangi

putting it to deep sleep between updates, and boards with available LiPo battery management.

Could you please give me more informations about the battery management. Only links is enough Thanks Giangi

e.g.

I think your options are...

1. Use a Very Big battery. AFAIR, a PiZeroW draws around 250 mA on average, when idling, so something around 40 Ah at 5V. Say 20 Ah at 12V, after you've included the 12V->5V voltage converter. It'll be something like a car battery in size, and correspondingly expensive.

1. Add some extra circuitry to completely power off the RPi between refreshes (making sure you wait until the RPi has shut down cleanly before cutting the power). I think you'd have to home-brew this circuitry.

2. Use a different processor, e.g. Arduino, ESP32, RP2040. I don't have any personal experience, but I think these all support a low power deep- sleep mode from which you can wake on a timer.

The RP2040, aka PICO, may be what the OP wants. Its cheap, low power, can be made to sleep for a user-definable time, and is intended to be programmed in C/C++ or PICO-assembler. It has no OS - just a set of support code, including a C standard library. You link your application code with C library etc and the hardware-specific support libraries to get a binary blob. Load that into the PICO, connect power and it runs. All the documentation is on the PICO section of the RaspberryPi Foundation website so, if this sounds interesting, go and read the docs.

The process of developing code for it looks similar to the way you'd program a Parallax STAMP or a PICAXE chip except that both of those are programmed using their own flavours of compiled integer BASIC while the PICO can be programmed in C/C++.

The RP2040 and the RPi Pico don't have networking. You can connect it via a wire to a USB port, but that's not what the OP wants.

It seems the Arduino people have an 'Nano RP2040 Connect' which has a u-blox NINA WiFi module on it... that has an ESP32 inside.

So you might as well just use an ESP32 to begin with.

Theo

Il 17/12/2021 14:40, Andy Burns ha scritto:

Thanks Giangi

Il 17/12/2021 16:04, Theo ha scritto:

Thanks to everyone. I think the ESP32 + web service is the best solution. I have found this board with integrated battery management and socket

Many thanks Giangi

I presume you mean 700mAh or 1000mAh capacity, rather than 500mA charging current, just mean it'll take between 90 minutes and 2 hours to charge

whenever USB power is supplied, the board will charge the battery.