[Top][All Lists]

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

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

From: Pawel Kot
Subject: Re: stable connection of nokia 3220 via CA42 cable is possible
Date: Fri, 26 Oct 2007 19:35:19 +0200


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).

> 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.

Thanks for that. Please keep in mind that FBUS protocol is a
proprietary protocol and all we got is guessed. So definitely there
may be some inaccuracies in the implementation.

> 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?

> Without this patch the connection to my nokia3220 will break mostly after the
> second gnokii command.

The second one during one gnokii connection?

> 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.

> 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.

take care,
Pawel Kot

reply via email to

[Prev in Thread] Current Thread [Next in Thread]