Discussion:
[BitPim-devel] VX5400 memo (Notes) test, version 1.0.3.20071206
r***@cox.net
2007-12-07 09:41:48 UTC
Permalink
Using the VX5400 setting of version 1.0.3.20071206, there are no exceptions raised when reading or writing notes. The notes are read into Bitpim correctly. But when writing notes to the phone, all of the notes have the same text and date/time as the first note in sch/memo.dat.

If anyone has a VX8550, could you check to see if the same thing is happening on that phone?

I have done some testing on the VX5400 to find out where the problem is. In sch/memo.dat, the first 4 bytes (apparently a dword?) are reserved for the number of text notes (memos), with low byte first. Bitpim increments and decrements this dword(?) correctly.

After those first 4 bytes, there are 312 byte segments written for each note. The text of the note begins at the 5th byte of the 312 byte segment and continues for 301 total bytes (each note has a text limit of 300 characters + null delimiter = 301 bytes). After the 301 bytes for the note's text, there are 7 remaining bytes of which the first 4 (again, a dword?) appear to be a date/time reference for the note. The last 3 bytes are 0. I tested the 300 character text limit of the VX5400 -- Bitpim is writing the text correctly, and truncates after 300 characters.

I don't know what the first 4 bytes (dword?) of each note segment represents, but for the first 4 bytes (dword?) of each note segment, Bitpim writes an identical dword for all notes. If the notes are sent to the VX5400 phone from Bitpim, all of the notes on screen will have the same text (and date/time) as the first note of memo.dat (the notes are written correctly by Bitpim to memo.dat, but the phone is apparently unable to read memo.dat correctly). If I manipulate the memo.dat file and make the first dword for each note segment unique (no particular order, and any of the 4 bytes of the dword), the notes appear on the phone with the correct text and date/time.

So, it appears that the VX5400 requires this dword to be unique for each note entry, even though the actual value of the dword appears to be insignificant. Is there a way to make this dword unique for each note in the VX5400 (or possibly in the parent phone -- VX8550 -- if it is showing the same problem)?

