You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(53) |
Apr
(48) |
May
(14) |
Jun
(3) |
Jul
(21) |
Aug
(11) |
Sep
(77) |
Oct
(67) |
Nov
(28) |
Dec
(163) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(112) |
Feb
(143) |
Mar
(114) |
Apr
(138) |
May
(173) |
Jun
(119) |
Jul
(119) |
Aug
(117) |
Sep
(187) |
Oct
(170) |
Nov
(254) |
Dec
(193) |
2005 |
Jan
(336) |
Feb
(284) |
Mar
(189) |
Apr
(100) |
May
(89) |
Jun
(52) |
Jul
(85) |
Aug
(138) |
Sep
(181) |
Oct
(137) |
Nov
(104) |
Dec
(98) |
2006 |
Jan
(76) |
Feb
(106) |
Mar
(224) |
Apr
(270) |
May
(103) |
Jun
(144) |
Jul
(77) |
Aug
(38) |
Sep
(37) |
Oct
(20) |
Nov
(14) |
Dec
(73) |
2007 |
Jan
(130) |
Feb
(68) |
Mar
(78) |
Apr
(60) |
May
(45) |
Jun
(63) |
Jul
(84) |
Aug
(45) |
Sep
(40) |
Oct
(12) |
Nov
(71) |
Dec
(56) |
2008 |
Jan
(44) |
Feb
(20) |
Mar
(25) |
Apr
(17) |
May
(33) |
Jun
(60) |
Jul
(97) |
Aug
(38) |
Sep
(10) |
Oct
(20) |
Nov
(13) |
Dec
(19) |
2009 |
Jan
(7) |
Feb
(5) |
Mar
(23) |
Apr
(10) |
May
(6) |
Jun
(5) |
Jul
(17) |
Aug
(7) |
Sep
(14) |
Oct
(27) |
Nov
(13) |
Dec
(12) |
2010 |
Jan
(37) |
Feb
(9) |
Mar
(13) |
Apr
(12) |
May
(8) |
Jun
(3) |
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(3) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Roger B. <ro...@ro...> - 2004-02-25 09:02:12
|
> I'm really hoping at some point I can > get some new animations and vibrating ringers on the phone. The BCI format supports multiple frames of images. If you look at brewcompressedimage.py you can see the decoding going on. I didn't figure out enough to encode a BCI image, but it would be nice. One thing that would be very useful is reducing an image to a palette of 256 colours (needed by BCI). I don't know if the newer phones support animated BCI or not. If they do, this would be an interesting route to pursue. Roger |
From: Derek J. L. <dla...@de...> - 2004-02-25 05:27:10
|
Looks likes that python site is definitely a good starting point. I'll also take a look through the archives and see if I can find a small project to try and tackle. I'm not sure what exactly I'd like to add to my resume, I'd like see BitPim the killer cell app like everyone else I imagine. In addition to maybe working with the UI, I'm really hoping at some point I can get some new animations and vibrating ringers on the phone. I've been playing a little with CMX Studio, but I'd love to get one of the Verizon backdrops off the phone to take a look at. _derek -----Original Message----- From: bit...@li... [mailto:bit...@li...] On Behalf Of Roger Binns Sent: Tuesday, February 24, 2004 3:39 PM To: bit...@li... Subject: Re: [Bitpim-devel] Newbie developer questions Derek J. Lambert wrote: > I'd also like to find some sites on Python programming with a slant > towards cross-language learning (i.e. Python for Perl/VB/etc. programmers) - > but anything would be helpful. Thanks! http://www.python.org/topics/learn/prog.html The one thing it may take a little while to realise is that Python is deceptively simple. > I would > like to try and contribute to the development effort, and was wondering if > there was a list of who was working on what currently The bitpim-cvs-checkins mialing list gives you every commit, so that tells you what code is actually changing and who did it. I do post a list of little projects that need to be done every few months to this list. There should be something in the archives. In general try and find a small self contained thing until you get familiar with the codebase and way of thinking. Then suggest an area that interests you. For example some people care about importing addressbook and calendar, others about printing, others about user interface, others about specific phone models. Being somewhat mercenary about it, if you wanted to add something to your resume, what would it be? Roger ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Bitpim-devel mailing list Bit...@li... https://lists.sourceforge.net/lists/listinfo/bitpim-devel |
From: Derek J. L. <dla...@de...> - 2004-02-25 05:17:26
|
Thanks, that's an interesting site. I've got a VX6000 here. I've never really heard much about LG till I got this device, but I'm definitely a fan now. -----Original Message----- From: bit...@li... [mailto:bit...@li...] On Behalf Of bfaye Sent: Tuesday, February 24, 2004 1:55 PM To: bit...@li... Subject: Re: [Bitpim-devel] Newbie developer questions I found a site through google that was a "Rosetta Stone" for programming languages. Its here: http://yagni.com/rosetta-stone/index.php You may get a bandwidth exceeded error, if so, just google for it and use the google cache! I figured out how to do loops there! So what phone do you have? I'm hacking away at my Sanyo 8100 with help from Stephen. I've gotten some code that will read off the pictures taken by the onboard camera from the phone. Billy --- "Derek J. Lambert" <dla...@de...> wrote: > Well after fighting with my cable for a number of weeks I've finally got it > working with BitPim. I must say this is an excellent little package. I would > like to try and contribute to the development effort, and was wondering if > there was a list of who was working on what currently - as to not duplicate > efforts. I'd also like to find some sites on Python programming with a slant > towards cross-language learning (i.e. Python for Perl/VB/etc. programmers) - > but anything would be helpful. Thanks! > > > > _derek > > __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Bitpim-devel mailing list Bit...@li... https://lists.sourceforge.net/lists/listinfo/bitpim-devel |
From: Tom T. <to...@to...> - 2004-02-25 02:29:00
|
I can verify that it does NOT work. I have the siren file that was sent (57K) and uploaded it as a .MID to my phone. It does NOT play... Cheers! Tom... "It's all about the ride..." Tom Tracey Puyallup, Washington www.tomtracey.com Proudly driving my "New" 1981 Yamaha Seca 750! "I was made to last forever, Though my body turn to sand, My soul is in His hand..." -=- Audio Adrenaline -=- ----- Original Message ----- From: "greg cunningham" <gre...@ya...> To: <bit...@li...> Sent: Tuesday, February 24, 2004 11:53 AM Subject: [Bitpim-devel] mp3 files may work on the vx4400 if under 64k and renamed .mid > I sent a mp3 file of a siren to a vx4400 owner. > He claims that if the file is under 64k he is able to > rename ANY mp3 file to a .mid extention and download > it to his vx4400. I no longer have a vx4400 so I am > not able to confirm this. > > Thanks > greg > > --- Stephen Wood <sa...@ge...> wrote: > > Billy, keep up your work on decoding the 8100 media > > transfer protocol! > > I am maintainer for Sanyo support in BitPim, and I > > am following your > > posts, but probably won't comment too much as I am > > putting my efforts to > > the SCP-5500 phonebook right now. > > > > The "fa 00 xx" header on packets seems to be a > > common theme for media > > transfer for Sanyo phones and phonebook transfer for > > newer phones. The > > 8100 camera download packets start with "fa 00 09", > > while the wallpaper > > upload starts with "fa 00 05". The phonebook > > packets on the SCP-5500 > > start with "fa 00 02". > > > > I'll send you some real sketchy notes on the 8100 > > protocol privately. > > Ignore them if they don't make any sense. > > > > Stephen > > > > On Tue, 2004-02-24 at 11:54, bfaye wrote: > > > After doing more studying, I figured the code > > below for p_sanyo8100.p would > > > > > Billy > > > > > > > > > ------------------------------------------------------- > > SF.Net is sponsored by: Speed Start Your Linux Apps > > Now. > > Build and deploy apps & Web services for Linux with > > a free DVD software kit from IBM. Click Now! > > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > > _______________________________________________ > > Bitpim-devel mailing list > > Bit...@li... > > > https://lists.sourceforge.net/lists/listinfo/bitpim-devel > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail SpamGuard - Read only the mail you want. > http://antispam.yahoo.com/tools > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Bitpim-devel mailing list > Bit...@li... > https://lists.sourceforge.net/lists/listinfo/bitpim-devel > |
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 |
From: Roger B. <ro...@ro...> - 2004-02-25 01:51:53
|
greg cunningham wrote: > The following message was posted in the lgvx4500 > group... one of the users was asking for help. If > someone has a solution to this please let me know Their log extracts don't tie up. Are you sure they are using a FutureDial USB to serial cable? And also have they correctly set the phone to use its serial rather than USB interface? Roger |
From: greg c. <gre...@ya...> - 2004-02-25 01:22:46
|
The following message was posted in the lgvx4500 group... one of the users was asking for help. If someone has a solution to this please let me know thanks greg Hello, I have the LG4500 with the data cable from VZW. The programs that came with the cable work fine and communicate with the phone. The Bitpim program 0.7-test4 just "stalls" and the following errors keep looping which seems forever, with the exception of the beginning error. --------------------- 19:47:29.030 Exception: An unexpected exception has occurred. Please see the help for details on what to do. Traceback (most recent call last): File "gui.pyo", line 1307, in OnRightUp File "gui.pyo", line 1647, in itemtopath File "wxPython\gizmos.pyo", line 444, in GetItemText wxPyAssertionError: C++ assertion "wxAssertFailure" failed in contrib/gizmos/treelistctrl.cpp(4358): invalid tree item Variables by last 8 frames, innermost last Frame ? in bp.py at line 44 __name__ = '__main__' __doc__ = 'Main entry point to Bitpim\n\nIt invokes BitPim in gui or c Frame run in gui.pyo at line 337 args = (['C:\\Program Files\\BitPim\\bitpim.exe'],) m = <gui.MainApp instance; proxy of C++ wxPyApp instance at _8c1 Frame MainLoop in wxPython\wx.pyo at line 1974 self = <gui.MainApp instance; proxy of C++ wxPyApp instance at _8c1 Frame MainLoop in wxPython\wx.pyo at line 92 _kwargs = {} self = <gui.MainApp instance; proxy of C++ wxPyApp instance at _8c1 _args = () Frame OnRightUp in gui.pyo at line 1307 pt = wxPoint(234, 162) unknown = -1 self = <gui.FileSystemView instance; proxy of C++ wxTreeListCtrl in item = '_a2a140_wxTreeItemId_p' flags = 4 event = <wxPython.events.wxMouseEventPtr instance; proxy of C++ wxMo Frame itemtopath in gui.pyo at line 1647 item = '_a2a140_wxTreeItemId_p' self = <gui.FileSystemView instance; proxy of C++ wxTreeListCtrl in Frame GetItemText in wxPython\gizmos.pyo at line 444 _kwargs = {} self = <gui.FileSystemView instance; proxy of C++ wxTreeListCtrl in _args = ('_a2a140_wxTreeItemId_p',) 19:47:44.546 auto: Auto detected port requested 19:47:44.812 auto: Trying next auto port 19:47:44.812 COM3: Opening port COM3, 115200 baud, timeout 3.000000, hardwareflow 0, softwareflow 0 19:47:44.828 COM3: Prolific USB-to-Serial Comm Port (COM3) 19:47:44.858 COM3: Open of comm port suceeded 19:47:44.875 LG-VX4500: Attempting to contact phone 19:47:44.875 LG-VX4500: Listing dir '' 19:47:47.875 COM3: Timed out waiting for 7e, requested bytes 1 - 0 bytes read 19:47:47.875 COM3: Changed port speed to 38400 19:47:51.375 COM3: Timed out waiting for 7e, requested bytes 1 - 0 bytes read 19:47:51.375 COM3: Changed port speed to 115200 19:47:54.875 COM3: Timed out waiting for 7e, requested bytes 1 - 0 bytes read 19:47:54.875 COM3: Changed port speed to 115200 19:47:58.375 LG-VX4500: No response to setting QCDMG mode 19:47:58.375 COM3: Changed port speed to 19200 19:48:01.875 LG-VX4500: No response to setting QCDMG mode 19:48:01.875 COM3: Port speed 230400 not supported 19:48:04.875 COM3: Timed out waiting for 7e, requested bytes 1 - 0 bytes read 19:48:07.875 COM3: Timed out waiting for 7e, requested bytes 1 - 0 bytes read 19:48:08.000 COM3: Trying next auto port 19:48:08.000 COM3: Opening port COM3, 115200 baud, timeout 3.000000, hardwareflow 0, softwareflow 0 . . . --------------------- Any ideas? __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
From: Roger B. <ro...@ro...> - 2004-02-24 23:40:17
|
Derek J. Lambert wrote: > I'd also like to find some sites on Python programming with a slant > towards cross-language learning (i.e. Python for Perl/VB/etc. programmers) - > but anything would be helpful. Thanks! http://www.python.org/topics/learn/prog.html The one thing it may take a little while to realise is that Python is deceptively simple. > I would > like to try and contribute to the development effort, and was wondering if > there was a list of who was working on what currently The bitpim-cvs-checkins mialing list gives you every commit, so that tells you what code is actually changing and who did it. I do post a list of little projects that need to be done every few months to this list. There should be something in the archives. In general try and find a small self contained thing until you get familiar with the codebase and way of thinking. Then suggest an area that interests you. For example some people care about importing addressbook and calendar, others about printing, others about user interface, others about specific phone models. Being somewhat mercenary about it, if you wanted to add something to your resume, what would it be? Roger |
From: bfaye <bf...@ya...> - 2004-02-24 22:54:29
|
It seems the wallpaper index number (XX in scp8100Index_xx) in the bitpim phonebook is also a number in the filename response packet. Its "num2" in my filename response packet definition. What happens is that if you save a camera taken picture to the "wallet", it makes a smaller copy of the picture with the same filename(!), so you get two files with the same name back when you read off the filenames. Also, it seems that wallet pics would get an index of 153 (0x99) or higher, and pics saved from the web (through vision download tools), get a lower index. I had one that was 58 (0x3a). So if you want, you can try to grab the pic for a pic assigned to a phonebook entry, but that "index" is not the "main" file index. You have to read all the filename entries until you get to the one with a "num2" that matches the one in the phonebook. I was wrong about the indexes in the filename not corresponding with the files themselves. I must of confused myself when I was looking at different log files. So if you read the filecontents back in order, you'll have the correct file name. The following code will write out all the camera pics from the phone. It doesn't handle the case where there are 2 files found on the phone with the same name yet. def getcamerapics(self): req=self.protocolclass.sanyoinitcampicread() res=self.sendpbcommand(req, self.protocolclass.sanyocamresponse) req=self.protocolclass.sanyonumofcamerapicrequest() res=self.sendpbcommand(req, self.protocolclass.sanyonumofcamerapicresponse) self.log("got %d camera pics" % (res.numcampics,)) for c in range(0, res.numcampics): req=self.protocolclass.sanyocampicfilenamerequest() req.reqindex=c res=self.sendpbcommand(req, self.protocolclass.sanyocampicfilenameresponse) self.log("campic filename: " + res.filename) self.log("campic num1: %d" % (res.num1,)) self.log("campic num2: %d" % (res.num2,)) self.log("campic num3: %d" % (res.num3,)) filename=res.filename outfile=open(filename, "wb") d=1 while d==1: req=self.protocolclass.sanyocampicfilerequest() req.fileindexnum=c res=self.sendpbcommand(req, self.protocolclass.sanyocampicfileresponse) self.log("campicfile indexnum: %d" % (res.indexnum,)) self.log("campicfile moredata: %d" % (res.moredata,)) self.log("campicfile packetlength: %d" % (res.packetlength,)) outfile.write(res.data[0:res.packetlength]) outfile.flush() d=res.moredata outfile.close() return And here is the updated packet defs I'm using: PACKET sanyonumofcamerapicrequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0072} +header 2 UINT {'constant': 0xffff} +word 172 UNKNOWN +pad PACKET sanyonumofcamerapicresponse: 172 UNKNOWN +pad 1 UINT numcampics 6 UNKNOWN +pad2 PACKET sanyocampicfilenamerequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0073} +header 2 UINT {'constant': 0xffff} +word 161 UNKNOWN +pad 1 UINT reqindex 10 UNKNOWN +pad2 PACKET sanyocampicfilenameresponse: 8 UNKNOWN +headerstuff 154 STRING +filename 1 UINT num1 3 UNKNOWN +pad 1 UINT num2 1 UNKNOWN +pad2 1 UINT num3 10 UNKNOWN +pad3 PACKET sanyocampicfilerequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0074} +header 2 UINT {'constant': 0xffff} +word 155 UNKNOWN +pad1 1 UINT fileindexnum 16 UNKNOWN +pad2 PACKET sanyocampicfileresponse: 8 UNKNOWN +headerstuff 150 DATA data 1 UINT packetlength 3 UNKNOWN +pad1 1 UINT indexnum 15 UNKNOWN +pad2 1 UINT moredata --- Stephen Wood <sa...@us...> wrote: > While you are looking at this, could you look at assignment of camera > pictures to phonebook entries. If you assign a camera picture to a name > in your phonebook, and then dump the phonebook with Bitpim, you will see > in the index file that BitPim makes a line like > > 'wallpapers': 'scp8100Index_XX', > > for each phonebook entry you assign a picture to. The XX is the index > number that the phone reports for the wallpaper. What would be nice is > to find out if these index numbers can be related to the picture > filenames that you are getting from the phone. > > > Stephen __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
From: Stephen W. <sa...@us...> - 2004-02-24 22:16:27
|
On Tue, 2004-02-24 at 15:29, bfaye wrote: > I just want to add in more packet descriptions so we got it in the mailing list > archive. I got a rough grasp of the how the camera file reading request and > response packets look like, unfortunately, I only have my phone to try. ... While you are looking at this, could you look at assignment of camera pictures to phonebook entries. If you assign a camera picture to a name in your phonebook, and then dump the phonebook with Bitpim, you will see in the index file that BitPim makes a line like 'wallpapers': 'scp8100Index_XX', for each phonebook entry you assign a picture to. The XX is the index number that the phone reports for the wallpaper. What would be nice is to find out if these index numbers can be related to the picture filenames that you are getting from the phone. Stephen |
From: bfaye <bf...@ya...> - 2004-02-24 21:55:34
|
I found a site through google that was a "Rosetta Stone" for programming languages. Its here: http://yagni.com/rosetta-stone/index.php You may get a bandwidth exceeded error, if so, just google for it and use the google cache! I figured out how to do loops there! So what phone do you have? I'm hacking away at my Sanyo 8100 with help from Stephen. I've gotten some code that will read off the pictures taken by the onboard camera from the phone. Billy --- "Derek J. Lambert" <dla...@de...> wrote: > Well after fighting with my cable for a number of weeks I've finally got it > working with BitPim. I must say this is an excellent little package. I would > like to try and contribute to the development effort, and was wondering if > there was a list of who was working on what currently - as to not duplicate > efforts. I'd also like to find some sites on Python programming with a slant > towards cross-language learning (i.e. Python for Perl/VB/etc. programmers) - > but anything would be helpful. Thanks! > > > > _derek > > __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
From: Derek J. L. <dla...@de...> - 2004-02-24 20:52:27
|
Well after fighting with my cable for a number of weeks I've finally got it working with BitPim. I must say this is an excellent little package. I would like to try and contribute to the development effort, and was wondering if there was a list of who was working on what currently - as to not duplicate efforts. I'd also like to find some sites on Python programming with a slant towards cross-language learning (i.e. Python for Perl/VB/etc. programmers) - but anything would be helpful. Thanks! _derek |
From: bfaye <bf...@ya...> - 2004-02-24 20:30:49
|
I just want to add in more packet descriptions so we got it in the mailing list archive. I got a rough grasp of the how the camera file reading request and response packets look like, unfortunately, I only have my phone to try. So if anyone else other there want to splice in some code to test with their 8100, it'd be cool to see if I'm on the right track. Here are the additions: p_sanyo8100.p (don't forget to do makepackets after you add in the changes): PACKET sanyonumofcamerapicrequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0072} +header 2 UINT {'constant': 0xffff} +word 172 UNKNOWN +pad PACKET sanyonumofcamerapicresponse: 172 UNKNOWN +pad 1 UINT numcampics 6 UNKNOWN +pad2 PACKET sanyocampicfilenamerequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0073} +header 2 UINT {'constant': 0xffff} +word 161 UNKNOWN +pad 1 UINT reqindex 10 UNKNOWN +pad2 PACKET sanyocampicfilenameresponse: 8 UNKNOWN +headerstuff 154 STRING +filename 1 UINT num1 3 UNKNOWN +pad 1 UINT num2 1 UNKNOWN +pad2 1 UINT num3 10 UNKNOWN +pad3 PACKET sanyocampicfilerequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0074} +header 2 UINT {'constant': 0xffff} +word 155 UNKNOWN +pad1 1 UINT fileindexnum 16 UNKNOWN +pad2 PACKET sanyocampicfileresponse: 8 UNKNOWN +headerstuff 150 DATA data 1 UINT packetlength 3 UNKNOWN +pad1 1 UINT indexnum 15 UNKNOWN +pad2 1 UINT unknum The following method can be added into com_sanyo8100.py, and you can test it by calling it at the beginning of getcalendar (at least thats how I've been testing it, I'm a Python noob). It assumes you have at least one picture, since it tries to grab the contents of the file at index 0 (which doesn't seem to match the fileNAME at index 0, probably 2 separate indices): def getcamerapics(self): req=self.protocolclass.sanyoinitcampicread() res=self.sendpbcommand(req, self.protocolclass.sanyocamresponse) req=self.protocolclass.sanyonumofcamerapicrequest() res=self.sendpbcommand(req, self.protocolclass.sanyonumofcamerapicresponse) self.log("got %d camera pics" % (res.numcampics,)) for c in range(0, res.numcampics): req=self.protocolclass.sanyocampicfilenamerequest() req.reqindex=c res=self.sendpbcommand(req, self.protocolclass.sanyocampicfilenameresponse) self.log("campic filename: " + res.filename) self.log("campic num1: %d" % (res.num1,)) self.log("campic num2: %d" % (res.num2,)) self.log("campic num3: %d" % (res.num3,)) d=150 while d==150: req=self.protocolclass.sanyocampicfilerequest() req.fileindexnum=0 res=self.sendpbcommand(req, self.protocolclass.sanyocampicfileresponse) self.log("campicfile indexnum: %d" % (res.indexnum,) ) self.log("campicfile unknum: %d" % (res.unknum,) ) self.log("campicfile packetlength: %d" % (res.packetlength,) ) d=res.packetlength return You can modify getcalendar so it starts like this (optional): def getcalendar(self,result): self.getcamerapics() result=com_sanyo.Phone.getcalendar(self,result) ... Billy > Billy, keep up your work on decoding the 8100 media transfer protocol! > I am maintainer for Sanyo support in BitPim, and I am following your > posts, but probably won't comment too much as I am putting my efforts to > the SCP-5500 phonebook right now. > > The "fa 00 xx" header on packets seems to be a common theme for media > transfer for Sanyo phones and phonebook transfer for newer phones. The > 8100 camera download packets start with "fa 00 09", while the wallpaper > upload starts with "fa 00 05". The phonebook packets on the SCP-5500 > start with "fa 00 02". > I'll send you some real sketchy notes on the 8100 protocol privately. > Ignore them if they don't make any sense. > > Stephen __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
From: greg c. <gre...@ya...> - 2004-02-24 19:54:33
|
I sent a mp3 file of a siren to a vx4400 owner. He claims that if the file is under 64k he is able to rename ANY mp3 file to a .mid extention and download it to his vx4400. I no longer have a vx4400 so I am not able to confirm this. Thanks greg --- Stephen Wood <sa...@ge...> wrote: > Billy, keep up your work on decoding the 8100 media > transfer protocol! > I am maintainer for Sanyo support in BitPim, and I > am following your > posts, but probably won't comment too much as I am > putting my efforts to > the SCP-5500 phonebook right now. > > The "fa 00 xx" header on packets seems to be a > common theme for media > transfer for Sanyo phones and phonebook transfer for > newer phones. The > 8100 camera download packets start with "fa 00 09", > while the wallpaper > upload starts with "fa 00 05". The phonebook > packets on the SCP-5500 > start with "fa 00 02". > > I'll send you some real sketchy notes on the 8100 > protocol privately. > Ignore them if they don't make any sense. > > Stephen > > On Tue, 2004-02-24 at 11:54, bfaye wrote: > > After doing more studying, I figured the code > below for p_sanyo8100.p would > > > Billy > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps > Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Bitpim-devel mailing list > Bit...@li... > https://lists.sourceforge.net/lists/listinfo/bitpim-devel __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
From: Stephen W. <sa...@ge...> - 2004-02-24 19:48:18
|
Billy, keep up your work on decoding the 8100 media transfer protocol! I am maintainer for Sanyo support in BitPim, and I am following your posts, but probably won't comment too much as I am putting my efforts to the SCP-5500 phonebook right now. The "fa 00 xx" header on packets seems to be a common theme for media transfer for Sanyo phones and phonebook transfer for newer phones. The 8100 camera download packets start with "fa 00 09", while the wallpaper upload starts with "fa 00 05". The phonebook packets on the SCP-5500 start with "fa 00 02". I'll send you some real sketchy notes on the 8100 protocol privately. Ignore them if they don't make any sense. Stephen On Tue, 2004-02-24 at 11:54, bfaye wrote: > After doing more studying, I figured the code below for p_sanyo8100.p would > Billy |
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: Steven P. <n9...@n9...> - 2004-02-24 18:36:38
|
On Feb 23, 2004, at 11:47 PM, Roger Binns wrote: > Looks good. It is what I was expecting, and you even check the > window is on the screen :-) Don't forget to update > help/versionhistory.htd I thought to be smart, I should do that. You'll notice that if the window is offscreen, I allow for the fact that the user may *want* it offscreen, so I only move it on the edge so they can grab it. Some people way like them off to the side, who knows. ;-) Also, if it is set very large I set the size to about 90% of the screen resolution, but don't move it entirely on the screen. Since the size is scaled for them, if they do want to move it on the screen at least it will fit, but I'm not forcing it on them. What's the versionhistory stuff? {grin} OK, I put in some notes. >> It doesn't save sash position for windows that have it, perhaps this >> is something that should be added as an optional parameter. > > Sashes matter less and have far more sizing issues. (Which side are > you sizing from, and what do you shrink if the overall window is too > large?) OK, you've convinced me, I'll leave them alone. :-) I did start to look at it and you are right, MANY issues involved there and it's not as clear-cut as the size/position stuff.... >> Perhaps a separate percentage for height/width? Hmmmm.... > > Maybe just a percentage of screen and aspect ratio instead? I think > the aspect ratio better defines if the window looks well proportioned. I've implemented a "aspect ratio" as a decimal value of width/height. I've made the first pass at resizing using the EVT_CLOSE stuff. It worked great for the print preview frame, but it doesn't seem to work for the dialogs like config or comm. When you hit the "OK", "CANCEL", etc... you don't end up ever receiving a close event, so for those I had to leave in the call to save settings for each case, and I added a OnClose event for the case where the user just clicks on the window-close button; I treat it like a Cancel button. This isn't as generic as your proposed suggestion, but that generic approach wouldn't work with dialogs anyway from what I've seen. I'll look at implementing it for windows that it *would* work for, dialogs would just need a little extra code to cover all the bases. I'll keep poking at it, but as it is it's functional for the main window, print preview window, config dialog and commbrowser dialog. It's a start, and I can always clean up and refine later. ;-) |
From: bfaye <bf...@ya...> - 2004-02-24 16:55:35
|
After doing more studying, I figured the code below for p_sanyo8100.p would help better: # 8100 Camera picture file reading PACKET sanyocamresponse: 179 UNKNOWN +pad PACKET sanyonumofcamerapicrequest: * sanyomediaheader {'command': 0x09, 'subcommand': 0x0072} +header 2 UINT {'constant': 0xffff} +word 172 UNKNOWN +pad PACKET sanyonumofcamerapicresponse: 172 UNKNOWN +pad 1 UINT numcampics 6 UNKNOWN +pad2 And this code to get the number of pics: req=self.protocolclass.sanyonumofcamerapicrequest() res=self.sendpbcommand(req, self.protocolclass.sanyonumofcamerapicresponse) self.log("got %d camera pics" % (res.numcampics-1,)) It seems command 0x09 and subcommand 0x0073 will get filenames. Sending a packet like the following will get a response back with the filename at the index specified at offset a8: 00000000 fa 00 09 73 00 ff ff 00 00 00 00 00 00 00 00 00 ...s............ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000a0 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 000000b0 00 00 00 f5 af 7e .....~ Billy __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
From: Stephen W. <sa...@us...> - 2004-02-24 16:47:30
|
On Tue, 2004-02-24 at 00:35, Roger Binns wrote: > > I made a version of sendpbcommand in com_sanyo5500 that seems to get > > around timeouts. I simply rewrite the output packet and wait for the > > reply again. This can work for the sanyo phones since there are no init > > and nextentry as there are for the LG phones. > > When you are happy with it, can you put it back in the main code for all > phones :-) Maybe add a safe to retry parameter to the routine which would > always be yes for Sanyo, and no for Brew and LG stuff? Are you proposing to merge sendbrewcommand, the LG sendpbcommand and the Sanyo sendpbcommand into one routine? They are all similar, so I guess that's possible. The Brew error reporting in sendbrewcommand should be safe for Phonebook calls since presumably there are no phonebook protocol packets starting with 0x59. Presumably I can also figure out how to bypass the sequence stuff in the LG sendpbcommand by testing to see if request.header.sequence exists. At any rate, there is stuff in the LG sendcommand, like CRC checking, that you added since I forked the Sanyo one that I should have in the Sanyo code. > > > E: Ad=8a(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > E: Ad=0b(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > > > I think the Sanyo 5500 is also 64 characters. > > That is what it looks like for those endpoints. It doesn't quite explain > why Snoopy was claiming packets larger than that since that would be a > violation of the USB protocol. Is there anyther usb monitor program that you recommend other than snoopypro? Stephen |
From: Roger B. <ro...@ro...> - 2004-02-24 05:47:30
|
Steven Palm wrote: > I've started to implement some of the window size/position saving code. > Roger, check it out and let me know if this is what you had in mind. Looks good. It is what I was expecting, and you even check the window is on the screen :-) Don't forget to update help/versionhistory.htd > It > doesn't save sash position for windows that have it, perhaps this is > something that should be added as an optional parameter. Sashes matter less and have far more sizing issues. (Which side are you sizing from, and what do you shrink if the overall window is too large?) > Perhaps a separate percentage for height/width? Hmmmm.... Maybe just a percentage of screen and aspect ratio instead? I think the aspect ratio better defines if the window looks well proportioned. > window by the user... The print preview thing goes off on it's own when > you do the show() method, and I can't find a hook to determine what the > last size/position was before it was closed. There are two ways of doing it. One is make it modal. The other simpler way is to hook into EVT_CLOSE. In particular note that EVT_CLOSE doesn't require the handler to be in the same class. My best guess is that the following should work in gui.py: def RegisterForSaveSize(self, window, prefix): wx.EVT_CLOSE(window, lambda evt: self.SaveSizeInfo(window, prefix, evt)) def SaveSizeInfo(self, window, prefix, evt): evt.Skip() # cause remaining event handlers to run ... save dimensions of window, using config key prefix You could even combine the RegisterForSaveSize to resize the supplied window based on the config (ie add in the percentage/aspect ratio params). I am not 100% certain the above will work, but if it does it should make it trivial to do sizing for all windows just by calling Register... from their constructor. Roger |
From: Roger B. <ro...@ro...> - 2004-02-24 05:35:33
|
> I made a version of sendpbcommand in com_sanyo5500 that seems to get > around timeouts. I simply rewrite the output packet and wait for the > reply again. This can work for the sanyo phones since there are no init > and nextentry as there are for the LG phones. When you are happy with it, can you put it back in the main code for all phones :-) Maybe add a safe to retry parameter to the routine which would always be yes for Sanyo, and no for Brew and LG stuff? > E: Ad=8a(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=0b(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > I think the Sanyo 5500 is also 64 characters. That is what it looks like for those endpoints. It doesn't quite explain why Snoopy was claiming packets larger than that since that would be a violation of the USB protocol.bp The USBFile code in BitPim chops up USB requests and responses to be the max size (or the size requested if smaller). Maybe the kernel internals do the same as well. Roger |
From: Roger B. <ro...@ro...> - 2004-02-24 05:29:42
|
> + data=com_brew.unescape(data) > + # get rid of leading junk > + d=data.find(firsttwo) > + if d>0: > + data=data[d:] > + # take off crc and terminator ::TODO:: check the crc > + data=data[:-3] You should add the CRC checking. Copy it from one of these places: com_lg.py line 90 com_brew.py line 297 They also deal with multiple responses being in the data read. That would happen if a command was sent, the comms failed for whatever reason, a second command is sent and succeeds and then the read returned both responses joined together. The readuntil code in the comms is arguably broken because it always reads all available characters, and then checks the last one to see if it has the character being looked for. The reason it is done that way is to avoid having buffers in the program code with unread data. Roger |
From: Steven P. <n9...@n9...> - 2004-02-24 04:58:17
|
I've started to implement some of the window size/position saving code. Roger, check it out and let me know if this is what you had in mind. It doesn't save sash position for windows that have it, perhaps this is something that should be added as an optional parameter. Also, some windows (like config dialong, etc) would do better with a suggested size rather than suggested percentage, since it's not square in it's best form. Perhaps a separate percentage for height/width? Hmmmm.... It is doing a much better job on the Mac for sizing the print preview window, however I can't find a way to save any size changes made to the window by the user... The print preview thing goes off on it's own when you do the show() method, and I can't find a hook to determine what the last size/position was before it was closed. I suppose in C++ you could override the destructor, but it doesn't exist in Python, does it? Any other ideas? I'm not coming up with much, so it's time to take a break and step back a little bit. |
From: Stephen W. <sa...@ge...> - 2004-02-24 04:57:01
|
On Mon, 2004-02-23 at 15:59, Roger Binns wrote: > > I'll do something. If I can keep the hack limited to com_sanyo5500, I > > may check it in. > > Ideally I would like a generic solution that can work for all phones. > So far I don't have a solution that works for ANY phone! I made a version of sendpbcommand in com_sanyo5500 that seems to get around timeouts. I simply rewrite the output packet and wait for the reply again. This can work for the sanyo phones since there are no init and nextentry as there are for the LG phones. > > > How do I get the bulk limit? When I was trying the Sanyo 4900 using > > libusb, things would seem to happen in 64 byte chunks. It also always > > eventually timed out on me. > > It is wMaxPacketSize in an endpoint descriptor. This is from an AudioVox > 8900. > > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type none > wMaxPacketSize 64 > bInterval 0 > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 9 Spd=12 MxCh= 0 D: Ver= 1.01 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0474 ProdID=0701 Rev= 0.00 S: Manufacturer=SANYO Electric Co. Ltd. S: Product=SANYO USB Phone S: SerialNumber=Serial Number C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm E: Ad=8a(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I think the Sanyo 5500 is also 64 characters. Stephen > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Bitpim-devel mailing list > Bit...@li... > https://lists.sourceforge.net/lists/listinfo/bitpim-devel |
From: bfaye <bf...@ya...> - 2004-02-24 02:42:26
|
I did some "snoopying" and got some code that would get the filenames and file contents of pictures taken with the onboard camera, as well as setting the camera into the "pc sync" mode. I'm not sure how to proceed, since the code is still "immature" at best. If there is another developer that wants to take a look at the code, and add it in properly/analyze it, let me know. I will post what I got here. I added this code in the getwallpaperindices function in com_sanyo.py, and looked at the protocol log to see the filenames. I did hit a snag though, when I got to reading the 11th filename, it just hung. If I program it to skip trying to get the 11th filename, it works. I have a total 15 camera files on my phone. Heres the code: def setSanyoPCSyncMode(self): data="\xfa\x00\x0A\x00\x00\x03\x6f\x7e" request=p_sanyo.bufferpartrequest() numretry=2 self.logdata("Sanyo camera pics request: setting phone to pc sync mode", data, request) #data=com_brew.escape(data+com_brew.crcs(data))+self.pbterminator self.logdata("Sanyo phonebook request after brew escape: ", data, request) firsttwo=data[:2] try: self.comm.write(data, log=False) # we logged above data=self.comm.readuntil(self.pbterminator, logsuccess=False, numfailures=numretry) ##data=self.comm.readsome() except com_phone.modeignoreerrortypes: self.mode=self.MODENONE self.raisecommsdnaexception("manipulating the phonebook") self.comm.success=True # log it responseclass=p_sanyo.bufferpartresponse self.logdata("sanyo camera pics response: setting phone to pc sync mode", data, responseclass) data=com_brew.unescape(data) # get rid of leading junk d=data.find(firsttwo) if d>0: data=data[d:] # take off crc and terminator ::TODO:: check the crc data=data[:-3] # log it responseclass=p_sanyo.bufferpartresponse self.logdata("sanyo camera pics response: setting phone to pc sync mode", data, responseclass) return "success" def getwallpaperindices(self, results): ## added by Billy request=p_sanyo.bufferpartrequest() numretry=2 self.comm.setbaudrate(38400) self.setmode(self.MODEBREW) self.setSanyoPCSyncMode() self.comm.ser.flushInput() self.comm.ser.flushOutput() ## not sure what this does... data="\xfa\x00\x09\x71\x00\xff\xff" data=data+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" data=data+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" data=data+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" data=data+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" data=data+"\x00\x00\x00\x00\x00\x00\x01\x00\x17\xdf\x7e" self.logdata("Sanyo camera pics request", data, request) firsttwo=data[:2] try: self.comm.write(data, log=False) # we logged above data=self.comm.readuntil(self.pbterminator, logsuccess=False, numfailures=numretry) ##data=self.comm.readsome() except com_phone.modeignoreerrortypes: self.mode=self.MODENONE self.raisecommsdnaexception("manipulating the phonebook") self.comm.success=True data=com_brew.unescape(data) # log it responseclass=p_sanyo.bufferpartresponse self.logdata("sanyo camera pics response", data, responseclass) # get rid of leading junk d=data.find(firsttwo) if d>0: data=data[d:] # take off crc and terminator ::TODO:: check the crc data=data[:-3] ################## ### this probably gets a count of how many pics are in the camera folder data="\xfa\x00\x09\x72\x00\xff\xff" for stupidcount in range(0, 172): data=data+"\x00" data=data+com_brew.crcs(data)+self.pbterminator self.logdata("Sanyo camera pics request", data, request) firsttwo=data[:2] try: self.comm.write(data, log=False) # we logged above data=self.comm.readuntil(self.pbterminator, logsuccess=False, numfailures=numretry) ##data=self.comm.readsome() except com_phone.modeignoreerrortypes: self.mode=self.MODENONE self.raisecommsdnaexception("manipulating the phonebook") self.comm.success=True data=com_brew.unescape(data) # get rid of leading junk d=data.find(firsttwo) if d>0: data=data[d:] # take off crc and terminator ::TODO:: check the crc data=data[:-3] # log it responseclass=p_sanyo.bufferpartresponse self.logdata("sanyo camera pics response", data, responseclass) for d in range(0,172): data=data[1:] campiccount=ord(data[0]) self.log("got %d camera pics" % (campiccount-1,)) #################### ### read filenames for cc in range(0, campiccount): self.comm.ser.flushInput() self.comm.ser.flushOutput() data="\xfa\x00\x09\x73\x00\xff\xff" for stupidcount in range(0, 161): data=data+"\x00" if cc==11: cc=12 data=data+chr(cc) ##for c in range(0,9): ## data=data+"\x00" ##data=data+"\x7d\x5d\xb8"+self.pbterminator ##else: for c in range(0, 10): data=data+"\x00" data=data+com_brew.crcs(data)+self.pbterminator self.logdata("Sanyo camera pics request", data, request) firsttwo=data[:2] try: self.comm.write(data, log=False) # we logged above time.sleep(0.5) data=self.comm.readuntil(self.pbterminator, logsuccess=False, numfailures=numretry) ##data=self.comm.readsome() except com_phone.modeignoreerrortypes: self.mode=self.MODENONE self.raisecommsdnaexception("manipulating the phonebook") self.comm.success=True data=com_brew.unescape(data) # get rid of leading junk # log it responseclass=p_sanyo.bufferpartresponse self.logdata("sanyo camera pics response", data, responseclass) ###################### return self.getmediaindex(self.builtinimages, self.imagelocations, results, 'wallpaper-index') ------------end code I didn't have code in there that retrieves content of the files, but the command sent is fa00097400ffff followed by a bunch of zeroes (haven't counted yet), the file index number, some more zeroes, the checksum and pbterminator. Oh, my name is Billy by the way. __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |