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.

On Fri, 22 Dec 2023 22:33:55 -0800 (PST), "rhor...@gmail.com"
<rhorerles@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.

I designed an acoustic monitor system for MTF, the NASA rocket test
site in Mississippi, with the boxes up on telephone poles. The big
hazard wasn't temperature or humidity, it was the locals shooting at
them just for fun.

We were accused of spurious low frequency oscillations, which turned
out to be the subsonic mating calls of bull alligators.

On Saturday, December 23, 2023 at 9:45:17 AM UTC-6, John Larkin wrote:
> I designed an acoustic monitor system for MTF, the NASA rocket test
> site in Mississippi, with the boxes up on telephone poles. The big
> hazard wasn't temperature or humidity, it was the locals shooting at
> them just for fun.

Well, in Mississippi - AKA Redneck Central, what else did you expect? :-)
> We were accused of spurious low frequency oscillations, which turned
> out to be the subsonic mating calls of bull alligators.

Well, in Mississippi - AKA Gator Central, what else did you expect? :-)

On Saturday, December 23, 2023 at 9:37:24 AM UTC-6, John Larkin wrote:
> 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.

Given the excellent feedback here, I have come up with a dual-pronged solution. For the prototypes at least, I am going to add a 5 pin header. Short the 2nd and third pin and run a wire jumper over to the RUN traces on the Pi, and the system will attempt to shut down the Pi using its RUN utility. I also put in a large header to short the isolated 5V pad to the main 5V pad, pr3eventing the FET from doing anything. Remove the large shunt and short the two left-most pins on the header, and the Arduino will attempt a shutdown by cutting the power. See below:
http://siliconventures.net/images/Raspberry%20Pi%20Board%20Universal%20Top.JPG
http://siliconventures.net/images/Raspberry%20Pi%20Board%20Universal%20Bottom.JPG

> I am reckless sort of guy, which averages out more upside than down.
When I was young, yeah. Not any more.

> Bipolar transistors are reliably off with the base open, at least at
> survivable temperatures. Still, we use resistors.

I did once have a case where a high gain BPJ transistor leaked from collector to emitter. Since then I have always added a safety.
> Mosfets can be fun.

Oh, yeah.

On a sunny day (Sat, 23 Dec 2023 05:58:19 -0800 (PST)) it happened
"rhor...@gmail.com" <rhorerles@gmail.com> wrote in
<ad682ac8-9b13-4c38-afcc-505e8e0d7072n@googlegroups.com>:

>On Saturday, December 23, 2023 at 6:27:35 AM UTC-6, Jan Panteltje w=
>rote:
>> >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 rec=
>over.
>
>The systems running this software vary a great deal. The one here at my ho=
>use is a 3B+ with a 250G SSD and a 32G SD card. The one I am testing is ru=
>nning on a Zero W with a 16G SD card. The only other thing directly attach=
>ed is a 3.3 - 5V level shifter attached to pin 2 (GPIO 18), and of course t=
>he 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 sit=
>uations 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 pow=
>ered 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 day=
>s, 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 5V=
>DC. 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

Nice boards

I usually just solder something together, some GPIO examples here:
https://panteltje.online/panteltje/xgpspc/index.html

That is an old raspi, lemme see:
https://panteltje.online/panteltje/raspberry_pi_dvb-s_transmitter/
was too big to fit as a 'hat' in the raspi housing.
Several more projects here....

>It is a Pi3B+ (needed for 5GHz WiFi), and it sits in a much larger enclosur=
>e with a 5 port Ethernet switch, an FM transmitter, two 120mm fans, and a v=
>ery large heat sink.

Yes I have 2 ethernet switches on my Pi 4 GB, ethernet cables go all over the house.

Best and most fun is to write your own code... design your own hardware.

Did your log files show anything about why it crashed?
You could make it report to some file?

On 12/23/2023 6:13 AM, Lasse Langwadt Christensen wrote:

[Apologies to Lasse as my reply is intended for rhorerles but my server
has decided not to show me that post. :< ]

> 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?

Um, maybe via the hardware RESET?

New to this field, eh?

