Bug #1024 (oscillating re-camping), a possible solution.
Joerg Reisenweber
joerg at openmoko.org
Fri May 29 22:58:53 CEST 2009
Just to mention it once again, and to stop a possible stampede:
AT%sleep=2 (sw-fix[1]) has fixed recamping reliably for 100% of affected
devices. Not all devices suffer from #1024, actually it seems it's only a
small percentage. FSO is capable of switching to AT%sleep=2 even
automatically[1].
Last not least: probably a better battery management will have more positive
effects on standby time than fixing #1024 in hw and using AT%sleep=4 all the
time. First raw estimations seem to suggest there's an increase in standby
time from maybe 60h with sleep2 to 75h with sleep4. If your standby time is
shorter than these figures then even percentage of difference gets *smaller*
(e.g. like 20h vs 21h = 5%, instead of 60/75 = 25%), due to savings from
sleep4 becoming negligible compared to higher suspend consumption of whole
system.
cheers
jOERG
[1]http://git.freesmartphone.org/?p=framework.git;a=blob;f=conf/example/frameworkd.conf
[framework.git] / conf / example / frameworkd.conf
101 # if you have a ti_calypso, you can choose the deep sleep mode. Valid
values are: never, adaptive (default), always
102 ti_calypso_deep_sleep = adaptive
find this file in /etc/frameworkd.conf on your Neo.
If you're concerned about #1024 and the short connectivity loss that might
happen until frameworkd senses it has to switch to sleep=2, then change to
ti_calypso_deep_sleep = never
which sets calypso to AT%SEEP=2. "always" is eqiv to AT%SEEP=4. "adaptive"
means frameworkd is sensing #1024 recamping and switches from sleep4 to
sleep2 automatically. This sensing might take a minute or two.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20090529/1be000d6/attachment.pgp
More information about the hardware
mailing list