Re: [Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

Re: [Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

[Radek Polak]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

On Tuesday 06 March 2012 20:17:32 Dr. H. Nikolaus Schaller wrote:

> @Radek: is it possible to manually contact the AT interface in this state
> and try if it is still operational and another AT+CLCC would succeed?

It seems after few errors it starts working again - if i understand it right 
(see log below). Btw the probability of +CME ERROR increases with smaller CLCC 
interval.

So ingoring the error and trying again is the way to go for us?

Regards

Radek

AtChat :  F : "+CLCC: 1,1,4,0,0,"+420608828973",145" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CLCC: 1,1,4,0,0,"+420608828973",145" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CLCC: 1,1,4,0,0,"+420608828973",145" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CLCC: 1,1,4,0,0,"+420608828973",145" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CME ERROR: 100" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CME ERROR: 100" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CME ERROR: 100" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "+CME ERROR: 100" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK" 
AtChat :  T : "AT+CLCC" 
AtChat :  F : "OK"

Re: [Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Hi Radek,

On 03/06/2012 03:30 PM, Radek Polak wrote:
> On Tuesday 06 March 2012 20:17:32 Dr. H. Nikolaus Schaller wrote:
> 
>> @Radek: is it possible to manually contact the AT interface in this state
>> and try if it is still operational and another AT+CLCC would succeed?
> 
> It seems after few errors it starts working again - if i understand it right 
> (see log below). Btw the probability of +CME ERROR increases with smaller CLCC 
> interval.
> 

FYI, CME ERROR: 100 means: "Unknown Error".  This firmware is rather
helpful here isn't it?

> So ingoring the error and trying again is the way to go for us?
> 

That sounds like your only avenue at this point.  If you're doing this
in oFono, then I would create an Option / GTA04 specific vendor quirk
for the voicecall driver.  When this quirk is set, ignore CME ERROR 100
errors (not any others) and retry the CLCC poll.

Regards,
-Denis

Re: Polling CLCC error handling on Option modem (GTA04)

[Radek Polak]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

On Monday 05 March 2012 20:26:29 Denis Kenzior wrote:

> You can always try ignoring CME ERROR 100 and re-try the CLCC poll.
> Maybe the modem is in a transitional period (e.g. call being released)
> and it can't answer the CLCC properly.  In other words, there's a bug
> related to timing of call state changes & CLCC implementation in the
> modem firmware.

Yes, it is definitely timing bug. Attached is patch that continues CLCC polling 
even after error assuming that CLCC will start working again. It works fine for 
me (see log below). It would be nice to get this in ofono git.

ofonod[1188]: App: < \r\n+CLCC: 1,1,4,0,0,"+420608828973",145\r\n\r\nOK\r\n
ofonod[1188]: App: > AT+CLCC\r
ofonod[1188]: App: < \r\n+CME ERROR: 100\r\n
ofonod[1188]: We are polling CLCC and received an error, retrying...
ofonod[1188]: App: > AT+CLCC\r
ofonod[1188]: App: < \r\nOK\r\n
ofonod[1188]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection 
event for id: 1, reason: 2


Regards

Radek

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: continue_clcc_after_error.patch --]
[-- Type: text/x-patch, Size: 598 bytes --]

diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
index d07052c..324ea4b 100644
--- a/drivers/atmodem/voicecall.c
+++ b/drivers/atmodem/voicecall.c
@@ -147,8 +147,9 @@ static void clcc_poll_cb(gboolean ok, GAtResult *result, gpointer user_data)
 	gboolean poll_again = FALSE;
 
 	if (!ok) {
-		ofono_error("We are polling CLCC and received an error");
-		ofono_error("All bets are off for call management");
+		ofono_error("We are polling CLCC and received an error, retrying...");
+		vd->clcc_source = g_timeout_add(POLL_CLCC_INTERVAL,
+						poll_clcc, vc);
 		return;
 	}
 

Re: [Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

[Matthias Apitz]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

El día Wednesday, March 07, 2012 a las 11:36:24AM +0100, Radek Polak escribió:

> On Monday 05 March 2012 20:26:29 Denis Kenzior wrote:
> 
> > You can always try ignoring CME ERROR 100 and re-try the CLCC poll.
> > Maybe the modem is in a transitional period (e.g. call being released)
> > and it can't answer the CLCC properly.  In other words, there's a bug
> > related to timing of call state changes & CLCC implementation in the
> > modem firmware.
> 
> Yes, it is definitely timing bug. Attached is patch that continues CLCC polling 
> even after error assuming that CLCC will start working again. It works fine for 
> me (see log below). It would be nice to get this in ofono git.
> 
> ofonod[1188]: App: < \r\n+CLCC: 1,1,4,0,0,"+420608828973",145\r\n\r\nOK\r\n
> ofonod[1188]: App: > AT+CLCC\r
> ofonod[1188]: App: < \r\n+CME ERROR: 100\r\n
> ofonod[1188]: We are polling CLCC and received an error, retrying...
> ofonod[1188]: App: > AT+CLCC\r
> ofonod[1188]: App: < \r\nOK\r\n
> ofonod[1188]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection 
> event for id: 1, reason: 2

I'm wondering if this ofonod log has no timestamps in the log lines? Or
is this something to be configured?

	matthias
-- 
Matthias Apitz
e <guru@unixarea.de> - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5

Re: [Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Matthias Apitz <guru@unixarea.de> writes:

>> ofonod[1188]: App: < \r\n+CLCC: 1,1,4,0,0,"+420608828973",145\r\n\r\nOK\r\n
>> ofonod[1188]: App: > AT+CLCC\r
>> ofonod[1188]: App: < \r\n+CME ERROR: 100\r\n
>> ofonod[1188]: We are polling CLCC and received an error, retrying...
>> ofonod[1188]: App: > AT+CLCC\r
>> ofonod[1188]: App: < \r\nOK\r\n
>> ofonod[1188]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection 
>> event for id: 1, reason: 2
>
> I'm wondering if this ofonod log has no timestamps in the log lines? Or
> is this something to be configured?

oFono does its logging by calling syslog, so maybe the absence of
timestamps is to do with how syslog is configured on Radek's phone.

      Neil

Re: [Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

Hi Matthias,

> > > You can always try ignoring CME ERROR 100 and re-try the CLCC poll.
> > > Maybe the modem is in a transitional period (e.g. call being released)
> > > and it can't answer the CLCC properly.  In other words, there's a bug
> > > related to timing of call state changes & CLCC implementation in the
> > > modem firmware.
> > 
> > Yes, it is definitely timing bug. Attached is patch that continues CLCC polling 
> > even after error assuming that CLCC will start working again. It works fine for 
> > me (see log below). It would be nice to get this in ofono git.
> > 
> > ofonod[1188]: App: < \r\n+CLCC: 1,1,4,0,0,"+420608828973",145\r\n\r\nOK\r\n
> > ofonod[1188]: App: > AT+CLCC\r
> > ofonod[1188]: App: < \r\n+CME ERROR: 100\r\n
> > ofonod[1188]: We are polling CLCC and received an error, retrying...
> > ofonod[1188]: App: > AT+CLCC\r
> > ofonod[1188]: App: < \r\nOK\r\n
> > ofonod[1188]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection 
> > event for id: 1, reason: 2
> 
> I'm wondering if this ofonod log has no timestamps in the log lines? Or
> is this something to be configured?

the output also goes to syslog and there you have timestamps.

Regards

Marcel