dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: RockBox - feedback (fwd)
From: Björn Stenberg (
Date: 2002-03-04

Here is a mail that was sent to me but is of interest to the list:


---------- Forwarded message ---------- Date: Mon, 4 Mar 2002 19:45:06 +0000 From: Reply-To: To: "" <> Subject: RockBox - feedback


Just a note to say how useful I've found your site and the RockBox project notes etc and thanks.

I've had a JB6000 for quite a while now and had sworn that I would not go delving inside it - until I recently decided that it was too much trouble to choose the 110 CD subset I would load before going on long travel trip (I use it on one-week liveaboard scuba-diving trips) and that I'd rather just load my entire CD collection and be done with it. So... having just competed a 30GB disk upgrade and planned some small modifications/improvement I wanted to do, I thought I'd repay the help I got from your site and activities by providing some of the info I've gleaned.

My background is mainly hardware systems with some software so I hope that some of the following helps compliment the wealth of programming experience the project seems to have acquired.

i) RAM upgrades/Use of the HD buffer cache:

Although it seems, at first, intuitively obvious that there is benefit to be gained by minimising the amount of disk access - I don't believe that it will return the sort of dramatic benefit people expect - certainly not enough to warrant any serious hardware surgery. Surprisingly - the JB design is quite well balaced in this respect. The following (rough) outline explains this (based on some measurements and assumptions):

Battery capacity 1500mAHours (standard, can optionally install 1800mAH batteries). Note that this capacity isn't fully utilised - since the JB powers the HD direct from the 'raw' battery voltage, it gives-up on the batteries before they reach terminal low voltage.

a) Nominal JB consumption in playback: 100mA (normal into line-out only) + 25mA (headphones - varies by volume etc) i.e. around 125mA with no disk activity or backlight (adds another 20mA while it's on). This varies a little and actually increases as the batteries go down (the switching converter in the JB draws more current to maintain the internal supply voltages). I also suspect that playback at lower data rates would consume less (these figures are my measurements with 160kb/s MP3).

NOTE: Based on the above - even if here were NO disk access, the normal replay battery life would only be approx 1500mAH/125mA = 12 Hrs or 15Hrs with line-out audio only.

b) HD access increases consumption depending on the MP3 data rate and memory buffers as follows:

@ 160kb/s MP3, the 2MByte RAM buffer represents a 100 second cache. The JB won't run this empty (risks interruption to replay), and some of the RAM is also used by the internal software ( I suspect that the Archos.Mod firmware upgrades are actually run from RAM). My own JB spins the disk-up every 1min 30 seconds so this consistent with this.

On spin-up, seek, and while moving the heads the HD draws, typically, an additional 500mA or more. While just spinning & reading sequential sectors, this drops to around 250mA. On my experience the former takes about 2 secs and the latter about 3 for a normal sequential read to top-up the RAM during replay.

The average additional consumption from the HD on this basis is then ((2s*500mA)+(3s*250mA))/90s = 20mA (approx). i.e. less than 20% of the JB normal consumption on playback.

Adding this to the replay figures produces an expected battery life of 1500mAH/(125+20)mA = 10 hours.

c) Conclusion:

With no HD access the expected max battery life would be 12 hours. With normal HD access this drops to 10 hours.

These times can be extended for lower MP3 data rates but will also be shortened by use of the backlight or changing settings (the JB immediately accesses the HD to update the stored settings in the first disk sector - as this involves a seek to the beginning of the disk, this is quite a heavy load).

On this basis - lowering the HD access by increasing RAM or using the HD cache can AT BEST add about 20% to the expected battery life - you can acheieve a similar effect by replacing the batteries with 1800mAH units or reducing the MP3 data rates you use?

Note that to use the disk RAM cache (my 30GB unit has a 2MB cache) would involve keeping the HD in either idle or sleep mode instead of turning it off completely when not used, as is done at the moment. The HD consumption in either of these modes is substantially higher than the average 20mA which results from the periodic spin-up and down approach so this would make the battery-life worse, not better.

ii) RemoCon:

Nice project. If anyone is interested in a simple RS232 serial to JB logic level interface - I have just finished a project which needed development of exactly this (to interface PC and PDA data loggers to dive computers).

It is a very simple circuit powered from the RS232 (no batteries needed). I need to scan- in the circuit and I'll send-on or post on a web-site. It should be a good development tool - particularly as you can debiug the interface using a terminal emulator on a Palm PDA.

I also found that I could get the 4-pole jack plugs for this from my local Maplin in the UK - I'll forward a part#.

iii) Disk upgrade procedure:

I notice that the link for this at doesn't seem to work anymore. I took some notes and pictures as I did mine and could put-up a web-page if there was enough interest?

Note that the hardware build for mine was obviously a bit later than yours so the pictures may be useful in any case?

iv) Replacing of output capacitors to improve the audio (bass) performance:

I was interested in this but, again, the link is dead. Does anyone have a copy of this or can they point me at the location of the relevant capacitors on the JB PCB?

vi) Nice to have's:

* Stop that 'clunk' on audio when the JB turns off.

* A simple serial read-out of the display text on the RemoCon pin (you can do a combined Tx/Rx on a single line with half-duplex operation - my serial interface would support this as this is exactly the way the Dive Computers it works with operate.) to allow a 'smart' remote with display.

* Develop the above to an infra-red RemoCon.

* A copy from CompactFlash drive ( they use a very IDE-like interface) to HD to allow the JB to be used as an archive for Digital Camera memory cards or to top-up CampactFlash based MP3 players.

* Cache any settings changes until the next normal disk access rather than spinning the disk up just to save the settings.

* A firmware 'hack' toolbox allowing modular changes to the firmware event handlers by hooking into the jump-tables. This could a more efficient way of producing software mods than rewriting the whole of the firmware including IDE drivers etc? This is the approach taken by e.g. hackmaster on the Palm PDA's.

* The new version 5.07a firmware does cache the directory/folder info while you're browsing providing scanning and allowing the disk to spin-down until you select. It doesn't then keep it in RAM once you start to play a track, however, so if you then select another track the disk keeps spinning. It would be better to cache the directory information on power-up and keep it in RAM so that all selection is done from RAM and the disk only spins-up as you select tracks to play.

Regards, Neil.

Neil Marley, Email: neil_at_tarboosh/biz

Page was last modified "Jan 10 2012" The Rockbox Crew