Exchanged two SMD resistors near IR module (the 33Ω and the 10Ω) for smaller values increasing current from 77mA to 150mA.
I’ve yet to perform conclusive tests to see if IR range has increased much, but the initial feeling is that it hasn’t.
There is scope to further increase the current, but until I’ve tested this first modifications effects I won’t know whether that would be worth it.
Treo SMS receipts are a missing option from the 2.12 ROW ROM when using T-Mobile.
I’d like the option of having them but here’s why we don’t get to :
a) nexter.prc calls CarrierCustomisation.lib to get the options list.
(PmCarrierCustomisation.prc) CarrierCustomisation.prc lives in ROM, on a even a soft-reset it extracts and overwrites any existing CarrierProfiles2 (CarrierDB ver 561 in the case of the 2.12ROW) and NetworkProfiles2 from itself. These two files then live in RAM.
CarrierProfiles2 stores settings keyed on MNC,MCC pairs :
234,10 = O2
234,15 = Vodafone
234,30 = T-Mobile
234,31 = T-Mobile (also)
234,33 = Orange
The options follow as a comma separated list. For CarrierDB ver 561, T-Mobiles entries are as follows :
234,30,1,,>j,,,,,,,,,,,,,,,4emg`gib`cb_^aa,l ~(Li^>|$x3DC< smws53t?E$Grh`b,<kba,3a`,?bgl,?bgl,,0,:gkg,:gkg,,0,,,,,,,,,,,,,,,,,0,0,0,=ke,=hj,0,,,3a`,5b,,,8#z^smws'uB,1,0,4emg`gib`cb_^aa,l ~(Li^>|$x3DC< smws53t?E$Grh`b,<kba,3a`,,,3a`,5b,1,0,O_ 234,31,1,,8c,,,,,,,,,,,,,,,4emg`gib`cb_^aa,l ~(Li^>|$x3DC< smws53t?E$Grh`b,<kba,3a`,8bde,8bde,,0,,,,,,,,,,,,,,,,,,,,,0,0,0,=ke,=hj,0,,,3a`,5b,9$%(@DC4tplw<3t?E$,,8#z^smws'uB,1,0,4emg`gib`cb_^aa,l ~(Li^>|$x3DC< smws53t?E$Grh`b,<kba,3a`,,,3a`,5b,1,0,O_
d) One of the comma separated options above is spoiling our fun. But which one ?
Based on the fact we know field 19 is very probably “http://mmsc.t-mobile.co.uk:8002“, we’re looking at an encrypted string. It’s not an XOR, and though I know it’s a substitution cipher it’s not a straightforward one as different characters are being encoded to the same crypt-character.
This may not matter though as we could just take the CarrierProfiles2 file from a CarrierDB where SMS-Receipts are enabled for T-Mobile and compare and replace the values.
There are 72 values, though many are empty, a comparison of working CarrierDBs should reveal what field contains our grail.
Comparison of CarrierDB 292 and 561 shows fields 21, 64 and 72 are different.
Comparison of CarrierDB 292 and 549 shows fields 21, 64 and 72 are different.
234,30 and 234,31 are resource indexes 41 and 42 in CarrierProfiles2.
Modifying values in CarrierProfiles2.pdb makes no difference, perhaps they are cached on boot somewhere ?
Solution : Copy working CarrierCustomisation.prc version 549 into RAM, it survives resets and will extract a good CarrierProfiles2 into RAM. Use Resco Explorer or similar to copy from SD Card to RAM, Filez will not work properly.
Now that the RAM copy will extract a version of CarrierProfiles2 after each reset, we can edit the MNC/MCC keyed lists in it and see if there are other useful things we can enable.
Interesting links :
CarrierCustomization.prc containing CarrierProfiles2 version 549.
The new 2.11 AT&T ROM release has prompted me to take a look behind the scenes of the romupdater.prc and I’ve discovered a few interesting new things beyond the commands we knew already :
? / help (lists the very few commands we knew before)
low <directory> (Flash LowRider IPL,SPL,TPL and OS. From RAM or SD directory)
list (lists the ROM images)
lt (list ROM tokens)
->prnm – Product name (TREO680)
->hser – HotSync/Handspring serial number (PMGG0BCxxxxx)
->hwvr – H/W version (A)
->Gime – IMEI *beware the Mobile Phones (Reprogramming) Act 2002*
->BTid – Bluetooth ID
->crnm – Carrier name (ROW)
->revn – ROM revision (2.11)
->gmfl – GM flag (GM)
->CleS – Cameraless ID
->Skip – Skip camera ID
->KBlo – Keyboard localization
->TScb – Screen calibration
->GoUc – Network Unlock PIN
->GpUc – Operator Unlock PIN
->Gvlt – GSM voice life timer (240)
->???? – GSM data life timer
->???? – Warranty date code
->HTCM – ?no idea? (FC6B07E…)
->HRST – ?no idea?
->Nohr – ?no idea?
dt <token> (delete ROM token)
wt <token> <value> (write ROM token)
su (superuser mode)
superuser mode enabled
duinit (Device Updater modifies carrier settings?)
DuLibInitialize returned: 0x0000
rev [list] (Show hardware revision or list all IPL files)
Board ID: LOW
HW Rev: cvt
reset (Soft reset)
listcards (Lists the SD cards available)
Vol: 0x0002 Attr: 0x00000001
updatebinfs (Requires superuser mode)
updateipl <low-ipl-cvt.pdb> (Requires superuser mode)
Updating the IPL…
Updating from SD card… Comparing image with flash…
Diff at offset 0x00000000
18, F0, 9F, E5, 18, F0, 9F, E5
6C, 6F, 77, 2D, 69, 70, 6C, 2D
updatespl (Requires superuser mode)
updatetpl <dir index> <filename> (Requires superuser mode)
format [ace|angus|low] <force> (?)
Low MaxOS Size: 0x2100000
Low BinFS Size: 0x02400000
Checking os file size (/ROM/low-palmos.zip) …
OS size on SD: 0x00849D91
MaxOS >= 0x00849E00
>> You can flash your device
plist (NOT IMPLEMENTED)
hreset (*Hard reset*, requires superuser mode)
Fastboot mode enabled…
check [ace|angus|brahma] (No LOW option)
cleartokens (Clear ROM tokens)
hdread (?, brahma-only)
hdfill (?, brahma-only)
norread (?, resets device)
smallrom <filename> (?)
No file specified. Assuming /ROM/Brahma_Release_EVT1_efgs.smallrom
Smallrom updated unsuccessfully.
What do dvt,evt,p1,p2 refer to?
M-Systems EVT3 = ?
M-Systems Ace/Camino = EVT2 = Treo650 / Treo680?
M-Systems Angus = T5?
lt and wt are useful for avoiding the official ROM update version checks as we can modify both carrier name (ROW/CNG,ROG,etc) and revision number (1.09/2.11,etc)
|Card Type||VFS MARK||Device|
|Sandisk 512M Ultra II||292||Treo 600|
|Sandisk 1GB||221||Treo 650|
|Sandisk 1GB||437||Treo 650|
|Lexar 1GB 32x||687||Treo 650|
|Sandisk 1GB ExtremeIII||504||Treo 650|
|Sandisk 2GB||950||Treo 650 (FAT32)|
|Transcend 2GB 150x||656||Treo 650|
|Transcend 4GB 150x||697||Treo 650|
|Transcend 4GB 150x||525||Treo 650 (FAT32)|
|Transcend 4GB 150x||676||Treo 700p|
|Transcend 4GB SDHC||633||Treo 650 (FAT32)|
|Transcend 8GB SDHC (2)||694||Treo 650 (FAT32)|
|Transcend 8GB SDHC (6)||886||Treo 650 (FAT32)|
|Transcend 8GB SDHC (6)||920||Treo 700p|
|Transcend 8GB SDHC (6)||1071||Treo 700p|
|A-Data 8GB SDHC (6)||958||Treo 700p|
A quick note of where the power-on and power-off sounds are kept within the 680 ROM.
I had expected them to be WAV resources, but no, they’re MIDI.
HsSysResource.prc has them at resource ID’s 25002 and 25003.
Both are 152bytes each, the longest MIDI resource in there is 289bytes.
Varnishator.prc – gets the ROM token (ROW|ATT|etc) and calls CapLib.prc
CapLib.prc – Unpacks CapPackage.zip and parses CapData.xml
Varnishator.prc is probably called after a reset, depending on the comparison of the ROM token and the CapData.xml, the splashscreens are then extracted or not. If they aren’t extracted (because the ROM token is different), then the splashscreens in TelephonyUI_CNGW_enUS.lprc are used as default.
In terms of using this behaviour to create our own custom ‘varnish’, we are probably looking at modifying the XML to match whatever our ROM token is, and changing the JPEG’s included in CapPackage.zip.pdb.
Rebuilding of CapPackage.zip.pdb will be awkward though as the JPEG images will need to be split into record sized (4k) chunks and padded accordingly with the original. So instead, we ensure the filenames contained in CapPackage.zip.pdb don’t match what the XML will look for, by doing that, Varnishator is somewhat defeated and we fall back on the Telephony_UI prc which is much easier to edit with custom splash screens using the same process as for the 650.