Re: stable connection of nokia 3220 via CA42 cable is possible

gnokii-users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stable connection of nokia 3220 via CA42 cable is possible

From:	Burkhard Soehne
Subject:	Re: stable connection of nokia 3220 via CA42 cable is possible
Date:	Sat, 27 Oct 2007 01:04:02 +0200
User-agent:	KMail/1.8

Hi,

Thank you very much for your kind and quick answer and for your interest.
Unfortunately for me it will always take a time to answer.

Am Freitag, 26. Oktober 2007 19:35 schrieb Pawel Kot:
> On 10/26/07, Burkhard Soehne <address@hidden> wrote:
> > With the appended patch of "common/links/fbus.c" to the last released
> > version 0.6.19 of gnokii I want to show that it is possible to establish
> > a stable connection of a nokia3220 via CA42 cable.
>
> Thanks for the work. Just a small note:
> -             res = device_read(buffer, 255, state);
> +             res = device_read(buffer, 255, state) == 255;
> The original problem here was that (still in AT mode) with certain
> DKU-5 cable (and probably certain kernel driver) the reply was going
> really slowly in parts. And I needed to wait for the whole answer
> before sending the next frame. The proper solution is is parse the
> answer here (if it is OK).
First it looked like garbage to me. But perhaps you can see something. Here is 
a sample:
   from PC:
   41 54 0d 0a                                     | AT              
   answer from mobile:
   55 55 55 55 55 55 55 55 1e ff 00 15 00 08 00 3a | UUUUUUUU       :
   00 c0 00 04 01 c0 1f dc 00 55 55 55 55 55 55 55 |          UUUUUUU
   55 1e ff 00 d0 00 03 01 01 e0 00 ff 2d 55 55 55 | U           -UUU
   55 55 55 55 55 1e ff 00 15 00 08 00 3a 00 c0 01 | UUUUU       :   
   04 01 c1 1e dd                                  |                 
   next from PC:
   41 54 26 46 0d 0a                               | AT&F            
   41 54 2a 4e 4f 4b 49 41 46 42 55 53 0d 0a       | AT*NOKIAFBUS    
   ...

Without this fix, on ubuntu you have to break the very first gnokii command 
with Ctrl-C. The next gnokii command will be successfull.
With this fix the first gnokii command will be successfull.

> > This patch IS NOT a proper solution, it is actually a workaround. It
> > should give a motivation of starting a discussion how to fix the
> > problems.
> > Mainly I have changed the handling of the sequence-id.
> > For my nokia3220 the sequence-id should not start at zero for every
> > gnokii command. It should set to zero only after booting the mobile.
> > The next expected sequence-id will be written and read in "/tmp/seq.dat".
>
> Perhaps static value is enough?
You have to count from one gnokii command to the next one (each starting from 
shell). In between there is not gnokii running to store any variable.
For that reason a file or a deamon running all the time is needed.

> > Without this patch the connection to my nokia3220 will break mostly after
> > the second gnokii command.
>
> The second one during one gnokii connection?
No! The first gnokii command was "gnokii --getdatetime". You get a date and a 
time. The second command is again "gnokii --getdatetime" just to test the 
connection. Here you get twice the "seq: 8x" and then a date and a time. The 
third "gnokii --getdatetime" will get:
   Couldn't open FBUS device: No error
   Error in link initialisation: 1
   Telephone interface init failed: Command failed.
   Quitting

> > The first command works fine.
> > The second command produces "Received Ack of type xx, seq: 80" and later
> > ..." seq: 81" and then works fine.
> > The third command always produces errors.
> > (The "seq: 8x" seem to identify a sequence error, which is ignored in the
> > released version.)
> >
> > It seem to be NOT a question of mobile-hardware or (clone-)cable-hardware
> > to establish a stable connection, it is only a question of software.
>
> Well, this may be true, but mabe not fully. If you'll look what's in
> buffer in send_command(), it is not entirely what should be there. The
> string is garbled.
> > There must be different firmware versions for the transmission over
> > FBUS2. My nokia7360 will work fine with the released version of gnokii,
> > but perhaps older mobiles (at least my 3220) have a different behaviour.
> > Perhaps we can add this in a reference list.
> >
> > To run my patch, please delete "/tmp/seq.dat" whenever you boot your
> > mobile. Please boot the mobile before the first start of gnokii. After
> > this you can run gnokii commands for many times.
> >
> > This synchronization is exactly the problem for a proper bugfix. How can
> > gnokii find out which sequence id the mobile expects?
> >
> > 1. Is there a way to check the sequence id?
> > 2. Is there a way to reset the sequence id?
> > 3. Should gnokii always send exactly 8 requests (or a multiple of 8),
> > because the sequence id always counts between 0 and 7?
>
> These are very valid questions. And I cannot give the answers at the
> moment.
I will wait...

> > 4. Do we need a deamon, which holds the connection all the time?
>
> Well, that's long term goal. But for completly different reasons :)
>
> > 5. Are there any other suggestions?
> >
> > Sometimes I have to reset mobile and "/tmp/seq.dat". I guess this is
> > after a transmission error. Sometimes gnokii can recover itself,
> > sometimes not. This happens after 5 to 200 commands on ubuntu. Under
> > MinGW I have seen no transmission error.
> >
> > The changes in send_command() are to provide an infinite loop in the
> > beginning of the very first command.
> >
> > I look forward to the discussion.
>
> I will look in detail into your changes and will test here. Thanks for
> that.

> Could you please show some debug logs with and without patch? I'm
> testing it with Nokia 6021 and CA-42 cable. And the patch makes gnokii
> not working at all. Without patch about 80% of commands are
> successful.

Every log-file is the debugging output of "gnokii --getdatetime &>file":

with gnokii 0.6.19 release:
3220_release_0_ctrl-c   You have to break gnokii
3220_release_1
3220_release_2
3220_release_3

with my patch:
3220_patch_1
3220_patch_2
3220_patch_2_problem    Perhaps a transmission problem
3220_patch_3

Here are similar files with an other mobile which works fine with the release 
and the patch:
7360_release_1
7360_release_2
7360_release_3

7360_patch_1
7360_patch_2
7360_patch_3

Hope this will help. If you want, I can send debugging output with much more 
information: I protocolled every transmitted byte

Hardi