Chiming in. I actually have had undervoltage issues for a while with a stable ATX supply. My problem was that the supply while in spec for 5VSB @ 4.8V was on the lower end for a Pi. I ended up hooking up my scope on my power distribution block(closer to the supply) and at the Pi GPIO header(where I power). When the motors turned on I saw a wild amount of noise on the block side and some reached out to the GPIO side. So far my fix has been to throw in a cap(5000uF - what i had on hand) at the 5V on the GPIO header and haven't had an issue thus far though it's only been a few days.
1 Like
OK, hadn't consider noise. I just happened to have a bunch of ferrites I can put on the input cables, they didn't help on the USB cable side. I will give it a shot. The 24V power supply in the printer is stable so I know it isn't causing an issue of the buck converter and it's output is stable as well. Haven't scoped anything, but your suggestion has some possibilities.
Ok, so now I've added a ferrite on the power supply and PI sides of the buck converter. Voltages are stable. I never knew about DMESG before, but I have been running dmesg -T and it appears I am seeing a 6 second event once every hour(ish). The print was idle for two events and printing for another. I have the PI out of it's case, the stock fan removed and several externally powered fans blowing on it.
[Wed Mar 24 08:37:16 2021] Under-voltage detected! (0x00050005)
[Wed Mar 24 08:37:23 2021] Voltage normalised (0x00000000)
[Wed Mar 24 08:37:24 2021] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[Wed Mar 24 08:52:02 2021] Under-voltage detected! (0x00050005)
[Wed Mar 24 08:52:07 2021] Voltage normalised (0x00000000)
[Wed Mar 24 09:42:10 2021] Under-voltage detected! (0x00050005)
[Wed Mar 24 09:42:16 2021] Voltage normalised (0x00000000)
[Wed Mar 24 10:51:10 2021] Under-voltage detected! (0x00050005)
[Wed Mar 24 10:51:14 2021] Voltage normalised (0x00000000)
dmesg -T -w | grep --line-buffered -i 'voltage' if you wanna watch for it live 
Thanks, that is useful. I'm just this side of inept with the command line, but can follow directions. What does the last digit in the event "5" mean? Why is it not just a 0 or 1 flag?
Convert the hex into binary then match the individual bits.
Actually just decoding it now looks like you got:
Under-voltage detected
Arm frequency capped
Arm frequency capping has occurred
Soft temperature limit has occurred
The PI is printing at the moment, but there are several fans blowing on it, it's outside of a case on a non-conductive pad, and the fluke is showing there has been no change to the input voltage. This thing is really a pain. I am giving the PI more than the minimum and just less than the maximum, yet it still has a problem. There just isn't anything more I can do for it, since more is greater than the USB-C spec and "supposedly" dangerous to the PI. I'm not overclocking or running anything abnormal. The only hardware I've added it the 3.5" TFT display. The only USB devices are a Logitech C310 camera and my printer. Tried putting them on a powered USB hub and it made no difference to this power warning. This thing is either generating the error itself or has a design/component failure. I just can't figure out which.
Fluke multimeter or scope? You likely won't see it on a multimeter if it's a short dip.
Meter, I'd have to borrow a scope. The event is 6 seconds in duration, I would hope the fluke could pick it up unless the duration is more due to software polling.
I have to believe that there are enough RPi 4B 4GB systems out there that if this was a design flaw there would be more instances reported in lots of different places. I think I'd consider replacing the RPi next.
BTW, mini digital oscilloscopes are reasonably priced, https://www.amazon.com/dp/B08DG1C129, one channel, 200KHz for ~$85; and https://www.amazon.com/dp/B074QBQNB7, 2 channels, 1MHz for ~$110.
$85 test equipment to diagnose a $35 module? My fluke is sufficient to establish that unless there is modulated or other noise, a 6 second power under volt condition of .6 volts or better would be displayed. There are a lot of complaints and documented issues out there, including a revision to the RPI 4 for a design issue on their USB-C port, so whether it manifests for everyone or only under certain circumstances, it's certainly not a figment of the mind. There are clearly issues with the PI 4 and power, the more I search the more I find. I ordered the "Official PI" power supply, so I can stop the "Use the Official power supply and all the worlds problems will be resolved".
I have met or exceeded every requirement for the power input to this Pi and it still reports an under voltage condition with 5.2v (26W by me only 13W from Raspberry PI) being supplied to the PI. The official PI forums are full of this exact complaint and the pat answer is always to use the "Official PI power Supply". If the device ONLY works with their power supply then it is by design, flawed or otherwise. It should be supplied in all the "kits" (My kit was made by Neego and it included a 3A power supply that still had this problem) and then nobody would be experiencing this issue, but check the web before you say this isn't a well established issue that many owners have. I was trying to find out if I was looking at a stuck flag from VCGENCMD or if the problem occurs on every boot, Octoprint does not report this even though the PI does report this.
1 Like
You clearly have a problem and have done your homework. The only thing you haven't changed is the RPi itself so at this point, either you spend $35 for another one or you abandon the Raspberry Pi and try something else.
I posted here, because I wanted to understand the software, the PI is separate but related. I do understand the difference between hardware and software, but since OctoPi and Octoprint are the software I'm using on the PI, the software tools included in them are my resource at the moment. I do have threads open on the Raspberry forums on the same issue, but it seemed strange that the hardware shows the warning, but Octoprint doesn't. I ordered the Official power supply as my last effort, if it doesn't work then the Pi is relegated to hobby tinkering and nothing important, and I'll use a Miniforums Z83-F as the new platform. I did learn some new tricks here today that are turning out to be very helpful, so the time spent has been worthwhile. Cheers
By default, OctoPrint only checks once every 5 mins if there is no problem, and once every 30 secs when there is throttling:
This is probably why you aren't seeing it reported in OctoPrint as much as it comes through on dmesg, and why dmesg is the best source of truth you have - OctoPrint is the next layer of slow polling above it.
I feel like maybe the Pi is internally polling too, just a feeling though. Since every time you have had an issue, it goes away after 6 secs or so, maybe it gets triggered and then will only poll to reset throttling every X seconds. Not an expert in the internals of the Pi here, so can't say for sure. I just know a lot about OctoPrint
1 Like
the problem isn't on the input voltage. it goes through an internal voltage controller then to the system. the monitoring is done AFTER the VC. you HAVE to measure the voltage at the GPIO pins if you want to see if the voltage is dipping for the Pi to sense. Have you taped the + pin of the USB to printer cable to isolate it? if the printer loads that terminal down, then the internal voltages on the Pi will drop.
Since it also does it when the printer is idle, when you aren't printing, unplug the USB and see if it happens. One other thing. A digital meter will rarely ever show you any quick spike or dip, unless it happens during the sample period for a reading.
The USB devices (Longer LK1 printer and Logitech C310 camera) are on a powered hub, the hub is then plugged into the PI. As for the sampling rate of my Fluke 87, it says its 250 micro seconds, that has to be fast enough to pick up a 6 second event, can't find anything on the power sampling rate of the PI, Octopi, Octoprint so not going to buy an O-Scope to diagnose further. There is nothing connected to the PI except the display and this problem predates that, but even so it shouldn't be enough to cause all this with a 3.5" TFT. I ordered a "Official PI Power Supply" and if it works then there is something magical or specific to the Pi that is not documented as I have exceeded everything in print and still have this issue,
Again, monitoring the voltage at the USB-C connector won't tell you squat.
You HAVE to monitor it at the GPIO pins.
And a powered hub can be just as bad. Quite a few of those have been reported to backfeed to the Pi and cause issues
Then why will using an "Official Raspberry Pi" power supply be the solution to this problem as stated by everyone? If the magic power supply is a fix to anything then the problem has to be on the input side of the PI.
Because it is a known working supply that's also made by the manufacturer. If that doesn't work then you know it's something else. Just because your buck converter has a rating of 5A doesn't mean that it's actually capable of delivering a constant 5V@5A. There are plenty of manufacturers out there that flat out lie. You can skip the official supply route if you can confirm your current supply with an oscilloscope.
I didn't recommend the official.power supply. I am running buck converters and POE hats on most of mine.
You have been monitoring the input at the USB-C, but have not checked and monitored at the GPIO pins which is where the pi actually monitors it.
Since it gives you power warnings even with the printer idle, disconnect the powered hub from the pi and let it run for a few hours and see if you get anymore. Almost guarantee you won't. It's a known issue with a large number of powered USB hubs that they feed power back to the pi, and if their voltage is lower than 4.7 on the feedback it will draw down the pi's 5v bus.
Instead of making excuses, monitor the GPIO.
You come asking for ideas and help, then want to argue about suggestions.
If you don't want help, leave the forum