>> AT+CGATT=1 - Attach to GPRS Service
<< OK
>> AT+CGDCONT=1,"IP","wap.cingular" - Define PDP Context (cid, PDP type, APN)
<< OK
>> AT+CDNSCFG="208.67.222.222","208.67.220.220" - Configure Domain Name Server (primary DNS, secondary DNS)
<< OK
>> AT+CSTT="wap.cingular","wap(at)cingulargprs.com","cingular1" - Start Task & set APN, User ID, and password
<< OK
>> AT+CIICR - Bring up wireless connection with GPRS - THIS MAY TAKE A WHILE
<< OK
>> AT+CIFSR - Get Local IP address
<< 10.190.245.172 - returns IP address assigned to your module
<< OK
>> AT+CIPSTATUS - Get Connection Status
<< OK
<< STATE: IP STATUS - returns status of connection, needs to be 'IP STATUS' before you can connect to a server
>> AT+CIPHEAD=1 - Tells module to add an 'IP Header' to receive data
<< OK
>> AT+CDNSORIP=1 - Indicates whether connection request will be IP address (0), or domain name (1)
<< OK
>> AT+CIPSTART="TCP","www.google.com","80" - Start up TCP connection (mode, IP address/name, port)
<< OK
<< CONNECT OK - Indicates you've connected to the server - IT MAKE TAKE A WHILE FOR THIS TO BE RETURNED
>> AT+CIPSEND - Issue Send Command
<< > - wait for module to return'>' to indicate it's ready to receive data
>> GET / HTTP/1.1 - Send data - this example is an HTTP request for the default page
>> Host: [url]www.google.com[/url]
>> Connection: Keep-Alive
>> Accept: */*
>> Accept-Language: en-us
>>
<< data from server returned - Server will return data here
at+cgatt=1
OK
at+cgdcont=1,"IP","indosatgprs"
OK
at+cdnscfg="208.67.222.222","208.67.220.220"
OK
at+cstt="indosatgprs","indosat","indosat"
OK
at+ciicr
OK
at+cifsr
10.168.170.128
at+cipstatus
OK
STATE: IP STATUS
at+ciphead=1
OK
at+cdnsorip=1
OK
at+cipstart="TCP","www.google.com","80"
OK
CONNECT
CLOSED
CONNECT OK
RDY
+CFUN: 1
+CPIN: READY
Hen, "CONNECT" without the "OK" is not a valid response. I suspect you have a hardware problem, although I've never seen a module fail in that way.hen said:Code:at+cipstart="TCP","www.google.com","80" OK CONNECT
This command adds a "header" to the data returned by ythe server. You don't need to send this command, but the header makes it easier to identify the data string and it indicates the number of bytes in the data packet.phaedrus said:Some queries :
Any idea of why CIPHEAD=1 is needed ? The modem seems to work in GPRS mode even when this is not set explicitly.
This is a classic symptom of a power supply problem. When transmitting the power draw increases substantially. If your power supply cannot deliver the required current, the voltage will drop and the module will reset. The problem is more likely to occur if you are operating at 850 or 900MHz as the power output on these bands is 2W. Also, the power draw is greater in GPRS mode. I've seen designs where the power supply was marginal and the reset problem was intermittent.phaedrus said:Did any of you face the problem of modem resetting during creation of socket ? viz
Code:RDY +CFUN: 1 +CPIN: READY
It may also be that his receiving program is dropping characters,which might happen if he is using a micro controller with less data buffer etc.But since he said that with the other modem he has never faced the problem,maybe this is not the case ? Or it may be a combination of RTS/CTS hardware failure on the defective modem and insufficient buffer size ?Hen, "CONNECT" without the "OK" is not a valid response. I suspect you have a hardware problem, although I've never seen a module fail in that way.
Could you explain further on this ?Maybe a cut paste of some response data would help, which shows the header ?I was getting the same data from the modem for both the cases.This command adds a "header" to the data returned by ythe server. You don't need to send this command, but the header makes it easier to identify the data string and it indicates the number of bytes in the data packet.
It's hard to troubleshoot that problem from a distance. He doesn't appear to be having problems receiving any other strings, so I wouldn't suspect the buffer size or the handshaking - but it may be. When you make a GPRS connection the power draw also increases significantly, so it may be a power supply issue. I've seen a lot of weird power supply problems. Again, hard to troubleshoot from a distance.phaedrus said:Hi GSMMan,It may also be that his receiving program is dropping characters,which might happen if he is using a micro controller with less data buffer etc.But since he said that with the other modem he has never faced the problem,maybe this is not the case ? Or it may be a combination of RTS/CTS hardware failure on the defective modem and insufficient buffer size ?Hen, "CONNECT" without the "OK" is not a valid response. I suspect you have a hardware problem, although I've never seen a module fail in that way.
phaedrus said:Could you explain further on this ?Maybe a cut paste of some response data would help, which shows the header ?I was getting the same data from the modem for both the cases.This command adds a "header" to the data returned by ythe server. You don't need to send this command, but the header makes it easier to identify the data string and it indicates the number of bytes in the data packet.
SEND OK
+IPD1029:HTTP/1.1 200 OK
Fri, 14 Aug 2009 18:06:14 GMT
Server: Oversee Webserver v1.3.18
Set-Cookie: parkinglot=1; domain=.google.com; path=/; expires=Sat, 15-Aug-2009 18:06:14 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
.
.
.
href="http://searchportal.information.com?epl=00790085QUdfCQtQAwZWA1NUDEMBXA5rFFIFUEUEEwgTXFdZUAxbWgNVXFhUWw5XDgYWBgleR1U5XgcIBlVZAQU">Click here to go to google.com</a>.</noframes></html>
at+cipmode=1
at+cipmode=0
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?