[Bitpim-devel] Sanyo Sprint phones

[Stephen Wood]

I have a Sanyo 4900 sprint phone. A while ago I came across the qcplink
project (http://qcplink.sourceforge.net/), a project to develop sync
software for the QCP-2760, an old Qualcomm phone. I also came across a
sketchy report of captures of traffic to/from a Sanyo4900 using a
commercial sync program. The gist of this report is that hdlc packets
508 bytes long are used. The first byte of "Read" packets is 0x0d and
write packets is 0x0e. I did a lot of exploring of the phone and found
how to read the phone book, calendar, received messages, call history,
speed dial list, ringer assignments, and owner information. I have not
tried writing to the phone yet, but I think the phone has to be put into
a mode to accept writes and then reset at the end. In addition to the
phone book entries, I think that buffers containing alphabetic sort
information and lists of phone number for caller ID to show names, must
be constructed properly and sent.

I have made a perl script (kind of ugly and probably not too efficient)
that includes basically all I learned about the phone and I would be
happy to share that with other Sanyo 4900 (or other recent Sanyo Sprint
phones) owners or post it here (are attachments allowed in this mailing
list?)

I discovered bitpim recently and noticed the note that other Qualcomm
chipset phone should work, at least in file system view. The filesystem
view indeed works with the 4900. The top directory contains the files:
RDM_PORT_MAP, $SYS.FACTORY, $SYS_RMT, uivrState.dat, $USER_DIRS amd the
directories nvm and VoiceDB. The VoiceDB directory has files with dates
that seem to corresond to when I recorded voice dial entries. I don't
know if they are digitized speech or just some meta information. The
files are about 500 to 700 bytes long (my voice dial entries are single
words or names) and have the file extension .tag. The nvm directory
contains $SYS.ESN, $SYS.INVAR1, $SYS.INVAR2 and nvm and prl
subdirectories. The files in prl seem to basically be full of nulls.
nvm contains 24 files (nvm_0000 to nvm_0023) with sizes from 5 to 48200
bytes. These files seem to contain all the information that I have
extracted from the phone via other means and not much else.

Are there other Sanyo owners here that would like to work with me on
adding Sanyo 4900 capability to Bitpim?

Steve

[Roger Binns]

Post by Stephen Wood
The gist of this report is that hdlc packets
508 bytes long are used.

Looking at their protocol document, the actual packet formatting
is similar. The CRC and \x7e on the end of each one is identical
as is the the AT$QCDMG. LG also has AT$LGDMGO.

Post by Stephen Wood
RDM_PORT_MAP, $SYS.FACTORY, $SYS_RMT, uivrState.dat, $USER_DIRS amd the
directories nvm and VoiceDB.

The joy of all of these phones is that the file system layouts are very
similar, but not identical. It seems like they arbitrarily go out
of their way to be different even for different models from the
same manufacturer.

Post by Stephen Wood
The VoiceDB directory has files with dates
that seem to corresond to when I recorded voice dial entries. I don't
know if they are digitized speech or just some meta information.

I believe they are purevoice files. BitPim in cvs has some support
for them.

Post by Stephen Wood
Are there other Sanyo owners here that would like to work with me on
adding Sanyo 4900 capability to Bitpim?

I will help you as much as I can, although I don't have the phone. The
first step is to check out the code and prerequisites as in
http://bitpim.sourceforge.net/developer.html

Note that the anonymous CVS stuff is at least 24 hours behind, and
doesn't seem to be working for me at all. If you have issues, email
me and I can send you the latest source etc in a zip file.

You should now have a look at what the other phones do to read a phonebook.

[Stephen Wood]

Thanks for the encouragement Roger. You have given me a bit to chew on.
I'll try to spend some time on it over the weekend.

I have a couple of comments about my phone.

The Sanyo 4900 phone book allows for each entry 7 phone numbers of the
fixed types Home, Work, Mobile, Pager, Data, Fax, and No Label. But the
phones in bitpim seem to be like what I have seen in friends phones,
namely that each phone number associated with a name can be given any
type, (which I find more useful). Can the Sanyo phone book structure be
fit into the bitpim structure that is being developed? I am guessing
that if one wanted to import a phone book with duplicate types (e.g. a
Home1, Home2, Home3), a sanyo sync could accept the first phone number
with a type matching Home.* and discard the rest. (Perhaps extra
numbers could optionally be shoved into less used types such as "No
Label", "Data", and perhaps Fax and Pager.)

Is there a framework within bitpim for holding call history and received
SMS messages? The call history and messages all have dates and times on
them, so perhaps this stuff could be read from the phone and put in
bitpim's calendar (and exported to vcalendar?). This could be handy for
someone who likes to keep a log of calls. If these call history and
message "calendar" entries are tagged, then they could be ignored when
syncing to the phone since it seems to me that the value is getting this
stuff out of the phone, not sending to the phone.

In interpreting 32 bit dates on the Sanyo4900, I had a fudge factor of 5
days different from starting the epoch on July 1, 1980. I noticed that
the fudge factor is 4 days and 17 hours for the LG-VX4400. Is that
because BITPIM translates times into GMT, whereas I am translating into
localtime? I don't believe my phone really knows what timezone it is
in, it just makes time whatever the towers tell it is.

Steve

[Roger Binns]

Post by Stephen Wood
Can the Sanyo phone book structure be
fit into the bitpim structure that is being developed?

Yes. Note that other data sources such as the Windows Address Book
also just have them seperately, with no idea of priority.

Post by Stephen Wood
I am guessing
that if one wanted to import a phone book with duplicate types (e.g. a
Home1, Home2, Home3), a sanyo sync could accept the first phone number
with a type matching Home.* and discard the rest. (Perhaps extra
numbers could optionally be shoved into less used types such as "No
Label", "Data", and perhaps Fax and Pager.)

Yes, that would be the general theory.

They way I have it structured now is that when you choose to write
out the phonebook, getfundamentals() is called on the Phone object.
It needs to get whatever information is appropriate from the phone.
For the 4400, it gets the group listing and the ESN. It will also
get the ringtone and wallpaper index (which I need to do some work
on).

Then the convertphonebooktophone() method is called in the Profile
object. This runs in the main thread (all serial comms is done
in a background thread).

convertphonebooktophone needs to massage the data into what it intends
to write. It can generate warnings and in very serious cases, errors.
I am hoping to "score" them in some way, and allow the user to see
the most important ones first, and potentially abort.

Some examples of warnings are that some phones (eg the 4400) can't
have entries without phone numbers. Also fields may be truncated
to various lengths. The helper class passed in to convertphonebooktophone
will log all this and do most of the conversion work. See
com_lgvx4400.Profile and phonebook.PhoneWidget for them working
together.

Post by Stephen Wood
Is there a framework within bitpim for holding call history and received
SMS messages?

Not yet, but it is on my todo list :-)

Post by Stephen Wood
The call history and messages all have dates and times on
them, so perhaps this stuff could be read from the phone and put in
bitpim's calendar (and exported to vcalendar?). This could be handy for
someone who likes to keep a log of calls. If these call history and
message "calendar" entries are tagged, then they could be ignored when
syncing to the phone since it seems to me that the value is getting this
stuff out of the phone, not sending to the phone.

Can you put a feature request into SourceForge for this, giving your
example etc so that we don't forget about it?

My current priorities are to get address book syncing working
(as well as a UI for the address book), and release that as
0.7. Then the other fluffy stuff follows like you SMS and call
history.

Post by Stephen Wood
In interpreting 32 bit dates on the Sanyo4900, I had a fudge factor of 5
days different from starting the epoch on July 1, 1980. I noticed that
the fudge factor is 4 days and 17 hours for the LG-VX4400. Is that
because BITPIM translates times into GMT, whereas I am translating into
localtime? I don't believe my phone really knows what timezone it is
in, it just makes time whatever the towers tell it is.

I use GMT in the code because I don't want timezone conversion done.
I too believe the phone has no idea of timezones.

So if the phone thinks that something is at 3pm, in the routines I
call I supply that 3pm as a GMT number, but display it to the user
as is, but saying it is local time (ie 3pm). If I did try to use
local timezone then the original number would have to be fudged and
other fun things.

The other possibility is that the phone may actually be operating
in GMT for date/timestamps.

The TM520/VX10 also used something different which Scott/Alan can
remind us of.

Roger