When entering a note on the phone, the dword appears to be increasing based on the time (but I don't believe the actual value is significant). Is it possible to take the dword value that Bitpim is writing for the first note and increment it for each note?

Thanks.

Ron
Nathan Hjelm
2007-12-07 16:16:59 UTC
Permalink
The field in question looked like a creation date (measured in seconds
since the brew epoch). It wouldn't surprise me if the date was
actually used as a unique identifier on some phones. It isn't be a
problem to add some sort of increment to this value. The Voyager isn't
affected by this problem but I will check if it affects the VX-8350.

-Nathan Hjelm
Post by r***@cox.net
Using the VX5400 setting of version 1.0.3.20071206, there are no
exceptions raised when reading or writing notes. The notes are read
into Bitpim correctly. But when writing notes to the phone, all of
the notes have the same text and date/time as the first note in sch/
memo.dat.
If anyone has a VX8550, could you check to see if the same thing is
happening on that phone?
I have done some testing on the VX5400 to find out where the problem
is. In sch/memo.dat, the first 4 bytes (apparently a dword?) are
reserved for the number of text notes (memos), with low byte first.
Bitpim increments and decrements this dword(?) correctly.
After those first 4 bytes, there are 312 byte segments written for
each note. The text of the note begins at the 5th byte of the 312
byte segment and continues for 301 total bytes (each note has a text
limit of 300 characters + null delimiter = 301 bytes). After the
301 bytes for the note's text, there are 7 remaining bytes of which
the first 4 (again, a dword?) appear to be a date/time reference for
the note. The last 3 bytes are 0. I tested the 300 character text
limit of the VX5400 -- Bitpim is writing the text correctly, and
truncates after 300 characters.
I don't know what the first 4 bytes (dword?) of each note segment
represents, but for the first 4 bytes (dword?) of each note segment,
Bitpim writes an identical dword for all notes. If the notes are
sent to the VX5400 phone from Bitpim, all of the notes on screen
will have the same text (and date/time) as the first note of
memo.dat (the notes are written correctly by Bitpim to memo.dat, but
the phone is apparently unable to read memo.dat correctly). If I
manipulate the memo.dat file and make the first dword for each note
segment unique (no particular order, and any of the 4 bytes of the
dword), the notes appear on the phone with the correct text and date/
time.
So, it appears that the VX5400 requires this dword to be unique for
each note entry, even though the actual value of the dword appears
to be insignificant. Is there a way to make this dword unique for
each note in the VX5400 (or possibly in the parent phone -- VX8550
-- if it is showing the same problem)?
When entering a note on the phone, the dword appears to be
increasing based on the time (but I don't believe the actual value
is significant). Is it possible to take the dword value that Bitpim
is writing for the first note and increment it for each note?
Thanks.
Ron
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel
Joe Pham
2007-12-07 22:30:27 UTC
Permalink
It wouldn't surprise me if the date was actually used as a unique
identifier on some phones. It isn't be a problem to add some sort of
increment to this value.
It could probably be done from within the protocol fields. I'll take a quick look at it.

-Joe Pham


_____________________________________________________________
Kaiser Permanente Affordable Plans
Quality health care coverage for individuals and families.
http://thirdpartyoffers.netzero.net/TGL2211/fc/JKFkuJO6ZVMumR8hKfnIVy8UWEyNJgpEDxJ02rQbeuH7tOqoKSWDVy/
Joe Pham
2007-12-07 22:57:31 UTC
Permalink
Post by r***@cox.net
If I manipulate the memo.dat file and make the first dword for each
note segment unique (no particular order, and any of the 4 bytes of
the dword), the notes appear on the phone with the correct text and
date/time.
Thanks for the feedback and the insight. We should be able to do something 'bout it. Any other feedback on the other functions of the VX5400?

-Joe Pham


_____________________________________________________________
Click for free information on attaining an equity line of credit.
http://thirdpartyoffers.netzero.net/TGL2211/fc/Ioyw6ijmOqqirSukNqWrzgYpZIRdDdMk6fdjU0gNe1ChcOap91pFTu/
r***@cox.net
2007-12-08 10:42:17 UTC
Permalink
Thanks Joe and Nathan. The image preview now works and the ringer index is working correctly for the built-in ringtones. There appears to be an odd indexing issue when retrieving either a PictureID or a RingerID (using mp3 or midi files -- not built-in), but this only occurs when either of the IDs are changed in the phone and then retrieved into Bitpim. For contacts having a changed PictureID or RingerID, the retrieved PictureID incorrectly defaults to the first path in dload/image.dat and the RingerID incorrectly defaults to the first path in dload/myringtone.dat. The new test version did not create this problem -- I missed it when testing before. To correctly see this problem:

1. I delete all of the phonebook entries from Bitpim (Edit/Select All, Edit/Delete).
2. Then I change either a PictureID or a RingerID for a contact on the phone itself.
3. Then I retrieve the phonebook from the phone (using Replace All).
4. Then I check the PictureID or RingerID (whichever I changed, or both) for the contact, and it (or they) are wrong.
5. If I change the PictureID or RingerID in Bitpim, upload it, then retrieve it again (using steps 1 - 3) from the phone, the ID data is correct.

I'm still working on a better definition of the problem (so don't hold me to this one -- I may be doing something wrong), and I'll repost when I think I have a better handle on it (I'm going to examine the pbentry.dat, pbRingIdSetAsPath.dat, and pbPictureIdSetAsPath.dat files for pre-download and post-upload differences). It may be related to this same problem for the VX8550:

http://sourceforge.net/mailarchive/forum.php?thread_name=473698C5.8040105%40gmail.com&forum_name=bitpim-user

