We can get the current input voltage from /sys/devices/iio_sysfs_trigger/subsystem/devices/iio:device0/in_voltage6_raw by dividing it with 172.45.
What about current amp usage?
I’m trying to get realtime / near-realtime power usage of the rock5
Realtime power usage
1 Like
I am interested in this. Where did you get that value of 172.45?
A power meter to measure it at wall is not real time enough? AFAIK most of people measure the power usage this way rather than rely on sensors reported by SoCs.
There’s a search function in the upper right corner here in this forum. It’s not Discord fortunately 
That’s not even a sensor but just some voltage divider circuitry fed into an ADC that spits out a value we blindly trust into. Same with other RK3588(s) thingies.
Certain PMUs and certain SoCs/CPUs (AMD, Apple, Intel for example) come with power sensors that could be trusted and a software interface that allows for reading out actual consumption data on the host (powercap/powermetrics).
But here it’s as you suggest externally measuring. I’m using NetIO switchable powermeters for this since they’re rather precise even with low loads when measuring in a certain way.
@gnattu however, with direct measurement by the device, you can log it or make available over the network, not to mention needing one fewer devices - not everyone has a power meter. And not everyone needs very accurate measurements.
@tkaiser I tried googling it and found nothing, but yeah, could have searched this forum first. I wonder if there’s a way to “brute force” looking for such a value that would enable amp measurement.
Look at the graphs generated using powermetrics when I reviewed an Apple M1 device. If the same would’ve been possible on Rock 5B or with RK3588 in general I would’ve flooded my Rock 5B review with same sort of graphs.
The least expensive thing I know to do these sorts of real-time measuring is something like this (inline) or that (wall).
And always remember that processing this data on the device being measured maybe invalidates the measurement (e.g. idle consumption measurements being bogus since data processing prevents the device from being idle -> clocking higher, needing more juice). That’s why I would always add to the external powermeter an external host (inexpensive SBC ofc) to process the data.
@incognito ROCK 5B Debug Party Invitation
@gnattu Most people do not want to add another wall shunt to measure the power usage and they usually do not come with something readable through BT or WiFi.
The biggest power draw would be the RK3588 itself, if we ignore the peripherals connected to it. On standard PCs we can check the CPU / APU current and calculate the package power so i was wondering if something like that is possible on rock5
Cool review, I didn’t know it existed!
Well, what you say does invalidate the measurement, but if all one needs is just an estimation/ballpark and not super accuracy then it is fine. Depends on the use case. If some measurement prevented a device from being idle, it would still measure something, just not the “true” idle power consumption.
And then you need to take in account motherboard consumption, disks consumption,motherboard, GPU, all other pcie devices, and +% from power loss from voltage conversion. You may calculate how much power rk3588 takes, but that’s != power consumption at all
1 Like
If there would be both a current and voltage sensor (for example as part of the PMU as it’s the case on old and boring Allwinner A10/A20 devices with their AXP209 PMU) on Rock 5B then we would be able to read out the whole device’s consumption. But there’s no such thing here.
Though since @phiber was mentioning ‘standard PCs’ as such stuff like RAPL (Intel Running Average Power Limit) which only provides consumption estimates for the CPU and not the whole PC I’ve no idea what he’s after.
For those who wonder how this thing works, there are 8 ADC inputs in SOC called SARADC and input 6 is connected to vbus pin of usbc socket with a resistive divider.
The SARADC input is 12bits scaled to 1.8V and you exactly read the raw value.
Therefore the gain of the input is = 1.8V/2^12 = 1,8/4096 = 439 x 10e-6, around 500uV per 1 unit of digital value. If you multiply the raw digital value with this gain, you will find the voltage at the input pin of saradc.
But since it is limited to 1.8V, there is a resistive voltage divider to measure highre voltage than 1.8V and the resistor chain is 100K at top 8.2 at the bottom. that will also lead a a gain of 8.2 / (100 + 8.2) = 0.075785.
Therfore:
Vbus * 0,075785 = Vdigital_inp * 0,000439
Vbus = Vdigital_inp * 0,005792
Vbus = Vdigital_inp / 172,45
For those who wonders how this works:
You can also get, rocovery key, phone jack status, boot mode selection, and any analogue input attached to pin 22 of gpio header with the same method.
So to my knowledge there is no current sensor anywhere including the PMIC rk806 which i think should be accessible over i2c even in the case kernel has no drivers, but as said i think pmic also has no current sensor or wattmetric sensor.
So one feasible option would be attach an external current sensot, or wattmetric sensor, and read the input with saradc input 4, namely gpio pin22, so that i can be monitored and logged.
1 Like
At least that’s the theory but since it’s always stupid to blindly believe into the numbers thrown out by some piece of hardware + some software let’s check…
The generated values with this 172.5 divider look like this:
(Most right columns are input voltage by SARADC postprocessed with formula and overall consumption measured with a NetIO powermeter at wall)
root@rock-5b:/home/tk# sbc-bench.sh -m
...
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp DC(V) mW
15:16:28: 600/1800MHz 0.20 1% 0% 0% 0% 0% 0% 46.2°C 5.06 4910
15:16:49: 600/1800MHz 2.05 99% 0% 98% 0% 0% 0% 54.5°C 5.08 6120
15:17:09: 600/1800MHz 4.30 100% 0% 98% 0% 0% 0% 56.4°C 5.23 7810
15:17:29: 600/1800MHz 5.42 99% 0% 98% 0% 0% 0% 57.3°C 4.97 8440
15:17:50: 816/1800MHz 6.15 100% 0% 99% 0% 0% 0% 59.2°C 5.13 8520
15:18:10: 1008/1800MHz 6.68 100% 0% 99% 0% 0% 0% 60.1°C 4.96 8710
15:18:30: 1200/1800MHz 7.20 100% 0% 99% 0% 0% 0% 61.9°C 4.99 9020
15:18:51: 1416/1800MHz 7.43 100% 0% 99% 0% 0% 0% 62.8°C 5.05 9320
15:19:11: 1416/1800MHz 7.67 100% 0% 99% 0% 0% 0% 64.7°C 5.08 9610
15:19:31: 1608/1800MHz 7.77 100% 0% 99% 0% 0% 0% 65.6°C 5.17 9820
15:19:52: 1608/1800MHz 7.83 100% 0% 99% 0% 0% 0% 67.5°C 5.03 10060
15:20:12: 1800/1800MHz 7.95 99% 0% 99% 0% 0% 0% 70.2°C 5.03 10660
15:20:32: 2016/1800MHz 7.96 100% 0% 99% 0% 0% 0% 73.0°C 5.05 11390
15:20:52: 2016/1800MHz 7.97 100% 0% 99% 0% 0% 0% 74.8°C 4.91 12150
15:21:12: 2016/1800MHz 7.98 100% 0% 99% 0% 0% 0% 76.7°C 4.86 12740
15:21:33: 2208/1800MHz 8.31 100% 0% 99% 0% 0% 0% 80.4°C 5.17 14440
This is Rock 5B powered by a dumb 10W USB-A power brick with an USB-A-to-USB-C cable connected. This power brick is know to drop below 5V already at 9W or 10W wattage. And this in a pretty linear way.
As load generator I used stress-ng --matrix 0 in another terminal and allowed the A76 cluster to constantly increase clockspeed and as such overall consumption. At 2.2 GHz and over 14W the board froze then. But the SARADC readings postprocessed with ‘our’ formula look both too high and too erratic.
Dont know, may be the kernel task that handles the saradc was in different core. Was the power consption at 14W when the votlage was raised to 5.17? May be the watt reader was delayed and was showing pre-crash values? or may be it was jsut spitting gibberrish, at least i think the scale factor is pretty linear with the voltage input since it is totlally resistive.
in steady state i measured with an avometer, and the values are quite accurate, even if they are not it is still possible to compensate the scale factor with actual readings. That would ofc be device specific though.
What i am more concerned about is that there is no protection mechanism in any inputs of those SARADC, so it is very easy to overvoltage them, i dont know if the soc has its own internal protections though, but i would speculate not.
Yep, the shown mW values were slightly delayed since being an averaged value over the last 10 measurements (measured every sec).
You may want to look into this gadget then:
It’s a Chinese designsold under various brands and on Alibaba as well, so should be available worldwide. Data can be read using Bluetooth however they only provide a smartphone app for this. I decompiled the Android App a while ago because honestly it’s crap and likes to crash, decompiled source is human readable. I should have a c version of it somewhere that I wrote with the pseudo-c for nthe Arduino libraries(my target in that case was an esp32), if demand exists I can share that for someone to port over to actual c with him bindings. Be aware that above design needs to be put into USB pd mode after powering on, unless you are fine with its default I think it was 15 w limits