My new device (a used + worn-out HTC S710/VDA V)

Well - I gave up on the weight issue and returned to an HTC device. I could get hold of a cheap used and worn out Vodafone VDA V (branded HTC S710 aka "Vox"). This now works as expected - despite I have to say that the noise level is still higher than on my old devices. Since the maximum volume is however high enough to compensate for a little attenuation in the music-adapter to get the noise to a low-enough level for the physical environment, it does not matter much.

If anyone gets hold of information how the BenQ E72 headset volume can be increased beyond the poor original state - let me know, please - I am really willing to give it another chance then. You can contact me via this blog or in the linked forums on the left side - my user name is tobbbie there.
.

Good bye my little friend...

Now that the device showed it cannot serve as a good music player, I have finally returned it to the vendor. I very much regret this, as there is no other device on the market that fits my simple scheme still.

• Music Player (no noise at low volume, still high volume possible)
• SDHC compatible
• no touchscreen
• Windows Mobile
• WiFi
  
• light-weight (less than 100g)
  
• and yes - it has to work as a mobile phone too :-)
  

My only choice seems to be giving up the "non touchscreen" option - next candidate is the LG KS-20 (Corona) - sigh - another set of investigations to do. Luckily the community for the LG is larger than for the BenQ.

High noise level :-(( on headphone

Now that finally I have all elements together to actually use the device for its main intended purpose (most of the time it will be used as a music player) I had to discover that the base-level of noise is unacceptable high. It is impossible to listen to music with low volume, e.g. in a silent environment, as simply the base noise is filling your head. This of course depends on the sensitiviy of your headphones, but is already audible on my Koss Porta Pro (60 Ohms) and unacceptable on my CX-300 (16 Ohms). On my old Tornado (and even my Amadeus) it was just audible with the CX-300, but not with the Porta Pro.
I am much disappointed and only a very slight hope remains to increase the volume on one hand (the max volume is rather low compared to my Tornado) and decrease the sensitivity of the headphone on the other (serial resistor).
Sigh...
Seems to develop to a never ending story with this device :-( and I suspect that there will not be a happy end.

[Edit 20090108]:
I have not found any option in the registry for increasing the sound volume when the headset is connected. The sometimes reported action to set the valule in HKCU\ControlPanel\Volume to Volume=0xffffff is nothing but the place for the System Volume that is adjusted with the volume keys anyway. Even snapshotting the registry with and without headset connected and comparing these has not revealed an option.
As the noise level cannot be changed - and the volume not increased, I fear that was my short love story with this little gadget :-(
It still fits for anyone that has a lower sensitivity headset and does not require higher volume sound level there.

.

Replacement batteries, compatibles + offers

While not really needing it now (I have yet to observe real-life behavior of the battery when I will use the device on a daily base) - it is still good to know the options you have :-)
So checking the various ebay offers, it seems that the following BenQ models share the same battery: C31, S81, E81 and E72 (Kyocera E4000). At time of writing the following ebay shop delivers the best price.

USB Headset connector - solved

Just see the updated post "Hacking the USB Headset connector".

Steer your charging options

[updated 20090105, see below]
I remember that for the HTC Tornado there was a setting to disable USB charging - to allow the battery to continue discharging while connected via USB (useful or not is another topic - see further down). As long as the device is switched on, the USB and Battery drivers of the Windows Mobile operating system have control of the charging functions. When switched off, the "hardwired" functionality of the BootROM code takes over. The following only affects the options while the OS is active.

My search in the extracted modules for registry options has revealed in the usbotg.dll the elements:

• USBChargeEnable
  
• USBForceCharge
• ACCurrent
• USBCurrent
  

They are all not present by default and need to be created (only if necessary) as "DWORD" values in the registry path HKLM\Drivers\BuiltIn\UsbOtg.

As written further down, my (refurbished) device was delivered with a non BenQ charger (a Blackberry with exchangeable plugs) - so I continue to use my old HTC Tornado charger which also connects via miniUSB. The systematic (lengthy) investigation has shown the following logic for the registry variables above:

1. none present: device charges from any source (just like when switched off)
2. Charging via USB connection cannot be disabled without also disabling the HTC AC Adapter (USBForceCharge = 0 disables both), but
   
3. charging via HTC AC Adapter can be disabled, still with USB charging possible (set USBChargeEnable = 1; if you want it the other way round - it will not work, I have tried all options)
   
4. Charging via Blackberry AC Adapter can be configured independently of the USB Charging (and follows an understandable logic), I suspect the same will also apply for the normal BenQ/Kyocera AC Adapter.
   
   • ACCurrent = 0 disables the charge via the (BB) AC-Adapter
   • USBCurrent = 0 disables the charge via the USB cable of the linked PC

I have created a table with all options I tried out but It is not usefull to post it here. If you can confirm my assumptions about the BenQ Charger would be helpful.

Now the question "is it useful to discharge the battery (completely) before charging again"? After consulting many resources around the web I strongly believe "no". When busy with the batterylevel problems of the device I have collected some links - make your own decision, see here: 1, 2, 3

I know that some are keen to get hold of the Flash animated homescreen that is present in the Asian ROMs (and I suspect that most parts can be extracted from an available - yet incomplete - dump) but mind that everything that happens automatically on your device will need the CPU and battery. So I recommend reading this article at wmexperts.com.

[updated 20090105:]
After running down the battery completly, I have discovered that the charging current (get it from HKLM\System\State\Battery "ChargingCurrent" value while charging) is limited to roughly 450mA when connected via USB (also for the HTC Charger) - the USB standards allows a maximum of only 500mA anyhow. When connected to an AC Adapter (that is recognized by the system as such - e.g. my Blackberry AC Adapter) then the current draw is higher - I have seen 650mA when the battery was recovering from "emergency switch off".

The lowest voltage until which the battery is used in the E72 is very low compared to my HTC. The E72 uses the battery down to 3.356 V, while the HTC switches off already at 3.570. This may sound like big difference, but it is not in terms of capacity when you look at the discharge curve for LiIon rechargeable batteries. The battery resources I have seen on the web (see links further up) usually recommend not to use a battery below 3.6V to preserve a good lifetime.

ROM dump + extraction of files

Hi - despite you can find all what I will write below also at XDA Developers (see related links on the left side) - It took me some time to understand which program does what and which are bare necessity and which are the "nice to have" things (which I do not yet care about).
As already mentioned in my notes about the bootloader, you just need two sets of tools that will do the jobs of dumping the ROM from the device (itsutils) and then extracing (WM5editrom) all the files from the just dumped ROM image to your PC.

Dumping the ROM from the device:
This is done with the itsutils from "itsme". There is one important thing to care about when doing the dump (and it must be stressed - as other wise the dump will be incomplete). OK, so now the step-by-step action list:

1. Your device must be "application unlocked". If you do not know what that means - stop here and get a little more comfortable with what Windows Mobile is about.
2. Download the itsutils (sometimes also called XDA-Utils) from the link above.
3. Extract them to a working folder on the PC.
4. Connect your device via Active Sync if it is not linked yet - wait until sync is complete.
5. Now we need find out what file-volumes are known at the device. Get into a CMD window on your PC in the directory where you have extracted the itsutils. Enter the command "pdocread -l" (no quotes) and confirm on your device that it may run an "unknown" program. You will see a list of output similar to this:
   

   Copying F:\Share\_Smartphone\ROM + Tools\itsutils\itsutils.dll to WCE:\windows\itsutils.dll
   36.00M (0x2400000) TrueFFS
   | 2.06M (0x20fc00) Part00
   | 2.69M (0x2b0000) Part01
   | 31.25M (0x1f40000) Part02
   19.00M (0x1300000) TrueFFS
   | 2.06M (0x20fc00) Part00
   | 2.69M (0x2b0000) Part01
   | 31.25M (0x1f40000) Part02
   3.75G (0xf0300000) DSK1:
   | 3.75G (0xeff00000) (label of your memory-card)
   STRG handles:
   handle 0fb7c76a 3.75G (0xeff00000)
   handle 0fb237ee 18.98M (0x12fc000)
   handle 8fb7ca86 31.25M (0x1f40000)
   handle afb7c88a 2.69M (0x2b0000)
   handle efb7c866 2.06M (0x20fc00)
   disk 0fb7c76a
   0 partitions, 0 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   disk 0fb237ee
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   disk 8fb7ca86
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 ee 22 02 01 0a 27 03 95 07 06 05 a0
   disk afb7c88a
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 ee 22 02 01 0a 27 03 95 07 06 05 a0
   disk efb7c866
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 ee 22 02 01 0a 27 03 95 07 06 05 a0
   

   I have issued the command above for my Tornado device - not the E72 (which is in a "lets see how long it survives in standby without charging" test), so it will look different, but the important thing to notice is the length of the part02 partition (marked in bold red) above. You need this for the command to actually dump the ROM in the next step.
6. Now enter "pdocread 0 (your-value-here-no brackets) part02.dump" like I did here:
   

   pdocread 0 0x1f40000 part02.dump
   CopyTFFSToFile(0x0, 0x1f40000, part02.dump)

   You see above that it starts to copy date from the device to the file. This takes several minutes - you can watch the file grow in the Windows Explorer if you like to - so be patient until you see the prompt again.
   That's it for extacting the ROM - nothing more to do if you just want to share it with others. Put "part02.dump" in a ZIP/RAR and label it with what you know about your device (Kyocera or BenQ - Windows Mobile Version - ROM Version from "Settings - About: Image Version, Build Date, Build Time).
7. If you want to dig deeper a little you may want to extract the contents of the just dumped ROM image. For this you need the WM5EditRom tools (imgfs_tools). Extract them in a different folder (e.g. aside the itsutils) and move the part02.dump file there as well.
8. Now enter again a CMD window - this time in the folder where you have extracted the imgfs_tools and moved the part02.dump. There enter "prepare_imgfs part02.dump -nosplit" resulting in:
   

   Searching for IMGFS start... Found at 004C0000
   Dumping IMGFS ...
   Done!

   This has created two files: imgfs_raw_data.bin and imgfs_removed_data.bin which is empty. The first is now the complete ROM filesystem and needs to be further decomposed with the next command.
   Again mind that the examples above are not originating from an E72/E4000 (WM6) but from an HTC Tornado (WM5), so your filesizes and addresses will be drastically different.
9. So now the last command for decomposition: Enter "viewimgfs imgfs_raw_data.bin > viewimgfs-output.txt" (no qoutes) on the commandline and press enter. As the command output is redirected into a file (using > filename) you will see nothing - but after a minute or so the command prompt returns. You can now examine the file "viewimgfs-output.txt" for errors (there should be none).
   The command has created a new directory below the current - called DUMP. Within this directory you find all files and modules that have been part of the ROM filesystem. You will notice that some files are just there like in the \windows directory of your device and others are decomposed in own directories. I am not expert enought to tell details here - consult the various discussions abuot ROM cooking at XDA Developers.
   Mind that often the reconstructed *.dll or *.exe in the module directories cannot directly replace their ROM counterparts.
10. The toolset contains also powerful tools to reassemble an imgfs and reconstruct an item to dump back to ROM. For me there are still too many things I don't understand - so I stop here describing anything more. Look up yourself at the referenced sources.
    

Still several questions stay which require to dive deeper in the water of understanding how the ROM filesystems on WinCe work before I recommend anyone to dare writing anything back to the device. Things I need to understand include:

• What do the other partitions of the filesystem contain?
• How are the partitions of the filesystem depending on each other?
  
• What is in the part of the ROM dump before the actual imgfs?
  Here I suspect the boot-image and the Radio ROM - but this needs to be confirmed still.
  
• Can the imgfs be cut down to use only the size of the actual (compressed) content?
  In my case the dumped ROM contains only FF starting from address 0x3569250 until the end at 0x4d0bfff - this makes roughly 24 MB of wasted space that was surely intended to hold other ROM options like localizations and programs. Would be good to get that as normal device installation memory.
  

Some interesting links (and pictures) around the net

When I was investigating if the BenQ E72 was a device for me - it was very hard to find any evidence if it had the option to attach a lanyard. Finally I found a set of pictures that told me where it was hidden, see the Taiwanese forum here (Google translated link).
Further squeezing out Google pictures search has also revealed some other interesting links that depict the history of the device's release roadmap. Initial pictures still show the BenQ-Siemens logo and a less glary screen, e.g. here or here or here or here.
It is interesting to note that marketing plans had initially thought about a sliver model, as can be derived from the existence of shop dummies - seen here. Even a black-silver version seemed to exist in the plans, as can be seen here (looks like photoshop-ed version though).
While the device is not really cutting edge technology any longer - plans originate in the 2006 range - I do not have much hope for any further serious updates for this little gadget. It seems though that BenQ (or the mother QisDa) have found cooperations to sell a few of these units around the world. Kyocera sells them as E4000 - and I have even seen evidence (Google translated link) that a Windows Mobile 6.1 version exists for that (despite the Kyocera site tells it is WM6 only). Thanks to the Polish E72 community forum (see left side + here - thanks for revealing the source!). Maybe I can convice some over there to dump us a ROM of that?!