Re: Reviving 3110 support

[Osma Suominen]

Hi Pawel. Nice to see you interested in my 3110 work.

On Sun, 2 Feb 2003, Pawel Kot wrote:

> Yes, I implemented only PDU frames in sms support, but it should be fairly
> easy to add text support as well.
[...]
> It should be done in gsm-sms.c when you set some field in gn_sms struct.
> At least I had such intension.

Okay. Based on this piece of information, I'm not trying to
encode/decode stuff in nk3110.c, but instead wait for changes in eg.
gsm-sms.c

> Okay, I'm waiting impatiently for the patch.

I put the first public version of the patch here:
http://sange.fi/~ozone/gnokii/gnokii-0.5.0pre5-nk3110-v0.1.patch.gz

The patch is against 0.5.0pre5 and I admit it's pretty ugly. The worst
hacks can be found by grepping for FIXME. But at least the following
gnokii commands work:
--identify
--sendsms
--savesms
--getsms
--deletesms
--getsmsc

On my todo list are at least the following things:
* encode/decode SMS userdata properly
* remove hardcoded stuff e.g. SMS validity
* test and debug other functions like data calls
* do something with the remains of old keepalive code - are they needed
  at all? If not, they could be removed entirely.

I've met some strange things with the current gnokii code:

* Both SMS centre number and remote number are stored in the gn_sms_raw
  data struct as BCD strings, with one byte each for number type and
  length. But why is the length encoded differently for these? At
  present there are many places with code like this:
        data->raw_sms->remote_number[0] =
                (data->raw_sms->remote_number[0] + 1) / 2 + 1;
  Why not be consistent? I think this mess could easily be cleaned up.
  Or do the phones or SMS spec require this inconsistency?

* When saving SMS's, the location in memory can be specified. But the
  3110 doesn't allow this to be specified AFAIK. However, when it
  acknowledges a succesful send it tells which location the SMS was
  saved in. This is put by the driver into the gn_sms_raw struct. But it
  is not copied (by gsm-sms.c) back into the gn_sms struct, so e.g.
  command line gnokii reports that the SMS was stored in location 0. Is
  this a bug? I think other drivers (e.g. nk6100.c) also do the same.

* Many pieces of code use the unsigned char type for strings that are
  sent to the phone or received from the phone. Doesn't this break on
  (64-bit) architectures where char's are not 8 bits wide? I noticed
  that older versions often used u8, which might work better. Is this
  a problem?

> > PS. There's one anomaly - the phone only sends one SMS message, after
> > which sending fails with the error code 0x65 0x15. Saving etc. still
> > work. This also happens with gnokii-0.3.5. Power-cycling the phone
> > helps, but then again only one SMS can be sent. A comment in the old
> > code said that the error code was for the situation where "the phone
> > originated SMS was disabled by the network for the particular phone".
> >
> > Any clues to what this could mean? I'm using the Finnish Sonera network,
> > if that matters. Maybe there's something suspicious about the message,
> > and the network denies further messages??
>
> The debug output for this could help a bit.

Not much I guess - the only difference between a succesful send and a
failed one is that in the latter case the phone answers with error code
0x65 0x15. Otherwise the data exchanged is identical. But I'll continue
investigating this one. In fact I already succeeded sending another
message, but only between several failures. So after turning on the
phone the first send always succeeds, but subsequent ones have a high
probability of failing. Strange...

-Osma

-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***