Re: [Bitpim-devel] Audiovox CDM8900

[Roger B. <ro...@ro...>]

Stephen Wood wrote:
> 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
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel