I think this will work??

On Friday, December 22, 2023 at 9:38:15 AM UTC-6, John Larkin wrote:
> >http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
> That has to work. Maybe delete R3. Any low-threshold, low Rds-on pfet 
> will work.
Well, one would think, but some of the MOSFETs I modeled dropped as much as 0.25 Volts.  Others modeled to be less than 0.06 volts.  The spec sheet says the threshold of the PMV28XPEA is between -0.6 and -1.3V and the Rds-on at 5A is a max of 50ma (less at cooler temperatures), both of which are pretty low.  Of course, I agree with you it SHOULD work, but I am a nervous sort of guy, I guess, when I am not certain of something.

R3 is just a safety measure to make sure nothing spurious triggers the LED.  It isn't really necessary, of course, but I habitually provide stray current protection whenever I a dealing with semiconductors.  Admittedly, diodes are pretty immune.  I have been caught a couple of times when I did not short the base / emitter or gate /source of a transistor.  It was amusing watching my flashlight slowly turn on all by itself, I must say.

On Friday, December 22, 2023 at 1:08:52 PM UTC-6, Lasse Langwadt Christensen wrote:
> easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers 
> 
> with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio 
> that turning off the power is safe

No, this is a watchdog.  It must be separate from the Pi.  If the Pi locks up - which happens a lot - then the code is no longer running.  In addition, there are states monitored by the Arduino of which the Pi knows nothing.

On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
> The point is that you (the OP) has to THINK about whether 
> or not the rPi can just be "unceremoniously" powered on/off.
Obviously.  Again, this is a watchdog.  If the Arduino determines the Pi has locked up, it reboots it.  SOP for a watchdog circuit.

On Friday, December 22, 2023 at 11:15:28 AM UTC-6, Fred Bloggs wrote:

> > http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
> Scrap that archaic and unnecessary power hog opto. Use this instead: 
Well, first of all, why would I scrap something I can use and for which I have already paid?  Secondly, the opto-coupler only uses a couple of milliamps, at most, and that only if I reduce the size of R4.  (Which, actually, I think I will just to be safe.)  That is nothing compared to the maximum 5 amperes the circuit has to handle.  Finally, the opto-coupler is going to be completely dead more than 99% of the time.  It will only be energized for about 10 seconds or so whenever it shuts down the Pi, which more than likely will be less than once a week.  That was deliberate.  Initially I was going to use anormally-on SPST relay, but they are too large and expensive.
> 
> https://www.amazon.com/Chanzon-N-Channel-Bipolar-Junction-Transistor/dp/B083TNW1M1/ref=sr_1_1_sspa?th=1 
Yeah, I have some 2N3904 transistors, and a few others. See above.
> 
> If 1.8R is representative of the RP circuit, which is nearly 3 Amps, then you have to stay with the PMV28XPEAR, a great part for the application. RDS max is 38mR, making power dissipation 3^2 x 0.038= 350 mW which with a max Rtheta,j-a in standard footprint, makes for .350 x 245 K/W= 83oC junction temperature rise. Tjmax of 175oC means your max operating environment is 175-83= 91oC= 200oF, which should be okay, unless it's under a car hood or something like that. Just don't put it near anything that can be damaged by the heat- like the circuit board.

It's worse than under a car hood, unfortunately.  It's outside.  In South Texas. (And potentially other very hot places.)  In direct sunlight.  In an air-tight enclosure.  The board has a 12V, high speed fan, and a drive for a Peltier cooler.

On Friday, December 22, 2023 at 12:45:55 PM UTC-6, Don Y wrote:
> *Why* do you want to remove power from the rPi? Are you trying to 
> *conserve* power?

No.  The entire system may use up to several thousand watts. (On AC line power, of course, not on 5VDC )  The Pi's power use is immaterial.

> Ensure a "restart from POST"?

No

>Deactivate the rPi regardless of what it may be doing at the time? etc.

Yes, although usually it won't be doing anything.  It will have suffered a kernel panic, or something.  The watchdog removes power for a few seconds and then restorers it.  The Arduino will also permanently disable the Pi if the environmental temperature goes too high.  A few times last year the temperatures in the case rose to over 70C.

> If trying to conserve power, have you looked at total power consumption 
> when the rPi is running vs. held in reset?

No, but the opto-coupler only users a couple of milliamps when energized.

> If trying to ensure a restart or unconditionally deactivate the 
> rPi, forcing reset can also do the trick.

