From: DanW <da...@ho...> - 2004-02-24 19:10:57
|
I have had some success using .62 to access the file system of my = Kyocera KX414. I don't really care to even use the other features. I = have been attempting to use the .7 betas, but I have gotten different = results. Bitpim actually recognizes and communicates with the phone = much more consistently and reliably with the new version, however, it = doesn't appear that the file system is read correctly. File names are = not displayed correctly, and even the number of files in a directory is = not correct. I would just like to know if this is because the code to read a phones = directory has actually changed this drastically, or if it's possible = there is a bug in the code that performs this function? Thanks, Dan |
From: DanW <da...@ho...> - 2004-05-24 16:57:43
|
I finally had a chance to view the data from my phone in the protocol = analyzer. bitpim 7 betas seem to accurately read the folder names, but not the = file names. Here is the partial information from the Protocol Log screen: 11:41:46.479 Other CDMA Phone: Listing dir 'user/mypictures' 11:41:46.709 Other CDMA Phone: brew response Data - 51 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 01 00 00 00 01 ff 00 01 00 56 23 af 2d = Y...........V#.- 00000010 35 17 00 00 00 18 00 00 10 19 75 73 65 72 2f 6d = 5.........user/m 00000020 79 70 69 63 74 75 72 65 73 2f 42 6d 70 30 31 2e = ypictures/Bmp01. 00000030 70 6e 67 png 11:41:46.719 Other CDMA Phone: brew request Data - 23 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 02 00 00 00 10 75 73 65 72 2f 6d 79 70 69 = Y......user/mypi 00000010 63 74 75 72 65 73 00 ctures. 11:41:46.759 Other CDMA Phone: brew response Data - 51 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 02 00 00 00 01 ff 00 01 00 bc 25 af 2d = Y............%.- 00000010 db 2a 00 00 00 2c 00 00 10 19 75 73 65 72 2f 6d = *...,....user/m 00000020 79 70 69 63 74 75 72 65 73 2f 42 6d 70 30 33 2e = ypictures/Bmp03. 00000030 70 6e 67 png 11:41:46.759 Other CDMA Phone: brew request Data - 23 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 03 00 00 00 10 75 73 65 72 2f 6d 79 70 69 = Y......user/mypi 00000010 63 74 75 72 65 73 00 ctures. 11:41:46.789 Other CDMA Phone: brew response Data - 51 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 03 00 00 00 01 ff 00 01 00 f6 2b af 2d = Y............+.- 00000010 d9 3d 00 00 00 40 00 00 10 19 75 73 65 72 2f 6d = =3D...@....user/m 00000020 79 70 69 63 74 75 72 65 73 2f 42 6d 70 30 32 2e = ypictures/Bmp02. 00000030 70 6e 67 png Here is some sample data from the Protocol Analyzer: p_brew.listfileresponse responseheader header: <p_brew.responseheader> UINTlsb commandmode: 89 0x59 UINTlsb command: 11 0xb UINTlsb errorcode: 0 0x0 UINTlsb entrynumber: 2 0x0 UNKNOWN unknown1: '\x01\xff\x00\x01' UINTlsb date: -1356481536 0xaf25bc00 UINTlsb size: 2808621 0x2adb2d UNKNOWN unknown2: '\x00\x00,\x00\x00' STRING filename: '\x19user/mypictures' 00000000 59 0B 00 02 00 00 00 01 FF 00 01 00 BC 25 AF 2D = Y............%.- 00000010 DB 2A 00 00 00 2C 00 00 10 19 75 73 65 72 2F 6D = *...,....user/m 00000020 79 70 69 63 74 75 72 65 73 2F 42 6D 70 30 33 2E = ypictures/Bmp03. 00000030 70 6E 67 png It would appear to me that the data from the newer Kyocera phones is = stored a bit differently from the other phones that are supported by = bitpim, but I am not that familiar with the code, so I could easily be = wrong. I wonder if anyone more familiar with the file system code could = easily make a modification to support these phones? Dan |
From: Roger B. <ro...@ro...> - 2004-05-24 23:59:35
|
> It would appear to me that the data from the newer Kyocera phones is > stored a bit differently from the other phones that are > supported by bitpim, but I am not that familiar with the code, so I could > easily be wrong. I wonder if anyone more familiar with > the file system code could easily make a modification to support these phones? For some reason the 'unknown2' field is one byte longer. Or the name has one more prefix byte depending on how you view it. I am working on some code that should work for all phones. Please can you post what protocol you get for listing files in the root directory. > p_brew.listfileresponse > responseheader header: <p_brew.responseheader> > UINTlsb commandmode: 89 0x59 > UINTlsb command: 11 0xb > UINTlsb errorcode: 0 0x0 > UINTlsb entrynumber: 2 0x0 > UNKNOWN unknown1: '\x01\xff\x00\x01' > UINTlsb date: -1356481536 0xaf25bc00 > UINTlsb size: 2808621 0x2adb2d > UNKNOWN unknown2: '\x00\x00,\x00\x00' > STRING filename: '\x19user/mypictures' Did you type that all in by hand? Roger |
From: Dale <dri...@te...> - 2004-05-25 14:35:47
|
Hi Roger, I was wondering if you are still going to work on the the code for the 4600 or are you going to wait until you can get the phone from RPI? |
From: Roger B. <ro...@ro...> - 2004-05-25 17:31:06
|
Dale wrote: > Hi Roger, I was wondering if you are still going to work on the the code for > the 4600 or are you going to wait until you can get the phone from RPI? It is going to take a while to get a phone via RPI. I am prepared to do more, but you have to tell me what works and what doesn't, and thoroughly test everything. Roger |
From: Dale <dri...@te...> - 2004-05-25 19:43:10
|
Ok, works for me. I was able to download a contact off the phone and was waiting to here back from you when I could try and upload to it. -----Original Message----- From: bit...@li... [mailto:bit...@li...] On Behalf Of Roger Binns Sent: Tuesday, May 25, 2004 10:31 AM To: bit...@li... Subject: Re: [Bitpim-devel] LG 4600 phone Dale wrote: > Hi Roger, I was wondering if you are still going to work on the the > code for the 4600 or are you going to wait until you can get the phone from RPI? It is going to take a while to get a phone via RPI. I am prepared to do more, but you have to tell me what works and what doesn't, and thoroughly test everything. Roger ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Bitpim-devel mailing list Bit...@li... https://lists.sourceforge.net/lists/listinfo/bitpim-devel |
From: Roger B. <ro...@ro...> - 2004-05-26 08:26:11
|
Dale wrote: > I was able to download a contact off the phone and was waiting to here back > from you when I could try and upload to it. I need the following from you: - Thorough confirmation that wallpaper and ringtone uploading and downloading work. You need to verify the various files match expectations and that the phone is happy with them, including deleting various ones and adding more. - I need the offset numbers for the phonebook. I detailed these in a previous message (the number added to the index number in the wallpaper/ringtone desc file when it is used in the phonebook). I won't attempt the upload code until I am certain every byte of the download code is correct. You should look at the decoding in the protocol log pane and change one thing in an entry and verify that the right thing is happening on the next read. The following fields are all two bytes on your J2ME phone, but one byte on the brew phone. That is currently my best guess and you need to work out if that is correct or not. - group - ringtone - wallpaper Roger |
From: Dale <dri...@te...> - 2004-08-23 20:28:52
|
Hey Roger, is this still all that is needed to finish the 4600 code? -----Original Message----- From: bit...@li... [mailto:bit...@li...] On Behalf Of Roger Binns Sent: Wednesday, May 26, 2004 1:26 AM To: bit...@li... Subject: Re: [Bitpim-devel] LG 4600 phone Dale wrote: > I was able to download a contact off the phone and was waiting to here > back from you when I could try and upload to it. I need the following from you: - Thorough confirmation that wallpaper and ringtone uploading and downloading work. You need to verify the various files match expectations and that the phone is happy with them, including deleting various ones and adding more. - I need the offset numbers for the phonebook. I detailed these in a previous message (the number added to the index number in the wallpaper/ringtone desc file when it is used in the phonebook). I won't attempt the upload code until I am certain every byte of the download code is correct. You should look at the decoding in the protocol log pane and change one thing in an entry and verify that the right thing is happening on the next read. The following fields are all two bytes on your J2ME phone, but one byte on the brew phone. That is currently my best guess and you need to work out if that is correct or not. - group - ringtone - wallpaper Roger ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Bitpim-devel mailing list Bit...@li... https://lists.sourceforge.net/lists/listinfo/bitpim-devel |
From: Roger B. <ro...@ro...> - 2004-08-23 21:36:13
|
Dale wrote: > Hey Roger, is this still all that is needed to finish the 4600 code? Those are the things that need to be addressed for the Telus (J2ME) one. There will probably be other details as well, but those are major details. Roger |
From: Dale <dri...@te...> - 2004-08-24 14:41:25
|
What version of python do I need to compile the new version of the code? I was using python22 -----Original Message----- From: bit...@li... [mailto:bit...@li...] On Behalf Of Roger Binns Sent: Monday, August 23, 2004 2:36 PM To: bit...@li... Subject: Re: [Bitpim-devel] LG 4600 phone Dale wrote: > Hey Roger, is this still all that is needed to finish the 4600 code? Those are the things that need to be addressed for the Telus (J2ME) one. There will probably be other details as well, but those are major details. Roger ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Bitpim-devel mailing list Bit...@li... https://lists.sourceforge.net/lists/listinfo/bitpim-devel |
From: Roger B. <ro...@ro...> - 2004-09-09 05:30:41
|
Dale wrote: > What version of python do I need to compile the new version of the > code? I was using python22 2.3 http://bitpim.org/developer.html Roger |
From: DanW <da...@ho...> - 2004-05-25 17:30:01
|
Yes, I did re-type that section of data, since copy/paste isn't = available. I'm not sure where I'm looking for protocol, so I'll just attach the = entire log and protocol log result from accessing the root of the phone. From Log tab: 12:20:20.150 COM2: Opening port COM2, 115200 baud, timeout 3.000000, = hardwareflow 0, softwareflow 0 12:20:20.180 COM2: Open of comm port suceeded 12:20:20.190 Other CDMA Phone: Listing dir '' 12:20:23.214 COM2: Timed out waiting for 7e, requested bytes 1 - 0 = bytes read 12:20:23.234 COM2: Changed port speed to 38400 12:20:26.740 COM2: Timed out waiting for 7e, requested bytes 1 - 0 = bytes read 12:20:26.759 COM2: Changed port speed to 115200 12:20:30.265 COM2: Timed out waiting for 7e, requested bytes 1 - 0 = bytes read 12:20:33.680 Other CDMA Phone: Now in brew mode From Protocol Log tab: 12:20:20.150 COM2: Opening port COM2, 115200 baud, timeout 3.000000, = hardwareflow 0, softwareflow 0 12:20:20.180 COM2: Open of comm port suceeded 12:20:20.190 Other CDMA Phone: Listing dir '' 12:20:20.210 Other CDMA Phone: brew request Data - 2 bytes <#! p_brew.memoryconfigrequest !#> 00000000 59 0c Y. 12:20:23.214 COM2: Timed out waiting for 7e, requested bytes 1 - 0 = bytes read 12:20:23.214 COM2: Incomplete read was Data - 0 bytes 12:20:23.234 COM2: Changed port speed to 38400 12:20:23.734 Other CDMA Phone: brew request Data - 2 bytes <#! p_brew.memoryconfigrequest !#> 00000000 59 0c Y. 12:20:26.740 COM2: Timed out waiting for 7e, requested bytes 1 - 0 = bytes read 12:20:26.740 COM2: Incomplete read was Data - 0 bytes 12:20:26.759 COM2: Changed port speed to 115200 12:20:27.260 Other CDMA Phone: brew request Data - 2 bytes <#! p_brew.memoryconfigrequest !#> 00000000 59 0c Y. 12:20:30.265 COM2: Timed out waiting for 7e, requested bytes 1 - 0 = bytes read 12:20:30.265 COM2: Incomplete read was Data - 0 bytes 12:20:30.265 COM2: Writing Data - 10 bytes 00000000 41 54 24 51 43 44 4d 47 0d 0a AT$QCDMG.. 12:20:33.470 COM2: Reading remaining data Data - 18 bytes 00000000 41 54 24 51 43 44 4d 47 0d 0d 0a 4f 4b 0d 0a 0a = AT$QCDMG...OK... 00000010 10 0c .. 12:20:33.470 Other CDMA Phone: brew request Data - 2 bytes <#! p_brew.memoryconfigrequest !#> 00000000 59 0c Y. 12:20:33.680 Other CDMA Phone: brew response Data - 11 bytes <#! p_brew.memoryconfigresponse !#> 00000000 59 0c 00 10 1a 18 00 10 66 05 00 Y.......f.. 12:20:33.680 Other CDMA Phone: Now in brew mode 12:20:33.690 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 00 00 00 00 02 2f 00 Y....../. 12:20:33.789 Other CDMA Phone: brew response Data - 37 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 00 00 00 00 01 1f 00 00 00 b7 d6 34 82 = Y.............4. 00000010 08 00 00 00 00 00 00 00 00 0b 75 69 62 75 69 6c = .........uibuil 00000020 64 2e 64 69 72 d.dir 12:20:33.789 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 01 00 00 00 02 2f 00 Y....../. 12:20:33.980 Other CDMA Phone: brew response Data - 36 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 01 00 00 00 01 ff 00 01 03 00 00 00 00 = Y............... 00000010 9c 02 00 00 00 04 00 00 00 0a 24 55 53 45 52 5f = .........$USER_ 00000020 44 49 52 53 DIRS 12:20:33.980 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 02 00 00 00 02 2f 00 Y....../. 12:20:34.029 Other CDMA Phone: brew response Data - 39 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 02 00 00 00 01 ff 00 01 00 00 00 00 00 = Y............... 00000010 04 00 00 00 00 04 00 00 00 0d 24 46 49 42 5f 43 = .........$FIB_C 00000020 48 45 43 4b 53 55 4d HECKSUM 12:20:34.029 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 03 00 00 00 02 2f 00 Y....../. 12:20:34.061 Other CDMA Phone: brew response Data - 34 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 03 00 00 00 01 ff 00 01 00 00 00 00 00 = Y............... 00000010 c3 08 00 00 00 0c 00 00 00 08 24 53 59 53 5f 52 = .........$SYS_R 00000020 4d 54 MT 12:20:34.061 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 04 00 00 00 02 2f 00 Y....../. 12:20:34.091 Other CDMA Phone: brew response Data - 36 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 04 00 00 00 01 ff 00 01 00 00 00 00 00 = Y............... 00000010 14 00 00 00 00 04 00 00 00 0a 24 4c 49 4e 4b 5f = .........$LINK_ 00000020 54 49 4d 45 TIME 12:20:34.101 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 05 00 00 00 02 2f 00 Y....../. 12:20:34.141 Other CDMA Phone: brew response Data - 40 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 00 05 00 00 00 01 00 00 ff 00 00 00 00 00 = Y............... 00000010 08 00 00 00 00 04 00 00 00 0e 24 53 59 53 5f 52 = .........$SYS_R 00000020 4d 54 2e 43 4f 55 4e 54 MT.COUNT 12:20:34.141 Other CDMA Phone: brew request Data - 9 bytes <#! p_brew.listfilerequest !#> 00000000 59 0b 06 00 00 00 02 2f 00 Y....../. 12:20:34.171 Other CDMA Phone: brew response Data - 3 bytes <#! p_brew.listfileresponse !#> 00000000 59 0b 1c Y.. 12:20:34.171 Other CDMA Phone: brew request Data - 4 bytes <#! p_brew.listdirectoriesrequest !#> 00000000 59 02 01 00 Y... 12:20:34.270 Other CDMA Phone: brew response Data - 38 bytes <#! p_brew.listdirectoriesresponse !#> 00000000 59 02 00 06 00 1f 00 62 72 65 77 00 66 6f 6e 74 = Y......brew.font 00000010 00 75 73 65 72 00 6e 76 6d 00 56 6f 69 63 65 44 = user.nvm.VoiceD 00000020 42 00 75 69 00 00 B.ui.. |
From: Roger B. <ro...@ro...> - 2004-05-25 17:37:23
|
DanW wrote: > Yes, I did re-type that section of data, since copy/paste isn't available. Ouch :-) Of course anyone is welcome to implement copy and paste :-) > I'm not sure where I'm looking for protocol, so I'll just attach the > entire log and protocol log result from accessing the root > of the phone. That had the information I needed. I am trying to write the code so that it automatically works wether the extra byte is present or not. It i quite hairy stuff. Can you please get a developer version of BitPim up and running so you can test my changes? Also, try saving a file to phone and see if that works. We need to verify that this is the only place they have gratioutously changed the protocol. Roger |
From: DanW <da...@ho...> - 2004-05-25 21:10:15
|
I downloaded 0.7-test11 and successfully copied a file to the phone. I = was able to set the image as my background. I setup the development environment a couple of months ago. I'm not = familiar with these tools, but I'm more than willing to give it a try. Dan |
From: Roger B. <ro...@ro...> - 2004-05-26 08:14:12
|
DanW wrote: > I downloaded 0.7-test11 and successfully copied a file to the phone. > I was able to set the image as my background. That is good since it means they have changed the protocol anywhere else. BTW what is your phone model again? > I setup the development environment a couple of months ago. I'm > not familiar with these tools, but I'm more than willing to give > it a try. You should just be able to do a CVS update and then run the code. I have just committed some code that automagically works out if that spurious zero is there. I have tested it against my own phones, as well as against your protocol traces and all is fine. For everyone else, the change only affects parsing the filenames when reading directory entries. Do look out for errors, such as characters being chopped off, or extra ones present. Roger |
From: DanW <da...@ho...> - 2004-06-11 18:15:16
|
It appears I can now view, read, and write to the file system on my = Kyocera KX414 with test 12. Dan |
From: Roger B. <ro...@ro...> - 2004-02-25 01:59:49
|
> I would just like to know if this is because the code to read a > phones directory has actually changed this drastically, or if > it's possible there is a bug in the code that performs this function? The substance of the code is the same. However before 0.7 the packets were decoded "by hand". That meant that particular byte ranges were extracted, byte swapped and understood. In 0.7 the various packets are described at a higher level (and then code is generated from that). Here is an example: http://cvs.sf.net/viewcvs.py/bitpim/bitpim/p_brew.p?view=markup Turn on protocol logging, and then when you have some data in the protocol log, press Ctrl-Alt-P and you will get an analyser (another benefit of the descriptions). That should give you a better idea of what is going on. You will need to manually compare against 0.6 but maybe you will spot the difference. Roger |