Electronics-Related.com
Forums

I think this will work??

Started by rhor...@gmail.com December 22, 2023
On Saturday, December 23, 2023 at 2:47:59 AM UTC-6, Don Y wrote:

> A reset is insufficient?
Again, via what means? Telekenesis?
> (What you've described is "Ensuring a restart from POST".)
Well, OK. I don't care whether the Pi reboots from POST or from a saved image, as long as any issues are cleared.
> Have you quantified how often this is *expected* to occur? The > distribution of expected failure events?
To you? No. The systems in question in past years failed once a week or sometimes more. Now they fail once every month or two. Some less, some more often? hey fail invariably if certain attached equipment loses power.
> And, determined that your remedy will "fix" the problem -- without > it immediately reoccurring?
No. Again, so what? In fact, I know it *WILL* sometimes automatically recur. Occasionally the power has needed to be shut down twice or one a couple of occasions twice before the Pi recovers. The Arduino will take care of that. In teh past, it was not unusual for the micro-SD card to become corrupted when the Pi shuts down. When that happens, the system is tost anyway until a new SD card is inserted. About 2 releases ago, they seem to have fixed that issue, but if it hapens again, it happens. Nothing can automatically fix that in this arena.
> Presumably, the rPi adds value to the > design so one would assume you would want it to be operational > more often than not.
That is an understatement. Many people run these systems entirely on a single Pi, and even those who use multiple Pis have a single master that runs all the rest. When that is down, the entire system fails. Most people at this point just put up with it, and go outside and unplkug the Pi and plug it back in. Some shut off the Pi during the day, and restart it every night. That mostly eliminates the issue for them, but many, like me, run 24/7.
> > 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.
At this point, I am almost compelled to ask you, "Who died and made you Pope? I will handle it the way I choose, thank you. In particular, this board supports a high speed fan and a Peltier cooler or other 12V, 5A cooling system. Tht has not been the most common issue, however, and in any case has nothing to do woith my original question. I thank you for your input, but I have already taken care of the other issues in a reasonable fashion.
> Or, as the Arduino seems to be TRUSTED to operate in those > extremes, let *it* do the work of the rPi.
It won't. It can't. Not even close. The software takes up at a bare minimum 4 Gigabytes. Some deployments take more. It runs poorly on a single CPU, if at all in some cases. Sixteen Gigs of storage minimum is suggested and at least 512M of RAM. The Arduino I am using has a total of less than 50 Kilobytes of RAM total, and no external storage. It also has no Wifi and no Ethernet, and both are required, as well as multiple USB ports. It's amazing that a $35 SBC canhandle this much, but a $4 MCO won't, and that is no surprise.
> >> If trying to ensure a restart or unconditionally deactivate the rPi, > >> forcing reset can also do the trick.
You keep saying that. How? The Pi has no hardware reset, at least not up until the Pi 5, and I am unsure of its' having one.
> > 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.
Are youj talking about the Pico? No, this software is Linux based, and runs on the Raspberry Pi models A & B and the Pi ZeroW. There is no RUN pin.
> You can design it so that the rPi defaults to being off -- in the event
Why would I do that? It's more complicated.
> 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?
No, it doesn't always. Stuff happens. In more than 99% of cases, it means it won't boot, at all. I suppose it is possible, but I have never had one fail and yet still be able to handle TCP/IP over WLAN and Ethernet. What if it does, however? How should I amticipate that in a way the developers will choose to support and yet won't cost a fortune? Hell, my main servers are not *THAT* robust. Whan something croaks, I fix it. ' Worst case, I stick in a new micro-SD card, unless the Pi itselfhas failed (I have only had that happen twice) and then I replace the Pi.
> Most GPIOs default to inputs until programmed otherwise. Many
I don't know about the Arduino. I have never checked. If it does, it does. So what? So it takes a few seconds longer to boot up? That is much better than being down for a week until someone can go reboot the Pi.
> [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]
'Not preferably. I don't want the system to fail just because the watchdog has failed. A system whose watchdog fails with no impact is no worse off than a system with mo watchdog. It is preferable a peripheral that is designed to linmit failures does not itself present an additional failure mode.
> How do you know it won't lock up AGAIN after the guy *leaves*?
What guy? With the watchdog, there won't BE any guy. That is the whole point.
> If you don't care about availability, then why worry about > ANY lockups?
A system which is available more than 99% of the time but only costs a few dollars more is FAR preferable to one which may be down for 5%, 10%, or perhaps even 20% of the time. This is why essentially all telecommunications systems have diverse paths at consideraby more than twice the cost of single-path equipment. They still haev failures, but far, far less often.
> So, the output i guaranteed to sink current even when the rPi is crashed?
A few milliamperes, yes. That and the attached peripheral equipment draws quite a few watts at idle. Again so what?
> So the Arduino is acting as nothing more than a CPU monitor (?)
Yes. It could be purposed to do more, but I have no intent for such at this time. MCUs are great for handling such minor tasks.
On Saturday, December 23, 2023 at 6:26:40 AM UTC-6, Lasse Langwadt Christensen wrote:
> > 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
I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here: https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg
lørdag den 23. december 2023 kl. 14.03.40 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 2:47:59 AM UTC-6, Don Y wrote: > > > A reset is insufficient? > > Again, via what means? Telekenesis? > > (What you've described is "Ensuring a restart from POST".) > Well, OK. I don't care whether the Pi reboots from POST or from a saved image, as long as any issues are cleared. > > Have you quantified how often this is *expected* to occur? The > > distribution of expected failure events? > To you? No. The systems in question in past years failed once a week or sometimes more. Now they fail once every month or two. Some less, some more often? hey fail invariably if certain attached equipment loses power. > > And, determined that your remedy will "fix" the problem -- without > > it immediately reoccurring? > No. Again, so what? In fact, I know it *WILL* sometimes automatically recur. Occasionally the power has needed to be shut down twice or one a couple of occasions twice before the Pi recovers. The Arduino will take care of that. In teh past, it was not unusual for the micro-SD card to become corrupted when the Pi shuts down. When that happens, the system is tost anyway until a new SD card is inserted. About 2 releases ago, they seem to have fixed that issue, but if it hapens again, it happens. Nothing can automatically fix that in this arena. > > Presumably, the rPi adds value to the > > design so one would assume you would want it to be operational > > more often than not. > That is an understatement. Many people run these systems entirely on a single Pi, and even those who use multiple Pis have a single master that runs all the rest. When that is down, the entire system fails. Most people at this point just put up with it, and go outside and unplkug the Pi and plug it back in. Some shut off the Pi during the day, and restart it every night. That mostly eliminates the issue for them, but many, like me, run 24/7. > > > 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. > At this point, I am almost compelled to ask you, "Who died and made you Pope? I will handle it the way I choose, thank you. In particular, this board supports a high speed fan and a Peltier cooler or other 12V, 5A cooling system. Tht has not been the most common issue, however, and in any case has nothing to do woith my original question. I thank you for your input, but I have already taken care of the other issues in a reasonable fashion. > > Or, as the Arduino seems to be TRUSTED to operate in those > > extremes, let *it* do the work of the rPi. > It won't. It can't. Not even close. The software takes up at a bare minimum 4 Gigabytes. Some deployments take more. It runs poorly on a single CPU, if at all in some cases. Sixteen Gigs of storage minimum is suggested and at least 512M of RAM. The Arduino I am using has a total of less than 50 Kilobytes of RAM total, and no external storage. It also has no Wifi and no Ethernet, and both are required, as well as multiple USB ports. It's amazing that a $35 SBC canhandle this much, but a $4 MCO won't, and that is no surprise. > > >> If trying to ensure a restart or unconditionally deactivate the rPi, > > >> forcing reset can also do the trick. > You keep saying that. How? The Pi has no hardware reset, at least not up until the Pi 5, and I am unsure of its' having one. > > > 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. > Are youj talking about the Pico? No, this software is Linux based, and runs on the Raspberry Pi models A & B and the Pi ZeroW. There is no RUN pin.
https://static.packt-cdn.com/products/9781786467577/graphics/image_11_024.png https://raw.githubusercontent.com/raspberrypisig/raspberrypisig.github.io/master/assets/images/rpi3runheader.jpg https://i.stack.imgur.com/mwnCX.jpg
lørdag den 23. december 2023 kl. 14.11.31 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 6:26:40 AM UTC-6, Lasse Langwadt Christensen wrote: > > > 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 > I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here: > https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg
top left corner of the board, "Run Header Used to Reset the PI"
On Saturday, December 23, 2023 at 1:34:00 AM UTC-5, rhor...@gmail.com wrote:
> 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.
You can't use that little PFET. This part has better thermal characteristics and current handling, and will do just as well: PSMP033-60YEX https://assets.nexperia.com/documents/data-sheet/PSMP033-60YE.pdf Costs 1.29 vs 0.42, but at least it will last. And it should endure just fine in free air with your fan. Doesn't save you anything to buy a cheap part not suited for the application. https://www.mouser.com/ProductDetail/Nexperia/PSMP033-60YEX?qs=zW32dvEIR3swNYsggPhu%252BQ%3D%3D On another note, your opto selection isn't even characterized for input drive less than 2mA. Don't believe the simulation. Ditch it.
On Saturday, December 23, 2023 at 6:27:35 AM UTC-6, Jan Panteltje wrote:
> >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
Not usually, no. I have dozens of them running 24/7, and most do not lock up very often, at all. It seems to be this software that is a bit wonky. As part of this recent project, I found out that the Pis running it reboot every few hours or so. Apparently, every once in a while, they fail to recover. The systems running this software vary a great deal. The one here at my house is a 3B+ with a 250G SSD and a 32G SD card. The one I am testing is running on a Zero W with a 16G SD card. The only other thing directly attached is a 3.3 - 5V level shifter attached to pin 2 (GPIO 18), and of course the po5V power supply.
> It is online, posting this from it, runs many applications, a.o. firefox webbrowser,
This application is by design headless. If it finds any working IP ports, it announces their IP addresses over the audio port. If not, it brings up a default tether on 192.168.8/24.
> There must be something wrong with your code or hardware.
It's not my code. Since it happens on all types of Pis in all sorts of situations I expect it is not the hardware, but I am investigating.
> I have older Pis that had even longer uptimes, like almost a year until I had to disconnect it when I moved house...
Hmm, this is interesting. All the Pis inside my house except three are powered via POE from a Cisco 3560-E. I didn't know this previously, but they all rebooted six days ago. Something must have burped on that switch. The three that are locally powered have been up 23 days, 203 days, and 557 days, respectively. All of them are running software I wrote, incidentally.
> But.. all run from an UPS. > Mains dips will kill a Pi, maybe that is it?
No, the one here at my house is on a battery that lasts over 48 hours when power fails. It isn't exactly a UPS, because it only supplies 12VDC and 5VDC. This is the board I use with it: http://siliconventures.net/images/Raspberry%20Pi%20UPS%20Top.JPG http://siliconventures.net/images/Raspberry%20Pi%20UPS%20Bottom.JPG It is a Pi3B+ (needed for 5GHz WiFi), and it sits in a much larger enclosure with a 5 port Ethernet switch, an FM transmitter, two 120mm fans, and a very large heat sink.
On Saturday, December 23, 2023 at 7:17:51 AM UTC-6, Lasse Langwadt Christensen wrote:
> > I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here: > > https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg > top left corner of the board, "Run Header Used to Reset the PI"
Ah, OK. 'Didn't know about that one. Do you know if it is monitored by software, or if it does a hard reset on the CPU? If it is guaranteed to reset the CPU even after a kernel panic, then that would indeed be a good choice, and much simpler. I can create a dual-use board and populate it only with a MOSFET to short those pins and see if it works. Otherwise, I can go ahead and add the power interrupter after the fact. Thanks!
lørdag den 23. december 2023 kl. 15.07.35 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 7:17:51 AM UTC-6, Lasse Langwadt Christensen wrote: > > > I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here: > > > https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg > > top left corner of the board, "Run Header Used to Reset the PI" > Ah, OK. 'Didn't know about that one. Do you know if it is monitored by software, or if it does a hard reset on the CPU? If it is guaranteed to reset the CPU even after a kernel panic, then that would indeed be a good choice, and much simpler. I can create a dual-use board and populate it only with a MOSFET to short those pins and see if it works. Otherwise, I can go ahead and add the power interrupter after the fact. Thanks!
it is power good from the supply chip connected to reset of the CPU, so it should be similar to removing power
On Saturday, December 23, 2023 at 7:37:23 AM UTC-6, Fred Bloggs wrote:
> You can't use that little PFET.
Why not? The part is rated for up to 5A continuous and up to 610mW with no heat sink (25C ambient) and 1.4W with a 6cm² copper trace attached to the drain. In my case, it's more like 3cm², but since the FET will be constantly saturated at less than 0.1V and the continuous current should be under 1.5A or even less, I don't expect it should be an issue. That is even if I use it in the way I was originally intending. I just found out there is a RUN jumper which may serve the purpose, and that will obviously use at most a couple of mA.
>This part has better thermal characteristics and current handling, and will do just as well: > > PSMP033-60YEX > > https://assets.nexperia.com/documents/data-sheet/PSMP033-60YE.pdf > > Costs 1.29 vs 0.42, but at least it will last. And it should endure just fine in free air with your fan.
Uh, no, that is $1.29 vs. $0.076. That is a factor of almost 1700%, and a real issue for me in my situation right now.
> Doesn't save you anything to buy a cheap part not suited for the application.
Normally, I would heartily agree, but right now I have literally ZERO money. I am going tol have a very hard time even scraping up the funds for the $50 it is going to cost for prototyping.
> https://www.mouser.com/ProductDetail/Nexperia/PSMP033-60YEX?qs=zW32dvEIR3swNYsggPhu%252BQ%3D%3D > > On another note, your opto selection isn't even characterized for input drive less than 2mA. Don't believe the simulation. Ditch it.
OK, I am already intending to drop the resistor value to 1K, or 3.3mA. I have used these before at 0.5mA with no problems. Needing to go above 2mA is not a good argument for ditching them.
On Fri, 22 Dec 2023 22:04:20 -0800 (PST), "rhor...@gmail.com"
<rhorerles@gmail.com> wrote:

>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.
Life is risky, but I wouldn't worry about that fet working. I am reckless sort of guy, which averages out more upside than down.
> >R3 is just a safety measure to make sure nothing spurious triggers the LED.
Use a big capacitor if spikes are possible!
>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.
Bipolar transistors are reliably off with the base open, at least at survivable temperatures. Still, we use resistors. Mosfets can be fun. Connect a 2N7000 and a 9v battery and a resistor and an LED, gate floating. Briefly touch +9 to the gate. The LED turns on and stays on. Or ground the gate briefly and the LED goes off. That lasts for a week or so. Extra credit: Touch drain to gate. Then use a pencil or a small screwdriver to transfer small packets of charge into/out of the gate. https://www.dropbox.com/s/i1sw7shpex29wf1/2N7000.jpg?raw=1 There's an interesting tap-toggle on/off circuit too, a single-mosfet T flipflop.