Socket ISSUES

I can’t really resolve the issue because i have difficulties replicating the problem locally on our work bench. I can run it for hours and days without any socket issues but once it is out on site, it just becomes a recurring issue. The issue may crop out within the first 10 mins, or after a few hours on site, which pretty much leaves me clueless.

have you tried creating reception problems? by for example using a lesser antenna, moving the testing unit to a area in the building with bad reception or even aluminum foil?

do you have a way to make sure the power-supply is stable in the field? (although i don’t really thing that would be the problem)

A more repeatable method to reduce signal strength is to use an inline attenuator in the antenna connection; eg,


uk.farnell.com/jsp/search/browse … tid=286788

true :slight_smile: (forgot about those :stuck_out_tongue:)

What they don’t give you is the kind of variable signal level - and interference - that you get in real life.

But they’re better than nothing!

I also have a coaxial relay and a couple of variable attenuators that I found on ebay - it’s well worth keeping an eye out for this kind of stuff! 8)

I already have an inline attenuator.
[attachment=0]IMG_0110.jpg[/attachment]

I really believe it’s something in the code that I’ve missed/put in, causing the problem.

When the BUSY event is triggered, I’ll get it consecutively until a part of my code closes the channel and re-creates a new TCP connection. When it attempts a new TCP connection, it will keep getting a WIP_CEV_ERROR immediately. I would not be able to create a new TCP connection until the modem is has done it’s resetting (switch power off, switch power on).

I’m really unsure beleaguered as to the source of the problem, and even harder is replicating it. I’ve got the modems pointing to the same server, same configurations, but still can’t replicate the issue. The only different variable here is the Sim Card which is used in the modems.

by sheer luck and stupidity i’ve managed to recreate partial of the problem in house. The only problem, it is not consistent and it happened only once or twice out of the 30 times I’ve tried today. I’ve got some debugging notes released from the modem.

This is what happens for a successful bearer connection -> TCP Connection

[GPRS]: open: -> DISCONNECTED
 [GPRS]: start: -> CONNECTING
