[BitPim-devel] Sanyo RL-4930

[Mc Kiernan, Daniel Kian]

I've just begun looking at the code for BitPim trying to discern what
I must learn or report to generate support for the Sanyo RL-4930.

I see that I should look at com_sanyo4920.py. Which other files
should draw special attention? What is generating p_sanyo4920.py?

(I don't presently know Python, but I have many other languages under
my belt.)

I immediately note the following differences from the RL-4920:

The memory of the RL-4930 is 2 MB (not 1 MB).

The digital voice recorder holds a total of 130 minutes (low qual)
or 65 minutes (high qual), divided amongst up to 20 memos.

The built-in ringtone melodies are these 9 (not 11):

'Gymnopedie', 'Hungarian Dance No.5', 'The Moment',
'Habanera', 'Pomp and Circumstance', 'Canon',
'Techno Beat', 'Asian Jingle', 'Kung Fu'

There may be 500 (not 300) phonebook records, and 700 numbers may be
stored).

The FCC ID is AEZSCP-4930.

Acting on a request/suggestion from Stephen Wood, I attempted to read
the phonebook using the BitPim settings both for the RL-4920 and for
the Sanyo 8300. In the case of the RL-4920 setting, in or out of PC
Sync mode, I get the error message

SCP-4920 on COM5: The phone is not responding while manipulating the
phonebook.

See the help for troubleshooting tips.

And the phone itself is relocked in-process.

In the case of the 8300 setting, in or out of PC Sync mode, there is
no relocking, but an extended diagnostic, as follows:

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

An unexpected exception has occurred.
Please see the help for details on what to do.

Traceback (most recent call last):
File "gui.pyo", line 174, in run
File "gui.pyo", line 114, in __call__
File "gui.pyo", line 1634, in getdata
File "gui.pyo", line 1628, in getfundamentals
File "com_sanyo8300.pyo", line 126, in getfundamentals
File "com_sanyomedia.pyo", line 63, in getmediaindices
File "com_sanyonewer.pyo", line 51, in sendpbcommand
File "com_sanyo.pyo", line 289, in sendpbcommand
SanyoCommandException: Sanyo Packet Error 0x79

Variables by last 8 frames, innermost last

Frame run in gui.pyo at line 167
e = <com_sanyo.SanyoCommandException instance at
0x02AB29B8>
res = None
self = <WorkerThread(BitPim helper, started daemon)>
item = (<gui.Request instance at 0x02AA2B48>,
<gui.Callback instance at 0x02AA2030>)
call = <gui.Request instance at 0x02AA2B48>
ex = <com_sanyo.SanyoCommandException instance at
0x02AB29B8>
resultcb = <gui.Callback instance at 0x02AA2030>
first = 0

Frame __call__ in gui.pyo at line 114
self = <gui.Request instance at 0x02AA2B48>
args = ()
d = Keys []
{}
kwargs = Keys []
{}

