Menu
▾
▴
bitpim-devel
|
From: Roger B. <ro...@ro...> - 2004-05-03 20:05:46
|
If you own one of the phone models listed below and would like to help BitPim better support your phone, then please read-on. You will need to have time to dedicate to this. You will need to be run the developer version of BitPim. The details to get up and going are at http://bitpim.sourceforge.net/developer.html You should be somewhat midly technical. In particular, you should be able to find your way around the protocol analyser. (Turn on protocol logging, do something, then press Ctrl-Alt-P in the protocol log pane). The expected method of progress is that a developer will make some changes, you do a cvs update and check to see if they work correctly. You may need to look in the protocol analyser to see if the various fields are being decoded properly and are the right size. Provide the feedback and repeat the loop. You may need to do things like create dummy phonebook entries and look at how they are being decoded, or add and remove ringtones, wallpaper and calendar entries. If noone steps forward for you model of phone, then progress will be very slow or non-existent. Having more than one person will be really great since that way we can better verify the code works correctly (having a sample of only one phone isn't too goood a test). LG VX4500: - Phonebook needs to be deciphered - Calendar needs verification - Complete list of media locations and index files (eg MMS) LG VX4600: - Phonebook needs to be deciphered - Calendar needs verification - The new media code needs checking Audiovox CDM8900: - The new phonebook code needs to be tested - Information is needed about media locations and index files Roger |
|
From: Dale B. <bi...@da...> - 2004-05-03 20:27:22
|
On Mon, 2004-05-03 at 16:05, Roger Binns wrote: > If you own one of the phone models listed below and would like > to help BitPim better support your phone, then please read-on. > Oops, repost from the right address. Admin: please delete the other post if possible. I'll volunteer for the CDM8900. I'm guessing this needs to be more-real time than email and that we won't want to clutter the lists with info from individual phones, not to mention the privacy issue.... Where do we go from here? -Dale > Audiovox CDM8900: > > - The new phonebook code needs to be tested > - Information is needed about media locations and > index files > > Roger |
|
From: Roger B. <ro...@ro...> - 2004-05-04 00:26:44
|
> Admin: please delete the other post if possible. I can't delete posts :-) > I'll volunteer for the CDM8900. I'm guessing this needs to be more-real > time than email and that we won't want to clutter the lists with info > from individual phones, not to mention the privacy issue.... Where do we > go from here? Nah, posting to the list is preferred, except where real data is being used in which case email it directly. The idea is that other people will have insights and can act as extra eyes double checking information. I also assume that everyone on this list is technical enough to figure out how to filter their email and quickly discard things they are not interested in. > > - The new phonebook code needs to be tested Just try reading your phonebook and see how it looks. I believe all the data is correctly decoded. After readin the group information, there are then 30 requests sent (with dunno in the request name). Have a look in the protocol log and see if you can figure out what they are. I have eliminated voice dials, speed dials and the calendar. I don't know what else the phone has 30 of. (BTW I have been sniffing the Curitel PC-Sync application to get all this). > > - Information is needed about media locations and > > index files This would be greatly appreciated. There are various fields in the index files and I need the size and purpose of each one. When I last looked at random other programs people had done, they just seemed to put in fixed numbers and hope for the best. I think many are actually dates. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-03 20:53:53
|
On May 3, 2004, at 4:05 PM, Roger Binns wrote: > LG VX4500: > > - Phonebook needs to be deciphered > - Calendar needs verification > - Complete list of media locations and index files (eg MMS) Hello Roger - I'm more than a little technically oriented and I just got a LG4500 and data cable as my son dropped my good 'ol star-tac in a cup of soda last week. A few months ago I used BitPim to set up my father-in-law's LG4400 with great success. Unfortunately, I'm pretty busy right now. That said, I'm more than happy to spend up to 1/2 hour in the morning and also up to 1/2 hour at the end of the day setting up bitfling experiments, reporting back results, doing well-defined tests, answering questions, etc. I've already installed the developer version and I'm cvs'ing each day (I'm in GMT+5). My usual working systems are OS X, FreeBSD, and reluctantly Win-XP, and all are on-line. I can boot up and work with Linux, but that will eat-up my Bitpim time budget. Given those restrictions, feel free to ask for any LG4500 help. I'll help out more when I can - Peter Peter Dufault HD Associates, Inc. |
|
From: Roger B. <ro...@ro...> - 2004-05-04 00:09:49
|
Peter Dufault wrote: > My usual working systems are OS X, FreeBSD, and reluctantly Win-XP, and > all are on-line. I can boot up and work with Linux, but that will > eat-up my Bitpim time budget. You can use whichever ones you want for the work. > Given those restrictions, feel free to ask for any LG4500 help. What is needed is correctly decoding the phonebook. The simplest thing to do is to tell BitPim to get your phonebook, and then look in the analyser to see what the first entry returned is. On your phone, change that entry so that every field is filled in to its maximum length. I usually do things like e1e1e1e1e1e... for first email address, 11111... for first phone number, memomemo for memo etc. (You will probably want to have create a new entry with the original phonebook entry details). Then with the now updated first entry, read the phonebook again and look in the protocol analyser. The fields are defined in p_lgvx4500.p. You may need to change sizes and other stuff. You can rebuild the Python code by running 'python protogen.py p_lgvx4500.p p_lgvx4500.py' Then check your work. Email your updated p_lgvx4500.p file, as well as the relevant packet from the protocol dump to this list. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-04 13:27:48
|
On May 3, 2004, at 8:09 PM, Roger Binns wrote:
> What is needed is correctly decoding the phonebook...
Well, I didn't get far today. Using the version cvs'd as of this
9:00AM EST I got an unexpected exception.
OS: Mac OS X 10.3.3
Platform: 667 MHz PowerPC G4 Powerbook
Python S/W, etc: versions as specified on "how to install the developer
version" on the website from last weekend.
Phone: LG VX4500 S/W T45VZV01 PRL 50154 ERI 50018
Cable: Verizon Mobile Office cable for the VX4500
===== Exception dialog:
9:05:36.632 Exception: An unexpected exception has occurred.
Please see the help for details on what to do.
Traceback (most recent call last):
File "/Users/dufault/work/bitpim/gui.py", line 703, in OnDataGetPhone
dlg.UpdateWithProfile(self.phoneprofile)
File "/Users/dufault/work/bitpim/guiwidgets.py", line 264, in
UpdateWithProfile
if self._dowesupport(source, self.actions[0][1], self.types[i][1])
and \
AttributeError: Profile instance has no attribute 'SyncQuery'
Variables by last 8 frames, innermost last
Frame ? in bp.py at line 58
profile = <function profile at 0x61470>
__file__ = 'bp.py'
__name__ = '__main__'
__doc__ = 'Main entry point to Bitpim\n\nIt invokes BitPim in
gui or c
Frame run in /Users/dufault/work/bitpim/gui.py at line 349
args = (['bp.py'],)
m = <gui.MainApp instance; proxy of C++ wxPyApp instance
at _32b
Frame MainLoop in
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
site-packages/wxPython/wx.py at line 1968
self = <gui.MainApp instance; proxy of C++ wxPyApp instance
at _32b
Frame MainLoop in
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
site-packages/wxPython/wx.py at line 89
_kwargs = {}
self = <gui.MainApp instance; proxy of C++ wxPyApp instance
at _32b
_args = ()
Frame OnDataGetPhone in /Users/dufault/work/bitpim/gui.py at line 703
self = <gui.MainWindow instance; proxy of C++ wxFrame
instance at _
dlg = <guiwidgets.GetPhoneDialog instance; proxy of C++
wxDialog i
_ = <wxPython.events.wxCommandEventPtr instance; proxy
of C++ wx
Frame UpdateWithProfile in /Users/dufault/work/bitpim/guiwidgets.py at
line 264
profile = <com_lgvx4400.Profile instance at 0x5bf7468>
count = 0
i = 1
self = <guiwidgets.GetPhoneDialog instance; proxy of C++
wxDialog i
source = 'phonebook'
cs = 0
type = 'OVERWRITE'
===== Both "Log" and "Protocol Log":
Same as exception dialog.
All I did was start it up with "pythonw bp.py" (I hope that's correct,
"python bp.py" doesn't bring the program to the front and "pythonw
bp.py" worked yesterday), changed the phone to vx4500 from vx4400 (Why
doesn't that seem to stick?) and did "Data...Get Phone Data". I get
the error immediately, I don't get the bullet list selector to select
what to get. This worked yesterday.
I have the versions of the support software specified on how to install
the developer version on the website.
The file system view works fine.
I do have a keyboard and mouse on the laptop today, I didn't yesterday.
I can't think of any other differences.
Yesterday I was able to get and send phone book entries, and set up
about ten contact entries that I had from the VX4400, though I didn't
get the wallpaper in right. I'm not 100% when I CVS'd that version,
maybe over the weekend.
Peter
Peter Dufault
HD Associates, Inc.
|
|
From: Roger B. <ro...@ro...> - 2004-05-04 17:07:32
|
> AttributeError: Profile instance has no attribute 'SyncQuery' I broke that and have just committed a fix. It was due to some code cleanup, but the VX4400 code is old and didn't do some stuff as it should have been. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-04 17:47:16
|
On May 4, 2004, at 1:07 PM, Roger Binns wrote: > I broke that and have just committed a fix. It was due to some > code cleanup, but the VX4400 code is old and didn't do some > stuff as it should have been. I found the definition for that function that was removed on the 30'th, so I had temporarily put it back in to the vx4400 code since I don't know python and couldn't figure out the right fix. I'll get your fix in a little while. Let me know that I'm doing the right thing here: I've zeroed out my phone book, loaded an entry as much as possible, and got a trace (further on) off the protocol log. (N123 is name 1, e123 email address one, e223 email address 2, etc). Now I should go through p_lgvx4400.p, p_lgvx4500.p, and p_lg.p and see that things match. I sort of see where things are. But where, for example, is the length of a phone number? 13:30:07.904 LG-VX4500: Read entry 0 - N123456789012345678901 13:30:07.905 LG-VX4500: lg phonebook request Data - 10 bytes <#! p_lg.pbnextentryrequest !#> 00000000 ff 12 0e 01 00 00 00 00 00 00 .......... 13:30:07.906 LG-VX4500: lg phonebook response Data - 563 bytes <#! p_lg.pbnextentryresponse !#> 00000000 ff 12 0e d0 00 00 00 00 00 00 09 00 00 00 00 00 ................ 00000010 4e 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 N123456789012345 00000020 36 37 38 39 30 31 00 01 00 65 31 32 33 34 35 36 678901...e123456 00000030 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012 00000040 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 3456789012345678 00000050 39 30 31 32 33 34 35 36 37 00 65 32 32 33 34 35 901234567.e22345 00000060 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 6789012345678901 00000070 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 2345678901234567 00000080 38 39 30 31 32 33 34 35 36 37 00 65 33 32 33 34 8901234567.e3234 00000090 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 5678901234567890 000000a0 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 1234567890123456 000000b0 37 38 39 30 31 32 33 34 35 36 37 00 77 77 77 2e 78901234567.www. 000000c0 75 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 u123456789012345 000000d0 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 6789012345678901 000000e0 32 33 34 35 36 37 38 39 30 31 32 33 00 00 00 00 234567890123.... 000000f0 4d 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 M123456789012345 00000100 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 6789012345678901 00000110 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 2345678901234567 00000120 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 8901234567890123 00000130 00 00 00 01 02 03 04 31 31 32 33 34 35 36 37 38 .......112345678 00000140 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 9012345678901234 00000150 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 5678901234567890 00000160 31 32 33 34 35 36 37 00 32 31 32 33 34 35 36 37 1234567.21234567 00000170 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 8901234567890123 00000180 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 4567890123456789 00000190 30 31 32 33 34 35 36 37 00 33 31 32 33 34 35 36 01234567.3123456 000001a0 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012 000001b0 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 3456789012345678 000001c0 39 30 31 32 33 34 35 36 37 00 34 31 32 33 34 35 901234567.412345 000001d0 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 6789012345678901 000001e0 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 2345678901234567 000001f0 38 39 30 31 32 33 34 35 36 37 00 35 31 32 33 34 8901234567.51234 00000200 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 5678901234567890 00000210 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 1234567890123456 00000220 37 38 39 30 31 32 33 34 35 36 37 00 00 00 00 00 78901234567..... 00000230 00 0f 00 ... Peter Dufault HD Associates, Inc. |
|
From: Roger B. <ro...@ro...> - 2004-05-04 17:57:49
|
Peter Dufault wrote: > I found the definition for that function that was removed on the 30'th, It was put into a parent class. It is just that the VX4400 code wasn't inheriting from the parent class like it should have been. BTW there is a cvs checkins mailing list that sends the diffs of every every cvs commit. That is very useful for tracking what changes have been happening. > Let me know that I'm doing the right thing here: Yes, you were very much on the right track. > 13:30:07.906 LG-VX4500: lg phonebook response Data - 563 bytes > <#! p_lg.pbnextentryresponse !#> The one we actually need is pbreadentryresponse. The LG phonebook has a "cursor" pointing at an entry. pbinitrequest is used to make it point to the beginning of the phonebook. pbreadentryrequest is used to read the entry currently being pointed at and pbnextentryrequest is used to move the cursor to the next entry. pbnextentryresponse tends to have what looks like an entry, but is mainly just junk. BitPim doesn't look at the fields in the response. Also, please attach the protocol dumps as a seperate file in your email as your email client wraps the lines! (Or turn off the wrapping). Roger |
|
From: Peter D. <du...@hd...> - 2004-05-04 18:28:33
Attachments:
protolog.txt
|
On May 4, 2004, at 1:57 PM, Roger Binns wrote: > Also, please attach the protocol dumps as a seperate file in > your email as your email client wraps the lines! (Or turn > off the wrapping). > I'm embarrassed to say I never realized that. The way things looked to me I thought it was just sending long lines unless I inserted a carriage return and also set "Format=flowed" in the mail header for the receiving client to clean things up. I just did "view raw source" on the message I sent and saw what I sent out. Ouch. Of course everything normally looks fine to me. Since I can't find anyway to turn it off (OS X mail client) I'll attach the protocol for now. I don't think I'll switch back to elm. |
|
From: Roger B. <ro...@ro...> - 2004-05-04 20:32:23
|
Peter Dufault wrote: > > Since I can't find anyway to turn it off (OS X mail client) I'll attach > > the protocol for now. I don't think I'll switch back to elm. All the elm users switched to mutt :-) Looking at the packet, they seem to have tweaked something for no appearent reason. The field named entrysize is the size of the entry for VX4400 and VX6000. For this phone it has a value of 0x0222 which isn't correct no matter how you slice this. For the 4400/6000 the field named unknown20c is beyond the end of the entrysize. On the 4400 it is always a sequence of 5 nulls. For the 6000 it is a 5 nulls followed by a two byte number. The 4500 seems to be doing the same as the 6000. If you can figure out what those last two bytes are I would be very interested. I have just done a commit you can test for writing. When writing the data back out, it sets the entrysize to 0x202 (same as vx4400/6000) instead of the 0x222 we get on 4500 reads. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-04 20:51:42
|
On May 4, 2004, at 4:32 PM, Roger Binns wrote:
> All the elm users switched to mutt :-)
You're right, I forgot:
hda:~% ls -latrd .mu* .elm*
|
drwx------ 2 dufault dufault 512 Jul 10 2001 .elm
drwxr-xr-x 2 dufault dufault 512 Aug 27 2001 .mutt
-rw-r--r-- 1 dufault dufault 150 Apr 15 2002 .muttrc
hda:~%
I guess I had switched to mutt before the OS X laptop became what I
hauled around instead of the thinkpad with FreeBSD.
Is it possible to cvs the developer stuff read-only if one wants to
check something out without waiting five hours?
Peter
Peter Dufault
HD Associates, Inc.
|
|
From: Roger B. <ro...@ro...> - 2004-05-04 22:22:38
|
> Is it possible to cvs the developer stuff read-only if one wants to > check something out without waiting five hours? Nope. You can however feed the stuff on the bitpim-cvs-checkins list into patch. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-05 13:20:06
|
On May 4, 2004, at 4:32 PM, Roger Binns wrote: > For the 4400/6000 the field named unknown20c is beyond the end > of the entrysize. On the 4400 it is always a sequence of 5 nulls. > For the 6000 it is a 5 nulls followed by a two byte number. > The 4500 seems to be doing the same as the 6000. If you can > figure out what those last two bytes are I would be very > interested. > Maybe this is just numerology, but: unknown20c is at position 9 in the block, and if you add that position with the value (0x222 = 546 decimal) you wind up with 555, which is the position of the sequence of 5 nulls. Those final two bytes have the value 0x231 (561), which happens to be its position in the block. Maybe this is used internally as some method of skipping over things or checking integrity. Peter Dufault HD Associates, Inc. |
|
From: Peter D. <du...@hd...> - 2004-05-05 13:27:11
|
On May 4, 2004, at 4:32 PM, Roger Binns wrote: > I have just done a commit you can test for writing. When > writing the data back out, it sets the entrysize to 0x202 > (same as vx4400/6000) instead of the 0x222 we get on > 4500 reads. > I tried this, it seems to work OK, but when you read the data back it is changed back to 0x222. I think I'd leave it at 0x222 until (or if) we figure out what it is. Peter Peter Dufault HD Associates, Inc. |
|
From: Roger B. <ro...@ro...> - 2004-05-05 23:57:16
|
Peter Dufault wrote: > On May 4, 2004, at 4:32 PM, Roger Binns wrote: > > > I have just done a commit you can test for writing. When > > writing the data back out, it sets the entrysize to 0x202 > > (same as vx4400/6000) instead of the 0x222 we get on > > 4500 reads. > > > > I tried this, it seems to work OK, but when you read the data back it > is changed back to 0x222. I think I'd leave it at 0x222 until (or if) > we figure out what it is. The reading and writing are unrelated for those pieces. The phones do silly things and this sort of thing is normal (it is usually unfinished bits of code, or two different people working on related areas). The important think to check is that the writing is actually succeeding and data is appropriately updated. I would recommend reading an entry, changing every field in BitPim, writing back out, then reading back in again. Verify every field reads correctly with what was written out. Especially check the serials. If that is all ok, then we are fine. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-06 00:12:44
|
On May 5, 2004, at 7:57 PM, Roger Binns wrote: > The important think to check is that the writing is actually succeeding > and data is appropriately updated. I would recommend reading an > entry, changing every field in BitPim, writing back out, then reading > back in again. Verify every field reads correctly with what was > written out. Especially check the serials. > OK, I'll try that. "It would be nice" (yeah, I know) if there were protocol logs from the different phones archived. I hope there are, but I tried searching for "4400 protocol logs" on the developer archives so that I could compare 4500 logs to 4400 logs without success. Peter Peter Dufault HD Associates, Inc. |
|
From: Roger B. <ro...@ro...> - 2004-05-06 00:36:48
|
Peter Dufault wrote: > "It would be nice" (yeah, I know) if there were protocol logs from the > different phones archived. I hope there are, but I tried searching for > "4400 protocol logs" on the developer archives so that I could compare > 4500 logs to 4400 logs without success. You will find them in the examples directory. There is also a test data generator. Make a directory named tests and then run: python experiments\gentestdata.py tests It will fill the directory with wallpapers, ringtones, calendar and a csv file for the phonebook. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-06 00:46:31
|
On May 5, 2004, at 8:36 PM, Roger Binns wrote: > You will find them in the examples directory. > > There is also a test data generator. Make a directory named tests > and then run: > > python experiments\gentestdata.py tests > > It will fill the directory with wallpapers, ringtones, calendar and > a csv file for the phonebook. Excellent, thanks. This needs an entry in the "Getting Started" section entitled "decoding phone protocols" or something, since that's where many beginners may begin. If it was already documented and obvious then I missed it. Maybe I can add docs soon - Peter Peter Dufault HD Associates, Inc. |
|
From: Roger B. <ro...@ro...> - 2004-05-06 01:33:12
|
Peter Dufault wrote: > Excellent, thanks. This needs an entry in the "Getting Started" > section entitled "decoding phone protocols" or something, since that's > where many beginners may begin. If it was already documented and > obvious then I missed it. > > Maybe I can add docs soon - If you want to write some docs, they will be welcomed. There is a seperate document web/phonespec.html that also needs fleshing out. I don't want the two merged - phonespec.html should just be a specification and no more. A seperate document talking about the analyser, using portmon and snoopy, the various tools in experiments etc would be what you are talking about. Roger |
|
From: Peter D. <du...@hd...> - 2004-05-04 19:24:19
|
On May 4, 2004, at 1:57 PM, Roger Binns wrote: > BTW there is a cvs checkins mailing list that sends the diffs of every > every cvs commit. That is very useful for tracking what changes > have been happening. > I'm going to subscribe to that now. But did you already commit those fixes for the vx4400 inheritance? I just did a "cvs update" and I don't see any changes from what I got at 9:00 AM. Peter Peter Dufault HD Associates, Inc. |
|
From: Roger B. <ro...@ro...> - 2004-05-04 19:46:24
|
Peter Dufault wrote: > I'm going to subscribe to that now. But did you already commit those > fixes for the vx4400 inheritance? Yes. > I just did a "cvs update" and I don't see any changes from what I got > at 9:00 AM. The anonymous CVS servers are synced with the developer ones every five hours. Roger |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X