SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[Jennifur]

Also the screen is a bit too wide and battery icon hides under the top edge of the screen. Probably OF does not use all available pixels.

I'm experiencing this too, but it might just be the screen isn't aligned properly. The top left seems a bit higher than the top right. As soon as I get it open I'll find out for sure. On that note. Can anyone give me a link to show me how to get this thing open?

Also, can I just keep it on hold and play all my music instead of an album for the battery bench? I usually keep it with me and listen to music most of the day and would really dislike not having it with me.

[funman]

On fuzev2 3 minutes of backlight will get the battery level down by 0.27% so it's small enough to ignore it.

http://www.anythingbutipod.com/archives/2008/03/sandisk-sansa-fuze-disassembly.php : steps to open fuzev1, but keep in mind that it's very easy to break it or to not be able to remount it.

EDIT: I have 2 benches of fuzev2 already: 18h20 playing mp3, and 8h20 playing mp3 with LCD on.

There is a different setting for current use when recording, I'm not sure if it's important for flash targets like the Sansas, but it would be nice to have a bench when recording just to be sure (record the microphone since FM seems to be buggy)

[Llorean]

On fuzev2 3 minutes of backlight will get the battery level down by 0.27% so it's small enough to ignore it.

That would mean the player can power the backlight for 18 hours if doing nothing else. Is this really true?

[funman]

On fuzev2 3 minutes of backlight will get the battery level down by 0.27% so it's small enough to ignore it.

That would mean the player can power the backlight for 18 hours if doing nothing else. Is this really true?

I have 2 benches of fuzev2 already: 18h20 playing mp3, and 8h20 playing mp3 with LCD on.

18h20 - 8h20 = using backlight reduce capacity by 10 hours

100 * 3 / (10*60) = 0.5%

using the backlight for 3 minutes will use an additional 0.5% of the battery (difference with the previous 0.27% probably comes from rounding)

[bilditup1]

Dual boot works like a charm now with the the latest commit. Per saratoga, mkamsboot (the patcher) in the rbutil folder must be built from the source, as well as the bootloader itself (../tools/configure, 63, b for Fuze). The precompiled version of mkamsboot at download.rockbox.org only works with firmwares older than 02.03.31 (the current one).

My battery gave out at 15:48 without backlight (except for a few checks); have yet to make the graph, sorry.

[funman]

Please also post the complete battery_bench.txt and tell which settings you used (volume, DSP, eq) and what files you played (some codecs are more intensive than others)

[Timar]

The build 25836 seems to have massively improved stability for my Clip+. I get none of those weird crashes/hangups anymore I got frequently with 25799. Did you make any changes regarding stability issues (4-bit bus!?)?

Battery bench is running

UPDATE: I have the same problem described in the adjacent post  - battery only charges 2/3 max with rockbox

[notlistening]

Ciip+ again,

Charging the battery stops at 63% and in rockbox info shows 63% even though the charger is still plugged in, shouls say charging. This problem has existed for about a month. OF reports 67% when checked and the OF will continue to charge beyond this limit.

NL

[bYOndo]

clipv2, r25836-100505
update on "pitch" function unstability: when the player crashes (but it doesn't everytime...) it gives me:

Code: [Select]

Undefined instruction at 30048CC4

when it does not crash, I can go back to WPS and file duration isn't scrambled anymore, it's always correct.

Massimo

[funman]

Code: [Select]

Undefined instruction at 30048CC4

Points to the instruction right after a "bl set_cpu_frequency"


I have opened FS#11246 which should get a bit more battery life on AMSv1 and hopefully on v2 too (still testing).

Can you give it a try and also comment on where to run this code ?

sdram code is only in the bootloader but I have put it in system_init() to avoid the need to update bootloaders.

[FlynDice]

re: abi forums and "temp brick" reports.

Please don't be alarmed by ^^^ there are no bricks being reported!  Just a temporary unresponsiveness for 2-3 mins.

From practical experience I think this is related to the v1.0 bootloader.  I was using one I compile myself for awhile and then last week tried the v1.0 to see if it made any difference with some of the things I was working on.  It didn't but I started to get these "temp bricks". Holding the pwr button for 10 secs did not reset but 20 secs did reset.  I'm now running a bootloader  produced from r25821 and have not had any more of these "temp Bricks" so I've got the feeling this is bootloader v1.0 related.

[bilditup1]

I got lazy about this graph thing. Anybody have a simple tool to do it for me?
My battery_bench.txt is attached.

My Fuze v2, build 25836, quit at 15:48:06, after starting at 93% (but 100% according to the OF). This is with 5-track alt-present-extreme LAME-encoded mp3 album that was 40 minutes long. Flat EQ, no replay gain, and volume at -20db.

In other news - I tried playing some NSFs and SPCs today on a whim. The NSFs played fine, but the scroll light was at the disco. SPCs played at an absurdly low volume, and also had scroll light problems. I don't know if these are issues specific to this port or Rockbox in general. While plugged in, it looks like the light now comes on and off at random during mp3 playback, too.

I've experienced a few crashes while scrolling through menus, with and without music playing, but otherwise, everything looks stable. Will investigate charges of volume being too low next - yay dual boot!

[funman]

re: abi forums and "temp brick" reports.

From practical experience I think this is related to the v1.0 bootloader.

Very likely, there were some fixes added after bootloader release: I think of the cache functions particularly, and also some race condition with the PMU ascodec register.

I got lazy about this graph thing. Anybody have a simple tool to do it for me?

Have a look at gnuplot

My battery_bench.txt is attached.

My Fuze v2, build 25836, quit at 15:48:06, after starting at 93% (but 100% according to the OF). This is with 5-track alt-present-extreme LAME-encoded mp3 album that was 40 minutes long. Flat EQ, no replay gain, and volume at -20db.

Thanks, did you force CPU boosting?

I had 18:20 on my fuzev2 (starting with 100% in OF and 94% in rockbox)

While plugged in, it looks like the light now comes on and off at random during mp3 playback, too.

Yeah this is normal, read the last pages of this thread.

[yimmu]

Battery benchmarking for Fuze v2, build r25814.
Volume was at -14db, playing a 17 track mp3 album at 128kb/s which was being played off a µSD card, with the equalizer was set to the preset 'rock'.

[bilditup1]

I forced nothing; I'm not quite sure how to boost speeds at all. Maybe the backlight was on when I wasn't looking (in my pocket). Maybe I checked the player one too many times. Maybe it's because the tracks were on the microSD? Should I try again? Will look up gnuplot.

I'd like to echo problems with recording (panics right and left when trying to change options) and charging (stops at ~67%).

-e