Problem with CGPS and TCP socket (WIP)

[Dismutel]

Hello,

I’m trying to make an application that gets GPS position and sends it through an GPRS socket (created with WIP commands). So I created a proyect whit GPS and WIP plugins based on QueryApp sample. As far as I know, both of them use UART1 for sending data, so (correct me If I am wrong) I have to subscribe and unsubscribe every time I want to use one or another . When the GPS starts (AT+NMEA=1, AT+CGPS=2), it subscribes the UART1. So I get the NMEA frames without problems. I’ve made 4 new at commands in order to “free” the serial port. Here are them:

[i]static void C1CmdHandler (adl_atCmdPreParser_t *para)
{
s8 retVal;
int aux=0;
ascii RspStr [ 50 ];
retVal = adl_fcmSwitchV24State(DataTRACE_fcmHandle, ADL_FCM_V24_STATE_DATA);
aux = DataTRACE_fcmHandle;
if (retVal == OK) {
wm_sprintf ( RspStr, “Successful switch to DATA mode. Handle: %d”,aux);
adl_atSendResponsePort ( ADL_AT_INT, para->Port, RspStr );
adl_atSendStdResponsePort ( ADL_AT_RSP, para->Port, ADL_STR_OK );
} else {
wm_sprintf ( RspStr, "ERROR switching to DATA: %d. Handle: %d ",retVal,aux);
adl_atSendResponsePort ( ADL_AT_INT, para->Port, RspStr );
adl_atSendStdResponsePort ( ADL_AT_RSP, para->Port, ADL_STR_CME_ERROR );
}
}

static void C2CmdHandler (adl_atCmdPreParser_t *para)
{
s8 retVal;
ascii RspStr [ 50 ];
int aux=0;
retVal = adl_fcmSwitchV24State(DataTRACE_fcmHandle, ADL_FCM_V24_STATE_AT);
aux = DataTRACE_fcmHandle;
if (retVal == OK) {
wm_sprintf ( RspStr, “Successful switch to AT mode. Handle: %d”,aux);
adl_atSendResponsePort ( ADL_AT_INT, para->Port, RspStr );
adl_atSendStdResponsePort ( ADL_AT_RSP, para->Port, ADL_STR_OK );
} else {
wm_sprintf ( RspStr, "ERROR switching to AT: %d. Handle: %d ",retVal,aux);
adl_atSendResponsePort ( ADL_AT_INT, para->Port, RspStr );
adl_atSendStdResponsePort ( ADL_AT_RSP, para->Port, ADL_STR_CME_ERROR );
}
}

static void C3CmdHandler (adl_atCmdPreParser_t *para)
{
s8 retVal;
ascii RspStr [ 50 ];
int aux=0;
retVal = adl_fcmUnsubscribe(DataTRACE_fcmHandle);
aux = DataTRACE_fcmHandle;
if (retVal == OK) {
wm_sprintf ( RspStr, “Successful unsubscribed UART. Handle: %d”,aux);
adl_atSendResponsePort ( ADL_AT_INT, para->Port, RspStr );
adl_atSendStdResponsePort ( ADL_AT_RSP, para->Port, ADL_STR_OK );
} else {
wm_sprintf ( RspStr, "ERROR unsubscribing UART: %d. Handle: %d ",retVal,aux);
adl_atSendResponsePort ( ADL_AT_INT, para->Port, RspStr );
adl_atSendStdResponsePort ( ADL_AT_RSP, para->Port, ADL_STR_CME_ERROR );
}
}

static void C4CmdHandler (adl_atCmdPreParser_t *para)
{
NMEADebugSetting = 0;
AppStarted=FALSE;
UART_GPS = ADL_PORT_NONE;
}
[/i]

DataTRACE_fcmHandle is the handle I get when GPS subscribes to UART1. I think the fourth function is not necessary but it’s a desperate try. So when I want to open the socket I do as follows:

AT+C2
OK
Successful switch to AT mode. Handle: 0
OK
//this is because in data mode i can’t unsubscribe it
AT+C3
OK
Successful unsubscribed UART. Handle:0
OK
AT+C4

So, teorically, the UART is free and unsubscribed for wip commands to subscribe them. Then I try to create a socket:

AT+CGDCONT=1,“IP”,“something”
OK
AT+CGATT=1
OK
AT+WIPCFG=1
OK
AT+WIPBR=1,6
OK
AT+WIPBR=2,6,11,“something”
OK
AT+WIPBR=2,6,0,“something”
OK
AT+WIPBR=2,6,1,“something”
OK
AT+WIPBR=4,6,0
OK
AT+WIPCREATE=2,1,“someIP”,5678
+WIPREADY: 2,1
Until here everything OK, but then

AT+WIPDATA=2,1,1
+CME ERROR: 846

Wich is described as:
internal error: FCM subscribtion failure

Am I missing something?? Am I in the right way?? What happens??

Excuse me if it’s a silly question but I’m new in OpenAT and I’m really lost.

I hope I’ve explained well enough my problem, I’m not english.

Thank you very much in advance

[awneil]

@Dismutel

I’m trying to make an application that gets GPS position

Where does it get its GPS position from?

and sends it through an GPRS socket (created with WIP commands).

The WIP AT commands are for use by an external application; if you’'re writing an Open-AT application (ie, internal to the modem), then you need to use the WIP API…

