I am working on a battery powered car and want the Pi to shut down automatically if the battery starts to go flat to try to prevent SD card corruption. I am a beginner to bash scripts! I will run this via crontab...
#!/bin/bash
powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then
echo Under Voltage Detected - Shutting Down
sudo halt
else
echo Voltage Normal
fi
Obviously it is not working!! Could someone correct and explain for me please.
Simple Simon <please.dontspa@me.com> wrote:
I am working on a battery powered car and want the Pi to shut down
automatically if the battery starts to go flat to try to prevent SD card
corruption. I am a beginner to bash scripts! I will run this via crontab... >>
#!/bin/bash
powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then
echo Under Voltage Detected - Shutting Down
sudo halt
else
echo Voltage Normal
fi
Obviously it is not working!! Could someone correct and explain for me
please.
You need spaces in the test:-
if [ $powerstatus = "throttled=0x1" ]
Without the spaces you are just testing if '$powerstatus="throttled=0x1"'
is not an empty string, and it never will be an empty string.
Brilliant - many thanks - works a treat - I was almost there!!
I am working on a battery powered car and want the Pi to shut down automatically if the battery starts to go flat to try to prevent SD
card corruption. I am a beginner to bash scripts! I will run this via crontab...
#!/bin/bash
powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then
echo Under Voltage Detected - Shutting Down
sudo halt
else
echo Voltage Normal
fi
Obviously it is not working!! Could someone correct and explain for me please.
I am working on a battery powered car and want the Pi to shut down automatically if the battery starts to go flat to try to prevent SD card corruption. I am a beginner to bash scripts! I will run this via crontab...
#!/bin/bash
powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then
echo Under Voltage Detected - Shutting Down
sudo halt
else
echo Voltage Normal
fi
Obviously it is not working!! Could someone correct and explain for me please.
Brilliant - many thanks - works a treat - I was almost there!!
Simple Simon <please.dontspa@me.com> wrote:
Brilliant - many thanks - works a treat - I was almost there!!
I'm curious... does this actually work for low battery detection?
Unless you're wiring the Pi directly across a battery that's giving out >somewhere around 5V (for example a 6v lead acid), most of the time you'll >have a voltage regulator between you and the battery. That regulator will >aim to keep providing 5V as the battery is going flat. When the voltage
sags below 5V it means the battery is so empty it can't maintain that, which >means it's in a very steep part of the voltage decline.
On 12/01/2021 12:14, Simple Simon wrote:
I am working on a battery powered car and want the Pi to shut down
automatically if the battery starts to go flat to try to prevent SD
card corruption. I am a beginner to bash scripts! I will run this via
crontab...
#!/bin/bash
powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then
echo Under Voltage Detected - Shutting Down
sudo halt
else
echo Voltage Normal
fi
Obviously it is not working!! Could someone correct and explain for me
please.
Not being much help, but...
I'm aware of Under Voltage problems from entries in journalctl. It seems
to me that listening for events logged to journalctl would be a pretty
common thing to do. So common that there should be some standard way of
doing it. Some kind of standard Observer pattern on jounalctl. Does
anyone know of one?
On 12/01/2021 16:40, Pancho wrote:
On 12/01/2021 12:14, Simple Simon wrote:
I am working on a battery powered car and want the Pi to shut down
automatically if the battery starts to go flat to try to prevent SD
card corruption. I am a beginner to bash scripts! I will run this via
crontab...
#!/bin/bash powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then echo Under Voltage Detected - Shutting Down sudo halt else echo
Voltage Normal fi
Obviously it is not working!! Could someone correct and explain for me
please.
Not being much help, but...
I'm aware of Under Voltage problems from entries in journalctl. It
seems to me that listening for events logged to journalctl would be a
pretty common thing to do. So common that there should be some standard
way of doing it. Some kind of standard Observer pattern on jounalctl.
Does anyone know of one?
Well that's just another problem with systemd.
Simple Simon <please.dontspa@me.com> wrote:
Brilliant - many thanks - works a treat - I was almost there!!
I'm curious... does this actually work for low battery detection?
Unless you're wiring the Pi directly across a battery that's giving out >somewhere around 5V (for example a 6v lead acid), most of the time you'll >have a voltage regulator between you and the battery. That regulator will >aim to keep providing 5V as the battery is going flat. When the voltage
sags below 5V it means the battery is so empty it can't maintain that, which >means it's in a very steep part of the voltage decline.
I'd expect it to be so steep you don't get enough time to do any meaningful >shutdown, but I could be wrong. What battery setup do you have and how does >it work out in practice?
Simple Simon <please.dontspa@me.com> wrote:
Brilliant - many thanks - works a treat - I was almost there!!
I'm curious... does this actually work for low battery detection?
Unless you're wiring the Pi directly across a battery that's giving
out somewhere around 5V (for example a 6v lead acid), most of the
time you'll have a voltage regulator between you and the battery.
That regulator will aim to keep providing 5V as the battery is going
flat. When the voltage sags below 5V it means the battery is so
empty it can't maintain that, which means it's in a very steep part
of the voltage decline.
I'd expect it to be so steep you don't get enough time to do any
meaningful shutdown, but I could be wrong. What battery setup do you
have and how does it work out in practice?
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
It's a good idea to have some independent means of anticipating this
point.
As mentioned 6V lead acid doesn't work for a starting battery - it might
be OK for a 'leisure' battery that is fine with deep discharge, but
again we're on a part of the curve where the battery is absolutely flat
and declining fast.
Joe <joe@jretrading.com> wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
It's a good idea to have some independent means of anticipating this
point.
But lithium ion cells don't work for this application. We need 5V.
One cell is too little, two cells is too much.
One cell would start at 4.2V which is too low to reliably run a Pi.
Two cells would start at 8.4V which is dangerously high for the Pi, and the proposed 5V cutoff would only come in below 2.5V per cell which is bad for the cells.
As mentioned 6V lead acid doesn't work for a starting battery - it might be OK for a 'leisure' battery that is fine with deep discharge, but again we're on a part of the curve where the battery is absolutely flat and declining fast.
Possibly LiFePO4 might be better, but a pair of cells at 3.6V fully charged is still too dangerous for the Pi.
4x alkaline cells might just about manage it - 1.6V per cell when new, ie 6.4V total, which is a bit dangerous but maybe OK. A gradual decline - I don't know where the Pi low voltage detection is but flat would be about
1.1V per cell or 4.4V total which is probably detectable. So if you don't mind throwing away cells at 20% capacity it might just work.
Theo
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V.
Any sensibly designed lithium battery will cut off its
output at the chosen lower bound,
because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
It's a good idea to have some independent means of anticipating this
point.
On 13/01/2021 22:04, Joe wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V.
They do.
Any sensibly designed lithium battery will cut off its
output at the chosen lower bound,
No, it wont. That isn't in the *battery* - that's in whatever is drawing >current off it. I have many lthium packs with no such ptotection
because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
No, again it goes on down to zero, 3V is just approximately the point at >which irreversible damage starts to happen.
The way to run a lithium in this application is to use a 2 cell lithium,
It's a good idea to have some independent means of anticipating this
point.
a constant voltage constant current charger limited to 8.4V and probably
no more than the battery mAh capacity divided by one hour... and a
switched mode 5V regulator to feed the Pi and then somehow monitor raw >battery voltage and switch it all off when it gets to say 6.6V and hope
that the SMPS and monitoring circuit don't then still draw enough to
damage the battery, or even if it is take it on the chin and replace the >battery when that happens.
Joe <joe@jretrading.com> wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
It's a good idea to have some independent means of anticipating this
point.
But lithium ion cells don't work for this application. We need 5V.
One cell is too little, two cells is too much.
On Thu, 14 Jan 2021 03:46:08 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 13/01/2021 22:04, Joe wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V.
They do.
Any sensibly designed lithium battery will cut off its
output at the chosen lower bound,
No, it wont. That isn't in the *battery* - that's in whatever is drawing
current off it. I have many lthium packs with no such ptotection
because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
No, again it goes on down to zero, 3V is just approximately the point at
which irreversible damage starts to happen.
The way to run a lithium in this application is to use a 2 cell lithium,
It's a good idea to have some independent means of anticipating this
point.
a constant voltage constant current charger limited to 8.4V and probably
no more than the battery mAh capacity divided by one hour... and a
switched mode 5V regulator to feed the Pi and then somehow monitor raw
battery voltage and switch it all off when it gets to say 6.6V and hope
that the SMPS and monitoring circuit don't then still draw enough to
damage the battery, or even if it is take it on the chin and replace the
battery when that happens.
To get round that use a latching relay 'start' circuit, and when the
battery voltage gets too low unlatch the relay- Zero power demand then.
On 13 Jan 2021 23:37:18 +0000 (GMT)
Theo <theom+news@chiark.greenend.org.uk> wrote:
Joe <joe@jretrading.com> wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline. >>>
It's a good idea to have some independent means of anticipating this
point.
But lithium ion cells don't work for this application. We need 5V.
One cell is too little, two cells is too much.
One cell and a DC-DC converter to give you a regulated supply,
monitor the cell so you can shut down (well) before there's too little to
run the converter.
On 14/01/2021 10:18, Ahem A Rivet's Shot wrote:
On 13 Jan 2021 23:37:18 +0000 (GMT)
Theo <theom+news@chiark.greenend.org.uk> wrote:
Joe <joe@jretrading.com> wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely discharges, >>> it's dead forever. Not a 'steep' decline, a 'fall off the wall'
decline.
It's a good idea to have some independent means of anticipating this
point.
But lithium ion cells don't work for this application. We need 5V.
One cell is too little, two cells is too much.
One cell and a DC-DC converter to give you a regulated supply,
monitor the cell so you can shut down (well) before there's too little
to run the converter.
It's slightly simpler and more efficient to use a step down from two
cells.
On Thu, 14 Jan 2021 11:04:55 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/01/2021 10:18, Ahem A Rivet's Shot wrote:
On 13 Jan 2021 23:37:18 +0000 (GMT)It's slightly simpler and more efficient to use a step down from two
Theo <theom+news@chiark.greenend.org.uk> wrote:
Joe <joe@jretrading.com> wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely discharges, >>>>> it's dead forever. Not a 'steep' decline, a 'fall off the wall'
decline.
It's a good idea to have some independent means of anticipating this >>>>> point.
But lithium ion cells don't work for this application. We need 5V.
One cell is too little, two cells is too much.
One cell and a DC-DC converter to give you a regulated supply,
monitor the cell so you can shut down (well) before there's too little
to run the converter.
cells.
It's only simpler if you look at what's on the converter board :)
On 13 Jan 2021 23:37:18 +0000 (GMT)
Theo <theom+news@chiark.greenend.org.uk> wrote:
Joe <joe@jretrading.com> wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V. Any sensibly designed lithium battery will cut off its
output at the chosen lower bound, because if it completely
discharges, it's dead forever. Not a 'steep' decline, a 'fall off the
wall' decline.
It's a good idea to have some independent means of anticipating this
point.
But lithium ion cells don't work for this application. We need 5V.
One cell is too little, two cells is too much.
One cell and a DC-DC converter to give you a regulated supply,
monitor the cell so you can shut down (well) before there's too little
to run the converter.
On 14/01/2021 11:46, Ahem A Rivet's Shot wrote:
On Thu, 14 Jan 2021 11:04:55 +0000
It's only simpler if you look at what's on the converter
board :)
No, that's not true. To step up you need to use a buck converter with a
choke big enough to store energy to push the voltage up. To step down
you only need a choke to smooth HF ripple, and transistor efficiency
goes up with voltage and down with current, so that's a win win too.
One cell and a DC-DC converter to give you a regulated supply, monitor the cell so you can shut down (well) before there's too little to
run the converter.
No, that's not true. To step up you need to use a buck converter with a
choke big enough to store energy to push the voltage up. To step down
you only need a choke to smooth HF ripple
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
One cell and a DC-DC converter to give you a regulated supply,
monitor the cell so you can shut down (well) before there's too little to
run the converter.
Which is all very nice, but is not what the OP is doing.
They're monitoring *the input rail of the Pi*, because that's all the Pi hardware does. You put 5V in, it tells you if it sags below some threshold. You don't get to put some other voltage in to test. If you put in your raw cell voltage that will under- or over-volt the Pi and it'll either not work or fry[1].
If they want to monitor some other voltage, they'll have to start from scratch because none of what they're doing (hardware or software) will work.
Theo
[1] the main SoC has some protection as it has its own voltage regulators, but USB-side things do use that 5V directly and you may fry it that way
In message <rtpd10$7hp$1@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:
No, that's not true. To step up you need to use a buck converter with a
choke big enough to store energy to push the voltage up. To step down
you only need a choke to smooth HF ripple
Not true. The step-down inductor needs to store energy too.
David
On 14/01/2021 09:23, Folderol wrote:
To get round that use a latching relay 'start' circuit, and when theIts getting as complicated as a renewable energy grid though isn't it?
battery voltage gets too low unlatch the relay- Zero power demand then.
On Wed, 13 Jan 2021 13:56:52 +0000, The Natural Philosopher wrote:
On 12/01/2021 16:40, Pancho wrote:One way to get a rapid notification of entries written to a log is the
On 12/01/2021 12:14, Simple Simon wrote:
I am working on a battery powered car and want the Pi to shut down
automatically if the battery starts to go flat to try to prevent SD
card corruption. I am a beginner to bash scripts! I will run this via
crontab...
#!/bin/bash powerstatus=$(vcgencmd get_throttled)
if [ $powerstatus="throttled=0x1" ]
then echo Under Voltage Detected - Shutting Down sudo halt else echo
Voltage Normal fi
Obviously it is not working!! Could someone correct and explain for me >>>> please.
Not being much help, but...
I'm aware of Under Voltage problems from entries in journalctl. It
seems to me that listening for events logged to journalctl would be a
pretty common thing to do. So common that there should be some standard
way of doing it. Some kind of standard Observer pattern on jounalctl.
Does anyone know of one?
use 'tail' in a script.
Running "sudo tail -f /var/log/messages" from a console shows you each message as it is written to /var/log/messages, so a script started a boot time to run with sufficient privilege to read those log entries could
easily use tail to read messages as they are written and filter out the
ones of interest with grep or awk and use them to , for instance force a clean shutdown on low battery, something like
#!/bin/bash
tail -f /var/log/messages | awk <<ENDPROG
/Under voltage/ { shutdown -h NOW }
ENDPROG
I thought << was a way of redirecting stdin, not redirecting command
line or program file.
In fact I couldn't get the following to work at all:
sudo journalctl -f | awk '{ print $0 }'
sudo journalctl -f | awk -- '{ print $0 }'
On 14/01/2021 14:17, David Higton wrote:
In message <rtpd10$7hp$1@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:
No, that's not true. To step up you need to use a buck converter with a choke big enough to store energy to push the voltage up. To step down
you only need a choke to smooth HF ripple
Not true. The step-down inductor needs to store energy too.
It isn't a step down inductor.
you just use variable PWM on the raw voltage. All you need to do is use a cap and some form of current limiter - a resistors works but dissipates power
sudo tail -f /var/log/messages | awk -- '{ print $0 }'
which works here.
On 16/01/2021 17:53, Martin Gregorie wrote:
Messages added to /var/log/messages with the following command aresudo tail -f /var/log/messages | awk -- '{ print $0 }'
which works here.
On 16/01/2021 22:33, Martin Gregorie wrote:
On Sat, 16 Jan 2021 20:39:09 +0000, Pancho wrote:Why not just use the logger command?
On 16/01/2021 17:53, Martin Gregorie wrote:Messages added to /var/log/messages with the following command are
sudo tail -f /var/log/messages | awk -- '{ print $0 }'
which works here.
displayed almost instantly, though they aren't exactly readable since
the text is shown as a hex string:
sudo echo "Another message" 2>&1 | logsave /var/log/messages -
e.g.
logger "Another message"
You seem to be over complicating things: why redirect stderr to stdin
&1 from echo, echo doesn't need sudo, logsave /var/log/messages doesneed sudo, logsave is truncating /var/log/messages.
The immediate response you are seeing is stderr from tail, which isn't
being piped to awk at all. This error message is generated by tail -f
because logsave truncates the file that is being tailed, logsave -a
appends.
The manual says pipes are buffered. My experiments say pipes are
buffered.
On Sat, 16 Jan 2021 20:39:09 +0000, Pancho wrote:
On 16/01/2021 17:53, Martin Gregorie wrote:Messages added to /var/log/messages with the following command are
sudo tail -f /var/log/messages | awk -- '{ print $0 }'
which works here.
displayed almost instantly, though they aren't exactly readable since the text is shown as a hex string:
sudo echo "Another message" 2>&1 | logsave /var/log/messages -
&1 from echo, echo doesn't need sudo, logsave /var/log/messages doesneed sudo, logsave is truncating /var/log/messages.
sudo echo "Another message" 2>&1 | logsave /var/log/messages -
Using an inductor in a conventional step-down switching regulator is
much more efficient, and of course requires the inductor to store
energy.
On Sat, 16 Jan 2021 23:30:34 +0000, Pancho wrote:
On 16/01/2021 22:33, Martin Gregorie wrote:
On Sat, 16 Jan 2021 20:39:09 +0000, Pancho wrote:Why not just use the logger command?
On 16/01/2021 17:53, Martin Gregorie wrote:Messages added to /var/log/messages with the following command are
sudo tail -f /var/log/messages | awk -- '{ print $0 }'
which works here.
displayed almost instantly, though they aren't exactly readable since
the text is shown as a hex string:
sudo echo "Another message" 2>&1 | logsave /var/log/messages -
e.g.
logger "Another message"
You seem to be over complicating things: why redirect stderr to stdin
&1 from echo, echo doesn't need sudo, logsave /var/log/messages doesneed sudo, logsave is truncating /var/log/messages.
The immediate response you are seeing is stderr from tail, which isn't
being piped to awk at all. This error message is generated by tail -f
because logsave truncates the file that is being tailed, logsave -a
appends.
The manual says pipes are buffered. My experiments say pipes are
buffered.
So how come you're getting delays and I'm not?
In fact I couldn't get the following to work at all:
sudo journalctl -f | awk '{ print $0 }'
In fact I couldn't get the following to work at all:
sudo journalctl -f | awk '{ print $0 }'
On 16/01/2021 05:53 pm, Martin Gregorie wrote:
In fact I couldn't get the following to work at all:
sudo journalctl -f | awk '{ print $0 }'
Why would you use awk at all here? You're just (re)printing the input line. BTW the above works here - LMDE4, GNU awk 4.2
Selecting some message text in Thunderbird seems to confuse it
However, I'm not yet convinced this is a sensible way of observing
events. I'm still undecided.
On 16/01/2021 05:53 pm, Martin Gregorie wrote:
In fact I couldn't get the following to work at all:
sudo journalctl -f | awk '{ print $0 }'
Why would you use awk at all here? You're just (re)printing the input
line.
BTW the above works here - LMDE4, GNU awk 4.2
On 16/01/2021 20:09, David Higton wrote:
Using an inductor in a conventional step-down switching regulator is much more efficient, and of course requires the inductor to store energy.
No, it doesn't have to store ALL the energy - like it does in a step up
And if you don't mind massive ripple, it isn't needed *at all*. Consider a
6V battery deeding a 3V lamp. Simply chop the 6V on a 50% duty cycle and there you are. No choke needed at all.
Add an LC filter and the cap stores all that is necessary. All the L does
is limit the peak current into the C.
On 16/01/2021 20:09, David Higton wrote:
Using an inductor in a conventional step-down switching regulator is
much more efficient, and of course requires the inductor to store
energy.
No, it doesn't have to store ALL the energy - like it does in a step up
And if you don't mind massive ripple, it isn't needed *at all*.
Consider a 6V battery deeding a 3V lamp. Simply chop the 6V on a 50%
duty cycle and there you are. No choke needed at all.
If it's going to limit the current, it must not saturate, in which case
it'd store the energy that you claim is unnecessary.
I'm not sure what awk interactive/buffering means. Without the "-W interactive" flag awk doesn't just buffer output, the system() call is delayed too. It's more like it is buffering input.
On Mon, 18 Jan 2021 13:20:59 +0000, Pancho wrote:
I'm not sure what awk interactive/buffering means. Without the "-WSince you're using a pipe to pass messages from the log reader to the awk program, awk makes a read request which will wait for input until either
interactive" flag awk doesn't just buffer output, the system() call is
delayed too. It's more like it is buffering input.
a line of text is written to the pipe, in which case it gets read by awk
(awk reads lines, so the message MUST be terminated by a newline) OR the
pipe is closed, in which case awk gets an EOF and stops. If the awk
script contains a END action, this is executed before is quits.
The only apparent buffering you should see is due to awk waiting for the newline that terminates the line being read.
About -W : according to the manpage for the awk version I'm using, 5.0.1,
-W has nothing to do with waiting for anything. All it does is to change
the option marker from - to --
I'm using Raspbian Buster, default awk is mawk 1.3.3.
On Sun, 17 Jan 2021 10:39:32 +0000, Pancho wrote:
However, I'm not yet convinced this is a sensible way of observingThat depends: if the occurrence of events to be observed cause messages
events. I'm still undecided.
to be logged rather than being dealt with by the program that observes
them, then watching a log for the occurrence might well be the best way
to do it since this separates the observation from the consequent action, offering the possibility of more than one observing process being able to trigger the action. Where that action is irreversable, as it is in this
case, that sounds like a good idea.
Of course, if the observer doesn't log anything, there's no reason to use
a general purpose logfile - just write the observations to a file or
pipeline that's accessable to the process that will execute the action:
as this is Linux, you can use shared memory or a semaphore (if the programming language supports it) to signal that an actionable event has occurred. Shared memory, event queues and asynchronous i/o are all
available in the C and Java standard function/class libraries but may not
be in other languages.
OTOH if the required action is specific to the observer, i.e. doesn't
affect anything outside the process(es) handling the data stream being observed, then simply deal with the observation inside the observing
process.
On 17/01/2021 15:57, David Higton wrote:
If it's going to limit the current, it must not saturate, in which case it'd store the energy that you claim is unnecessary.
Go back and re read your electronics 101
About -W : according to the manpage for the awk version I'm using,
5.0.1, -W has nothing to do with waiting for anything. All it does is
to change the option marker from - to --
I'm using Raspbian Buster, default awk is mawk 1.3.3.
Perhaps that explains our different experience. mawk buffering doesn't
appear to be line buffering by default, i.e it buffers blocks somewhere between 2 to 3kB (whatever the correct name for that is).
What OS are you using?
On 13/01/2021 22:04, Joe wrote:
Lithium cells have a linear-ish discharge curve, from 4.2V down to
around 3V.
They do.
Any sensibly designed lithium battery will cut off its
output at the chosen lower bound,
No, it wont. That isn't in the *battery* - that's in whatever is drawing >current off it. I have many lthium packs with no such ptotection
because if it completely discharges,
it's dead forever. Not a 'steep' decline, a 'fall off the wall' decline.
No, again it goes on down to zero, 3V is just approximately the point at >which irreversible damage starts to happen.
The way to run a lithium in this application is to use a 2 cell lithium,
It's a good idea to have some independent means of anticipating this
point.
a constant voltage constant current charger limited to 8.4V and probably
no more than the battery mAh capacity divided by one hour... and a
switched mode 5V regulator to feed the Pi and then somehow monitor raw >battery voltage and switch it all off when it gets to say 6.6V and hope
that the SMPS and monitoring circuit don't then still draw enough to
damage the battery, or even if it is take it on the chin and replace the >battery when that happens.
I would imagine that the whole setup would cost more than the Pi itself
On Thu, 14 Jan 2021 03:46:08 +0000, in <rtoeq0$pt9$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
The way to run a lithium in this application is to use a 2 cell
lithium, a constant voltage constant current charger limited to 8.4V
and probably no more than the battery mAh capacity divided by one
hour... and a switched mode 5V regulator to feed the Pi and then
somehow monitor raw battery voltage and switch it all off when it
gets to say 6.6V and hope that the SMPS and monitoring circuit don't
then still draw enough to damage the battery, or even if it is take
it on the chin and replace the battery when that happens.
Yes... with special care to observe that safe cutoff voltage so that
when power returns the constant current, constant voltage charger
doesn't charge the battery any faster than it can accept safely. But
wait... the constant current needs to be all that is needed to run the
Pi PLUS the additional safe amount to recharge the battery, but... how
do you assure the Pi and the battery share the current appropriately
so that the Pi runs and the battery recharges safely? Maybe a bit more control is needed to assure a battery voltage above a certain value
before the Pi is rebooted.
On Mon, 18 Jan 2021 14:02:33 +0000, Pancho wrote:
About -W : according to the manpage for the awk version I'm using,
5.0.1, -W has nothing to do with waiting for anything. All it does is
to change the option marker from - to --
I'm using Raspbian Buster, default awk is mawk 1.3.3.
Perhaps that explains our different experience. mawk buffering doesn't
appear to be line buffering by default, i.e it buffers blocks somewhere
between 2 to 3kB (whatever the correct name for that is).
What OS are you using?
Fedora 32 for these tests, which uses awk 5.0.1 - The Buster awk is very old, so raising a bug requesting an upgrade to the latest awk may be a
good idea.
Running "man 7 pipe" tells you almost everything you'd want to know about pipes and that the implementation changed at Linux 2.6.11 - Fedora 32 is using the Linux 5.9.16 kernel.
On Tue, 19 Jan 2021 13:46:18 +0000, Pancho wrote:
I think this clarifies in my mind why I wouldn't ever use this technique
to observe events in practice. It is too fragile.
So raise a bug to get it fixed: this will help everybody and is, after
all, why most Linux distros have decent bug reporting facilities. Plus
its quite a good way of thanking the developers for their work.
I think this clarifies in my mind why I wouldn't ever use this technique
to observe events in practice. It is too fragile.
Yeah that is kind of the point, I'm a mediocre old programmer, I don't
want to know everything about everything. What I want is an easy life. I
want a basic technique to work, reliably, environment agnostically as possible.
I think this clarifies in my mind why I wouldn't ever use this technique
to observe events in practice. It is too fragile.
realtime filtered, reformatted viewSQL statements to stdout
statisticsAfter processing every input line:
On 19/01/2021 15:24, Martin Gregorie wrote:
On Tue, 19 Jan 2021 13:46:18 +0000, Pancho wrote:There is not a bug, just different implementations, different behaviour. Different buffering, different arguments.
I think this clarifies in my mind why I wouldn't ever use this
technique to observe events in practice. It is too fragile.
So raise a bug to get it fixed: this will help everybody and is, after
all, why most Linux distros have decent bug reporting facilities. Plus
its quite a good way of thanking the developers for their work.
On Tue, 19 Jan 2021 15:34:00 +0000, Pancho wrote:
On 19/01/2021 15:24, Martin Gregorie wrote:
On Tue, 19 Jan 2021 13:46:18 +0000, Pancho wrote:There is not a bug, just different implementations, different behaviour.
I think this clarifies in my mind why I wouldn't ever use this
technique to observe events in practice. It is too fragile.
So raise a bug to get it fixed: this will help everybody and is, after
all, why most Linux distros have decent bug reporting facilities. Plus
its quite a good way of thanking the developers for their work.
Different buffering, different arguments.
Disagree: the delay you're seeing is definitely a bug, though possibly
its a task scheduler issue. If you run less than a buffer-full of data through a pipe there should not be a noticeable delay under a UNIX/Linux
OS because the buffer is in memory and the task scheduler is a
multitasking scheduler and so can interleave both the writing and reading tasks without any delay except those caused by task switching and being preempted by higher priority tasks.
You're reporting multi-second delays you can see which task(s) are
involved: run the delayed pipe again, but this time with 'top' running in another console window to see what programs are active during the delay.
On 19/01/2021 16:21, Martin Gregorie wrote:
On Tue, 19 Jan 2021 15:34:00 +0000, Pancho wrote:
On 19/01/2021 15:24, Martin Gregorie wrote:
On Tue, 19 Jan 2021 13:46:18 +0000, Pancho wrote:
I think this clarifies in my mind why I wouldn't ever use this
technique to observe events in practice. It is too fragile.
So raise a bug to get it fixed: this will help everybody and is, after >>>> all, why most Linux distros have decent bug reporting facilities. Plus >>>> its quite a good way of thanking the developers for their work.
There is not a bug, just different implementations, different behaviour. >>> Different buffering, different arguments.
Disagree: the delay you're seeing is definitely a bug, though possibly
its a task scheduler issue. If you run less than a buffer-full of data
through a pipe there should not be a noticeable delay under a UNIX/Linux
OS because the buffer is in memory and the task scheduler is a
multitasking scheduler and so can interleave both the writing and reading
tasks without any delay except those caused by task switching and being
preempted by higher priority tasks.
You're reporting multi-second delays you can see which task(s) are
involved: run the delayed pipe again, but this time with 'top' running in
another console window to see what programs are active during the delay.
I think you are missing the point. If I pipe 4095 characters into
mawk, nothing happens, if a pipe an extra char to make 4096, it prints
out.
[...]I'm using Raspbian Buster, default awk is mawk 1.3.3.
Fedora 32 for these tests, which uses awk 5.0.1 - The Buster awk is very old, so raising a bug requesting an upgrade to the latest awk may be a
good idea.
On 19/01/2021 16:21, Martin Gregorie wrote:
On Tue, 19 Jan 2021 15:34:00 +0000, Pancho wrote:I think you are missing the point. If I pipe 4095 characters into mawk, nothing happens, if a pipe an extra char to make 4096, it prints out.
On 19/01/2021 15:24, Martin Gregorie wrote:
On Tue, 19 Jan 2021 13:46:18 +0000, Pancho wrote:There is not a bug, just different implementations, different
I think this clarifies in my mind why I wouldn't ever use this
technique to observe events in practice. It is too fragile.
So raise a bug to get it fixed: this will help everybody and is,
after all, why most Linux distros have decent bug reporting
facilities. Plus its quite a good way of thanking the developers for
their work.
behaviour.
Different buffering, different arguments.
Disagree: the delay you're seeing is definitely a bug, though possibly
its a task scheduler issue. If you run less than a buffer-full of data
through a pipe there should not be a noticeable delay under a
UNIX/Linux OS because the buffer is in memory and the task scheduler is
a multitasking scheduler and so can interleave both the writing and
reading tasks without any delay except those caused by task switching
and being preempted by higher priority tasks.
You're reporting multi-second delays you can see which task(s) are
involved: run the delayed pipe again, but this time with 'top' running
in another console window to see what programs are active during the
delay.
Agreed. It is easy to reproduce.
$ (seq 9999 | head -c 4095; sleep 2; echo) | mawk '{print}'
I have no idea what the benefit of the latter policy is, it seems to
make the code a lot more complicated for no clear gain (and it breaks
your use case). It’s plainly deliberate, so in that sense not a bug, although it seems like a bizarre design decision to me.
[...]I'm using Raspbian Buster, default awk is mawk 1.3.3.
Fedora 32 for these tests, which uses awk 5.0.1 - The Buster awk is very
old, so raising a bug requesting an upgrade to the latest awk may be a
good idea.
There is no such thing as mawk 5.0.1, Fedora is presumably using GNU Awk (which also available in Debian and its derivatives). These are totally different programs and it does not make any sense to compare their
version numbers.
I think you are missing the point. If I pipe 4095 characters into mawk,
nothing happens, if a pipe an extra char to make 4096, it prints out.
Thats definitely faulty behaviour: pipe operation should not depend on
how full the pipe is.
On 19/01/2021 22:15, Martin Gregorie wrote:
Richard explained it better than me. It's mawk waiting until it has aI think you are missing the point. If I pipe 4095 characters into
mawk,
nothing happens, if a pipe an extra char to make 4096, it prints out.
Thats definitely faulty behaviour: pipe operation should not depend on
how full the pipe is.
block of 4096 bytes (or EOF). Clearly designed behaviour.
With 20.04, Ubuntu seems to have switched from mawk to gawk as default
awk. I don't know if this is Ubuntu specific or Debian. So it's quite possible this will be reflected in the next version of Raspbian
(Rasberry Pi OS)
This is exactly what I mean by fragile. Someone writes a script to do something using awk, an OS update comes along and the app completely
changes.
On Wed, 20 Jan 2021 10:03:49 +0000, Pancho wrote:
On 19/01/2021 22:15, Martin Gregorie wrote:
Richard explained it better than me. It's mawk waiting until it has aI think you are missing the point. If I pipe 4095 characters into
mawk,
nothing happens, if a pipe an extra char to make 4096, it prints out.
Thats definitely faulty behaviour: pipe operation should not depend on
how full the pipe is.
block of 4096 bytes (or EOF). Clearly designed behaviour.
With 20.04, Ubuntu seems to have switched from mawk to gawk as default
awk. I don't know if this is Ubuntu specific or Debian. So it's quite
possible this will be reflected in the next version of Raspbian
(Rasberry Pi OS)
This is exactly what I mean by fragile. Someone writes a script to do
something using awk, an OS update comes along and the app completely
changes.
In Fedora systems the binary is called gawk with awk as an alias
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
So, the same shell script should run in both places: my test scripts do exactly that *and* do not show the long delay you're seeing.
In mine, [...]
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
Martin Gregorie <martin@mydomain.invalid> wrote:
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
Not here, or did you not mean aliases to mawk? It's /usr/bin/awk -> /etc/alternatives/awk -> /usr/bin/gawk. /usr/bin/mawk is a separate
binary with these properties:
On 20/01/2021 10:49 am, Martin Gregorie wrote:
On Wed, 20 Jan 2021 10:03:49 +0000, Pancho wrote:In mine, Linux raspi-3plus 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT
On 19/01/2021 22:15, Martin Gregorie wrote:
Richard explained it better than me. It's mawk waiting until it has aI think you are missing the point. If I pipe 4095 characters into
mawk,
nothing happens, if a pipe an extra char to make 4096, it prints
out.
Thats definitely faulty behaviour: pipe operation should not depend
on how full the pipe is.
block of 4096 bytes (or EOF). Clearly designed behaviour.
With 20.04, Ubuntu seems to have switched from mawk to gawk as default
awk. I don't know if this is Ubuntu specific or Debian. So it's quite
possible this will be reflected in the next version of Raspbian
(Rasberry Pi OS)
This is exactly what I mean by fragile. Someone writes a script to do
something using awk, an OS update comes along and the app completely
changes.
In Fedora systems the binary is called gawk with awk as an alias In
Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
So, the same shell script should run in both places: my test scripts do
exactly that *and* do not show the long delay you're seeing.
2020 armv7l GNU/Linux,
# ls -l /usr/bin/?awk -rwxr-xr-x 1 root root 537K Sep 14 2018
/usr/bin/gawk*
-rwxr-xr-x 1 root root 93K Apr 8 2012 /usr/bin/mawk*
lrwxrwxrwx 1 root root 22 May 27 2020 /usr/bin/nawk -> /etc/alternatives/nawk*
so mawk is well out of date!
/usr/bin/awk -> /etc/alternatives/awk -> /usr/bin/gawk
/usr/bin/mawk -W version says:
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
compiled limits:
max NF 32767 sprintf buffer 1020
So really, well worth linking awk to gawk if you can.
On Wed, 20 Jan 2021 12:18:16 +0000, A. Dumas wrote:
Martin Gregorie <martin@mydomain.invalid> wrote:Well, that is effectively aliases, just selective ones and is what I have here. I've newer switched that alternative on my RPi, so I've been
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
Not here, or did you not mean aliases to mawk? It's /usr/bin/awk ->
/etc/alternatives/awk -> /usr/bin/gawk. /usr/bin/mawk is a separate
binary with these properties:
running mawk as awk.
Fedora does not use alternatives - just /usr/bin/gawk with /usr/bin/awk
as an alias.
Martin Gregorie <martin@mydomain.invalid> wrote:
On Wed, 20 Jan 2021 12:18:16 +0000, A. Dumas wrote:
Martin Gregorie <martin@mydomain.invalid> wrote:Well, that is effectively aliases, just selective ones and is what I have
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
Not here, or did you not mean aliases to mawk? It's /usr/bin/awk ->
/etc/alternatives/awk -> /usr/bin/gawk. /usr/bin/mawk is a separate
binary with these properties:
here. I've newer switched that alternative on my RPi, so I've been
running mawk as awk.
Fedora does not use alternatives - just /usr/bin/gawk with /usr/bin/awk
as an alias.
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but especially on Debian/Raspbian which I have used for quite a few years and never noticed that awk was linked to mawk. Pretty sure it isn't, in a standard installation.
On Wed, 20 Jan 2021 12:18:16 +0000, A. Dumas wrote:
Martin Gregorie <martin@mydomain.invalid> wrote:Well, that is effectively aliases, just selective ones and is what I have here. I've newer switched that alternative on my RPi, so I've been
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
Not here, or did you not mean aliases to mawk? It's /usr/bin/awk ->
/etc/alternatives/awk -> /usr/bin/gawk. /usr/bin/mawk is a separate
binary with these properties:
running mawk as awk.
Fedora does not use alternatives - just /usr/bin/gawk with /usr/bin/awk
as an alias.
On 20/01/2021 01:18 pm, Martin Gregorie wrote:
On Wed, 20 Jan 2021 12:18:16 +0000, A. Dumas wrote:/usr/bin/awk -> /etc/alternatives/awk -> /usr/bin/gawk Not aliases, soft links, AIUI
Martin Gregorie <martin@mydomain.invalid> wrote:Well, that is effectively aliases, just selective ones and is what I
In Raspbian Buster the binary is /usr/bin/mawk with awk and nawk as
aliases
Not here, or did you not mean aliases to mawk? It's /usr/bin/awk ->
/etc/alternatives/awk -> /usr/bin/gawk. /usr/bin/mawk is a separate
binary with these properties:
have here. I've newer switched that alternative on my RPi, so I've been
running mawk as awk.
Fedora does not use alternatives - just /usr/bin/gawk with /usr/bin/awk
as an alias.
alias awk='gawk' would not work if user not logged in (e.g in cron)
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but especially on Debian/Raspbian which I have used for quite a few years and never noticed that awk was linked to mawk. Pretty sure it isn't, in a standard installation.
So, questions for Pancho:
- how did you create your input files?
- Is there any chance that they don't contain any 'newline' characters?
I'm asking because its quite possible that awk would stall, waiting for a
the next character, if it had read several KB of data without finding a newline character or EOF.
$ (seq 9999 | head -c 4095; sleep 2; echo) | mawk '{print}'
A. Dumas <alexandre@dumas.fr.invalid> writes:
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but
especially on Debian/Raspbian which I have used for quite a few years and
never noticed that awk was linked to mawk. Pretty sure it isn't, in a
standard installation.
If both are installed, gawk wins (priority 10 vs priority 5).
However mawk is Priority: required, while gawk is Priority: optional.
So mawk is the default in the sense that it’s certain to be installed
while gawk is not, but gawk is the default in the alternative sense that
if you have both, awk->gawk.
A. Dumas <alexandre@dumas.fr.invalid> writes:
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but
especially on Debian/Raspbian which I have used for quite a few years and
never noticed that awk was linked to mawk. Pretty sure it isn't, in a
standard installation.
If both are installed, gawk wins (priority 10 vs priority 5).
However mawk is Priority: required, while gawk is Priority: optional.
So mawk is the default in the sense that it’s certain to be installed
while gawk is not, but gawk is the default in the alternative sense that
if you have both, awk->gawk.
On 20/01/2021 13:02, Martin Gregorie wrote:
So, questions for Pancho:I used:
- how did you create your input files?
- Is there any chance that they don't contain any 'newline' characters?
I'm asking because its quite possible that awk would stall, waiting for
a the next character, if it had read several KB of data without finding
a newline character or EOF.
tail -f testfile | mawk...
I used vi to generate files, with newlines, which I appended into the testfile, or just echo "stuff..." appended into the test file.
But Richard's example is perfect to demonstrate the problem:
$ (seq 9999 | head -c 4095; sleep 2; echo) | mawk '{print}'
Not only does seq quickly generate a byte stream, but it allows you to
see exactly what byte you are on. I'm not sure why he used the brackets
() but I left them in as they don't hurt.
I guess he used the echo because he is habitually tidy :-).
Maybe the answer is that for reliability I should have used perl instead
of awk?
Maybe perl is more standard?
I used:
tail -f testfile | mawk...
I used vi to generate files, with newlines, which I appended into the testfile, or just echo "stuff..." appended into the test file.
But Richard's example is perfect to demonstrate the problem:
$ (seq 9999 | head -c 4095; sleep 2; echo) | mawk '{print}'
Not only does seq quickly generate a byte stream, but it allows you to
see exactly what byte you are on. I'm not sure why he used the
brackets () but I left them in as they don't hurt.
I guess he used the echo because he is habitually tidy :-).
Maybe the answer is that for reliability I should have used perl
instead of awk? Maybe perl is more standard?
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but especially on Debian/Raspbian which I have used for quite a few years and never noticed that awk was linked to mawk. Pretty sure it isn't, in a standard installation.
On Wed, 20 Jan 2021 15:49:49 +0000, Pancho wrote:
On 20/01/2021 13:02, Martin Gregorie wrote:Dunno about that: awk takes a bit of getting used to because its a specialised tool for extracting data from text files: I suggested using
So, questions for Pancho:I used:
- how did you create your input files?
- Is there any chance that they don't contain any 'newline' characters?
I'm asking because its quite possible that awk would stall, waiting for
a the next character, if it had read several KB of data without finding
a newline character or EOF.
tail -f testfile | mawk...
I used vi to generate files, with newlines, which I appended into the
testfile, or just echo "stuff..." appended into the test file.
But Richard's example is perfect to demonstrate the problem:
>> $ (seq 9999 | head -c 4095; sleep 2; echo) | mawk '{print}'
Not only does seq quickly generate a byte stream, but it allows you to
see exactly what byte you are on. I'm not sure why he used the brackets
() but I left them in as they don't hurt.
I guess he used the echo because he is habitually tidy :-).
Maybe the answer is that for reliability I should have used perl instead
of awk?
it in this case because its brilliant for tasks like scanning log files
for a set of error messages and doing appropriate stuff for each one it spots. As you've seen, the code needed to recognise 'battery low'
warnings in, say, /var/log/messages and issue a 'shutdown -h now' command
if one is found would be a trivially small program because it
automatically reads lines and splits them into words before using a regex
to trigger actions on any lines that the regex matches: about all you
need to write is the regexes and the code that each of them triggers.
By comparison C, Java, Perl or Python, ... are all general purpose programming languages and so you need to code the file reading loop and (probably) the scan routine that recognises interesting lines in the file
as well as the code to do something useful when a line is recognised.
IOW, to spot a 'battery low' message in the /var/log/messages logfile and issue a STOP command the Raspbian would be a one liner in awk:
awk -- '/battery low/ { system("shutdown -h now") }' /var/log/messages
as compared with at least 10-20 lines in any of the other languages I mentioned - and they'll take longer to write simply because the loop and
the line parser will need to be coded and debugged.
The above, of course, is assuming that you don't want to simply build the shutdown command into the program that's watching battery voltage
A lot of programmers would do it that way while others, of which I'm one, like to keep different activities in single purpose programs - and,
though its unlikely in this particular case, would keep them separate
because you might someday need to let another program trigger the boojum
as well as the one you're designing right now.
On 20/01/2021 14:44, A. Dumas wrote:
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but
especially on Debian/Raspbian which I have used for quite a few years and
never noticed that awk was linked to mawk. Pretty sure it isn't, in a
standard installation.
I've just checked /etc/alternatives/awk on my bakers dozen Pi's, and the
two running Raspbian with the Mate desktop are gawk, all the others
running Raspbian Pixel and Raspbian Lite are using mawk, so it would
seem mawk is the default on standard installations.
Op 21-01-2021 om 11:07 schreef druck:
On 20/01/2021 14:44, A. Dumas wrote:
But I also haven't changed those aliases, or at least don't remember. I
would find it very strange if mawk was the default awk anywhere, but
especially on Debian/Raspbian which I have used for quite a few years
and
never noticed that awk was linked to mawk. Pretty sure it isn't, in a
standard installation.
I've just checked /etc/alternatives/awk on my bakers dozen Pi's, and
the two running Raspbian with the Mate desktop are gawk, all the
others running Raspbian Pixel and Raspbian Lite are using mawk, so it
would seem mawk is the default on standard installations.
Huh. Thanks for checking. Perhaps I am the "victim" of an automated
switch from mawk to gawk after installing it as a dependency from other things I always install.
On Mon, 18 Jan 2021 17:07:59 +0000
Jim H <invalid@invalid.invalid> wrote:
On Thu, 14 Jan 2021 03:46:08 +0000, in <rtoeq0$pt9$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
The way to run a lithium in this application is to use a 2 cell
lithium, a constant voltage constant current charger limited to 8.4V
and probably no more than the battery mAh capacity divided by one
hour... and a switched mode 5V regulator to feed the Pi and then
somehow monitor raw battery voltage and switch it all off when it
gets to say 6.6V and hope that the SMPS and monitoring circuit don't
then still draw enough to damage the battery, or even if it is take
it on the chin and replace the battery when that happens.
Yes... with special care to observe that safe cutoff voltage so that
when power returns the constant current, constant voltage charger
doesn't charge the battery any faster than it can accept safely. But
wait... the constant current needs to be all that is needed to run the
Pi PLUS the additional safe amount to recharge the battery, but... how
do you assure the Pi and the battery share the current appropriately
so that the Pi runs and the battery recharges safely? Maybe a bit more
control is needed to assure a battery voltage above a certain value
before the Pi is rebooted.
The way to do it is to use a purpose-made lithium battery charger IC,
for a pound or two. A diode, an inductor, a capacitor, a resistor and a >transistor are all that is additionally needed, and some ICs
incorporate the transistor. You then need a power source that will
provide current for both charging and a reasonable amount to run the
device itself. The resistor sets the main charging current, typically
0.3-0.5 of the battery capacity, independently of the device
consumption. The diode, inductor, capacitor and transistor do the same
jobs as in any switch-mode power supply.
Huh. Thanks for checking. Perhaps I am the "victim" of an automated
switch from mawk to gawk after installing it as a dependency from
other things I always install.
I think that is the case, as I don't recall ever deliberately
installing gawk on those two machine.
druck <news@druck.org.uk> writes:
Huh. Thanks for checking. Perhaps I am the "victim" of an automated
switch from mawk to gawk after installing it as a dependency from
other things I always install.
I think that is the case, as I don't recall ever deliberately
installing gawk on those two machine.
Could be. I have two Pis, one is running Raspbian 8 and
/etc/alternatives/awk points to mawk. The other is running Raspbian 10
and /etc/alternatives/awk points to gawk. I don't think I have installed
gawk on the latter but I don't really remember for sure.
By the way, since I haven't seen this mentioned, Debian provides a tool
to manage those symlinks in /etc/alternatives, it's called update-alternatives. IMO it has an obscure syntax and is hard to use but
I'd say it's still better than manually modifying the symlinks.
By the way, since I haven't seen this mentioned, Debian provides a tool
to manage those symlinks in /etc/alternatives, it's called update-alternatives. IMO it has an obscure syntax and is hard to use but
I'd say it's still better than manually modifying the symlinks.
| Sysop: | Rempala |
|---|---|
| Location: | Richlands, NC |
| Users: | 103 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 24:18:14 |
| Calls: | 157 |
| Files: | 6 |
| Messages: | 110,381 |