Battery Powered Project

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.

Sure that's all on the board :) From a system perspective it's just a board with battery in and 5V out :)

Oh I agree a step down only is a simpler board, but either way it's an off the shelf small component.

The Powerboost 1000C from Adafruit does that - has 5v input an is connected to an RPi and a single cell LiPO cell, so is a a postage-stamp sized 1 amp UPS.

It can run the attached RPi while charging the LiPO from the 5v supply and continue to run the RPi off the LoPO in the 5v feed is turned off.

Needs some soldering: it comes with all the connectors that can be attached to it, but not soldered in. The idea is that you only install the ones you need.

Note I have one, but haven't yet found the round tuit I need to get it and a Pi Zero up and running using it. When the project is complete I'll what will be effectively a pocketable system TFT touch screen and built- in charger.

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

Not true. The step-down inductor needs to store energy too.

David

and the point is that any regulated supply will simply die without warning, so they will have to

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

Oh come on now! I designed my first latching relay/(manual)shutdown thing when I was about 10. When I was in my early teens I did one that would automatically time out, using one of those new-fanged transistor things and a cap.

I thought

'man bash' is your friend - look up 'here documents' in the bash manpage

awk is expecting to be passed the awkscript in one of these ways:

and in (2) the '--' which marks the end of awk options, is mandatory if you use this syntax.

Since journalctl only reads the systemd journal, if you want to read any other journal, and /var/log/messages is the default for most non-system programs you need to use tail, not journalctl, so write something like

sudo tail -f /var/log/messages | awk -- '{ print $0 }'

which works here.

Just a short form of words - I was referring to an inductor in a step down regulator.

There are regulators that use capacitors, sure (commonly step up, e.g. for EIA-232 line drivers), but they inherently require significant resistance in the switch elements to limit the current, so they're lossy. For a low power application the losses don't matter, but in the case discussed here, I don't think you'd want that level of loss. It works out the same as a linear regulator, according to my maths.

Using an inductor in a conventional step-down switching regulator is much more efficient, and of course requires the inductor to store energy.

(Apologies for the delay in replying - the news server I use changed its implementation of NNTP and I have had to modify my news transport client's code to suit.)

David

when you say works, what do you mean?

A quick check on my machine show that this too is buffered.

Try writing messages using the logger command in a bash shell.

It looked to me as if I had to write nearly 3000 bytes before it flushed ,and hence awk printed out.

Messages added to /var/log/messages with the following command are 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 -

Changing the listener to

$ sudo tail -f /var/log/maillog | awk -- '{ print $0 }' so its looking for messages sent to /var/log/maillog and then running

$ sendmail -?

which runs sendmail with invalid parameters shows this fatal message being logged almost instantly:

fatal: usage: sendmail [options]

Why not just use the logger command?

e.g.

logger "Another message"

You seem to be over complicating things: why redirect stderr to stdin

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?

sudo echo ... | ... doesn't work the way you probably intend. The sudo only applies to echo, not the second command. You could use instead: sudo logsave -a logfile command_with_parameters &>/dev/null

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.

Dunno, I thought I had explained the

sudo echo "Another message" 2>&1 | logsave /var/log/messages -

Causing an error in tail -f /var/log/messages.

On further reflection (and Googling) I have discovered it was awk that was buffering, not the pipe. Apparently when awk is in a pipeline it stops being in "interactive" mode. This can be fixed using awk -W interactive

For a simple example:

In one bash shell terminal:

$ tail -f /var/log/messages | awk -- '{ print $0 }'

In another:

$ logger "Another message."

You will see nothing until you repeat the same command many times. Then you will see it all burst out in one go. (Less repeats if you use use a longer message.)

However, this command produces an immediate response.

$ tail -f /var/log/messages | awk -W interactive -- '{ print $0 }'

This applies to journalctl -f, too.

So something new learnt :-) (or possibly even relearnt, for me anyway)

However, I'm not yet convinced this is a sensible way of observing events. I'm still undecided.

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