How does Octopi/Octoprint determine an "Undevolt" condition

[ 15.758737] Under-voltage detected! (0x00050005)
[ 22.003188] Voltage normalised (0x00000000)

I don't have an O-scope, but a fluke hasn't recorded a drop in input voltage. 5.1VDC +/- .03.

There isn't anything left to replace.... except the PI

The β‰ˆ 7 seconds should be long enough to see a drop on the Fluke.

Are you sure that the USB-C connector isn't the problem?

Also, if you want to measure something closer to internal voltage, measure between the 5v and gnd GPIO pins - it's not clear where you're measuring at the moment but that would show you closer to what the Pi sees.

The supplied switched USB power supply, an Apple charger AND a buck converter with a soldered USB-C all bad? I'm not a lucky person, but that seems too unlikely that everything used all have the same problem. I've used a powered USB hub between the PI and the printer and USB camera, still no change, so it's cant be a USB device. The problem occurred before the display was added and still exists, so not likely it is causing the problem. Octoprint occasionally reports on initial start but a reboot clears the warning. I really can't understand what is causing the PI to have an issue, but then be fine. The problem seemed better before I did the python 3/.18/1.53 upgrade, but don't believe software is causing this unless it lowered a threshold somewhere, but nothing I have found. I have no faith in the PI platform at this point since, this issue seems to be more phantom than substance and I have invested a lot of quality parts to have the problem continue. I'm reluctant to buy/borrow and O-Scope to capture anything on the input voltage, if it's occurring faster than the Fluke can record.

GPIO is blocked by display, and before we blame it, this has been occurring before the display was added. I am measuring the voltage at the USB-c connector, input to the PI.

As far as I know (just to give some numbers/evidence to it) the undervoltage detection is done by a specific circuit in the Pi, it trips at ~4.6v and sends the signal. I am not aware of this being a configurable threshold, more one that is set by the hardware circuit design itself.

To state the obvious, this is an intermittent issue that only seems to occur on boot to the Pi. It's entirely possible that you won't see this the other side of the connector - which is why I suggested GPIO. I know it is 'in principle' broken, but this is for a very small amount of time. Once the voltage normalises there won't be any further throttling of the system. What I'm trying to say, is that maybe you can just ignore it since you have tried a lot of things and it still won't go away.

1 Like

That was my feeling, except that Octoprint is logging that the event has occurred. I can't tell if it is affecting the print, even though the lightning bolt isn't showing octoprint.log is showing an event occurred. I wanted to see if it was possible to reset after the initial boot, so I can see if it is actually occurring or if it's something caused during the initialization. I have monitored the power input meticulously and despite replacing everything and even raising the input voltage to 5.2VDC I still see this message. Unfortunately I can't see how low the PI measured since it doesn't seem to log the value, so I have to take it's word that it occurred. I'm more inclined to believe it's a bug somewhere since I can't quantify the problem with any external measurements. And even if I could, I can't raise the input voltage anymore or risk damaging the PI. I might make a connector for the GPIO header for my fluke probes, but I'm beginning to think this is a false report caused by the software pausing or not initializing correctly.

It will only affect the print if it is sustained or active during the print. dmesg is the most accurate source of information for when the voltage goes up and down - OctoPrint is just reading vcgencmd get_throttled periodically.

There is vcgencmd measure_volts but this is not the same thing that trips the undervoltage circuits. I don't think it is that useful. There's nothing in the software that measures and calculates it as far as I know, it is a single signal from the hardware of the Pi that is either undervoltage or no undervoltage.

Dmesg just reported it again on an Idle printer, so everything just sitting while I'm typing here and the PI reports an undervolt, Octoprint whish is also open and running - idle, did not report the event.

[ 901.848256] Under-voltage detected! (0x00050005)
[ 906.008540] Voltage normalised (0x00000000)

I tried using the vcgencmd voltage parameters, but since I don't know what voltage and where I haven't had any success on using them.

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

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.

See vcgencmd get_throttled

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