>>> (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.

Sure seems like a piss poor design. Do you tolerate many of the other items
you use ROUTINELY refusing to operate AS EXPECTED? (Or, do you simply
EXPECT this to fail, often?)

>>> 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.

Can you assure yourself (and your customers) that it will NEVER recur often
enough that it fails to perform its intended function?

Probabilistic Systems Analysis. Should be a freshman course in any
engineering curriculum...

> Occasionally the power has needed to be shut down twice or one a couple
> of occasions twice before the Pi recovers.

How do you know it won't need THREE -- or FOUR -- or COUNTLESS such
"shutdowns"? You haven't identified the cause so how can you be sure
you've got a cure?

> The Arduino will take care of that.

And the Arduino will be 100% reliable.

"Why don't they make aircraft out of the same material that they
use for their Black Boxes?"

> 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.

So, the solution *IS* the problem! "Buy two!"

> About 2 releases ago, they seem to have fixed that issue,

Who is "they"? Are you a customer or a supplier?

> but if it hapens again, it happens. Nothing can automatically fix that in this arena.

Nothing that you've apparently *tried*. Or, you've tied your hands with
a particular solution before completely exploring what's possible.

>>> 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.

So, yet another bad solution. Sure starts to sound like a HOBBYIST
approach to a problem and not an ENGINEERED solution.

> 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.

Is there some reason we can't know what it *does* that you would
be so patient with such a half-assed solution?

>>>> 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?

No one. *But*, none of my clients would accept a solution that
"sort-of, almost worked... EXCEPT when _____".

"What happens if this ______ happens while we're in surgery?"

"If this _______ happens, how long will the manufacturing line
be shut down? How OFTEN can we expect to be thusly inconvenienced?
Should we keep a live spare on hand? Should we find someone else to
design this for us??"

It's YOUR problem. Solve it whatever way you are willing to TOLERATE.
Until, of course, you decide to look for a REAL solution!

> 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.

And I've not asked or commented about them.

> 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.

Wrong answer. Code *size* has no bearing on what a "smaller"
device can/can't handle. I would routinely deploy Z80-based
products with a megabyte of code (when their entire address
space was 64KB for code+data).

> Some deployments take more. > It runs poorly on a single CPU, if at all in some cases.

You haven't hesitated to ADD an MCU so why are you afraid
of adding a second CPU?

> Sixteen Gigs of storage minimum is suggested and at least 512M of RAM.

Again, storage isn't a constraint. The rPi doesn't have a 16G
address space so you're only accessing PART of that storage at
any time. And, if on an SD card, you have a serial interface
to it. I.e., you can access a smaller portion over a similar
serial interface on a slower/smaller processor. (I designed
a 1-bit wide DRAM array in a product, accessing it 8 times
to "build" a single byte of data)

> The Arduino I am using has a total of less than 50 Kilobytes of RAM

Yes, sounds more and more like a HOBBYIST product...

> total, and no external storage. It also has no Wifi and no Ethernet,
> and both are required, as well as multiple USB ports.

Again, you've said nothing that REQUIRES an rPi or
precludes the use of something else. I've run network stacks
on PICs.

> It's amazing that a $35 SBC canhandle this much, but a $4 MCO won't, and that is no surprise.

So, $35 for something that ALMOST works. Sounds like a plan!

>>>>> 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.

Wow, you really *are* new to this, eh? You don't even know
what the device you're using can do -- yet are convinced
IT is the solution!

>>>> 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

Thanks, Lasse.

On Saturday, December 23, 2023 at 12:47:50 PM UTC-6, Don Y wrote:
>> Again, via what means? Telekenesis?

> Um, maybe via the hardware RESET?

Until two days ago, I did not know the Raspberry Pi had one. It doesn't have one on its 40 pin I/O interface, which is surprising. If I do use it, I am going to have to ask my clients to solder on their Raspberry Pi's, and a lot of these people have never held a soldering iron in their lives. 'Not exactly the best recommendation for a product, I must say. How often do you tell your clients they are going to have to take one of their own devices and solder on it?

Meanwhile, I can only notice the fact it was someone other than you who pointed out the actual location of the RUN port on the Pi and that it is not on the I/O header where a person developing a board like this has direct access to it.

> New to this field, eh?

If starting in 1972 constitutes "new", then I guess so.

> Sure seems like a piss poor design.

Talk to the developers. Since they are all volunteers and are not paid for their work, I am sure they will be happy to deal with your arrogant attitude.

Meanwhile, what, exactly, do you suggest as an alternative? It must be able to load and run Debian Linux, get updates from the internet, and cost less than $40. You also have to convince the developers to support it, and I have been unable to get them to even support the Orange Pi or similar boards. 'Not that I blamer them.

> Do you tolerate many of the other items you use ROUTINELY refusing to operate AS EXPECTED?

Yes, but then I live in the real world. Thank goodness, because if everything always worked as expected, I would not have had a job for the last 40 years.

> (Or, do you simply EXPECT this to fail, often?)

Based on historical data, yes. One of the systems went down an hour and 8 minutes ago. Fortunately, this time it recovered by itself. It doesn't always.

> Can you assure yourself (and your customers) that it will NEVER recur often
> enough that it fails to perform its intended function?

No. Does General Motors? IBM? General Electric? Microsoft? Hell, even a Rolls Royce will "fail to proceed", and it will take a good chunk out of $1 million. We are talking about free software that runs on a free operating system hosted on a $35 SBC.

> How do you know it won't need THREE -- or FOUR -- or COUNTLESS such "shutdowns"?

I know for a probable fact that will happen. Again, so what?

> You haven't identified the cause so how can you be sure you've got a cure?

When the exact cause or causes are not known, treating the symptoms frequently works well enough. This is doubly true when it is known the cause absolutely cannot be addressed. 'Sort of like there is no way for me to stop you from spouting nonsense.

>> The Arduino will take care of that.

> And the Arduino will be 100% reliable.

No. Unfortunately, you did not design the Arduino, so it is not 100% reliable </sacasm>

> "Why don't they make aircraft out of the same material that they
> use for their Black Boxes?"

I see I can rest my case.

>> 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.

> So, the solution *IS* the problem! "Buy two!"

Which solves nothing, especially since it is going to be fairly difficult to get most of the demographic to buy one.

>> About 2 releases ago, they seem to have fixed that issue,

> Who is "they"?

Who do you think? The software developers. Who else would fix software?

> Are you a customer or a supplier?

I am a customer of the software, and a potential supplier of supplemental hardware, if this works. What does it matter?

> but if it hapens again, it happens. Nothing can automatically fix that in this arena.

> Nothing that you've apparently *tried*. Or, you've tied your hands with
> a particular solution before completely exploring what's possible.

This is a product that must cost less than $50 and will probably at the very most sell perhaps 200 or so units. It is supplemental to software that only is supported to run on the Raspberry Pi and Beaglebone SBCs. Are you volunteering your time and resources to investigate and "fix the issue"? I thought not.

>> When that is down, the entire system fails.

> So, yet another bad solution. Sure starts to sound like a HOBBYIST
> approach to a problem and not an ENGINEERED solution.

It is a hobbyist product. So what? Are you suggesting there is something wrong with that? If products designed for hobbyist use are beneath your magnificence, then quit bothering to comment.

> Is there some reason we can't know what it *does*

How is that relevant to my questions? 'Not that your attitude or any of your comments compel cooperation on my part, but it is a holiday light and multimedia display primarily designed to control WS281x pixel strings. The industry as a whole, as it happens, involves many millions of dollars worldwide, but many hobbyists, such as I, indulge themselves in it.

> that you would be so patient with such a half-assed solution?

I am not patient. I do recognize when a "solution" is not worth the time, cost, and effort.

> No one. *But*, none of my clients would accept a solution that
> "sort-of, almost worked... EXCEPT when _____".

Well, bully for you. I don't know who your clients are - nor care, really - but my professional industry (which this is not) involves trillions of dollars and billions in revenue, of which my company raked in a good 20%, and involved clients such as AT&T, Verizon (both of whom were also competitors), T-Mobile, the U.S. Department of Defense, the National Security Agency, Intel, Microsoft, and others I cannot mention. We never offered them any 100% guarantees, and some of them payed us millions a year. If I am incredibly lucky, I might make $500 off this.

> "What happens if this ______ happens while we're in surgery?"

Most of the world is not comprised of surgeons, although as it happens, a mistake of mine did once possibly contribute to the death of an infant. I am not happy about it.

> "If this _______ happens, how long will the manufacturing line be shut down?

Not even a single millisecond. But then not everyone is as wonderful as you. OTOH, when and why did this thread come to be about you and your customers? How does that apply to whether the two components I mentioned will work to my satisfaction?

> Until, of course, you decide to look for a REAL solution!

Oh, brother.

>> That has not been the most common issue, however, and in any
>> case has nothing to do woith my original question.

> And I've not asked or commented about them.

Then you are doing nothing but wasting our time.

> Wrong answer. Code *size* has no bearing on what a "smaller"
> ...
> space was 64KB for code+data).

