Fidonet Portal
Hello everyone,
I'm a new user in this newsgroup.
I would like to create a personal google calendar and ToDo list using a,
e-ink display without power adapter: a frame with display in it on the wall.
The display has a power consume of 48mW during refresh and I would like
to refresh it once at hour (maybe 30 minutes), obviously it will be
connected by wi-fi.
Once a week/month/year I can take it from the wall, charge it an the put
it again on the wall.
I have some questions to people more expert than me:
1) It have to be without power adapter so I need a "battery", which is
the cheapest way to feed the raspberry? I googled for it but I see
battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
the differences between them.
2) I would like to use Visual Studio Code to develop the software side.
For the power consumes is it better to install a full OS (Raspberry Pi
OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in
different ways?
These are the first dubts I have.
If you have more informations or dubts please don't be shy

Many thanks in advance
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 16/12/2021 15:00, Giangi72 ha scritto:
> 1) It have to be without power adapter so I need a "battery", which is
> the cheapest way to feed the raspberry? I googled for it but I see
> battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
> the differences between them.
> 2) I would like to use Visual Studio Code to develop the software side.
> For the power consumes is it better to install a full OS (Raspberry Pi
> OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in
> different ways?
3) Is there any way to suspend the raspberry after refresh and restart
it again before next refresh to save power?
thanks again
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
To: All
Date: Thu, 16.12.21 11:21
Re: E-ink calendar and ToDo list
On Thu, 16 Dec 2021 15:00:37 +0100, Giangi72 <invalid@invalid.net>
declaimed the following:
>The display has a power consume of 48mW during refresh and I would like
>to refresh it once at hour (maybe 30 minutes), obviously it will be
>connected by wi-fi.
What voltage/amperage? That may have a limitation on what type of power
source you can use.
>Once a week/month/year I can take it from the wall, charge it an the put
>it again on the wall.
>
>I have some questions to people more expert than me:
>1) It have to be without power adapter so I need a "battery", which is
>the cheapest way to feed the raspberry? I googled for it but I see
>battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
>the differences between them.
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.
>2) I would like to use Visual Studio Code to develop the software side.
>For the power consumes is it better to install a full OS (Raspberry Pi
>OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in
>different ways?
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>)
https://www.tomshardware.com/news/raspberry-pi-e-ink-google-candar
https://github.com/speedyg0nz/MagInkCal
https://hackaday.com/2019/02/11/get-organized-with-this-raspberry-pi-e-ink-calen
dar/
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 16/12/2021 17:21, Dennis Lee Bieber ha scritto:
> On Thu, 16 Dec 2021 15:00:37 +0100, Giangi72 <invalid@invalid.net>
> declaimed the following:
>
>> The display has a power consume of 48mW during refresh and I would like
>> to refresh it once at hour (maybe 30 minutes), obviously it will be
>> connected by wi-fi.
>
> What voltage/amperage? That may have a limitation on what type of power
> source you can use.
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
>> Once a week/month/year I can take it from the wall, charge it an the put
>> it again on the wall.
>>
>> I have some questions to people more expert than me:
>> 1) It have to be without power adapter so I need a "battery", which is
>> the cheapest way to feed the raspberry? I googled for it but I see
>> battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
>> the differences between them.
>
> 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.
Perfect, but are there any battery hats (cheaper) that can tell to
raspberry how many remaning charge they have?
e.g.
https://thepihut.com/products/li-ion-battery-hat-for-raspberry-pi
but I found the same, in the past, a 3-4€
If I'm able to understand how many charge remains I can send a visible
warning: mail, notification, ...
>> 2) I would like to use Visual Studio Code to develop the software side.
>> For the power consumes is it better to install a full OS (Raspberry Pi
>> OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in
>> different ways?
>
> 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.
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?
> Does a library already exist for the display, or do you have to create
> that too?
No, no everything already exists
https://www.waveshare.com/wiki/7.5inch_e-Paper_HAT_(B)
> 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>)
>
> https://www.tomshardware.com/news/raspberry-pi-e-ink-google-candar
> https://github.com/speedyg0nz/MagInkCal
I know this project, but it is in pyton, some informations are very
useful but not the whole project
>
https://hackaday.com/2019/02/11/get-organized-with-this-raspberry-pi-e-ink-calen
dar/
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
3) Is there any way to suspend the raspberry after refresh and restart
it again before next refresh to save power?
Many thanks
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Giangi72 wrote:
> 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
>
> 3) Is there any way to suspend the raspberry after refresh and restart it
again
> before next refresh to save power?
Maybe use an ESP32 instead of an RPi?
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
To: All
Date: Thu, 16.12.21 16:51
Re: E-ink calendar and ToDo list
On Thu, 16 Dec 2021 17:58:30 +0100, Giangi72 <invalid@invalid.net>
declaimed the following:
>During refresh, I read on datasheet
>Typical operating current 6.6 mA
>
Taking your previous statement of 48mW and this 6.6mA, that yields a
7.3V power source (W = V * A). Raspberry-Pi's provide 5V and 3.3V (and
GPIOs can be killed if fed more than 3.3V; the 5V is from the input power
supply and primarily provided to USB ports)
>Perfect, but are there any battery hats (cheaper) that can tell to
>raspberry how many remaning charge they have?
>e.g.
>https://thepihut.com/products/li-ion-battery-hat-for-raspberry-pi
>but I found the same, in the past, a 3-4€
>
Did you look at the documentation for that unit?
"""
7. 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
https://www.amazon.com/Pisugar2-Portable-Platform-Raspberry-Accessories/dp/B08D8
PPCKN/ref=sr_1_2?keywords=raspberry+pi+battery+pack&qid=1639688505&sr=8-2
"""
It can also shut down safely when the power is too low to avoid data loss
and damage caused by sudden power failure.
"""
Onboard RTC: The onboard RTC makes it possible to obtain real time in any
network condition. Timing boot function is also provided.
"""
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.
>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?
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.
>https://www.waveshare.com/wiki/7.5inch_e-Paper_HAT_(B)
>
>
>I know this project, but it is in pyton, some informations are very
>useful but not the whole project
>
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.
>
>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
>
>3) Is there any way to suspend the raspberry after refresh and restart
>it again before next refresh to save power?
>
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.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Andy Burns <usenet@andyburns.uk> wrote:
> Giangi72 wrote:
>
> > 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
> >
> > 3) Is there any way to suspend the raspberry after refresh and restart it
again
> > before next refresh to save power?
>
> Maybe use an ESP32 instead of an RPi?
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:
https://shop.m5stack.com/products/m5paper-esp32-development-kit-960x540-4-7-eink
-display-235-ppi?variant=37595977908396
https://shop.m5stack.com/products/m5stack-esp32-core-ink-development-kit1-54-eln
k-display?variant=37404426174636
Theo
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 16/12/2021 20:05, Andy Burns ha scritto:
> Giangi72 wrote:
>
>> 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
>>
>> 3) Is there any way to suspend the raspberry after refresh and restart
>> it again before next refresh to save power?
>
> Maybe use an ESP32 instead of an RPi?
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
https://stackoverflow.com/questions/19766912/how-do-i-authorise-an-app-web-or-in
stalled-without-user-intervention/19766913#19766913
What are the main advantages to use ESP32 instead of Raspberry pi?
Thanks
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Giangi72 <invalid@invalid.net> wrote:
> 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
>
https://stackoverflow.com/questions/19766912/how-do-i-authorise-an-app-web-or-in
stalled-without-user-intervention/19766913#19766913
>
> What are the main advantages to use ESP32 instead of Raspberry pi?
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
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 16/12/2021 22:51, Dennis Lee Bieber ha scritto:
> On Thu, 16 Dec 2021 17:58:30 +0100, Giangi72 <invalid@invalid.net>
> declaimed the following:
>
>> During refresh, I read on datasheet
>> Typical operating current 6.6 mA
>>
>
> Taking your previous statement of 48mW and this 6.6mA, that yields a
> 7.3V power source (W = V * A). Raspberry-Pi's provide 5V and 3.3V (and
> GPIOs can be killed if fed more than 3.3V; the 5V is from the input power
> supply and primarily provided to USB ports)
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:
https://www.waveshare.com/w/upload/4/44/7.5inch_e-Paper_B_V2_Specification.pdf
Image update current typical 8, max 12 mA
Power panel (update) typical 26.4, max 45 mW
=
typical 3.3, max 3.75 V
V3 page 9:
https://www.waveshare.com/w/upload/8/8c/7.5inch-e-paper-b-v3-specification.pdf
Typical power 21.78 mW
Typical operating current 6.6 mA
=
3.3V
>> Perfect, but are there any battery hats (cheaper) that can tell to
>> raspberry how many remaning charge they have?
>> e.g.
>> https://thepihut.com/products/li-ion-battery-hat-for-raspberry-pi
>> but I found the same, in the past, a 3-4€
>>
>
> Did you look at the documentation for that unit?
Sigh, no, just now.
It was under "View More" then "wiki ...", then manual
[CUT]
This means there is no way to power raspberry by battery and let it last
for at least a week?
>> I know this project, but it is in pyton, some informations are very
>> useful but not the whole project
>>
>
> So what is wrong with Python -- it IS the language the R-PI foundation
> targeted for users <G>

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.
> 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.
This is absolutely correct and wonderful suggestion.
>> 3) Is there any way to suspend the raspberry after refresh and restart
>> it again before next refresh to save power?
[CUT]
> WiFi is likely the biggest power drain you have on an R-Pi.
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
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 17/12/2021 00:25, Theo ha scritto:
> Andy Burns <usenet@andyburns.uk> wrote:
>> Giangi72 wrote:
>>
>>> 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
>>>
>>> 3) Is there any way to suspend the raspberry after refresh and restart it
again
>>> before next refresh to save power?
>>
>> Maybe use an ESP32 instead of an RPi?
>
> 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?
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?
> I quite like the M5Stacks as neatly packaged ESP32 boards, with batteries
> and displays:
>
https://shop.m5stack.com/products/m5paper-esp32-development-kit-960x540-4-7-eink
-display-235-ppi?variant=37595977908396
>
https://shop.m5stack.com/products/m5stack-esp32-core-ink-development-kit1-54-eln
k-display?variant=37404426174636
Thanks for your suggestions but the display is too small and I would
like to put it in a beautiful frame.
Thanks
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Giangi72 wrote:
> What are the main advantages to use ESP32 instead of Raspberry pi?
putting it to deep sleep between updates, and boards with available LiPo
battery
management.
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 17/12/2021 14:12, Andy Burns ha scritto:
> Giangi72 wrote:
>
>> What are the main advantages to use ESP32 instead of Raspberry pi?
>
> 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
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Giangi72 wrote:
> Andy Burns ha scritto:
>
>> Giangi72 wrote:
>>
>>> What are the main advantages to use ESP32 instead of Raspberry pi?
>>
>> 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
e.g. <https://unexpectedmaker.com/tinys2>
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
In article <j23attFm984U1@mid.individual.net>, invalid@invalid.net
says...
>
> This means there is no way to power raspberry by battery and let it last
> for at least a week?
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.
2. 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.
3. 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.
--
John
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
On Fri, 17 Dec 2021 13:41:14 -0000, John Aldridge wrote:
> In article <j23attFm984U1@mid.individual.net>, invalid@invalid.net
> says...
>>
>> This means there is no way to power raspberry by battery and let it
>> last for at least a week?
>
> 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.
>
> 2. 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.
>
> 3. 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++.
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Martin Gregorie <martin@mydomain.invalid> wrote:
> 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
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 17/12/2021 14:40, Andy Burns ha scritto:
>>>> What are the main advantages to use ESP32 instead of Raspberry pi?
>>>
>>> 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
>
> e.g. <https://unexpectedmaker.com/tinys2>
Thanks
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Il 17/12/2021 16:04, Theo ha scritto:
> 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.
Thanks to everyone.
I think the ESP32 + web service is the best solution.
I have found this board with integrated battery management and socket
https://www.aliexpress.com/item/1005003416635072.html?spm=a2g0o.cart.0.0.31be3c0
0pggd6r&mp=1
and
https://www.aliexpress.com/item/1005002412550877.html?spm=a2g0o.cart.0.0.31be3c0
0pggd6r&mp=1
and I read
"Lithium battery interface(battery not include), 500mA Max charging
current."
1) What does it means? If I have a 700mA or 1000mA battery? Sorry for
this newbie question.
2) I don't understand how to charge the battery once it is connected to
the board. Using usb port or detaching it and charging it externally?
Many thanks
Giangi
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)
Giangi72 wrote:
> 500mA Max charging current."
>
> 1) What does it means? If I have a 700mA or 1000mA battery? Sorry for this
> newbie question.
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
> 2) I don't understand how to charge the battery once it is connected to the
> board. Using usb port or detaching it and charging it externally?
whenever USB power is supplied, the board will charge the battery.
---
* Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10)