And I think another issue that might be a problem is when a contact entry is erased on the phone and the phonebook is then retrieved into Bitpim. The data for the now empty contact is filled with garbage. I'm still examining this issue as well. I'm guessing that it may appear on other phones using the same or similar pim/pbentry.dat layout.

The VX5400 works fine with a straight USB cable. The phone is identified correctly using the phone info button, and the detect phone selection finds the phone OK. Playlist and To Do are not supported, but that's not a big deal. The only other thing that I noticed about the phone is that mp3s should be saved with (at minimum) the 44.1khz and 48kbs settings (using mono). The phone has some type of automatic volume control that will distort lower quality mp3s.

Thanks again for all of the effort and results.

Ron
Post by Joe Pham
Post by r***@cox.net
If I manipulate the memo.dat file and make the first dword for each
note segment unique (no particular order, and any of the 4 bytes of
the dword), the notes appear on the phone with the correct text and
date/time.
Thanks for the feedback and the insight. We should be able to do something 'bout it. Any other feedback on the other functions of the VX5400?
-Joe Pham
Nathan Hjelm
2007-12-08 13:51:41 UTC
Permalink
\And I think another issue that might be a problem is when a contact
entry is erased on the phone and the phonebook is then retrieved
into Bitpim. The data for the now empty contact is filled with
garbage. I'm still examining this issue as well. I'm guessing that
it may appear on other phones using the same or similar pim/
pbentry.dat layout.
I have a fix for the issue you describe that did not make it into my
previous patch. I will submit the patch later today.

-Nathan
Nathan Hjelm
2007-12-08 21:12:58 UTC
Permalink
The promised patch is attached.



-Nathan
Post by Nathan Hjelm
\And I think another issue that might be a problem is when a
contact entry is erased on the phone and the phonebook is then
retrieved into Bitpim. The data for the now empty contact is
filled with garbage. I'm still examining this issue as well. I'm
guessing that it may appear on other phones using the same or
similar pim/pbentry.dat layout.
I have a fix for the issue you describe that did not make it into my
previous patch. I will submit the patch later today.
-Nathan
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel
r***@cox.net
2007-12-09 00:09:50 UTC
Permalink
Ken, I use the View/Filesystem in Bitpim to turn on the Filesystem branch. Then I select the Filesystem branch and expand the folder. See this link for more directions on activating and using Filesystem in Bitpim:

http://www.bitpim.org/help/tab-filesystem.htm

I think you can use Bitpim (and the Filesystem viewer) with your phone if you select Edit/Settings and then, for Phone Type, select Other CDMA. The link above explains how you can view and/or save the binary files on the phone to your computer. I would suggest using the Backup Entire Tree (right-click on a Filesystem folder to view the menu options) to transfer all of the files to your computer, first, and then use only copies of the backed up files for editing. To view and/or modify the files on your computer, you need a hex editor compatible with your operating system. For Windows XP, I use Cygnus Free Edition, located at:

http://www.softcircuits.com/cygnus/fe/

If you have a different OS, you will need to search the web for a hex editor. After editing a file, it can be sent back to the phone by using Bitpim -- see the instructions at the first link above. I would suggest being very cautious about overwriting files on your phone, especially if you have never edited a binary file. You might lock up your phone, so be sure to read the warnings at the link above, especially this one:

