[Bitpim-devel] Better 8100 camera pic protocol

[bfaye]

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

[Stephen Wood]

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

Post by bfaye
After doing more studying, I figured the code below for p_sanyo8100.p would
Billy

[greg cunningham]

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

Post by Stephen Wood
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

Post by bfaye
After doing more studying, I figured the code

below for p_sanyo8100.p would

Post by bfaye
Billy

-------------------------------------------------------

Post by Stephen Wood
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

Post by Stephen Wood
_______________________________________________
Bitpim-devel mailing list

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

[Tom Tracey]

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" <***@yahoo.com>
To: <bitpim-***@lists.sourceforge.net>
Sent: Tuesday, February 24, 2004 11:53 AM
Subject: [Bitpim-devel] mp3 files may work on the vx4400 if under 64k and
renamed .mid

Post by greg cunningham
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

Post by Stephen Wood
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

Post by bfaye
After doing more studying, I figured the code

below for p_sanyo8100.p would

Post by bfaye
Billy

-------------------------------------------------------

Post by Stephen Wood
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

Post by Stephen Wood
_______________________________________________
Bitpim-devel mailing list

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
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[bfaye]

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

Post by Stephen Wood
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

[Stephen Wood]

Post by bfaye
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

[bfaye]

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

Post by Stephen Wood
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

[greg cunningham]

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

[Roger Binns]

Post by greg cunningham
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