retrying to send data after a certain delay

Using Arduino Networking, Protocols, and Devices
1

Hello,

I'm trying to "detect" a connection problem.
Sometimes my arduino with the 3Gmodule stops functionning:
it stops at AT+TCPWRITE="sizeof(x)"
I'd like to know when it blocks.

    Serial.print(F("AT+TCPWRITE=")); Serial.println(sizeof(x));
    Serial.flush();
	
    while(Serial.available()==0 || Serial.read()!='>');

I've already tried to detect "ERROR" but I can't seem to make it work,
so I'm trying to get a timeout: If the AT+TCPWRITE doesn't receive the '>' and blocks,
I'll detect the fact that there's no response for a while so I'll send the command again.

I've come to this, I know it doesn't work, that's why I need your help!

unsigned long curMillis = millis();
unsigned long prevMillis = 0;
int ok = 0;
do{		
		if(curMillis - prevMillis > 6000 || ok == 1){
		        prevMillis = curMillis;
		        Serial.print(F("AT+TCPWRITE=")); Serial.println(sizeof(xr));
			Serial.flush();
			while(Serial.available()==0 || Serial.read()!='>');
			ok = 1;
		}else{
			ok = 1;
                        //retry the command
		}
		
}while(ok != 1);

Would you have some advice on how to it, and am I doing this the right way?
Thanks!

2

I looked at your other post. I'm not familiar with the transport, but I am with the protocol. It appears you are sending the request, but not reading the server response before closing your end. In a HTTP transaction, the client opens the connection and sends a request. The server responds, and closes its end when it is finished sending packets. Then you close the client end.

I do not see where your code waits for the server to respond and close its end before you close yours. Just a thought...

3

After I transmit the data,
I send the command: AT+NETCLOSE which closes the socket I opened before.
The server responds with an "OK", there everything's fine.

It's at the TCPRWITE where it blocks or doesn't receive any response

4

SeanHotRice:
After I transmit the data,
I send the command: AT+NETCLOSE which closes the socket I opened before.
The server responds with an "OK", there everything's fine.

It's at the TCPRWITE where it blocks or doesn't receive any response

I think "OK" is from your GSM provider (client), and means "I closed the connection ok", not from the server meaning "I got all that, and all was ok". What did the server send? Normally, it sends an html doc with the results of the request you sent. Isn't that what it does with your web browser?

edit: Basically what you are doing is clicking the "submit" button on the webpage, then immediately clicking the "stop" button on your browser menu before you get a response from the server.

5

The response body is empty, but not the header.
I use PUT

the server doen't even get the request when my arduino blocks,
I have a feeling it has to do with the arduino and the shield

6

SeanHotRice:
The response body is empty, but not the header.
I use PUT

I'm sorry. I must have missed something. Where did you read the server response header in that code? I see where the code sends the request. I see where you immediately close the connection, but I do not see a read.

7

I don't think I ever read the header O.o

I used this code (TCP Client)
http://www.cooking-hacks.com/index.php/documentation/tutorials/arduino-3g-gprs-gsm-gps?utm_source=banner_3g_shield&utm_medium=banner#step14

Does this read any header?
I do the same steps

8

This looks like it:

    do{
        while(Serial.available()==0);
        data[x]=Serial.read();  
        x++;                        
    }while(!(data[x-1]=='K'&&data[x-2]=='O'));

...and that does not look right. I would have used this:

    do{
        while(Serial.available() > 0) {
          data[x]=Serial.read();  
          x++;                        
        }
    }while(!(data[x-1]=='K'&&data[x-2]=='O'));
9

Well that was the "OK" I was talking about earlier. I read the response until I get the OK
But it seems that sometimes I never receive it.

10 
    Serial.print("{\"method\":\"put\",\"resource\":\"/feeds/");
    Serial.print(COSM_FEED); 
    Serial.print("\",\"params\":{},\"headers\":{\"X-PachubeApiKey\":\"");
    Serial.print(COSM_API_KEY);
    Serial.print("\"},\"body\":{\"datastreams\":[{\"id\":\"0\",\"current_value\":\"");
    Serial.print(bottleN);  
    Serial.print("\"},{\"id\":\"1\",\"current_value\":\"");
    Serial.print(waterHeight);
    Serial.print("\"},{\"id\":\"2\",\"current_value\":\"");
    Serial.print(derivative);
    Serial.println("\"}]},\"token\":\"0x12345\"}");
// The line above is the end of your request, correct?

// The server response should be read here. It does in the example you posted.

// This is where you close the connection after the "OK" in the example
    Serial.println("AT+NETCLOSE"); //Opens the socket with the type of protocol and the port 
    Serial.flush();
11

Yes that's the end of my request!

Thanks! I think I remember why I took it out, because it blocked there,
well it does now too, it doesn't seem to get the OK
But the server gets the request, and sends the response back

12

I am not familiar with the transport, so you will have to figure that part out. If this was an ethernet shield, I would use this after sending the request

while(client.connected()) {
  // stay in this loop until the server closes the connection
  while(client available()) {
    // stay in this loop until all characters are out of the rx buffer
    client.read();
  }
}
// close client end after the server closes its end
client.stop();

You must figure out how you tell when the server closes the connection. That is the signal it is finished sending. It may be an "OK" on a line by itself.

13

Okay, thanks a lot for your help! I'm actually using the 3G shield.
Î'll be looking into it!

14

I knew exactly what you were using. I'm just not familiar with the technicalities of the transport. Since it uses AT commands like the old Hayes modem (whew, that shows my age!), it finishes everything with "OK" on a line by itself. That appears to be what your example code does. It reads the serial port until it receives "OK". It does not check if it is on a line by itself. That may be a bug.