[Dismutel]

Where does it get its GPS position from?

I’m working whith Fastrack Supreme 10 with IESM IO-USB-GPS extension

The WIP AT commands are for use by an external application; if you’'re writing an Open-AT application (ie, internal to the modem), then you need to use the WIP API…

I’ve included the WIP plugin in the proyect and I call the

wip_ATCmdSubscribe();

function to subscribe to AT+WIP commands. I have no problem with WIP commands because if I don’t call AT+NMEA=1 & AT+CGPS=2 commands, I can call AT+WIPDATA=2,1,1 without problems connecting and switching to data mode inmediatly, with typical CONNECT answer.

Thank you for your help.

[awneil]

@Dismutel

I’m working whith Fastrack Supreme 10 with IESM IO-USB-GPS extension

In that case, the GPS is on UART2

I’ve included the WIP plugin in the proyect

Good.

and I call the

wip_ATCmdSubscribe();

function to subscribe to AT+WIP commands.

Wrong!

As I said, the WIP AT commands are for use by an external application - not for use by your own internal Open-AT application.

For your Open-AT application, you must use the WIP API calls, which are of the form wip_xxxxx(…) - for details, see the “Open AT IP Connectivity Development Guide (WIPlib Vx.yy)”

BTW: Note that it’s “project” - not “proyect”

[Dismutel]

I’ve think I’ve explained bad,

Wrong!

As I said, the WIP AT commands are for use by an external application - not for use by your own internal Open-AT application.

For your Open-AT application, you must use the WIP API calls, which are of the form wip_xxxxx(…) - for details, see the “Open AT IP Connectivity Development Guide (WIPlib Vx.yy)”

I want to create the socket from an external application (like hyperterminal) through the DB9 port, with AT commands.

In that case, the GPS is on UART2

The GPS module communicates whith Wireless COM through UART 2 but shows NMEA frames through UART1 (if you type NMEA=1)

Thank you for your help

[awneil]

@Dismutel

I want to create the socket from an external application (like hyperterminal) through the DB9 port, with AT commands.

In that case, your Open-AT application has to create the custom commands, and your Open-AT application must use the WIP API in order to implement the functions.

You can see examples of this in the samples.

The GPS module communicates whith Wireless COM through UART 2

Yes, the physical connection is fixed on UART2 - cannot be changed.

but shows NMEA frames through UART1 (if you type NMEA=1)

The Open-AT application does that - and you can change it, if required…

[Dismutel]

In that case, your Open-AT application has to create the custom commands, and your Open-AT application must use the WIP API in order to implement the functions.

You can see examples of this in the samples.

Yeah, I know that’s another option, but I’d like to avoid writing my own client socket code. I’d like to know what’s wrong with the option I’ve implemented.

Thank you very much.

[awneil]

@Dismutel

I’d like to know what’s wrong with the option I’ve implemented.

You can’t have access to the WIPsoft AT commands while you’ve got your own Open-AT application running in the modem.

That’s because WIPsoft is an Open-AT application - and you can only have one Open-AT application in the modem at any one time.

[davidc]

Hiya,

@awneil

You can’t have access to the WIPsoft AT commands while you’ve got your own Open-AT application running in the modem

Not quite true.

You can provide console/serial port/uart access to the AT+WIPxxx commands from within your own program if you link the WIP library and call the wip_ATCmdSubscribe() function from within your own application. BTW, wip_ATCmdSubscribe() is described in the WIPAT Commands Guide, not the WIP OpenAt Connectivity guide…

However, you CANNOT use wip_ATCmdSubscribe() to link the the AT+WIPxxx cocmmands, and then use adl_cmdCreate() family of functions to access the WIP functionality from within your own program. For this you have to use the wip_xxx() API library functions.

ciao, Dave

[awneil]

Ah - I see (I think)…

[Dismutel]

You can provide console/serial port/uart access to the AT+WIPxxx commands from within your own program if you link the WIP library and call the wip_ATCmdSubscribe() function from within your own application. BTW, wip_ATCmdSubscribe() is described in the WIPAT Commands Guide, not the WIP OpenAt Connectivity guide…

However, you CANNOT use wip_ATCmdSubscribe() to link the the AT+WIPxxx cocmmands, and then use adl_cmdCreate() family of functions to access the WIP functionality from within your own program. For this you have to use the wip_xxx() API library functions.

That’s exactly what I do, I explain it in my first post, please read it to understand my problem. I don’t call any adl_cmdCreate() family functions. I don’t understand why I have an FCM subscribtion failure when the wip_xxx API functions try to set the UART in data mode, if I’ve succesfully called the adl_fcmUnsubscribe passing the UART handle.

Anyone knows?

Thank you very much for your help

[charlvz]

I dont know if this has been resolved yet but here it goes.

Here is my interpretasion:
The UART1 port is subscribed for FCM by the GPS function. When you switch the port back from Data to AT mode you don’t actually Unsubscribe to FCM on the UART1. Use the adl_fcmUnsubscribe Function to unsubscribe from FCM before the AT+WIPDATA=2,1,1 command tries to Resubscribe to it.

Hope this helps.

[awneil]

@charlvz

The UART1 port is subscribed for FCM by the GPS function.

Note that the more recent GPS stuff uses the “raw” UART access - rather than FCM.

But, if the WIP commands are trying to subscribe the UART, the effect could still be the same…