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

Rockbox mail archive

Subject: RockBox - feedback (fwd)

RockBox - feedback (fwd)

From: Björn Stenberg <>
Date: Mon, 4 Mar 2002 23:18:24 +0100 (CET)

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
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
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:
_at_ 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
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.
Neil Marley,
Email: neil_at_tarboosh/biz
Received on 2002-03-04

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy