Reply
Thread Tools
kimmoli's Avatar
Posts: 562 | Thanked: 2,744 times | Joined on Dec 2013 @ Espoo, Finland
#61
Originally Posted by psonek View Post
Maybe while charging the phone wont enter deep sleep?
Yep, it stays active when charging.
__________________
TOH ideas, concepts and creations since 2013 toholed tohuart toheink Heebo tohIRi i2ctool tohmm LeTOH FMTOH
 
Posts: 100 | Thanked: 389 times | Joined on Dec 2013 @ Finland
#62
You need better solar panel(s). For example my panel gives out 4x more juice per hour.
 
Posts: 29 | Thanked: 43 times | Joined on Mar 2014
#63
It seems that my theory is right verified by simple test. First stop upowerd so that it does not blink with leds, vibra and undims screen:

killall -s STOP upowerd

Then i have simple script that blinks with red led:

[root@jolla nemo]# cat ./blink.sh
#!/bin/bash
while true
do
sleep 1
echo 0 > "/sys/class/leds/led:rgb_red/brightness"
sleep 1
echo 50 > "/sys/class/leds/led:rgb_red/brightness"
done

Run this script and put the phone in standby.

Normaly the led stops blinking soon because CPU enters idle state. While powered by solar TOH it keeps blinking which indicates that CPU is not idle.

Does this make sense? I wonder what to do so that the processor goes idle. Otherwise solar charges will be quite ineffective because ~30mA is wasted on CPU.
 
Posts: 29 | Thanked: 43 times | Joined on Mar 2014
#64
Oki, some more debugging:

cat /proc/wakelocks | sort > w1.txt ; sleep 5; cat /proc/wakelocks | sort > w2.txt ; diff -u w1.txt w2.txt | grep '+\|-'

After this command if i move jolla under lamp, the CPU wakes up and shows this interesting lines:

-"power-supply" 2097 0 11 0 1156191680 1098783785 17446964 2266241071209
-"power-supply" 218 0 0 0 187567735 165166352 9797039 2266240949161
-"power-supply" 239 0 0 0 1541130070 1139839364 44895468 2266244946246
+"power-supply" 2106 0 11 0 1169010084 1111602189 17446964 2326885012348
+"power-supply" 222 0 0 0 194434802 172033419 9797039 2326884890266
+"power-supply" 243 0 0 0 1578425861 1177104634 44895468 2326898532864

If i understad it well then CPU wont go idle because of "power-supply" wakelock. This wakelock is defined in linux kernel in power_supply_core.c The question is now how to suppress it.
 
Posts: 29 | Thanked: 43 times | Joined on Mar 2014
#65
Originally Posted by skvark View Post
You need better solar panel(s). For example my panel gives out 4x more juice per hour.
Sure, i even ordered stronger panel, but it's also thicker and wont be as nice as these thin stripes.

I'd still consider this as bug unless there is good explanation why the CPU does not enter idle state (my previous phones didnt have problem with this). The charging rate will slow down because of this very much.

As far as i can see the only workaround could be done by recompiling kernel, but i am afraid that this is quite dangerous becase we dont have kernel sources, flasher etc..
 
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#66
Originally Posted by psonek View Post
Sure, i even ordered stronger panel, but it's also thicker and wont be as nice as these thin stripes.

I'd still consider this as bug unless there is good explanation why the CPU does not enter idle state (my previous phones didnt have problem with this). The charging rate will slow down because of this very much.
Now this is guesswork, as I do not know the HW internals of the Jolla device so well, but if it follows the design of N9 at all, then the device has to be alive to monitor the battery charging process.

Some devices implement the charging all in the HW, for example the older symbian devices. On some devices the algorithms are run by SW in the main CPU.
 
Posts: 1,258 | Thanked: 672 times | Joined on Mar 2009
#67
When details on Jolla's TOH interface were announced, and it was speculated it could be used for solar charging and such, I always assumed one would have to implement it as solar panel + battery, with the panel slowly charging up its own battery, and then dumping that battery quickly to jolla, in order to minimize extra energy use for phone.
 

The Following User Says Thank You to shadowjk For This Useful Post:
kimmoli's Avatar
Posts: 562 | Thanked: 2,744 times | Joined on Dec 2013 @ Espoo, Finland
#68
hmm... could a thin supercap utilised here? to allow fast discarge/charging cycles.
Annoying thing here will be the constant notifications charging/not charging, unless some tricks could be made. maybe need to do some lab-supply-experiments, iirc if voltage is lowered to certain level, it will say it is charging, but draws minimal current.
I imagine this is place for small micro to take care of the charge cycling, monitoring charge level of supercap and discharge to the phone.

first google result: http://www.cap-xx.com/
__________________
TOH ideas, concepts and creations since 2013 toholed tohuart toheink Heebo tohIRi i2ctool tohmm LeTOH FMTOH
 
Posts: 29 | Thanked: 43 times | Joined on Mar 2014
#69
Originally Posted by juiceme View Post
Now this is guesswork, as I do not know the HW internals of the Jolla device so well, but if it follows the design of N9 at all, then the device has to be alive to monitor the battery charging process.

Some devices implement the charging all in the HW, for example the older symbian devices. On some devices the algorithms are run by SW in the main CPU.
Yup, we'll have to figure out how it's done in Jolla. If it's done in SW it could be maybe improved by rtc wakeups?
 
Posts: 29 | Thanked: 43 times | Joined on Mar 2014
#70
Originally Posted by kimmoli View Post
hmm... could a thin supercap utilised here? to allow fast discarge/charging cycles.
Annoying thing here will be the constant notifications charging/not charging, unless some tricks could be made.
The trick is quite simple:

killall -s STOP upowerd

it's more hack then trick, but it works Maybe the charging could be controlled by simple circuit on i2c pins - you could disable the charging notification before you start charging from the supercap.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 23:35.