GPRS always + GSM calls when needed

[operapg]

I didn’t know if I should post this here or in the FCM section, so here it goes:

First of all, this is how my application should behave:

• GPRS connection should always be active (I do it using WIP GPRS bearer).
• One socket is connected to UART 1 when it is active.
• GSM data calls should always be accepted. When a data call is active, it has to be connected to UART 1 (automatically answered with ats0>=2).

So far it is easy, but here comes the problem:

• The data coming from the GSM call has to be monitored for certain purposes.

This means that I need to subscribe to GSM flow with adl_fcmSubscribe. Obviously, I can’t subscribe to GSM flow while WIP is using GPRS flow.

How I do it:

1. Subscribe to GSM call events with adl_callSubscribe.
2. Establish GPRS connection with WIP.
3. Open sockets, etc…

When I get ADL_CALL_EVENT_RING_DATA:

4. Close sockets.
5. Disconnect with wip_bearerStop (I get WIP_BERR_OK_INPROGRESS).
6. After 1 second, and without waiting for WIP_BEV_STOPPED event, subscribe to GSM flow with adl_fcmSubscribe (this is why ats0 is set to >=2, so that I can subscribe the flow before the call is answered).

I have been unable to think of a better way to do it. Anyway, this works, but only the first time.

The second (and subsequent) times, adl_fcmSubscribe returns ADL_FCM_RET_ERROR_GSM_GPRS_ALREADY_OPENNED. And in fact, it is correct, as WIP library never gets past WIP_BERR_OK_INPROGRESS, so I guess it gets stuck somewhere in there and doesn’t release GPRS flow.

Anyone has experienced something similar, or is it just me?

By the way, I initialize the WIP library in my adl_main function with wip_netInit and never terminate it. I’ve tried terminating it too with same results.

[awneil]

@operapg

6. After 1 second, and without waiting for WIP_BEV_STOPPED event, subscribe to GSM flow with adl_fcmSubscribe

Why do you not wait for WIP_BEV_STOPPED ?

As far as I can tell, this is the event that tells you that WIP has finished with its FCM subscription - so you need to wait for it!

These are the Traces I get immediately after a wip_bearerStop call:

158.164	Trace	CUS4	25	FCM Unsubs 1 : 0
158.164	Trace	CUS4	30	[ADL port] IsAvailable(80) : 1
159.105	Trace	CUS4	21	Get Mem 0106F8F4
159.105	Trace	CUS4	21	Get Mem 0106F400
159.105	Trace	CUS4	27	Call unsubs 0023AC05 : 0
159.105	Trace	CUS4	3	Bearer Event 4: WIP_BEV_STOPPED.

(this is why ats0 is set to >=2, so that I can subscribe the flow before the call is answered).

Wouldn’t it be better to use ATS0=0 (ie, no auto-answer), and have your Open-AT application handle the call?
That way, your application would be in complete control, and not in a “race” to beat the auto-answer…

I guess it gets stuck somewhere in there and doesn’t release GPRS flow.

See above - I think that’s why you need to wait for WIP_BEV_STOPPED ?

[operapg]

Hi awneil, and thanks for answering!

@awneil

Why do you not wait for WIP_BEV_STOPPED ?

As far as I can tell, this is the event that tells you that WIP has finished with its FCM subscription - so you need to wait for it!

Sorry, I didn’t explain it all. I do it that way because it takes 9 rings for WIP_BEV_STOPPED to arrive when there is an incoming call, and some operators end the call before that.

@awneil

Wouldn’t it be better to use ATS0=0 (ie, no auto-answer), and have your Open-AT application handle the call?
That way, your application would be in complete control, and not in a “race” to beat the auto-answer…

I know, but for legacy reasons it is done like that. It was done like that when I took the project from someone else, and clients don’t like to see stuff changed in GSM related things. They think that this way it will always work, even if I have a bug in my app.

@awneil

See above - I think that’s why you need to wait for WIP_BEV_STOPPED ?

Actually, I tried some stuff that I didn’t include in my post (it already was quite long).

One of them was manually establishing and terminating the connection with custom commands. This way, I could do a wip_bearerStop and wait for WIP_BEV_STOPPED whenever I wanted.

I could connect and disconnect at my wish. This worked all the time:

1. Connect.
2. Open sockets, etc.
3. Disconnect and wait for WIP_BEV_STOPPED.
4. Go back to 1.

This didn’t work:

1. Connect.
2. Open sockets, etc.
3. Disconnect and wait for WIP_BEV_STOPPED.
4. Receive a call (made by me with another modem), answer it, hang up (from the other modem).
5. Go back to 1 → get stuck in WIP_BERR_OK_INPROGRESS, no WIP_BEV_STOPPED event.

[awneil]

@operapg

I do it that way because it takes 9 rings for WIP_BEV_STOPPED to arrive when there is an incoming call, and some operators end the call before that.

Hmmm… I think if that’s how long it takes for the event to arrive, then that is how long you have to wait!

If you’re messing with the stuff that WIP wants before it tells you it’s finished with it, I think that’s asking fo trouble…

clients don’t like to see stuff changed in GSM related things

Yes, but the system must surely be able to cope with a call not getting answered, and re-try it?

[operapg]

@awneil

Hmmm… I think if that’s how long it takes for the event to arrive, then that is how long you have to wait!

When there is no incoming data call the event comes almost immediately, at least in my case.

@awneil

If you’re messing with the stuff that WIP wants before it tells you it’s finished with it, I think that’s asking fo trouble…

