[Bitpim-devel] Samsung VGA-1000 schedule file

[Ben Curtis]

I'm sure this applies to many other Samsung phones, since they all appear
to be using the same basic calendar. I've been examining the schedule
file in the nvm/nvm folder of my phone, and have created a specification
for the file.

I've learned that each entry in the calendar has 47 hex numbers associated
with it, and what 45 or 46 of those 47 stand for. I've even figured out
where the time stamps are stored so I can create a calendar entry
programmatically already. However, bitpim doesn't appear to have the
ability to overwrite files on my phone. Is anyone currently working on
this functionality?


Thanks,
Ben

P.S. I sent an email like this one to the list before I was a member, so
no need to pass that through if your an admin. Thanks!

[Roger Binns]

Post by Ben Curtis
I've learned that each entry in the calendar has 47 hex numbers associated
with it, and what 45 or 46 of those 47 stand for. I've even figured out
where the time stamps are stored so I can create a calendar entry
programmatically already.

Post a description to the group. Look in the source for packetdescription.txt
which is the format it is described in. The various p_*.p files are
good examples to crib from.

Also please check to see if there is an explicit synchronization protocol
for the calendar. It is always better to use the official protocol
rather than just changing files behind the scenes.

Post by Ben Curtis
However, bitpim doesn't appear to have the
ability to overwrite files on my phone.

What happens when you try? If you get file locked exceptions then that
is the phone not wanting those to be overwritten.

I have some vague information on there being file attributes and the ability
to change them. However I won't be looking at it for a while.

Post by Ben Curtis
Is anyone currently working on this functionality?

I believe there is a phone in the mail heading towards Stephen courtesy
of RPI Wireless.

Post by Ben Curtis
P.S. I sent an email like this one to the list before I was a member, so
no need to pass that through if your an admin. Thanks!

I reject all those emails. (If I let them on, then the next one will need
to be explicitly allowed etc. Far too much work!)

Roger

[Ben Curtis]

Post by Roger Binns

Post by Ben Curtis
I've learned that each entry in the calendar has 47 hex numbers associated
with it, and what 45 or 46 of those 47 stand for. I've even figured out
where the time stamps are stored so I can create a calendar entry
programmatically already.

Post a description to the group. Look in the source for packetdescription.txt
which is the format it is described in. The various p_*.p files are
good examples to crib from.
Also please check to see if there is an explicit synchronization protocol
for the calendar. It is always better to use the official protocol
rather than just changing files behind the scenes.

Unfortunately those files are way over my head, which is why I was
wondering if it would be useful for anyone who knew what they were doing.
What I have is basically 47 numbers (b3, e9, af, etc) for each entry and
determined what each does/means. Where do I even go to find out about
synchronization protocols? (I'm fairly new to any type of mobile device
development, can you tell? :) )

Post by Roger Binns

Post by Ben Curtis
However, bitpim doesn't appear to have the
ability to overwrite files on my phone.

What happens when you try? If you get file locked exceptions then that
is the phone not wanting those to be overwritten.

I get a really long debug message, the same message that you get if you
try to do anything in bitpim other than view the filesystem (I.E. Get
Data). I can paste it (and what I found out about the schedule file) if
anyone will use it. Though if someone who actually has a clue is getting
one soon, I'm sure he'll hit the error rather quickly.


Thanks,
Ben

[Roger Binns]

Post by Ben Curtis
What I have is basically 47 numbers (b3, e9, af, etc) for each entry and
determined what each does/means.

Post here what seems most natural to you and I will translate it.

Post by Ben Curtis
Where do I even go to find out about
synchronization protocols?

Look to see if any products support the calendar, and then record them
doing so. DataPilot doesn't. I can't tell about SnapSync and I
have trouble even figuring out what Smith Micro's product supports.

Post by Ben Curtis
I get a really long debug message, the same message that you get if you
try to do anything in bitpim other than view the filesystem (I.E. Get
Data).

That isn't a debug message, it is an error exception and the details
in it actually matter!

Roger

[Ben Curtis]

OK, rather than try to post everything I figured out for the schedule file
format, I've put my "tracking" document online. It is basically all the
steps I took to find out what each place did.

http://www.nosolutions.com/bitpim/VGA1000.pdf

As for if any software modifies the calendar, I have read on many a forum
that nothing is out right now.


Thanks,
Ben

[Roger Binns]

Post by Ben Curtis
OK, rather than try to post everything I figured out for the schedule file
format, I've put my "tracking" document online. It is basically all the
steps I took to find out what each place did.

Looks good. IIRC you said that the file can't be overwritten though?
I believe Stephen does have the protocol information anyway though.

It is somewhat confusing that you use MSB in the middle of the
document and then switch to LSB at the end. (eg stating that
times increase by 0x100e each hour). All the phones have been
LSB, so you should just use LSB throughout (you have probably
figured that out by now :-)

One thing we have found is that each manufacturer seems to use
a different time for zero. It is usually a few days into
January 1980.

Decoding the date for the LG calendar was fun. It is actually a
bit field.

12 bits for year
4 bits for month
5 bits for day
5 bits for hour
6 bits for minutes

In terms of the descriptions we use in the various *.p files, yours
would look something like:

PACKET scheduleentry:
1 id "probably start marker"
4 UINT start
4 UINT end
30 STRING title
1 UNKNOWN u1
1 UINT alarm
1 UNKNOWN u2
3 UINT modifiedtime
1 id2 "probably end marker"

The first id is probably something like if the event is active.
u1 is probably the null terminator for the string. u2 is probably
part of the alarm value. id2 is probably part of modifiedtime
(3 bytes is a very unusual size for something).

Roger