Re: [Bitpim-devel] Audiovox CDM8900

[Stephen W. <sa...@us...>]

On Sun, 2004-05-02 at 04:15, Roger Binns wrote:
> For those who are curious (eg Stephen :-) the phone has 300 slots
> available for phonebook entries.  There is one request to get a listing
> of which slots are in use (with a byte per slot, a non-zero value in
> the byte).  It also has yet another silly way of encoding strings
> for the phone numbers (other strings use a different mechanism).
> There is a count byte, followed by a fix sized buffer.  The count
> says how many of the bytes make up the string.
The Sanyo strings are fixed length fields and most have a length byte. 
I ignore the length on reading, because the strings are always null
padded if less than the field length.  (Of course on writes, the length
has to be computed.)  Sometimes the length byte is not adjacent to the
string, but after a whole bunch of other things, like it was added as an
afterthought.


>   It also uses a
> scheme where if a response is 123 bytes, you have to send a 123 byte
> request (ie requests must be the same size as the expected response).
The Sanyo is like this.  Packets are 505 bytes, not including checksum
and framing byte.  For the newer phones, the packet size went to over
1000, although, in most cases the extra 500 bytes are never used.  But
for these newer phones, the packet sent to the phone does not need to
match in size any more.

> It also has no error codes. 
Sanyo has an error code if you send it a packet that doesn't have the
right size or is otherwise bad.  It sends back a small packet with Y (I
think) as the first character and a fragment of the packet sent to it.

>  If you ask for a slot that has nothing
> in it, you get almost random data back.  
For Sanyos, if the slot has been previously used, you get the old data,
otherwise zeros.  So if you delete entries on the phone, you could
potentially recover them.  (Or someone else could!)

> The same is true of 
> padding in the strings.  (If it was actually using the buffer
> I sent, I would have expected nulls).
Fortunately, my strings are null padded.

> It still boggles my mind
> how badly written the embedded software is in these phones.
At least all these phones share the same HDLC framing.

I may have a Samsung phone to play with soon.  We'll see how it's
weirdness compares to what we know so far.

			Stephen

> 
> Roger
>