Pandora power consumption breakdown


For short periods, suspend to ram is not worth it, because the difference with lid closed is small, and the extra activity to suspend and resume takes much more power than the extra activity happening upon closing/opening the lid. In the new kernels, if you have nothing running (or only idle processes), the cpu will use nearly no power at all, whether you underclock it or not. Disabling the "power on" led makes a bigger difference.

I have a rebirth unit, and I keep it running at 900MHz at max OPP, never shut down or suspend to ram. I just close the lid and make sure nothing power consuming is running when I'm not using my Pandora for a long time (e.g. overnight).
 
Any videos showing the different brightness levels?  I would like to know how dark the lowest brightness setting is.  I have found the lowest brightness setting on most devices is good for indoors and not so great for outdoors.
 
Any videos showing the different brightness levels?  I would like to know how dark the lowest brightness setting is.  I have found the lowest brightness setting on most devices is good for indoors and not so great for outdoors.
I always use the lowest brightness when indoors, highest when outdoors, and usually something in between when on a train.

Just a question, how can I disable the power led?
As root, echo 0 > /sys/class/leds/something
 
It's /sys/class/leds/pandora::power/brightness. That only temporarily disables it though, it comes back on if you then go to sleep and wake up. You also need to edit /usr/pandora/scripts/op_power.sh to comment out the references to that file.
 
It's /sys/class/leds/pandora::power/brightness. That only temporarily disables it though, it comes back on if you then go to sleep and wake up. You also need to edit /usr/pandora/scripts/op_power.sh to comment out the references to that file.
Thank to both.

I wich way sould I edit /sys/class/leds/pandora::power/brightness? It looks is about brightness... What if I just want to make it less bright? or blinking... does that make a difference?
 
I wich way sould I edit /sys/class/leds/pandora::power/brightness? It looks is about brightness... What if I just want to make it less bright? or blinking... does that make a difference?
To turn it off, make sure you "echo 0 > /sys/class/...". When it goes to suspend mode, you'll see that it does an "echo 16 > ..." to make the LED dim and an "echo 255 > ..." when it wakes up to make the LED bright again. You can adjust however you want.If you want to see it blink, try "echo heartbeat > /sys/class/leds/pandora\:\:power/trigger". To restore it to normal "echo none > /sys/class/leds/pandora\:\:power/trigger"
 
I wich way sould I edit /sys/class/leds/pandora::power/brightness? It looks is about brightness... What if I just want to make it less bright? or blinking... does that make a difference?
To turn it off, make sure you "echo 0 > /sys/class/...". When it goes to suspend mode, you'll see that it does an "echo 16 > ..." to make the LED dim and an "echo 255 > ..." when it wakes up to make the LED bright again. You can adjust however you want.
If you want to see it blink, try "echo heartbeat > /sys/class/leds/pandora\:\:power/trigger". To restore it to normal "echo none > /sys/class/leds/pandora\:\:power/trigger"
OK, I'm starting to understand how it works. Thank you a lot

Sorry, but I left linux more than 3 years ago and I never went much deep.

As I can see, this is just some plain files (i assume as text) which defines the pandora behavior.

Nice.

The trick worked for make the led less bright, but I'm a bit scared of cat to power trigger, because that file contains more text, looks like define the blink mode for many situations.
 
Last edited by a moderator:
/sys (sysfs) is a virtual filesystem. Mostly the files are not really anything more than "links" to a piece of code that dynamically creates content on demand (cat /sys/...) or parses given content to change a driver parameter (echo stuff > /sys/...).

What is written doesn't need to match the format that is read out exactly. The LED subsystem trigger file lists all possible triggers with [] highlighting the current one - when read out that is. When writing it expects just the name of the new trigger ("echo heartbeat > /sys/.../trigger"). Mostly if you can get inside the head of the driver developer this is all intuitive :p

Btw, heartbeat is a bit more than just a blinking led... "The flash frequency is a hyperbolic function of the 1-minute load average."... well the name says it better IMHO :p
 
So it flashes faster when load is high? I did not know that! That may actually be useful in some situations.
 
Hehe, like an electrocardiogramm  :D

Q: "How stressed is you Pandora?"

A: "Hmm, dunno, just look at the heartbeat of its LED!"
 
USB consumption (measured by sysinfo, numbers were calculated from state differences)

 mA title

 46 USB host service

  0 USB network service per se ("Start USB network on bootup")

 40 USB OTG cable connected (Unplugging always put consumption to as before! Service seems to really run only on demand!)

 90 USB2 hub in USB OTG port (Digitus Slim Spider USB hub)

 50 USB2 hub in USB host port (Digitus Slim Spider USB hub)

120 USB1 Logitech Premium Optical Wheel mouse — idle

140 USB1 Logitech Premium Optical Wheel mouse — active

 35 USB1 Logitech Wireless Rumblepad - receiver idle

 44 USB1 Logitech Wireless Rumblepad - receiver active (or when turned on broadcasting/listening for controller ack)

For consumption optimization:

  • The active running USB-OTG (40mA) or USB-host (46mA) services consume quite the same.
  • If you only use 1 input device (no hub necessary) use it through the OTG port. This effectively saves the hub consumption (90-100mA) !
  • If you use a USB2 hub, use it through the USB host port (was more efficient than on the OTG port).

Hint: Hubs on the USB-host-port are buggy. So for now, if you merely use the hub to connect input devices (USB1 !), use them on the USB-OTG-port!
 
Last edited by a moderator:
Back
Top