[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for better Samsung B2100 support
Re: Patch for better Samsung B2100 support
Sun, 17 Jul 2011 13:02:28 +0200
On Sat, Jul 16, 2011 at 10:35:11PM +0200, Pawel Kot wrote:
> > Some communication is attached, however it gets somehow complicated as
> > two new problems arose"
> Can you please show also some successful communication?
Successfull communication (writephonebook to non-empty memory) was
attached to previous message as writephonebook-nonempty.out.
Unfortunately I cannot get successfule getbphonebook ME dumps now as my
phone still reports errors when trying to read memory (see below).
> > 1) when using writephonebook to popullate empty phone memory,
> > gnokii fails to (attempt to) write the very first entry:
> > Initialisation completed
> > Message sent: 0x00 / 0x000d
> > 41 54 2b 43 50 42 53 3d 22 4d 45 22 0d | AT+CPBS="ME"
> > write: [AT+CPBS="ME"<cr>]
> > read : [AT+CPBS="ME"<cr><cr><lf>OK<cr><lf>]
> > Message received: 0x00 / 0x0013
> > 02 41 54 2b 43 50 42 53 3d 22 4d 45 22 0d 0d 0a | AT+CPBS="ME"
> > 4f 4b 0d | OK
> > Received message type 00
> > Message sent: 0x67 / 0x000a
> > 41 54 2b 43 50 42 52 3d 3f 0d | AT+CPBR=?
> > write: [AT+CPBR=?<cr>]
> > read : address@hidden<cr><cr><lf>+CME ERROR: 23<cr><lf>]
> > Message received: 0x67 / 0x001c
> > 05 00 17 2b 43 50 42 52 3d 3f 0d 0d 0a 2b 43 4d | +CPBR=? +CM
> > 45 20 45 52 52 4f 52 3a 20 32 33 0d | E ERROR: 23
> > Received message type 67
> > Write failed (Command failed.): memory type: ME, loc: 1, name:
> > test1, number: 1
> Well, we didn't get here to the write command. This is just checking
> memory status. Perhaps it fails with the empty memory only? I guess I
> could add some workaround for that.
> > There are two workaround for this - either creating a single contact
> > in phone memory using the phone, or adding a dummy entry as the first
> > one in phonebook.
> >From gnokii perspective I can do two things:
> - ignore the error
> - catch the error -> write a dummy entry -> read memory status ->
> delete a dummy entry
I believe the best thing to do here is to ignore the error and attemt to
write entries from the first position.
> > Is there already a driver flag not to get confused by getting no
> > reasonable response on AT+CPBS="ME"?
> No, I do not think so. That's probably the first phone that suffers
> this problem.
> > 2) getphonebook stopped working after I wiped phone memory and repopulated
> > it using
> > writephonebook. Now the phone responds with
> > \05\00\03d+CPBR=1 +CME ERROR: 100
> > when attempting to read non-empty positions.
> With any non empty? Does phone display them correctly?
Yes, with any non empty, and the entries are displayed correctly on the
phone. I believe the phone must have gone into some internal error state
as it keeps doing this even after wiping entire phonebook (either by
Contacts/Settings/Delete/All or by Settings/Memory settings/Clear phone
memory/Phonebook) and populating it from SIM. Already tried turning the
phone off and on (even with battery removal), changing USB mode to mass
storage and back, sending AT&F, but nothing helped. The phone stil
reports ERROR 100 when attempting to read any non-empty. The only things
left are resetting the phone to default settings, which is quite
invasive while there are doubts that it might help so I haven't tried it
yet, and reflashing/updating the phone firmware (in theory it should be
possible with Samsung's "New PC Studio", but I have to visit someone
with a Windows PC to accomplish this, or a Samsung's repair service if
the theory proves wrong).
Reading from SIM works, but I found another curiosity here: seems the
phone returns unencoded number when reading from SIM (while it returned
encoded ones when memory reads were working) - see attached
getphonebook-SM.out, the entry has name "0" with number 0 on the phone.
Is there any other phone witch this behavior?
> >> Quite frankly I'd prefer to have the flags:
> >> - encode_number_write
> >> - encode_number_read
> >> - encode_name_write
> >> - encode_name_read
> >> Do you mind updating the patch like that?
> > No problem, but it will probably take some days to finish as the
> > getphonebook issue seems more important now (and also separating
> > encode_number will need some more changes).
> No problem.
> >> > With this patch, both readphoonebook and writephonebook work with
> >> > Samsung B2100, although writephonebook's -o (overwrite) option seems
> >> > to have no effect, the phone probably uses some internal find-free
> >> > function
> >> Which memory type? It if was SM the fix was added just recently.
> > Memory type is ME. Observed behavior is that repeated writephonebook calls
> > with the same entry create repeated identical entries in the phone.
> I see. I wonder why did Samsung so screw up with your phone.
Actually I'm still not disappointed as the South Korean comrades did a
very good job everywhere else on the phone, after many years with Series40
models it really scores as extremely cheap replacement with many useful
feautures in both SW & HW (except for the ERROR 100 one).
NOTE FOR WINDOWS (TM) USERS: IN NO EVENT UNLESS REQUIRED BY APPLICABLE
LAW WILL I BE LIABLE TO YOU FOR ANY SW OR HW DAMAGE, SYSTEM MALFUNCTION,
DATA LOSS AND/OR DATA BREACH ARISING OUT WHILE YOU ARE READING THIS NOTE.
Description: Text document
Re: Patch for better Samsung B2100 support, Daniele Forsi, 2011/07/18