Receiving data from GPRS takes too long

He all!!, im sendig data from the CPU to a server by GPRS. The problems is that the time that requires to transmit its too long. My code is this:

Note that all the data is entered by the USB port, with the highest Baudrate aviable, and then transmited by GPRS to the server.

When i send the data from USB the traces tell me traht data is aviable to send and send it, in a few second all the file supossely es send, but it takes ages to really came to the server, and sometimes the connection falls. And somethimes wip_write return zero…

Thank you for advance, i know i can count on you!.

/* Main function*/
void adl_main ( adl_InitType_e  InitType )
{
.....
if(adl_fcmIsAvailable(ADL_PORT_USB) ==TRUE)
  {
  handle_envio_uart=adl_fcmSubscribe(ADL_PORT_USB,CtrlHandler,DataHandler);
	if(handle_envio_uart >= 0)
	TRACE((5,"[adl_main]:adl_fcmSubscribe OK"));
  }
....
}
........................................................................
........................................................................
/* DataHandler function*/
bool DataHandler (u16 datalenght,u8 *Data)
{
int i;

if(puerto_abierto==5) //this means that the "ADL_FCM_EVENT_FLOW_OPENNED" was ok and "adl_fcmSwitchV24State" too
	{
              contador+=datalenght;
              TRACE((5,"[DataHandler]:Datos enviados %d",contador));
              TRACE((5,"[DataHandler]:datalenght %d",datalenght));

if(send_more_data==FALSE)
{
	s32 Write = wip_write(canal_TCP,(ascii *)Data,datalenght-offset); //offset is a global variable inicialize in zero
		TRACE (( 4, "[Send_Data]:Resultado de write: %d",Write));

		if(Write>0)
		{
		   /*Send the data to the remote party*/
		   TRACE (( 4, "[Send_Data]:%d bytes sent to the remote Server",Write));

		   offset+=Write;
		   if(offset>=datalenght)
			{
			  TRACE (( 4, "[Send_Data]:offset==sizeof(buffer)"));
			  send_more_data=FALSE;
			  offset=0;
			}
		   else
			{
			   send_more_data=TRUE;
			}

		  u32 retSetOpts = wip_setOpts(canal_TCP,WIP_COPT_RESET_CEV_WRITE,1,WIP_COPT_END);
		   if(retSetOpts == 0)
		   {
			  TRACE (( 4, "[Send_Data]:set WIP_COPT_RESET_CEV_WRITE"));
		   }
		   adl_atSendResponsePort(ADL_AT_INT,ADL_PORT_UART1,"\r\nOK\r\n");

		}
		else {
		   switch(Write)
		   {
				 case WIP_CERR_CSTATE:
					  /* The channel is not ready to accept data */
					  TRACE (( 4, "Write Error: WIP_CERR_CSTATE"));
					  break;
				 case WIP_CERR_NOT_SUPPORTED:
					  /* This channel does not support data writing operation */
					  TRACE (( 4, "Write Error: WIP_CERR_NOT_SUPPORTED" ));
					  break;
		   }
		}

}


    }



	
return TRUE;
}

...........................................................................................
...........................................................................................

Hiya,

Don’t forget that the maximum GPRS transmission speed is around 44kbits/sec - and may be slower than this if the network is busy or you are in a bad coverage area.

Sounds like the data is being buffered internally (which is why the data is being accepted by the USB connection), and is taking some time to be processed by the GPRS stack and transferred to the server. The intermittent connection failures are probably network related.

There’s nothing that can be done about the GPRS transmission speed - you might need to break your data into smaller blocks, or wrap your own protocol around the transmission to ensure data integrity.

ciao, Dave

Thanks a lot for your reply!!, i thought that it was a GPRS connection problem, but the delays for transmitting to the server is greater that recieving from it. Believe me, i cant send a 100kbytes file because its take too long and WIP_CEB_ERRORs appears just make that the connection fails!.

Its my code wrong?, i forgot about something??. Im not using the FCM to send and recieve the data from GPRS, just plain wip funcitons…i dont know if that affects the internal buffering.

One more time, i really aprecciate your answer!.

Nicolas.

Bear in mind that, if you’re sending small chunks of data, there’s a certain time in which TCP will buffer the data to send before actually sending it.

Using UDP may be worth trying; sending retries of UDP packets can prove better than TCP in fast fading environments (the handshake of TCP succeeds but the data fails).

Check the WIP_NET_OPT_IP_TOS option in the AT+WIPCFG spec’ - may be worth choosing to “maximise reliability”.

Make sure you’re not trying to send too much at once, as the internal buffers in the WIP stack could get full.

I don’t know if there’s a “packet size” option, hence you can expedite the sending of TCP by appending “fill” data to the end of a shorter packet so it can be sent immediately (used to do that).

I think there is - but can’t remember what just now…

I haven’t seen WIP_CEV_WRITE event handler in your code. And also some weird WIP_COPT_RESET_CEV_WRITE. It does not seem very right for me. What is your actual transfer speed? While using FTP I’ve got a 160 kbytes file sent in about 1,5 minutes with something around 5% chance of reconnect.

Hi all!!, thank u so much for the replys!!. I solved but forgoted to reply for thanking all and explaying what happened.

First, i changed the module and i notice a better behaviour, but cant send lots of data. Then i realice an event wich tell me that the battery voltage was down. So i realiced that the battery was unable to handle the current consumption. Then and finally with a more powerfull battery the module worked just fine!.

So, if anyone has this problem, i strongly recommend that have your power supply checked.

Thank u a lot!!!
Best Regards.
Nicholas.

Hiya,

Thanks for letting us know how you solved the problem - it’s important when others have similar issues to know where to start looking.

Sounds like another one for the FAQ :smiley:

ciao, Dave