How? The kernel has panicked (or something), and the Pi is locked up.  Other than removing power, how am I to reset it?

> Be sure to consider the case where the Arduino is powering *up* 
> and the GPIO(s) will likely be indeterminate (e.g., external pullup 
> in input mode -- causing your rPi to be OFF until the Arduino 
> can successfully start, set the GPIO to output mode AND drive 
> it low (to enable the rPi).

Yes, of course.  That is all part of the startup.  The first line in the Arduino code will set up the pim and drive the GPIO low.  Obviously, I can't do anything about anything until then.  If the Pi's operation is delayed by a few seconds, c'est la vie.
 
> Also, if the rPi is doing something of value,

When the Pi is locked up, the "value" of its operations are moot.  Getting it back online is the only issue at hand.  The last time the system locked up, the guy was away, and it took over a week for him to come back and unplug and re-plug the power.

> consider any 
> synchronization issues that may be part of the Arduino 
> interaction (e.g., if you just power it on/off, there is 
> no guarantee it will "remember" particular data values 
> correctly; memory and I/O cycles will be "abused")

They are not synchronized.  Operation is asynchronous.  The Arduino monitors two lines from the Pi.  One is toggled continuously by software every few milliseconds.  If the toggling stops, the Arduino assumes the Pi has stopped functioning and kills power.  The second line is held low by the Pi until it wants to disable the Arduino, presumably because the Pi wants to shut down or perform maintenance.  This sends the Arduino into a permamnet loop, insuring it will never kill power.  The only way to re-enable the watchdog is to manually restart the Arduino.

Here are pictures of the current board design:
http://siliconventures.net/images/Raspberry%20Pi%20Board%20Top.JPG
http://siliconventures.net/images/Raspberry%20Pi%20Board%20Bottom.JPG

On 12/22/2023 11:13 PM, rhor...@gmail.com wrote:
> On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
>> The point is that you (the OP) has to THINK about whether
>> or not the rPi can just be "unceremoniously" powered on/off.
> Obviously.  Again, this is a watchdog.

"Again"?  I don't see that mentioned in your post.

> If the Arduino determines the Pi has locked up, it reboots it.  SOP for a watchdog circuit.

Why does YOUR watchdog need to cycle power instead of
asserting RESET?

How are you sure the Arduino can function well-enough to
be able to detect an *apparently* failed rPi?  (are you sure the
rPi can't fail in a manner that the Arduino mistakes as being
operational?)  Why is the Arduino circumspect but the rPi, not?
(i.e., perhaps the rPi is a poor choice for the application)

Is the flaw in your hardware?  Or, software?

Needing a watchdog is usually a sign of a problem elsewhere
in the design.  Especially as a means of indicating that the
watchdog has been active is usually needed for users to
determine that the product has likely failed to perform it's
required duties.  Imagine how useful a self-reseting fuse
would be to a user... how would he know that something was wrong
if faults were never made known to him?

On 12/23/2023 12:53 AM, rhor...@gmail.com wrote:
> On Friday, December 22, 2023 at 12:45:55 PM UTC-6, Don Y wrote:
>> *Why* do you want to remove power from the rPi? Are you trying to 
>> *conserve* power?
> 
> No.  The entire system may use up to several thousand watts. (On AC line
> power, of course, not on 5VDC )  The Pi's power use is immaterial.
> 
>> Ensure a "restart from POST"?
> 
> No
> 
>> Deactivate the rPi regardless of what it may be doing at the time? etc.
> 
> Yes, although usually it won't be doing anything.  It will have suffered a
> kernel panic, or something.  The watchdog removes power for a few seconds
> and then restorers it.

A reset is insufficient?

(What you've described is "Ensuring a restart from POST".)

Have you quantified how often this is *expected* to occur?  The
distribution of expected failure events?

(average interarrival time of wombats)

And, determined that your remedy will "fix" the problem -- without
it immediately reoccurring?  Presumably, the rPi adds value to the
design so one would assume you would want it to be operational
more often than not.

> The Arduino will also permanently disable the Pi if
> the environmental temperature goes too high.  A few times last year the
> temperatures in the case rose to over 70C.

Then either figure out how to alter the operating environment
or change the approach to the problem.

Or, as the Arduino seems to be TRUSTED to operate in those
extremes, let *it* do the work of the rPi.

>> If trying to ensure a restart or unconditionally deactivate the rPi,
>> forcing reset can also do the trick.
> 
> How? The kernel has panicked (or something), and the Pi is locked up.  Other
> than removing power, how am I to reset it?

You haven't indicated WHICH rPi you are using.  Try bringing RUN to
ground.

>> Be sure to consider the case where the Arduino is powering *up* and the
>> GPIO(s) will likely be indeterminate (e.g., external pullup in input mode
>> -- causing your rPi to be OFF until the Arduino can successfully start,
>> set the GPIO to output mode AND drive it low (to enable the rPi).
> 
> Yes, of course.  That is all part of the startup.  The first line in the
> Arduino code will set up the pim and drive the GPIO low.  Obviously, I can't
> do anything about anything until then.  If the Pi's operation is delayed by
> a few seconds, c'est la vie.

You can design it so that the rPi defaults to being off -- in the event
that the Arduino isn't present or powered.  Or, on -- whichever case you
choose.  Presumably, the rPi talks to "something(s)"... are you
sure it will "behave" when crashed?

Most GPIOs default to inputs until programmed otherwise.  Many
have light pullups to ensure that -- as inputs -- they are at
a predictable input level.  You can exploit this to ensure the
output is sourcing current (through the internal pullup
potentially augmented with an external discrete) and the Arduino
has to *counter* that action.

[I would assume you would want the rPi to default to OFF as
the Arduino can also crash and fail to *actively* reset the
rPi]

>> Also, if the rPi is doing something of value,
> 
> When the Pi is locked up, the "value" of its operations are moot.  Getting
> it back online is the only issue at hand.  The last time the system locked
> up, the guy was away, and it took over a week for him to come back and
> unplug and re-plug the power.

How do you know it won't lock up AGAIN after the guy *leaves*?
If you don't care about availability, then why worry about
ANY lockups?

>> consider any synchronization issues that may be part of the Arduino 
>> interaction (e.g., if you just power it on/off, there is no guarantee it
>> will "remember" particular data values correctly; memory and I/O cycles
>> will be "abused")
> 
> They are not synchronized.  Operation is asynchronous.  The Arduino monitors
> two lines from the Pi.  One is toggled continuously by software every few
> milliseconds.  If the toggling stops, the Arduino assumes the Pi has stopped
> functioning and kills power.  The second line is held low by the Pi until it
> wants to disable the Arduino, 

So, the output i guaranteed to sink current even when the rPi is crashed?

> presumably because the Pi wants to shut down
> or perform maintenance.  This sends the Arduino into a permamnet loop,
> insuring it will never kill power.  The only way to re-enable the watchdog
> is to manually restart the Arduino.

So the Arduino is acting as nothing more than a CPU monitor (?)

> Here are pictures of the current board design: 
> http://siliconventures.net/images/Raspberry%20Pi%20Board%20Top.JPG 
> http://siliconventures.net/images/Raspberry%20Pi%20Board%20Bottom.JPG

On Saturday, December 23, 2023 at 2:25:21 AM UTC-6, Don Y wrote:
> On 12/22/2023 11:13 PM, rhor...@gmail.com wrote: 
> > On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote: 
> >> The point is that you (the OP) has to THINK about whether 
> >> or not the rPi can just be "unceremoniously" powered on/off. 
> > Obviously. Again, this is a watchdog.
> "Again"? I don't see that mentioned in your post.
Not in the original post, no, but in  more than one reply above.

> > If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit.
> Why does YOUR watchdog need to cycle power instead of 
> asserting RESET? 

RESET on the PI, in hardware, you mean?  AFAIK, there is no such thing.  In fact, I am almost certain of it, as it is one of the most requested things for the Pi over the years.  I think the new Ri 5 has a reset button, not a pin, but in any case, it is unlikely Pi 5s are going to be used with this any time soon.  Watchiing a GPIO pin in software suffers the same frailty as any other software.  It is terminated during a kernel panic.

> How are you sure the Arduino can function well-enough to 
> be able to detect an *apparently* failed rPi? (are you sure the 
> rPi can't fail in a manner that the Arduino mistakes as being 
> operational?)

Not 100%, of course.  So what?  SOMETHING is wrong on the Pi, and rebooting should clear it.  If not, then something other than a simple kernel panic is going on, and the system needs to be taken in for maintenance.  If this were going into space, then triple-redundancy would be in order, with at a minimum two independent CPUs running the same software.  This is a hobbyist platform that needs to come in under $50.  What do you expect?

> Why is the Arduino circumspect but the rPi, not? 

The two are independent, running completely different software.  In addition, the software on the Arduino is vastly less complex.  All it does is monitor two GPIO lines for simple, unintelligent pulses and control a third GPIO line.  'A few dozen lines of code, at most.  The software on the Pi is comprisedof tens of thousands or perhaps even hundreds of thousands of lines of code dealing with innumerable interrupts and tons of I/O.

> (i.e., perhaps the rPi is a poor choice for the application)

It's not my choice.  I didn't write it.  It is only supported on the Raspberry Pi and the Beaglebone.

> Is the flaw in your hardware? Or, software? 

Who knows?  One would suspect the software, since none of my Raspberry Pis running other software3 has exhibited the behavior, and every version of Raspberry Pi I have used has exhibited the behavior.  It has gotten better through the years, but still persists in Version 5.5.  Version 7.2 is out, and after Christmas I am going to see if it still has the issue, assuming it not to be the hardware, of course.  It's not that big of an issue, however.  Watchdog timers are nothing new.

> Needing a watchdog is usually a sign of a problem elsewhere 
> in the design.

Not so much.  Systems that run 24/7 can always encounter issues.  Our Nortel OPS cost over $20,000 each, and they had watchdog timers to make sure nothing, not even someone accidentally typing `shutdown -h`, would take the system down "permanently".  It is an inexpensive and fairly reliable means of hardening a system.

> Especially as a means of indicating that the 
> watchdog has been active is usually needed for users to 
> determine that the product has likely failed to perform it's 
> required duties.

Not at all.  Stuff happens.  When it does, the system can, if required make a reasonable effort to handle it.  Engineering is never about perfection.  It is always about meeting the needs in an economical way.  $10 worth of hardware is cheap insurance that will eliminate 90% or more of bothersome issues.

> Imagine how useful a self-reseting fuse 
> would be to a user... how would he know that something was wrong 
> if faults were never made known to him?

I don't have to imagine.  Apparently you are unaware the Raspberry Pi and many, many other products *DO* have PPTC fuses that automatically self-reset.  Mouser has hundreds of thousands of them in stock in more than 3400 different sizes and footprints.

lørdag den 23. december 2023 kl. 12.49.23 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 2:25:21 AM UTC-6, Don Y wrote: 
> > On 12/22/2023 11:13 PM, rhor...@gmail.com wrote: 
> > > On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote: 
> > >> The point is that you (the OP) has to THINK about whether 
> > >> or not the rPi can just be "unceremoniously" powered on/off. 
> > > Obviously. Again, this is a watchdog. 
> > "Again"? I don't see that mentioned in your post.
> Not in the original post, no, but in more than one reply above.
> > > If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit. 
> > Why does YOUR watchdog need to cycle power instead of 
> > asserting RESET?
> RESET on the PI, in hardware, you mean? AFAIK, there is no such thing. In fact, I am almost certain of it, as it is one of the most requested things for the Pi over the years.

run_pg is reset, global_en controls the powersupply chip

On a sunny day (Fri, 22 Dec 2023 22:08:50 -0800 (PST)) it happened
"rhor...@gmail.com" <rhorerles@gmail.com> wrote in
<12a3578e-2b70-49f3-b5d3-0d0cb2f5f287n@googlegroups.com>:

>On Friday, December 22, 2023 at 1:08:52&#8239;PM UTC-6, Lasse Langwadt Ch=
>ristensen wrote:
>> easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are stand=
>ard drivers 
>> 
>> with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff s=
>ignals via gpio 
>> that turning off the power is safe
>
>No, this is a watchdog.  It must be separate from the Pi.  If the Pi locks =
>up - which happens a lot - 

Pis do not normally lock up, I am posting this from a Pi4 8GB
raspberrypi: ~ # uptime
 13:17:17 up 103 days, 20:53, 13 users,  load average: 1.37, 1.25, 0.72

It is online, posting this from it, runs many applications, a.o. firefox webbrowser,
music players, drives LED strips, what not..
using it to write C code and compile and test it 
Has a 4 TB harddisk connected to it too,
There must be something wrong with your code or hardware.
I have older Pis that had even longer uptimes, like almost a year until I had to disconnect it when I moved house...
But.. all run from an UPS.
Mains dips  will kill a Pi, maybe that is it?
There is also an IR camera module hanging from the GPIO on this one.