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
Just to clarify some things somewhat hidden up there:
- The throttle state is monitored by the Pi. It does not persist reboots, but it will reflect back past undervoltage situations since last boot.
- The voltage monitor inside the Pi monitors after its own voltage regulator, as has been said. Measure across the GPIO pins to get the real picture of what is going on, anything else is one step above guess work.
- The official power supply has a really good track record in our experience, whereas buck converters, random cell phone chargers from the cable bin and cheap supplies off of ebay or amazon are hit and miss.
- OctoPrint only reports what the Pi reports, if the Pi reports a problem there is a problem.
Disconnect everything but the power from the Pi, monitor if power is stable then. If it is, it's one of your peripherals. If it's not, it's either you buck converter or your Pi is faulty. Measuring the input to a complex multi component system and seeing it stable with a multimeter tells you absolutely nothing about the state of the whole system over time.
3 Likes
While I agree with your message, you could have said that in a bit more diplomatic way.
As long as the arguing is in a friendly manner it's alright.
OK, for some reason this has gone to a tangent. My problem was trying to determine where the software was getting the condition, and whether it survived the reboot or was being re-triggered at every boot. That's what I came here to get answers to. I have been getting a lot of "extra" opinions and suggestions, which I responded to in kind. I have done my due diligence and I have taken my hardware issues to the raspberry pi community where it is more appropriate. I did not post asking for a solution to a raspberry pi problem, I asked about how Octopi/Octoprint report them, and for the record.... Octoprint is not reporting the warning when the PI is, not sure why, but I could watch the PI report almost hourly an undervolt, and Octoprint was running both idle and printing and only once reported the warning itself. I really don't care that there is a discrepancy, but I was trying to understand how the warning was recorded and reported. I have disconnected the powered hub and still saw the warning on the PI, not Octoprint. The camera (Logitech C310) has acted up and I have had to restart the "webcamd" service to restore it since the last upgrade to .18 & 1.5.3, I know a lot changed and I've been slowly working through my setup to get things working again.
I shouldn't have to defend myself to posts who assume I didn't do my homework, bought junk parts, didn't read the advice and notices here, etc. I don't have to agree with everything that is posted as a response, and there are a lot of bad responses posted with good intentions. I can certainly defend or justify my choices, I never told anyone to leave or go elsewhere, but I can choose to accept or reject their "opinion" at my choosing. Telling me to accept an opinion or leave is un called for. If the people responding had bothered to read the original post, I never asked for anyone to direct me to an alternative hardware configuration, I asked about the software.
I believe the tone and finality are not appropriate, and my original post qualifies me to post here on the matter I needed help with. Everything else was outside of the original post and I was not deserving of the remark or tone.
2 Likes
I agree with this.
I'm sorry if my post sounded like it was attacking you or blaming you or anything like that. It was to provide a bit of a summary of the points made in this whole by now lengthy topic, clarifying when the reports are cleared and when not (which actually I understood to be a question of your OP), and suggest the next steps to debug the issue - which is also something I understood you were asking for suggestions with by asking for anyone else with similar experience.
But please also understand that when you go on a forum, asking for information that's clearly hinting at you trying to troubleshoot a problem that's currently leaving you puzzled (the title "undervoltage warning despite multiple remedies" alone hints at that), it's a bit of a bad approach to communication to then get mad at or annoyed by suggestions too.
1 Like
I didn't get annoyed or mad. I responded in kind to the posts, it was the "take my advice, I am an expert, or leave" and the "everything you are doing to troubleshoot is one step above guess work". Even posting that my troubleshooting technique, which again was not part of this original post was unsolicited. As for posting here and taking what I get, I did. It was the moderator, poster and yourself that escalated this.
I did get useful responses, CLI commands to use in response to my topic.
Alright.
I think everyone made their positions clear and everything has been said.
If you have further questions regarding the power supply of the pi I suggest you try it in the raspberry pi forums - the engineers who designed the pi are probably able to tell you more.
I'm closing this thread now.