You are absolutely right, but I have been unable to find another way.

I’ve asked for a decent solution to this issue for over a year now (to our provider here in Spain, not directly to wavecom), as I had similar problems with edLib too.

I guess we are not important enough, but it seems like such an obvious need to me. Letting the wavecom do it’s stuff and send GSM data to UART 1 on it’s own works great, I should be able to do it too.

@awneil

Yes, but the system must surely be able to cope with a call not getting answered, and re-try it?

Sure, and it does, but I meant that they don’t want to get rid of the ats0 because, for them, that “always works”.

[tobias]

1. When you open your GSM data flow, do you first check with adl_fcmIsAvailable that the flow is available for subscription?

2. After your GSM data call is finished, do you make sure you receive the ADL_FCM_EVENT_FLOW_CLOSED if it’s the calling side that hangs up, or manually close the flow if you are the one who hang up?

You might also want to check afterwards that GSM and GPRS flows are available with the above command, before start up GPRS again.

[operapg]

Hi tobias.

@tobias

1. When you open your GSM data flow, do you first check with adl_fcmIsAvailable that the flow is available for subscription?

Yes, I do, but it’s quite unnecessary because it always returns TRUE, even when adl_fcmSusbscribe returns ADL_FCM_RET_ERROR_GSM_GPRS_ALREADY_OPENNED.

@tobias

2. After your GSM data call is finished, do you make sure you receive the ADL_FCM_EVENT_FLOW_CLOSED if it’s the calling side that hangs up, or manually close the flow if you are the one who hang up?

Yes, I always receive ADL_FCM_EVENT_FLOW_CLOSED.

@tobias

You might also want to check afterwards that GSM and GPRS flows are available with the above command, before start up GPRS again.

For the sake of curiosity, I’ve put some adl_fcmIsAvailable calls around. It always returns TRUE. For example, both GSM and GPRS flows are available in WIP_BEV_IP_CONNECTED event!

[awneil]

@tobias

2. After your GSM data call is finished, do you make sure you receive the ADL_FCM_EVENT_FLOW_CLOSED if it’s the calling side that hangs up…

@operapg

Hi tobias.Yes, I always receive ADL_FCM_EVENT_FLOW_CLOSED.

Note that there are certain situations where you might not get the ADL_FCM_EVENT_FLOW_CLOSED;
see: wavecom.com/modules/movie/sc … low_closed

[awneil]

In my application, the unit is normally idle and can accept an incoming Data Call (CSD), or establish a GPRS session as required.

If a GPRS session is started after a data call has been handled (and correctly closed with ADL_FCM_EVENT_FLOW_CLOSED etc), I find that I never get the WIP_BEV_STOPPED when trying to close the GPRS session.

In other words, this is not just a problem when a data call “interrupts” a GPRS session - it seems be be a fundamental problem with WIP whenever any Data call has previously used the FCM GSM Flow!!

[operapg]

@awneil

In other words, this is not just a problem when a data call “interrupts” a GPRS session - it seems be be a fundamental problem with WIP whenever any Data call has previously used the FCM GSM Flow!!

Yes, I know. That’s exactly what I meant in one of my previous posts when I said:

1. Connect.
2. Open sockets, etc.
3. Disconnect and wait for WIP_BEV_STOPPED.
4. Receive a call (made by me with another modem), answer it, hang up (from the other modem).
5. Go back to 1 → get stuck in WIP_BERR_OK_INPROGRESS, no WIP_BEV_STOPPED event.

[tobias]

What versions are affected by this?

I don’t do GSM Data calls in the products I work on now, but it’s interesting to know if it’s the 3.1x series (Q24…) or 4.1x or 4.2x (Q2686/Q2687) that is affected.

I’m currently working with SDK 3.15/FW6.57c and SDK 4.21/FW6.62 myself.

[operapg]

@tobias

What versions are affected by this?

I’m using Q24PLUS/Q2406B with Open AT v3.15.

[tobias]

I believe we have been bitten by this bug too now…

A bug report has been sent and I hope that it reaches Wavecom in time…

So far we have only seen this bug after first setting up GPRS, then disconnecting due to incoming data call, subscription and unsubscription of the GSM data flow, then set up GPRS again.

Our testing has been with Q2686/6.63/4.22a.

If anyone knows of a solution, or if Wavecom has responded to this issue, please post.

[tobias]

I have received word that this issue is gonna be fixed in 6.63d and that there currently is no workaround, as the flow closed event is not generated.

I don’t know when that is supposed to be released though.

[joeyyang]

Hi, Everyone,
I also meet this question when I use GPRS setting:

wip_bearerOpen(&myBearer, “GPRS”, myHandler, NULL) return ok.
wip_bearerSetOpts(myBearer,
WIP_BOPT_GPRS_APN, “emome”,
WIP_BOPT_LOGIN, “”,
WIP_BOPT_PASSWORD, “”,
WIP_BOPT_END);

I can receive “WIP_BERR_OK_INPROGRESS” info, but I can’t receive “WIP_BEV_IP_CONNECTED” message.
And I often meet this situation when I install machine in the car.
When I drove on the freeway and speed is approximately 80-100 KM, this situation happen “Everytime”,
But when I test in office (in one place, don’t move), this situation don’t happen.
I confused about this situation so I search the forum.
Now I think maybe this situation is a bug.

Because I don’t know how to solve this question, I share my test experience to everyone.
I hope wavecom can solve this question quickly.

[tobias]

6.63d solves the problems we had with CSD and GPRS.
It was released together with SDK 4.26.