I repeat: Oh, brother.

> Some deployments take more. > It runs poorly on a single CPU, if at all in some cases.

> You haven't hesitated to ADD an MCU so why are you afraid of adding a second CPU?

Because no one would pay the extra money. It would kill the project before it even got started.

> Sixteen Gigs of storage minimum is suggested and at least 512M of RAM.

> I.e., you can access a smaller portion over a similar

*I* am not doing anything. Linux is. Do you have a problem with people running Linux or writing software for it?

> (I designeda 1-bit wide DRAM array in a product

Yeah, we all know how wonderful you are.

> Yes, sounds more and more like a HOBBYIST product...

Yeah, so what? In the U.S. alone, the hobbyist industry accounts for over $14 billion a year in revenue. Gaming accounts for gawd knows how much worldwide. My professional work is not part of the hobbyist industry, but many hundreds of thousands of people's employment is, and this personal project is. What, exactly, is your point? How does it relate to the questions at hand?

Just out of curiosity, did you sneer at the developers of the Nintendo or Playstation?

> Again, you've said nothing that REQUIRES an rPi or
> precludes the use of something else. I've run network stacks
> on PICs.

No, I haven't, because it has absolutely nothing to do with the topic. Aside from the fact the software is only supported on one other hardware platform, this project is for a daughterboard that attaches to a Raspberry Pi. Selecting some other platform would completely eliminate the entire project. 'Satisfied?

> So, $35 for something that ALMOST works. Sounds like a plan!

No, the plan is to ignore anything else coming from you unless you can manage to bring it on-topic and ditch the attitude.

On 12/24/2023 2:41 PM, rhor...@gmail.com wrote:
> On Saturday, December 23, 2023 at 12:47:50 PM UTC-6, Don Y wrote:
>>> Again, via what means? Telekenesis?
>
>> Um, maybe via the hardware RESET?
>
> Until two days ago, I did not know the Raspberry Pi had one. It doesn't have one on its 40 pin I/O interface, which is surprising. If I do use it, I am going to have to ask my clients to solder on their Raspberry Pi's, and a lot of these people have never held a soldering iron in their lives. 'Not exactly the best recommendation for a product, I must say. How often do you tell your clients they are going to have to take one of their own devices and solder on it?

Who chose the rPi?

> Meanwhile, I can only notice the fact it was someone other than you who pointed out the actual location of the RUN port on the Pi and that it is not on the I/O header where a person developing a board like this has direct access to it.

Wow, so you're nitpicking because I told you it existed but didn't tell
you where to find it -- even before you had told me WHICH rPi you were using?

Growth the f*ck up.

>> New to this field, eh?
>
> If starting in 1972 constitutes "new", then I guess so.

And, after 50 years, you didn't know"
- processors have a RESET ability
- the product YOU (?) chose had one
Maybe the NEXT 50 years will improve upon your education...

>> Sure seems like a piss poor design.
>
> Talk to the developers. Since they are all volunteers and are not paid for their work, I am sure they will be happy to deal with your arrogant attitude.

That's an oblique way of saying they are cheap and don't want
to BUY a working design.

Is your DENTIST similarly inclined?

> Meanwhile, what, exactly, do you suggest as an alternative? It must be able to load and run Debian Linux, get updates from the internet, and cost less than $40. You also have to convince the developers to support it, and I have been unable to get them to even support the Orange Pi or similar boards. 'Not that I blamer them.

THEY decided it has to run Debian. Why should I be constrained by
their choice? What if they had equally arbitrarily decided it
should be YELLOW?

>> Do you tolerate many of the other items you use ROUTINELY refusing to operate AS EXPECTED?
>
> Yes, but then I live in the real world. Thank goodness, because if everything always worked as expected, I would not have had a job for the last 40 years.

Ah, the real world that I design in has consequences for failures and
faulty products. Cars being recalled, providers being sued, etc.
These tend to be big incentives to get things RIGHT.

Volunteers usually don't worry about these things because they aren't
the ones being sued!

>> (Or, do you simply EXPECT this to fail, often?)
>
> Based on historical data, yes. One of the systems went down an hour and 8 minutes ago. Fortunately, this time it recovered by itself. It doesn't always.

Wow, you've found a problem that's harder to solve than designing interstellar
space probes with multi decade missions!

>> Can you assure yourself (and your customers) that it will NEVER recur often
>> enough that it fails to perform its intended function?
>
> No. Does General Motors? IBM? General Electric? Microsoft? Hell, even a Rolls Royce will "fail to proceed", and it will take a good chunk out of $1 million. We are talking about free software that runs on a free operating system hosted on a $35 SBC.

They wouldn't select a $35 SBC for the solution! Or, were know how to
use it in such a way that it didn't fail.

>> How do you know it won't need THREE -- or FOUR -- or COUNTLESS such "shutdowns"?
>
> I know for a probable fact that will happen. Again, so what?

It's a "probable fact" that it will REPEATEDLY fail. So,
why not just NOT deploy it and claim the (non-deployed)
product is failing as expected and NOT providing the desired service?

Or, why not design a solution that actually works?

I.e., find smarter volunteers and "customers" that are
willing to pay more than $35 for a solution. (i.e., THAT
declares the value of your product, to the customer).

I wouldn't pay more than $35 for a doorbell. So, I guess
their problem is of similar value.

>> You haven't identified the cause so how can you be sure you've got a cure?
>
> When the exact cause or causes are not known, treating the symptoms frequently works well enough. This is doubly true when it is known the cause absolutely cannot be addressed. 'Sort of like there is no way for me to stop you from spouting nonsense.

Ah, and there's the rub. Yo' don't understand engineering so it sounds like
nonsense to you. Well, it would also sound like nonsense to a child...

>>> The Arduino will take care of that.
>
>> And the Arduino will be 100% reliable.
>
> No. Unfortunately, you did not design the Arduino, so it is not 100% reliable </sacasm>

So, you've put an unreliable monitor into a product to monitor an
unreliable design. Why not add yet another? Eventually, ONE of them
will sort out what's going on.

>> "Why don't they make aircraft out of the same material that they
>> use for their Black Boxes?"
>
> I see I can rest my case.
>
>>> 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.
>
>> So, the solution *IS* the problem! "Buy two!"
>
> Which solves nothing, especially since it is going to be fairly difficult to get most of the demographic to buy one.

So, it's not worth -- to them -- the price you are paying for the components.
Or, it isn't reliable enough to be worth that.

Sounds like your "volunteers" have a poor grasp of the problem AND the market.

>>> About 2 releases ago, they seem to have fixed that issue,
>
>> Who is "they"?
>
> Who do you think? The software developers. Who else would fix software?

You haven't said if "they" are you, a party with which you have influence or
control, a supplier or...

>> Are you a customer or a supplier?
>
> I am a customer of the software, and a potential supplier of supplemental hardware, if this works. What does it matter?

It matters to the extent that you have a stake in the decision making
process. A customer can find an alternate supplier. A supplier can
risk losing their customers due to poor design choices.

A customer that CAN'T find an alternate supplier is at the mercy of
his supplier. A supplier who can't "fix" the design is at the mercy of
the market finding an alternative that makes his efforts/investment
wasted.

A client of mine recounted a story where they sold a piece of expensive
equipment to a customer of theirs. The customer returned it, irate,
because it was obviously "hand built/wired/etc." and they didn't
consider it "made to professional standards" (whatever those are).

A few weeks later, they asked to repurchase it when they discovered
that it was the *only* product serving their small, niche market.
(Gee, no wonder it was built in quantities of *one*!)

>> but if it hapens again, it happens. Nothing can automatically fix that in this arena.
>
>> Nothing that you've apparently *tried*. Or, you've tied your hands with
>> a particular solution before completely exploring what's possible.
>
> This is a product that must cost less than $50 and will probably at the very most sell perhaps 200 or so units. It is supplemental to software that only is supported to run on the Raspberry Pi and Beaglebone SBCs. Are you volunteering your time and resources to investigate and "fix the issue"? I thought not.

Of course not. Why would I care about *your* problem? Some markets
can't be addressed under the constraints that folks would *like* to
apply. I'm sure NASA would have loved to be able to go to the moon
for a few thousand (!) dollars -- and, only a handful of times.

Can't squeeze the balloon at both ends. The desire to *go*
was greater than the desire to do so cheaply.

>>> When that is down, the entire system fails.
>
>> So, yet another bad solution. Sure starts to sound like a HOBBYIST
>> approach to a problem and not an ENGINEERED solution.
>
> It is a hobbyist product. So what? Are you suggesting there is something wrong with that? If products designed for hobbyist use are beneath your magnificence, then quit bothering to comment.

You didn't point that out at the onset of your post.
Most of us (here) design products for sale -- for folks
who understand the value of the devices that they
want to purchase. Tell us you want something on the
cheap for folks who "have short arms" and no one will
spend much time trying to understand your problem.

On Sat, 23 Dec 2023 08:47:13 -0800 (PST), "rhor...@gmail.com"
<rhorerles@gmail.com> wrote:

>On Saturday, December 23, 2023 at 9:45:17?AM UTC-6, John Larkin wrote:
>> I designed an acoustic monitor system for MTF, the NASA rocket test
>> site in Mississippi, with the boxes up on telephone poles. The big
>> hazard wasn't temperature or humidity, it was the locals shooting at
>> them just for fun.
>
>Well, in Mississippi - AKA Redneck Central, what else did you expect? :-)
>

Mostly nice people, and shrimp+grits.

>> We were accused of spurious low frequency oscillations, which turned
>> out to be the subsonic mating calls of bull alligators.
>
>Well, in Mississippi - AKA Gator Central, what else did you expect? :-)

Mosquitoes as big as chickens.