Note: You can cause damage to your phone in the filesystem view if you make any changes. Be very careful. (BitPim itself doesn't damage anything - it is just that the phone really cares about the contents and existence of some of those files, and deleting or changing them could upset it).

Ron
Post by Ken Schnell
What kind of tool is used to view the file system on the newer sanyo
phones - I would like to do some work on the phone development but I am
having some trouble working blind.
Joe Pham
2007-12-08 22:04:07 UTC
Permalink
Post by Nathan Hjelm
The promised patch is attached.
Committed.

-Joe Pham

_____________________________________________________________
Click now to shop a huge selection of name brand women's boots!
http://thirdpartyoffers.netzero.net/TGL2211/fc/Ioyw6ijlHzdqAqkkchkjyDs5WYZsLbrGfjIkGK5jNYEvngZiCZPZmU/
Ken Schnell
2007-12-08 22:25:38 UTC
Permalink
What kind of tool is used to view the file system on the newer sanyo
phones - I would like to do some work on the phone development but I am
having some trouble working blind.

-----Original Message-----
From: bitpim-devel-***@lists.sourceforge.net
[mailto:bitpim-devel-***@lists.sourceforge.net]On Behalf Of
***@cox.net
Sent: Saturday, December 08, 2007 5:42 AM
To: bitpim-***@lists.sourceforge.net
Subject: Re: [BitPim-devel] VX5400 memo (Notes) test, version
1.0.3.20071206


Thanks Joe and Nathan. The image preview now works and the ringer index is
working correctly for the built-in ringtones. There appears to be an odd
indexing issue when retrieving either a PictureID or a RingerID (using mp3
or midi files -- not built-in), but this only occurs when either of the IDs
are changed in the phone and then retrieved into Bitpim. For contacts
having a changed PictureID or RingerID, the retrieved PictureID incorrectly
defaults to the first path in dload/image.dat and the RingerID incorrectly
defaults to the first path in dload/myringtone.dat. The new test version
did not create this problem -- I missed it when testing before. To
correctly see this problem:

1. I delete all of the phonebook entries from Bitpim (Edit/Select All,
Edit/Delete).
2. Then I change either a PictureID or a RingerID for a contact on the
phone itself.
3. Then I retrieve the phonebook from the phone (using Replace All).
4. Then I check the PictureID or RingerID (whichever I changed, or both)
for the contact, and it (or they) are wrong.
5. If I change the PictureID or RingerID in Bitpim, upload it, then
retrieve it again (using steps 1 - 3) from the phone, the ID data is
correct.

I'm still working on a better definition of the problem (so don't hold me to
this one -- I may be doing something wrong), and I'll repost when I think I
have a better handle on it (I'm going to examine the pbentry.dat,
pbRingIdSetAsPath.dat, and pbPictureIdSetAsPath.dat files for pre-download
and post-upload differences). It may be related to this same problem for
the VX8550:

http://sourceforge.net/mailarchive/forum.php?thread_name=473698C5.8040105%40
gmail.com&forum_name=bitpim-user

And I think another issue that might be a problem is when a contact entry is
erased on the phone and the phonebook is then retrieved into Bitpim. The
data for the now empty contact is filled with garbage. I'm still examining
this issue as well. I'm guessing that it may appear on other phones using
the same or similar pim/pbentry.dat layout.

The VX5400 works fine with a straight USB cable. The phone is identified
correctly using the phone info button, and the detect phone selection finds
the phone OK. Playlist and To Do are not supported, but that's not a big
deal. The only other thing that I noticed about the phone is that mp3s
should be saved with (at minimum) the 44.1khz and 48kbs settings (using
mono). The phone has some type of automatic volume control that will
distort lower quality mp3s.

Thanks again for all of the effort and results.

Ron
Post by Joe Pham
Post by r***@cox.net
If I manipulate the memo.dat file and make the first dword for each
note segment unique (no particular order, and any of the 4 bytes of
the dword), the notes appear on the phone with the correct text and
date/time.
Thanks for the feedback and the insight. We should be able to do something
'bout it. Any other feedback on the other functions of the VX5400?
Post by Joe Pham
-Joe Pham
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Stephen Wood
2007-12-09 00:32:25 UTC
Permalink
The developers are unaware of any tool to view the filesystem on newer
Sanyo phones. That is not to say that such a tool doesn't exist, but
we havn't heard about it if it does.

Stephen
Post by Ken Schnell
What kind of tool is used to view the file system on the newer sanyo
phones - I would like to do some work on the phone development but I am
having some trouble working blind.
Loading...