Problem with adl_atCmdSubscribe


#1

Hello, I am a beginner in Wavecom but this Forum has cleared out most of my doubts. I have a simple problem but I don’t know how to get rid of it. When I subscribe to atd command like this:
adl_atCmdSubscribe(“atd”, UserHandler, 0x1000); and then I send, for instance, an:
atdip/port
It starts to stablish a connection, but the problem is that before answering CONNECT, the module always sends a NO CARRIER answer, So How can I avoid this?.

Regards,
Camilo


#2

Hi Camilo,
Are you trying to establish a GPRS data call or a normal voice call?

If you are giving ATD /, this will not create a GPRS call to the specified IP and the port number. The ATD command is used to establish a GSM data/voice call to the specified number. For instance, if you give ATD; it will be a voice call and ATD will be a data call (note the absence of semi colon here).

To be able to establish a GPRS data call, you first need to define a PDP conetxt and then activate that PDP context. You can activate the PDP context using ATD99**1# command (where the PDP context 1 is activated).

Also, note that when you subscribe to a particular command, it means that you want to provide your own functionality to your command. Here you are subscribing to ATD command. Hence, it means that whenever ATD command is given, your “UserHandler” function will be called.
The third parameter of adl_atCmdSubscribe () API defines which type of command should lead to the execution of the callback function “UserHandler”.

Please refer to ADL user guide for more information on how to use this API.

Best Regards,
Open AT Fan.


#3

Thank you very much for your help.

Well, in fact I am using atdip/port and make a callback to the UserHandler where I extract the ip address and the port and establish a Client session opening the UART1 flow to send data. All of this keeping in mind that I have started a Gprs session. But my real doubt is that I am not sure if I can subscribe to atd command, as I said, without receiving also answers from the module, because when I execute the program and give atd/ it sends before saying CONNECT wich is an answer I gave inmediatly after ed_SocketTCPStart() when it flags ED_INFO_WAITING_FOR_DATA, the following:

atd200.119.14.122/5002

+WIND: 5,1

NO CARRIER //this is sent by the module

+WIND: 6,1

CONNECT

and I just want it to answer what I said “CONNECT”. Do you have any idea?, I would really aprecciate it?

regards,
Camilo


#4

Hi Camilo,
I too have encountered similar scenario in which I was not able to block the ATD command from reaching the core AT software when I subscribed to it. It seems to be a limitation of Open-AT (though I don’t know the real motive of Wavecom behind this functionality).

If you want to stop this kind of behaviour, you can subscribe to call services too in addition to normal subscription to ATD command. Now, whenever ATD is given, you will receive ADL_CALL_EVENT_SETUP_FROM_EXT. From this event, you hang up the call. This will help you preventin the ATD command from reaching the core AT firmware.
As you have also subscribed to ATD command, your command handler will be triggered now, and you can do whatever you want to do from the command handler function.

Best Regards,
Open AT Fan.


#5

Hello again, thanks for your advice, it was very helpful and I did what you said: Subscribe to call service and when it flags with ADL_CALL_EVENT_SETUP_FROM_EXT, I hang up the call and then I return with ADL_CALL_NO_FORWARD and that works in order to not to receive the NO CARRIER answer, but the problem is that now I receive this:

+CME ERROR: 600 and I tried with :

adl_atUnSoSubscribe("+CME ERROR: 600",NC_Handler)

and return FALSE in order to get rid of that answer but it seems that does not subscribe. Do you have any idea why?

Regards,
Camilo.


#6

Hi Camilo,
The +CME ERROR: 600 is returned as you are returning ADL_CALL_NO_FORWARD from the call handler. This is how it is implemented in Open-AT. The ADL user interface guide too explains that if you return ADL_CALL_NO_FORWARD, then a +CME ERROR: 600 will be returned.

To solve this, change the ADL_CALL_NO_FORWARD to ADL_CALL_FORWARD.

Hope this solves the problem.

Best Regards,
Open AT Fan.


#7

Hello again:

Well it’s being very difficult to me to get rid of those answers, I did what you said but it has not been effective at all, and it shows a very strange behaviour I can’t stand yet. :angry:
when I subscribed to call service I return with ADL_CALL_FORWARD and seems well in remote mode, but when I open the application in target mode, I have a NO CARRIER answer.
if I return with ADL_CALL_NO_FORWARD I have the same +CME ERROR: 600 in both execution modes. Is there another way?.

Oh and I have another question to be solved When I am trying to send data over the air with ed_SendDataExt(), I have noticed it only sends 333 bytes, is it OK? or is there a possibility to achieve a bigger size to be sent to the server?