Sansа Clip Zip - Improve battery life

[saratoga]

Mihail:  Could you post the most up-to-date version of your patch?  I'd like to do a little testing but I'm not sure where you are at with the code right now.

Thanks.

[Mihail Zenkov]

I don't work on this patch last few months.

I have same problem with usb like in keyb_gr last posts. But ...
1. it hard to reproduce - it crash one time for 10-30 connect/disconnect and probably only when we write something
2. not sure is it one problem or few - most time player just freeze with screen on, but one time I have hard lockup - in this state player have screen off and can't be reset by power button, but disconnecting battery (or drain battery like keyb_gr do) help.
3. probably it not related to this patch

In any case I want try debug it. Is rockbox have easy way to write/append in to file (log)? I want find in which function player freeze.

[johnb]

I guess it is time for me to report back. I have been using Mihail's version: 983c808M-150809 on my clip+.

During regular usage I have not seen any quirks. I am not using any fancy EQs though, just replaygain, sometimes treble & bass, timestretch in podcasts. Formats: mpc, mp3, flac, opus

But I had three incidents in the context of USB:
2 times after safely removing the player (Win7 Pro) I still had the USB logo in the background and a rectangular box over it saying "loading " (I don't remember if it said firmware or file). I had to press power for several seconds for it to recover.

One time when connecting to USB there was a screen saying "prefetch abort ...".

As this happened over the past 2-3 months, I still consider it usable for me. I did have USB problems in-regularly with other builds before too.

P.S. I usually power the player on before connecting to USB.

[oid_maps]

* amsv2_scaling_v9.patch.txt

Your patch ('amsv2_scaling_v9.patch.txt') deactivates the functionality
of the "hold" button on Sansa Fuze v2: It is simply not functional
anymore, if I operate it it behaves just as if it has not been operated.

Without the patch, it works.

I am using rockbox version ad5e5c4M-151204 (according to the menu item
"System" -> "Rockbox Info" on the device itself),

it is compiled from the rockbox-source from
'git://git.rockbox.org/rockbox', git-checkout done at 2015-12-04 09:52
UTC, last commit was, according to 'git log', at 2015-11-17 21:30:31
UTC by Marcin Bukat:

  commit ad5e5c42fb00334ec0e9b0e9e8c69c4b7d05ac7a
  Author: Marcin Bukat <marcin.bukat@gmail.com>
  Date:   Tue Nov 17 22:40:31 2015 +0100

      hwstub: fix atj213x dsp lua code
   
      Change-Id: I5fbd1799b958bedbe74f91bdcdd8a544e15d2a78

[Mihail Zenkov]

oid_maps
Can you check amsv2_scaling_v9.patch.txt  + rockbox-gui_boost.patch.txt?
http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910

P.S. I also recommend use rockbox-usb.patch and rockbox-restore_irq.patch if you use amsv2_scaling_v9.patch.txt.

[oid_maps]

oid_maps
Can you check amsv2_scaling_v9.patch.txt  + rockbox-gui_boost.patch.txt?
http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910

P.S. I also recommend use rockbox-usb.patch and rockbox-restore_irq.patch if you use amsv2_scaling_v9.patch.txt.

Also with all those four patches ("amsv2_scaling_v9.patch.txt" + "rockbox-gui_boost.patch.txt" + "rockbox-usb.patch.txt" + "rockbox-restore_irq.patch.txt") the hold switch is without function.

This might practically decrease battery life, since every accidential turn of the wheel will activate the backlight.

[oid_maps]

oid_maps
Can you check amsv2_scaling_v9.patch.txt  + rockbox-gui_boost.patch.txt?
http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910

P.S. I also recommend use rockbox-usb.patch and rockbox-restore_irq.patch if you use amsv2_scaling_v9.patch.txt.

Also with all those four patches ("amsv2_scaling_v9.patch.txt" + "rockbox-gui_boost.patch.txt" + "rockbox-usb.patch.txt" + "rockbox-restore_irq.patch.txt") the hold switch is without function.

This might practically decrease battery life, since every accidential turn of the wheel will activate the backlight.

No idea what could be changed in the patch to regain function of the hold switch?

[Mihail Zenkov]

Probably we have problem with delay. Try attached patch.

[oid_maps]

Probably we have problem with delay. Try attached patch.

Does not work, but there are some "symptoms" now:

If I switch to "hold", screen goes black very shortly (like a "black"-blinking), then is on again. Sometimes immediately, sometimes after ca. 2 seconds, or anything in between. If the switch stays in hold position, it infinitely continues to blink black, with varying pauses between the blink, anything in between ca. half a second and several seconds.

It seems that, if the device is doing less (no playiing, no scrolling text on the screen), the black-blinks are less often, even "never" (until the timeout for normal display-off occurs).

The device can be operated with the switch in "hold"-position.

[Mihail Zenkov]

Another patch with bigger delay:

[oid_maps]

Another patch with bigger delay:

Yes, that does the job, thanks.

Why are the delays important? Race conditions?

Does it make sense if I try to "tweak" the delays as low as possible, or is it negligible effect if the delay is a bit bigger than necessary?

[Mihail Zenkov]

Yes, that does the job, thanks.

Thanks for report and testing

Why are the delays important? Race conditions?

Fuze v2 have hold and power button on same pin. We need some hack to detect hold state. This hack sensitive to delays.

Does it make sense if I try to "tweak" the delays as low as possible, or is it negligible effect if the delay is a bit bigger than necessary?

Yes, it will be good. When we check buttons state we disable irq. So better have this delays low as possible.

[oid_maps]

Does it make sense if I try to "tweak" the delays as low as possible, or is it negligible effect if the delay is a bit bigger than necessary?

Yes, it will be good. When we check buttons state we disable irq. So better have this delays low as possible.

There are two delays; the second one in your patches is half the time of the first one. How do the delays interact? Should I try arbitrary combinations of both (so it is a two-dimensional problem), should I keep the factor 2 (which makes it an one-dimensional problem), or should the second one be in some, but not strict, relationship to the first one?

[Mihail Zenkov]

First, try find lower value for first delay. Then try same for second delay.

[oid_maps]

When just changing the patch and compiling with changed values, everything "up to date" -- which binary to upgrade to the device? fuzpa.bin, or the .rockbox/-tree? (Currently, I copy both over to the device.)