Frame getdata in gui.pyo at line 1634
self = <WorkerThread(BitPim helper, started daemon)>
req = <guiwidgets.GetPhoneDialog; proxy of C++ wxDialog
instance at _d867e901_p_wxDial
todo = [(<bound method WorkerThread.rebootcheck of
<WorkerThread(BitPim helper, started

Frame getfundamentals in gui.pyo at line 1628
self = <WorkerThread(BitPim helper, started daemon)>
results = Keys ['ringtone-index', 'uniqueserial',
'wallpaper-index']
{'wallpaper-index': {}, 'uniqueserial':
'14e1596bcf9a6a91818df3d975048e125cfb2e2

Frame getfundamentals in com_sanyo8300.pyo at line 126
res = <p_sanyo.esnresponse object at 0x02B07210>
self = <com_sanyo8300.Phone instance at 0x02AA2B70>
req = <p_sanyo.esnrequest object at 0x028D4630>
results = Keys ['ringtone-index', 'uniqueserial',
'wallpaper-index']
{'wallpaper-index': {}, 'uniqueserial':
'14e1596bcf9a6a91818df3d975048e125cfb2e2

Frame getmediaindices in com_sanyomedia.pyo at line 63
copypat = <_sre.SRE_Pattern object at 0x027B1AA0>
res = <p_sanyomedia.sanyochangedirresponse object at
0x02B07430>
idir = 1
req = <p_sanyomedia.sanyonumfilesrequest object at
0x02B073B0>
results = Keys ['ringtone-index', 'uniqueserial',
'wallpaper-index']
{'wallpaper-index': {}, 'uniqueserial':
'14e1596bcf9a6a91818df3d975048e125cfb2e2
ringermedia = Keys [1, 2, 3, 10, 11, 12, 13, 14, 15, 16, 17, 30,
31, 32, 33, 34, 35, 36, 37, 38]
{32: {'origin': 'builtin', 'name': 'Hungarian
Dance'}, 1: {'origin': 'builtin',
imagemedia = Keys []
{}
self = <com_sanyo8300.Phone instance at 0x02AA2B70>

Frame sendpbcommand in com_sanyonewer.pyo at line 51
numsendretry = 2
writemode = False
responseclass = <class 'p_sanyomedia.sanyonumfilesresponse'>
callsetmode = True
returnerror = False
request = <p_sanyomedia.sanyonumfilesrequest object at
0x02B073B0>
self = <com_sanyo8300.Phone instance at 0x02AA2B70>

Frame sendpbcommand in com_sanyo.pyo at line 289
numsendretry = 2
isendretry = 2
origdata =
'y\xfa\x00\tr\x00\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00}^\x98~'
trydata =
'y\xfa\x00\tr\x00\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00'
d = 1
responseclass = <class 'p_sanyomedia.sanyonumfilesresponse'>
writemode = False
i = 0
res = <p_sanyomedia.sanyonumfilesresponse object at
0x02B074F0>
callsetmode = True
returnerror = False
firsttwo = '\xfa\x00'
request = <p_sanyomedia.sanyonumfilesrequest object at
0x02B073B0>
crc = '~\x98'
buffer = <prototypes.buffer instance at 0x02AA5198>
rdata =
'y\xfa\x00\tr\x00\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00}^\x98~'
data =
'y\xfa\x00\tr\x00\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00~\x98~'
self = <com_sanyo8300.Phone instance at 0x02AA2B70>
numretry = 0
crcok = True

[Stephen Wood]

Post by Mc Kiernan, Daniel Kian
...
I see that I should look at com_sanyo4920.py. Which other files
should draw special attention? What is generating p_sanyo4920.py?

com_sanyo4920 doesn't have much in it. The real meat is in com_sanyo.py and
com_sanyomedia.py from which the 4920 inherits code. The p*.py files are
generated from the p*.p files. Running "python protogen.py" compiles all
the .p files. Again here, most of the interesting stuff is in p_sanyo.p and
p_sanyonewer.p.

Post by Mc Kiernan, Daniel Kian
There may be 500 (not 300) phonebook records, and 700 numbers may be
stored).

This would be good to confirm.

...

Post by Mc Kiernan, Daniel Kian
Acting on a request/suggestion from Stephen Wood, I attempted to read
the phonebook using the BitPim settings both for the RL-4920 and for
the Sanyo 8300. In the case of the RL-4920 setting, in or out of PC
Sync mode, I get the error message

What I think I get from this report is that like the 8300, the 4930's
filesystem can't be read by BitPim. The 8300 support does not depend on the
filesystem, but it looks like it bombed out becuase it was trying to read
information about the camera, which I presume the 4930 does not have.

If you can get BitPim running from source code (see
http://www.bitpim.org/developer.html), I could make provisional 4930 module
and we could find out if adding 4930 support to BitPim is feasible.

Stephen

[Mc Kiernan, Daniel Kian]

Post by Stephen Wood

Post by Mc Kiernan, Daniel Kian
There may be 500 (not 300) phonebook records, and 700 numbers may be
stored).

This would be good to confirm.

By "may" I mean that that many records are permitted. I drew those
figures from Sanyo specifications. (I admit to not attempting to enter
that many records.)

Post by Stephen Wood
the camera, which I presume the 4930 does not have.

Right; no camera.

Post by Stephen Wood
If you can get BitPim running from source code

Okay, when next I have booted to linux, I will do this.

[Stephen Wood]

Post by Mc Kiernan, Daniel Kian

Post by Stephen Wood

Post by Mc Kiernan, Daniel Kian
There may be 500 (not 300) phonebook records, and 700 numbers may be
stored).

This would be good to confirm.

By "may" I mean that that many records are permitted. I drew those
figures from Sanyo specifications. (I admit to not attempting to enter
that many records.)

I guess that confirms it!

Post by Mc Kiernan, Daniel Kian

Post by Stephen Wood
If you can get BitPim running from source code

Okay, when next I have booted to linux, I will do this.

BitPim also runs from source under Windows just fine. (Not that I prefer to
do so.)

Stephen

[Mc Kiernan, Daniel Kian]

Post by Stephen Wood

Post by Stephen Wood
If you can get BitPim running from source code

Okay, I've done this.

Post by Stephen Wood
BitPim also runs from source under Windows just fine. (Not that I
prefer to do so.)

I'll slog through the process of getting that going later. ;-) (I note
that the Windows binaries for the infrastructure (pyWin and all that)
are out-of-date.)

[Stephen Wood]

Post by Mc Kiernan, Daniel Kian

Post by Stephen Wood

Post by Stephen Wood
If you can get BitPim running from source code

Okay, I've done this.

Great.

Try this.

Edit com_sanyo8300.py. Change LAST_MEDIA_DIRECTORY=3 to
LAST_MEDIA_DIRECTORY=1. (I think LAST_MEDIA_DIRECTORY=2 might be OK, but
try 1 first.)

Then try reading your phonebook (and other things) using the 8300 setting.
Do this with protocol logging turned on and send me (privately) the entire
protocol log.

Post by Mc Kiernan, Daniel Kian
BitPim also runs from source under Windows just fine. (Not that I

Post by Stephen Wood
prefer to do so.)

I'll slog through the process of getting that going later. ;-) (I note
that the Windows binaries for the infrastructure (pyWin and all that)
are out-of-date.)

There has been some discussion of this here lately, I forget the details.
One part of it is that for windows we are stuck on Python 2.3 because of
uncertainty about licensing issues. In any case, I did successfully setup
the windows environment on two different machines in the last few months.

Stephen

[Roger Binns]

Post by Mc Kiernan, Daniel Kian
(I note
that the Windows binaries for the infrastructure (pyWin and all that)
are out-of-date.)

The same version of all components is used on all platforms, so you
are just as out of date on Linux and Mac.

Everything should work with more recent and in many cases older versions
of the components. However that means that any testing and bug finding
you do will first have to go through a round of working out if the bug
is in the component or in BitPim.

Roger

[Mc Kiernan, Daniel Kian]

Post by Roger Binns

(I note that the Windows binaries for the infrastructure (pyWin and
all that) are out-of-date.)

The same version of all components is used on all platforms, so you
are just as out of date on Linux and Mac.

Well, no and yes. win32all doesn't participate in other platforms,
and I was writing of the Windows binaries. But I'm sure that I could
get everything co-operating if I punted and recompiled (hence my
reference to slogging through such an installation).