I don't have high CPU while charging. I'm leaning towards a daemon.

Also, pedometer, if it's the one counting steps, is running a loop and monitoring accelero several times a second. That can't be good.

If you need to kill stuff, ps from terminal gets you processes and kill kills them. Killall is better.

Frankly, you should not be there. Killing a drain is last resort. It shouldn't be there in the first place.

Also, yes, TMO search vacuums. I have used Google on many occasions.

I don't have high CPU usage whilst charging and the device is ON, but it's one of the very times that I have switched it OFF and charged it, and hence noticing this 50% use scenario. Thanks for the info on killall and ps, I'll give them a shot but currently am monitoring battery without the pedometer switched on.

TMO search vacuums. I like it!

I had similar problem some time ago - this is what worked for me:
1) reflashing to clean 1.3
2) Installing apps I need one at the time and monitoring battery life and cpu after each new app.
This way I managed to optimize my battery life to 5 days (I do not use wifi and 3g, and I have only 2 desktops enabled with minimum of widgets I use).

Some months ago, there was a discussion thread about a bug in Hildon-Desktop causing high CPU usage:

http://talk.maemo.org/showthread.php?t=54462

As far as I understood, to use certain programs triggered this bug, which caused a constant CPU usage by some sub-process in the hildon desktop. It seems that this bug is still present in 1.3.

One of the programs which triggered this bug seems to be Catorize (http://maemo.org/downloads/product/Maemo5/catorise/)

Should have have Catorize installed, you might check whether the CPU usage becomes normal after rebooting, while not launching any application over the application menu.

I had this problem of ~10% CPU during idle, deinstalling Catorize and rebooting solved the issue for me.

No, no catorize on mine mate, but thanks for the heads up. The process that continually chews my CPU is hildon-home, not hildon-desktop, but that may well be linked to the pedometer mentioned earlier.

Monitoring battery life currently with pedometer switched off, see what happens, I'll report back if that was the case.

@Switch_ didn't you say you had 50% CPU while N900 is hard off? This is ridiculous, when phone is OFF nothing is running, no CPU. I assume your Battery Graph is simply showing nonsense. How would Battery Graph know what is going on in CPU when system is OFF?

If your battery drains while phone is off, either the phone hardware has a hard failure (N900 -> Nokia Service) or the battery is dead (easy to replace).

@rm53, Yes mate, 50% use shown in Batterygraph when phone is HARD OFF.... I was gobsmacked by it myself, hence the initial reason for the post. Guess it may simply be a bug in batterygraph, as vi_ reported the same from his system......

Nothing runs when phone is hard off, not the OS not batterygraph.

My guess is that either

a) Batterygraph has no data so it draws the last known value for the off period (likely)

b) You didn't off it.

To exclude b) just power it off, count to 20 and hold the power button for a little while. You should see the white LED fading in. DO NOT LET IT FINISH. This is just to make sure it's off, because after it appears off it still does stuff for a few seconds and pulling battery can corrupt root.

Once you know it's off, pull the battery. See how that shows after a while.

Note, however, that the phone is NOT off if it has power via USB, be it charging or connected to a PC or whatever. It boots to a minimal stage, where daemons like BME start but no user login (IIRC). If it is charging and "off" then the CPU might as well be at 50% for what I know but it's likely that in that stage data about load is not available.

Also, IIRC the Catorize bug was fixed? It had to do with the fact that the menu always scrolled in the original. Once Catorize or any folder thing kicked in and there was no scrolling, the code that did the elastic band thing never finished, bouncing one pixel forever and eating CPU.

That can be fixed by either using ApMeFo to make folders (but no to few) or not scrolling (which is hard) or killing the Hildon thing. I do distinctly remember them fixing that in 1.3 - I no longer have the bug. I use ApMeFo for 10 folders or so with zero issues.

Anyhow, back to the point. There is no CPU when phone is off. Also, please use either batterygraph or the commandline to see voltage of battery when charged completely. (x-term command is "lshal | grep battery").

You might have a feeble battery, as suggested. Oh, and, get cpumem-applet. It offers insight on CPU load all the time. Once it seems to not go down, use top or conky to see the troublemaker.

Also, how many images, videos, sounds do you have? A bad/lot of media can have the tracker track for hours.

Absolutely, that is precisely what I was most confused about - hard off = all systems, services and processes are dead; defunkt; killed; not running; unloaded from RAM; to all extents and purposes DO NOT EXIST! That's what had me so confused about the phone being hard off and yet still data somehow being sent to batterygraph. As you also state, takes data from the last known point and extrapolates it until next data point is taken would explain it.

Ah, now, you make a very good point there, one that I hadn't considered. BME must be running to charge the battery therefore there is minimal OS activity albeit background. Based on that you could potentially say that data can be passed to batterygraph as I would imagine that BME is one of the services that it pulls data from. From this you could also say that the processor is going to running threads, it's just a question of how many and how intensively.

Potentially - see above.....? I'll take a look at mAh / V on full charge and let you know.

I use CPU-MEM Applet and have done for a loooooong time, it never reports considerable and sustained CPU activity or load unless I am performing a task that calls for it.

An absolute sh*tload - about 4.5Gb videos, 16Gb Music and about 2Gb images. Although I don't believe any of them are "bad". tracker never seems to rate highly in the list of running processes in conky.

Thanks for all the replies lads

Well, Conky is more unstable than cpumem for some reason. e.g., I have seen Conky report 20% load while cpuem said 100 and since it was running apt--

Sorry, Fennec interpreted a space as send.

Where was I?

Ah, Conky isn't the most reliable out there. If cpumem says it's cool, it's cool.

Let us know how lshal claims the battery has been (ab) used and see how it's faring. Frankly, locking the CPU at 50% should give you about 2 hours autonomy (or so) and warm the device.

If you don't see cpumem show you 50%, it's probably an artifact from batterygraph or another program that gets tricked like Conky.

From experience, background CPU is noticeable. Leaving MC do a copy over wifi depleted my battery in 1.5 hours (wasn't full). Now, the CPU was not 50%, granted, but it's not like load is a direct indication of consumption. I overclock as a matter of life and I know this to be true.

So, AFAICT, your CPU is not locked to 50%. Besides, it's reasonably hard to lock a single core to 50%.

How much do you get out of your battery, full to empty, on light and heavy usage? (light: say 20 minutes call, 1 hour browse via wifi, 2/5 backlight, 2G, plus a little fiddle).

Also, if you charge at night to 95+, how much is left in the morning? My 8 hour standby eats between 10 and 15% (connected to wifi via WPA, BT, 3G).