Starting GPRS[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
 [GPRS]: GPRS EVENT: 27 (cid=1)
 [GPRS]: GPRS EVENT ACTIVATE OK (cid=5)
[GPRS]: GPRS: -> CONNECTED
 [WIP] new TCPCLIENT 0x180e56e8
WIP_CEV_OPEN
WIP_CEV_WRITE

Once connection is established, the modem proceeds to send GPS data through the created TCP Channel, and waits for an ACKNOWLEDGEMENT (WIP_CEV_READ event).

case WIP_CEV_READ:
retVal = wip_read (Channel, (ascii*)test, 90);
break;

PROBLEM HERE:
For some odd reasons, after a while, it didn’t receive any acknowledgement from the server. The program will firstly close the channel, and re-create a TCP connection in which then this happened

Successfully Closed
[WIP] closing TCPCLIENT 0x180e4d08
[WIP] new TCPCLIENT 0x180e5748

It basically stopped short in creating the new TCPClient (No WIP_CEV_OPEN, WIP_CEV_WRITE) event
The program checks the state of the channel and it returns

BUSY

After a minute or so, the WIP_CEV_ERROR is triggered. When the event is triggered, the program attempts to close the bearer

wip_bearerStop(Br_Id)
wip_bearerClose(Br_Id)

[WIP] closing TCPCLIENT 0x180e5748
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: close: -> CLOSED
Bearer successfully closed

The program will attempt to connect to the bearer and TCP socket after 20 seconds. This was when i could no longer connect to the bearer until the whole unit is restarted. Following is the log received

[GPRS]: open: -> DISCONNECTED
 [GPRS]: start: -> CONNECTING
Starting GPRS[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate

after 2 mins + 

[GPRS]: GPRS EVENT SETUP/ACTIVATE KO (cid=1): -> DISCONNECTED
GPRS Conn Failed (Event WIP_BEV_CONN_FAILED: triggered)

It stopped short of creating event 27 for reasons which i do not understand at all. Like i say, no uniform pattern and it happens randomly. But seemingly more so evidently on site then my work bench. I’ve tried using wip_netExit(), no luck.

I have reached a point where I am easily tempted to put AT+CFUN=1 on parts of the code.

In order, the WIP codes i’m using.

Ret_Value = wip_netInitOpts(
                                  WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART1, 
                                  WIP_NET_OPT_END);

When I get ADL_SIM_STATE_FULL_INT as the state :

Wip_bearerOpen(&Br_Id, “GPRS”, BearerHandler, NULL);
wip_bearerSetOpts(Br_Id,WIP_BOPT_GPRS_APN,APN,
                                                                WIP_BOPT_LOGIN,APNUname, WIP_BOPT_PASSWORD,APNPwd,
                                                                WIP_BOPT_END);
Wip_bearerStart(Br_Id)


Bearer Open callback function BearerHandler, that’s where we check when there is an event that is returned from BearerOpen.

case WIP_BERR_GPRS_FAILED:
case WIP_BEV_CONN_FAILED:
case WIP_BEV_IP_CONNECTED:
                Channel = wip_TCPClientCreate(IpAddr,Port,ClientEventHandler,NULL);
case WIP_BEV_IP_DISCONNECTED:
case WIP_BEV_STOPPED:

Hi -Jono-,

I have exact same problem, but it is happening every time!
After first successful connection I try to open a second Tcp connection which shows this behaviour.

My code was developed with FW6.63g and WIP 3.20.2030 where it is running as expected.
When compiled for FW7.4a and WIP 5.20.0.2040 this problems occur!
So i assume the problem lies in new WIP lib.

Hmm… this is interesting: I am also having problems where WIP seems to have been “broken” between v3 and v5
see: WIP v5.10 Bug: Multiple HTTP Requests
and follow the link to: Multiple HTTP Requests - every other one fails

I’m using HTTP, but I wonder if this might be related…?

Hi awneil!

Yes i think you are right with your assumption that WIP lib v5 is broken.
I enabled all wip traces as suggested by you:

wip_logEvents = TRUE; /* Enable all WIP Event traces */

Here are the results. 2 consecutive tries to open a Tcp channel from ground up.
wip_netInitOpts, … , wipnetExit

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c5f1c
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180c5f1c
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180c5f1c (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c5f1c (0 bytes)
...
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c5f1c (0 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c5f1c
[WIP] closing TCPCLIENT 0x180c5f1c
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=5): -> DISCONNECTED
[GPRS]: close: -> CLOSED

10min between

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT: 27 (cid=1)
[GPRS]: GPRS EVENT ACTIVATE OK (cid=5)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c6afc
[WIPEV] WIP_CEV_ERROR @ TCPCLIENT 0x180c6afc (errno = WIP_CERR_TIMEOUT/-986)
[WIP] closing TCPCLIENT 0x180c6afc
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=5): -> DISCONNECTED
[GPRS]: close: -> CLOSED

Can you give the corresponding traces from WIP v3?

Here the traces with WIP 3.20.2030:

[GPRS]: initialized.
[GSM]: initialized.
[UART1]: initialized.
[UART2]: initialized.
[]: initialized.
[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT: 27 (cid=1)
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1): FCM open
[GPRS]: FCM subscribe: 1
[GPRS]: FCM EVENT FLOW OPENNED: -> CONNECTED
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180d45d0
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180d45d0 (5840 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (16 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (2 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (79 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180d45d0
[WIP] closing TCPCLIENT 0x180d45d0
[GPRS]: stop: FCM close -> DISCONNECTING
[GPRS]: FCM unsubscribe (1)
[GPRS]: FCM EVENT FLOW CLOSED: GPRS deactivate
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=1): -> DISCONNECTED
[GPRS]: close: -> CLOSED
[]: exit.
[UART2]: exit.
[UART1]: exit.
[GSM]: exit.
[GPRS]: exit.

I post only 1 sequence as they are all the same.
You can see clearly the traces of wip_netInitOpts() & wipnetExit() which are missing in WIP v5 although its the same source !!.

A second test with WIP 5.20.0.2040 shows that it is possible to open 2 consecutive Tcp connection as long as Gprs is kept open:

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c60dc
[WIP] closing TCPCLIENT 0x180c60dc
[WIP] new TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c60dc
[WIP] closing TCPCLIENT 0x180c60dc
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=5): -> DISCONNECTED
[GPRS]: close: -> CLOSED

In WIP v5 header wip_net.h you can find this:

s8 wip_netExit( void);  /* deprecated */

Why is this function deprecated? And why is this not mentioned in doc?
There were definately some major changes in initialization/exit of the lib.

Hi all!

I found my problem! I was using a Q26 Extreme module. The problem is only related to this module!
For a real comparison of the WIP libs i now used a Q2686H with same SW as with Q26 Extreme and now everything is working as expected.

regards,
Gregor

For the benefit of others who may have similar problems, can you expand on what the actual problem is?

ie, what is it specifically about the Q26 Extreme that causes this problem? Is there a workaround?

The problem is, that subsequent Tcp connection fail with timeout.
It only occurs on Q26 Extreme modules, so I can’t be more specific (HW or FW).

It is definately not a problem of the WIP lib/application, because the same application runs on an Q2686H.

I would say that it’s more likely that it is a problem of the WIP lib/application - and it just that it happens not to manifest on the Q2686H…

But that’s just a hunch.

Information from Support:

Hi,
I have same problem. I wrote my code and results are follow bellow. I was wondering if anyone know how to resolve this problem.

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT: 27 (cid=1)
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1): FCM open
[GPRS]: FCM subscribe: 0
[GPRS]: FCM EVENT FLOW OPENNED: -> CONNECTED

HTTP Client Service test application : Init
ERRLOG http.c:118: Internet Protocol Feature not activated
cannot create http session channel

No, you don’t - you have a completely different problem!

ERRLOG http.c:118: Internet Protocol Feature not activated

That is your problem - clearly stated!

See: SMTP Internet Protocol Feature not activated - #2 by awneil

FAQ: forum.sierrawireless.com/viewtop … IKI#p17078

Hi,

I saw your answer, but this problem due to sim or device?
I should contact to distributor to Activate SIM card or GSM Q24 Module?
I changed my sim with an activated sim-card which could connect to GPRS service and use it, but the problem remains as past.