[Gta04-owner] Tracking down power 'leak'
Dr. H. Nikolaus Schaller
hns at goldelico.com
Wed Sep 4 11:01:21 CEST 2013
Am 04.09.2013 um 10:39 schrieb Christ van Willegen:
> On Wed, Sep 4, 2013 at 10:28 AM, Dr. H. Nikolaus Schaller
> <hns at goldelico.com> wrote:
>> Instead of an Amperemeter it would be better to insert a 0.1 Ohm shunt
>> resistor in the - (GND) line of the battery and connect an Oscilloscope.
> That makes it easier to adjust the scale, and it probably won't blow up :-)
> The A-meter I have at home goes to 2A without replugging (I have 20A
> that needs re-plugging), so I _may_ be able to do this myself.
Oh, that is fine!
Another word of caution - amperemeters may or may not low-pass filter
rapidly changing currents, i.e. you may get false readings if the current
flow has spikes.
BTW: the same may hold for the bq27000 fuel gauge - i.e. it might not
correctly estimate spikey discharging.
But since we are looking for suspended mode, there shouldn't be big spikes.
>>> Also, would it be possible to build a minimal system that has either
>>> USB or serial support (I don't have a serial cable, so I can't do this
>>> at home...) and then connect to it and manually (using a simple C
>>> program tugging registers left and right) toggling all the hardware to
>>> the lowest power state possible. Then. when we are reasonably sure
>>> that everything is off, we can measure power usage to have a baseline
>> Hm. Unfortunately the OMAP is so complex that there is no minimal
>> system allowing for this approach. The closest thing is to use U-Boot
>> (which is a single-user, no built-in power management OS). But
>> there we don't have protocol support to enable/disable some peripherals.
> Could it support SSH via USB somehow, or is only serial possible?
It is serial only.
> Can we bit-bang our way into the peripherals?
Yes (some by I2C), but the question is what it would help. In the long run it can
only demonstrate that each peripheral can be switched off (or can't).
For one (IrDA/RS232) we know that it can't be properly switched off which
would be improved on the GTA04A5 board.
Anyways,t we must get full control it into our Linux kernel and allow for wakeup
of all of them.
So the question is why the Linux kernel is not turing off everything it probably
>>> In the real system, is there a way to catch the (kernel) calls that
>>> turn off various devices so that they can be logged somewhere? That
>>> would enable finding out which devices are still enabled in some way.
>> Christoph has done yet another approach a while ago (I think he did report
>> it somewhere): 1. send the device to suspend, 2. use a very sensitive
>> infrared camera to detect those chips that still dissipate some mW.
>> If I remember correctly it did point out only CPU+RAM.
> That would be enough to get down to a few mA, so there must be power
> dissipated somewhere else.
> Also, I suspect that the battery I'm using now is old. At the moment
> I'm russing QtMoko v56, which uses about 35mA. That would mean an
Well, one reason for potentially 35 mA is known and something we can't do much
about it. The modem is specified to be at 3-10 mA while being registered with the
network and waiting for an incoming call or SMS. But this is the best case.
One part is that we can't switch of the DRAM or we have to reboot on any incoming
call. So parts of the CPU and the DRAM refresh must be kept operating. This draws
some unavoidable mA (but I don't know if that is already reduced to the absolute
There is a case (especially if the device is just sitting somewhere deeply inside a room)
where the modem receives the base station easily but needs to transmit
intensively so that the basestation can hear it. This may be influenced
by other network users closer to the base station or even airplanes reflecting
some power, etc.
In that case the modem must much more often and intensively retransmit to be heared
by the base station than in a best case scenario - and draws a higher current.
Now you may wonder why the modem just waiting for incoming calls is transmitting
at all. This is a mechanism in the GSM protocols to handle the case that a device
looses power and simply disappears from the network so that the network knows
that the device has disappeared and can switch to the TAM.
This happens if the modem is no longer regularily pushing the "still-alive button".
Otherwise an incoming call would have to page for the device delaying the TAM diversion.
You probably know that mobile phones in pockets may generate some GSM buzz
from time to time in speakers or microphone systems, even if not used. This is
exactly the "still alive" transmission described.
> empty battery in about 34hrs. (at least, more than a day). But, I need
> to re-charge every day, so my battery is probably less than 1200 mAh
> by now.
> I have 2 other batteries, perhaps I need to pop in another one to see
> if that helps...
Yes, please do such tests. They may reveal important system knowledge.
More information about the Gta04-owner