Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
oid_maps:
OK, first delay 19, second delay 4 works for me (fuze v2).
How I tested: Just switching on the device and see if in "hold"-position screen stays dark.
Are there more/ special conditions I should test?
oid_maps:
--- Quote from: saratoga on January 16, 2016, 07:13:26 PM ---
--- Quote from: oid_maps on January 16, 2016, 06:27:55 PM ---
--- Quote from: saratoga on January 14, 2016, 06:10:57 PM ---Adding the delay fixes boosting (well played for a few minutes at least).
Removing the second delay causes immediate reboot.
I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.
Edit: Both delays set to 10 works pretty well, will try other values:
http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z
Edit2: diff: http://mit.edu/mgg6/www/amsv2_scaling_v10.patch
--- End quote ---
Confirmed: For my fuzev2, both delays to 10 does _not_ work
--- End quote ---
If you're referring to the 10 delay above, thats for the ClipV2, it won't do anything on the Fuze.
--- End quote ---
Ah, OK. That wasn't clear from your writings, and since we were discussing fuzev2 and you didn't state otherwise I assumed you meant fuze v2.
saratoga:
I pushed the updated delays for the clipv2. If 19,4 are the lowest values that work on the Fuzev2, should I commit 20,5 to be safe? Or maybe even 22,6 just in case since we only tested on a single device?
Mihail Zenkov:
I think 20,5 should be good for start. If we start with 22,6, we do not dare to reduce it in the future and do not know optimal value.
saratoga:
One question, any idea why such a long udelay is needed with frequency scaling? I'm surprised that button read out should be so dependant on CPU frequency.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version