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 
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 


      [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