• Re: I think this will work??

    From Bill Sloman@21:1/5 to rhor...@gmail.com on Sat Dec 23 01:40:13 2023
    On 23/12/2023 12:53 am, rhor...@gmail.com wrote:
    Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actually
    A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal
    at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. I have run it in my simulator, and it works there, but there are a couple of catches. The problem is , I am using Micro-Cap 12.2, and it does not have exact matches for all
    of my components.

    In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact match
    for this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.

    A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some perform
    quite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the
    others I used in the sim are failing. Increasing the value of R5 in the sim did not increase the output voltage. Is anyone out there familiar with the PMV28XPEAR, or know of a very low cost MOSFET that would be guaranteed to work? My cost for the
    PMV28XPEAR is $0.076 each.

    http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG

    Do you actually need the opto-isolation? The switch would drive an NPN transistor into saturation when it closed, or a small N-MOSfet. You'd
    need a pull-up resistor to +5V to get the voltage swing you want, but
    it's much the same circuit with less to go wrong.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to rhorerles@gmail.com on Fri Dec 22 07:37:13 2023
    On Fri, 22 Dec 2023 05:53:24 -0800 (PST), "rhor...@gmail.com" <rhorerles@gmail.com> wrote:

    Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actually
    A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal
    at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. I have run it in my simulator, and it works there, but there are a couple of catches. The problem is , I am using Micro-Cap 12.2, and it does not have exact matches for all
    of my components.

    In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact match
    for this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.

    Should be OK.


    A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some perform
    quite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the
    others I used in the sim are failing. Increasing the value of R5 in the sim did not increase the output voltage. Is anyone out there familiar with the PMV28XPEAR, or know of a very low cost MOSFET that would be guaranteed to work? My cost for the
    PMV28XPEAR is $0.076 each.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to rhor...@gmail.com on Fri Dec 22 11:45:41 2023
    On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
    Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin
    from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be
    on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.

    *Why* do you want to remove power from the rPi? Are you trying to
    *conserve* power? Ensure a "restart from POST"? Deactivate
    the rPi regardless of what it may be doing at the time? etc.

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

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

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

    Also, if the rPi is doing something of value, 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")

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt Christensen on Fri Dec 22 14:20:21 2023
    On 12/22/2023 12:08 PM, Lasse Langwadt Christensen wrote:
    fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
    On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
    Actually, I am fairly sure - but not certain - it will work, and I am a
    little less sure it will work well enough. I have included a link to a
    schematic of the design below. "Switch 1" is actually a GPIO output pin
    from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have >>> the Arduino shut down the RPi when a certain variable is true and turn it >>> back on when the variable is false. The default will be for the RPi to be >>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, >>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
    *Why* do you want to remove power from the rPi? Are you trying to
    *conserve* power? Ensure a "restart from POST"? Deactivate
    the rPi regardless of what it may be doing at the time? etc.

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

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

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

    Also, if the rPi is doing something of value, 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")

    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

    The *Arduino* is the device that is directly controlling the power *to*
    the rPi. So, unless there is some other mechanism for the Arduino *tell*
    the rPi (not mentioned or shown in schematic) that it is about to pull
    the plug on the rPi, the rPi will just find power removed from under it...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt Christensen on Fri Dec 22 18:47:10 2023
    On 12/22/2023 4:24 PM, Lasse Langwadt Christensen wrote:
    fredag den 22. december 2023 kl. 22.20.36 UTC+1 skrev Don Y:
    On 12/22/2023 12:08 PM, Lasse Langwadt Christensen wrote:
    fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
    On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
    Actually, I am fairly sure - but not certain - it will work, and I am a >>>>> little less sure it will work well enough. I have included a link to a >>>>> schematic of the design below. "Switch 1" is actually a GPIO output pin >>>>> from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have >>>>> the Arduino shut down the RPi when a certain variable is true and turn it >>>>> back on when the variable is false. The default will be for the RPi to be >>>>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, >>>>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. >>>> *Why* do you want to remove power from the rPi? Are you trying to
    *conserve* power? Ensure a "restart from POST"? Deactivate
    the rPi regardless of what it may be doing at the time? etc.

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

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

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

    Also, if the rPi is doing something of value, 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")

    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
    The *Arduino* is the device that is directly controlling the power *to*
    the rPi. So, unless there is some other mechanism for the Arduino *tell*
    the rPi (not mentioned or shown in schematic) that it is about to pull
    the plug on the rPi, the rPi will just find power removed from under it...

    so you need two gpios and enabling two standard drivers

    The point is that you (the OP) has to THINK about whether
    or not the rPi can just be "unceremoniously" powered on/off.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to rhor...@gmail.com on Sat Dec 23 01:47:43 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to rhor...@gmail.com on Sat Dec 23 01:25:06 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to rhor...@gmail.com on Sat Dec 23 12:27:27 2023
    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 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to rhorerles@gmail.com on Sat Dec 23 07:44:09 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to rhorerles@gmail.com on Sat Dec 23 07:36:17 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to rhor...@gmail.com on Sat Dec 23 17:48:44 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to And I've not on Sat Dec 23 11:47:33 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to rhor...@gmail.com on Sun Dec 24 16:12:25 2023
    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.

    Because your counterarguments will be predictably "we
    don't have the time, money, expertise, etc. to do that".

    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.

    None of your QUESTIONS compel answers on MY part. Yet, I took
    it upon myself to offer you advice as to issues that could
    assist your initial posted effort.

    For that, I am rewarded by a guy who is defensive of his ignorance.

    If the industry is "millions of dollars worldwide" (which is
    true of probably MOST applications, "worldwide"), then someone
    will solve your problem for a few *dollars*. Because they
    won;t rely on "volunteers" to come up with a solution
    as they will expect to reap the profits from those "millions
    of dollars" of potential sales.

    So, if you *want* to solve the problem, realize the OPPORTUNITY
    that you claim exists and finance a *real* solution. And, prepare
    to scale up quickly as that few dollar solution will likely be
    copied, quickly, and sold direct by the firm that you outsource to
    build the things FOR you.

    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.

    Then why are you bothering? Surely it means SOMETHING to you. I spend $500
    in a few hours of my time. Wouldn't you prefer to be able to say you've
    come up with a solution that *works* (for however much/little money it
    nets you) than to waste your time on something that doesn't?

    Why not just put a MECHANICAL timer on the power supply and have it, UNCONDITIONALLY, power off the rPi for a few seconds every HOUR?
    Isn't that solution just as bad as yours? And, likely you can find
    something COTS that can be repurposed to that goal!

    "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 you assume some applications are less important than others, then
    you don't give your best effort to the design of ALL applications.

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

    Apparently, you and the customers you are addressing have low standards.
    You can probably save a few pennies by omitting the silkscreen, using
    85C caps, soldering direct instead of using connectors, etc. If
    you don't care about the quality of the product...

    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.

    Because I didn't ask about OTHER things that you didn't mention?
    "In particular, this board supports a high speed fan and a Peltier
    cooler or other 12V, 5A cooling system. That has not been the most
    common issue, however, and in any case has nothing to do woith my
    original question."

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

    I repeat: Oh, brother.

    My sentiments, exactly: "Oh, brother! This guy with 50 years experience
    STILL is clueless about software, processors, etc. Arduinos and rPis... (sigh)"

    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.

    Because you are looking at the problem wrong. The rPi is the problem.
    Remove *it* and you've got "$35" to play with!

    But, that's obviously beyond your capabilities as you've bought into the
    idea that you *need* an rPi, Linux, Peltier cooler, etc. to solve this
    problem.

    If you looked at it "from scratch", your approach would likely not
    be so constrained. But, you'd need to be able to point to THE issues
    that are causing the problems so you could focus on addressing THOSE
    in your NEW solution.

    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?

    The problem seems to be that their software isn't reliable on the rPi
    in YOUR application. It's not *my* problem, at all!

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

    Yeah, we all know how wonderful you are.

    I've got a trophy here to remind folks who forget.

    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?

    Because the whole approach is not "well conceived". It's like a client
    saying "let's take a PC and..."

    Why a PC? Just because it's a computer? There's a computer in my phone.
    Why not use that one, instead? Or, the one in my mouse? Or...

    Hobbyists try to piece together solutions from "stuff they can get".
    This ties one or both of their hands. And, leads to unforseen
    consequences down the road when their (usually) ill-defined goals
    meet up with reality.

    A ("professional") designer looks at the problem and ENTIRE solution
    space and finds the best solution to fit the criteria specified.

    And, stands a helluvalot better chance of hitting his target.

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

    I seem to recall them sold by real companies, not hobbyists operating
    out of garages.

    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?

    How does it have nothing to do with the project? It is the reason
    behind your perceived need!

    Select that "other platform" and eliminate the project -- and the problem!

    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.

    That's great! I can look forward to not seeing any more of
    your posts!

    Be sure to keep us appraised of your "successes". Maybe add an electomechanical counter to each device so you can reliably
    report how often it activates -- to justify its use over a simpler
    "reset the processor every minute" approach.

    Holly Hapidays!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to rhorerles@gmail.com on Tue Dec 26 11:15:38 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)