Hello.
I want to push data to an ftp-Server and can´t establish a GPRS connection.
I´m using a CR1000-Datalogger with COM110-Modem (connected via SC105 to CS I/O) as part of the CS-GPRS-package.
I followed the CS-GPRS-manual and failed to establish connection.
Mobile Data Assistant - COM110-settings:
-------------------------------------
Connection Type: GPRS
Baud Rate: 115.2k
IP-Control: Logger IP stack
Connection Control: Logger Program Callback
Datalogger Port: CS I/O SDC7
APN: A1.net
User ID: ppp@A1plus.at
Password: ppp
SC105 configuration:
-------------------------------------
115.2kBaud, CS I/O: SDC7
Device Config CR1000
-------------------------------------
Port CS I/O SDC7
IP: 0.0.0.0
User name: empty
Passworf: empty
Modem Dial String: *99***1#
Modem Dial Response: CONNECT
Programm used for testing the connection:
-------------------------------------
SequentialMode
Const FTPServerAddress = "xx.xx.xxx.xx"
Const FTPUserID = "xxxxxxxxxxxxxxxxx"
Const FTPPassword = "xxxxxxxxxxx"
Public FTPSuccess As Boolean = False, LastFileName As String * 32, PTemp, Batt
Public SendFTP As Boolean = False, OutStat As Boolean = False, DestinationFilename As String * 32
DataTable (FTP,1,-1)
TableFile("USR:FTPTest",12,5,5,0,Min,OutStat,LastFileName)
Sample(1,PTemp,FP2)
Sample(1,Batt,FP2)
EndTable
BeginProg
SetStatus("UsrDriveSize",8192)
Scan (15,Sec,0,0)
PanelTemp(PTemp,_50Hz)
Battery(Batt)
CallTable(FTP)
If OutStat Then SendFTP = True
NextScan
SlowSequence
Do
If SendFTP Then
DestinationFilename = Right(LastFileName,Len(LastFileName)-4)
FTPSuccess = FTPClient(FTPServerAddress, FTPUserID, FTPPassword, LastFileName, DestinationFilename,2)
SendFTP = False
EndIf
Loop
EndProg
Troubleshooting:
-------------------------------------
* the SIM-card used is activated for GPRS-use and has dynamic IP; PIN disabled;
* Signal strength is good
* i have read/write access to the ftp-Server with the login credentials used (tested with FileZilla)
* Real Time Monitoring - ppp state: dial failed
Hello,
Did you allow the MDA (Mobile Data Assistant) to program the CR1000? Which operating system version are you using in the CR1000?
Hello,
Yes, the settings of the CR1000 have been made with the Mobile Data Assistant.
The operating system of the datalogger is: CR1000.Std.26
The reason you were asked about applying the settings is that your reported:
Device Config CR1000
-------------------------------------
Port CS I/O SDC7
IP: 0.0.0.0
User name: empty
Passworf: empty
Modem Dial String: *99***1#
Modem Dial Response: CONNECT
The username and password should show the User ID and Password you reported above if you entered those settings in the MDA before applying them to the logger?
You can always enter them in Devconfig if you wish.
You might also consider upgrading your logger operating system to OS27 (from this website). Then have a look at the four new optional parameters at the end of the ftpclient instruction. These let you "stream" data directly from the loggers main datastorage, with the same format options as Tablefile. The avoids having to create USR drive space and manage the files that are there. There is an example of its use at the bottom of the program example listings in the CRBasic help file.
Hello,
I´ve upgraded the datalogger operating system to OS27.
I´ve also reapplied all settings to the COM110 and CR1000 with MDA;
Mobile Data Assistant settings - step by step:
-------------------------------------
COM-Port: COM1
Baud Rate 8,N,1: 115200
Find Modem: Modem found on COM1 at 115200 8 N 1
Setup:
--------
Connection Type: GPRS
Logger Selection: CR1000
Baud Rate: 115200 Baud
IP-Control: Logger IP Stack
Connection Control: Logger Program Callback
Settings:
Datalogger Port CS I/O SDC7
APN: A1.net
User ID: ppp@A1plus.at
Password: ppp
Device Config CR1000 now reports:
TCP/IP:
-------------------------------------
Ethernet Interface:
IP: 0.0.0.0
CS I/O IP:
-------------------------------------
CS I/O Interface #1
IP Address: 0.0.0.0
CS I/O Interface #2
IP Address: 0.0.0.0
PPP:
-------------------------------------
Config/Port Used: CS I/O SDC7
IP Address: 0.0.0.0
User Name: EMPTY
Password: EMPTY
Modem Dial String: 255.255.255.255
Modem Dial Response: ppp@A1plus.at
SC105 settings:
-------------------------------------
CS I/O Port Configuration: SDC Address 7
RS-232 Port Configuration: [Modem] [115.2k,8,N,1] [APD-Enabled]
I guess the MDA isn´t applying the ppp-settings correct as User Name and Password are still empty and Modem Dial String and Modem Dial Response are obviously wrong?
* Last updated by: schiller on 11/11/2013 @ 4:10 AM *
After configuring the datalogger settings manually in DevConfig one single empty file (Test73.dat with 0kB) has been sent to the ftp-Server.
PPP settings manually entered:
-------------------------------------
Config/Port Used: CS I/O SDC7
IP Address: 0.0.0.0
User Name: ppp@A1plus.at
Password: ppp
Modem Dial String: ATV1;ATD*99***1#
Modem Dial Response: CONNECT
The issue with the MDA is something we are investigating. A recent upgrade to some associated tools (the Device Configurator) seems to have broken the order in which the settings are applied to the logger by the MDA program.
Our apologies for this. We are working on a fix. Meanwhile please use Devconfig to manually apply the settings.
Thats what i supposed and why I´ve entered the settings manually with DevConfig, yet can´t establish a connection.
The SerialComms-Sniffer reveals the following:
-------------------------------------
T 13:43:55.81 A
R 13:43:55.84 A
T 13:43:55.85 T
R 13:43:55.89 T
T 13:43:55.89 D
R 13:43:55.94 D
T 13:43:55.95 *
R 13:43:55.99 *
T 13:43:56.00 9
R 13:43:56.04 9
T 13:43:56.05 9
R 13:43:56.09 9
T 13:43:56.10 *
R 13:43:56.14 *
T 13:43:56.15 *
R 13:43:56.19 *
T 13:43:56.20 *
R 13:43:56.24 *
T 13:43:56.25 1
R 13:43:56.29 1
T 13:43:56.30 #
R 13:43:56.34 #
T 13:43:56.35
R 13:43:56.39
R 13:43:56.39 CONNECT 115200
R 13:43:56.39 ~.}#.!}!}!} }<}!}$}%.}"}&} } } } }%}&$...}'}"}(}"}#}$.#..~
R 13:43:56.39 ~.}#.!}!}!} }<}!}$}%.}"}&} } } } }%}&$...}'}"}(}"}#}$.#..~
T 13:43:56.46 ~.}#.!}!A} }6}!}$}%.}"}&} } } } }%}&} P%.}'}".?~
T 13:43:56.48 ~.}#.!}"}!} }<}!}$}%.}"}&} } } } }%}&$...}'}"}(}"}#}$.#..~
R 13:43:56.49 ~.}#.!}"A} }6}!}$}%.}"}&} } } } }%}&} P%.}'}"!.~
T 13:43:56.66 ~.#....ppp@A1plus.at.pppq~
R 13:43:56.72 ~.}#.!}%}"} }$Y(~
T 13:43:56.86 ~...!.....~
R 13:43:56.91
R 13:43:56.91 NO CARRIER
As i don´t know how the string should look like I´m lost with establishing a connection and I don´t know which other settings I could change to get it working.
* Last updated by: schiller on 11/12/2013 @ 7:52 AM *
What you can see above looks normal but it would seem that either the username or password is being rejected by the remote system of the APN has not been set in the modem correctly.
I have double-checked the APN settings and when testing the SIM-card with my mobile phone they work perfectly.
Can you follow the instructions in the troublshooting section of the CS-GSM-GPRS manual to capture an IPTrace log of a connection attempt please and post here.
The fact you managed to send one file would indicate the settings have worked at some point though.
There is a possibility that your operator does not like the COM110 as a device type or is rejecting it as you have moved the SIM between your phone and the COM110. (Some do not like you moving the SIM too often as it can be a sign of SIM cloning)
Hello.
here is the IPTrace log:
-------------------------------------
CR1000
08:03:19.97 ET0 mac=00d02c041ba9, ip=0, mask=ffffff00, gw=0
08:03:19.97 PPP opened, comnum 3
08:03:19.98 ET1 mac=000000000000, ip=0, mask=ffffff00, gw=0
08:03:19.98 ET2 mac=000000000000, ip=0, mask=ffffff00, gw=0
08:03:19.99 prepped 4 interfaces, initializing...
08:03:20.08 CHAP setup: required: NO, secret: ppp, username: ppp@a1plus.at
08:03:20.09 PAP setup: required: NO, usename: ppp@a1plus.at, password: ppp
08:03:20.09 init error 2 on net[2]
08:03:20.09 init error 3 on net[3]
08:03:20.14 socketTask starting, dhc_setup() starting
08:03:20.14 ip_startup() initialized okay
08:03:20.15 dhc_setup() finished
08:03:20.15 tcp srv port 6785 - starting.
08:03:20.15 tcp srv port 23 - starting.
08:03:20.16 tcp srv port 80 - starting.
08:03:20.16 tcp srv port 21 - starting.
08:03:20.17 ftp succeeded to init
08:03:27.12 ppp started dialing
08:03:27.62 dial TX: A
08:03:27.65 dial RX: A
08:03:27.65 dial TX: T
08:03:27.70 dial RX: T
08:03:27.70 dial TX: D
08:03:27.75 dial RX: D
08:03:27.75 dial TX: *
08:03:27.80 dial RX: *
08:03:27.80 dial TX: 9
08:03:27.85 dial RX: 9
08:03:27.85 dial TX: 9
08:03:27.90 dial RX: 9
08:03:27.90 dial TX: *
08:03:27.95 dial RX: *
08:03:27.95 dial TX: *
08:03:28.00 dial RX: *
08:03:28.00 dial TX: *
08:03:28.05 dial RX: *
08:03:28.05 dial TX: 1
08:03:28.10 dial RX: 1
08:03:28.10 dial TX: #
08:03:28.12 ppp is dialing
08:03:28.15 dial RX: #
08:03:28.15 dial TX: r
08:03:28.21 dial RX: r
08:03:28.21 dial RX: r
08:03:28.21 dial RX: n
08:03:28.21 dial RX: C
08:03:28.22 dial RX: O
08:03:28.22 dial RX: N
08:03:28.22 dial RX: N
08:03:28.22 dial RX: E
08:03:28.22 dial RX: C
08:03:28.23 dial RX: T
08:03:28.23 dial RX:
08:03:28.23 dial RX: 1
08:03:28.24 dial RX: 1
08:03:28.24 dial RX: 5
08:03:28.24 dial RX: 2
08:03:28.24 dial RX: 0
08:03:28.25 dial RX: 0
08:03:28.25 dial RX: r
08:03:28.39 ppp_fsm_init (link 0020DF6E)
08:03:28.39 lowerup: (link 0020DF6E) LCP
08:03:28.39 ppp_fsm (link 0020DF6E): LCP state: INITIAL -> CLOSED cmd 0 pcode 0 inlen 0
08:03:28.40 open (link 0020DF6E): LCP
08:03:28.40 opening LCP
08:03:28.40 ppp_fsm (link 0020DF6E): LCP state: CLOSED -> REQSENT cmd 1392 pcode 0 inlen 0
08:03:28.41 ppp_fsm (link 0020DF6E) sending CONFREQ, len:18
08:03:28.41 ppp Sending 26 bytes, service 5d2c38
08:03:28.42 ppp_SETTIMER fsm_tmo for 6 secs
08:03:28.42 opening IPCP
08:03:28.43 ppp_fsm (link 0020DF6E): IPCP state: INITIAL -> STARTING cmd 48 pcode 1 inlen 0
08:03:28.43 open (link 0020DF6E): LCP
08:03:28.43 opening LCP
08:03:28.44 ppp_fsm (link 0020DF6E): LCP state: REQSENT -> REQSENT cmd 0 pcode 0 inlen 0
08:03:28.44 opening IPCP
08:03:28.44 ppp_fsm (link 0020DF6E): IPCP state: STARTING -> STARTING cmd 0 pcode 1 inlen 0
08:03:28.45 ppp link 0020DF6E rcvd 5b4edc pkt 30 bytes, proto c021
08:03:28.45 ppp_inpkt (link 0020DF6E); prot: LCP, code CONFREQ, state REQSENT, len 24
08:03:28.46 lcp_reqci: rcvd MRU(1500)(ACK)
08:03:28.46 lcp_reqci: rcvd ASYNCMAP(0)(ACK)
08:03:28.46 lcp_reqci: rcvd MAGICNUMBER(0)(ACK)
08:03:28.47 lcp_reqci: rcvd PCOMPRESSION(ACK)
08:03:28.48 lcp_reqci: rcvd ACCOMPRESSION(ACK)
08:03:28.48 lcp_reqci: rcvd AUTHTYPE(c023)(ACK)
08:03:28.48 lcp_reqci: returning CONFACK.
08:03:28.49 calling ppp_fsm: event 6
08:03:28.49 ppp_fsm (link 0020DF6E): LCP state: REQSENT -> ACKSENT cmd 128 pcode 0 inlen 24
08:03:28.49 ppp_fsm (link 0020DF6E) sending CONFACK, len:24
08:03:28.50 ppp Sending 32 bytes, service 5d2c38
08:03:28.50 ppp link 0020DF6E rcvd 5b4c3c pkt 24 bytes, proto c021
08:03:28.51 ppp_inpkt (link 0020DF6E); prot: LCP, code CONFACK, state ACKSENT, len 18
08:03:28.52 LCP rcvd ACK: OK
08:03:28.52 calling ppp_fsm: event 8
08:03:28.52 ppp_fsm (link 0020DF6E): LCP state: ACKSENT -> OPENED cmd 1296 pcode 0 inlen 18
08:03:28.53 ppp_CLEARTIMER fsm_tmo
08:03:28.53 lowerup: (link 0020DF6E) AUTH
08:03:28.53 ppp Sending 24 bytes, service 5d2c38
08:03:28.54 upap_sauth: Sent id 1.ppp_SETTIMER auth_tick for 1 secs
08:03:29.59 ppp_CLEARTIMER auth_tick
08:03:29.59 ppp_SETTIMER auth_tick for 1 secs
08:03:30.79 ppp_CLEARTIMER auth_tick
08:03:30.79 ppp_SETTIMER auth_tick for 1 secs
08:03:31.99 ppp_CLEARTIMER auth_tick
08:03:31.99 ppp_SETTIMER auth_tick for 1 secs
08:03:33.19 ppp_CLEARTIMER auth_tick
08:03:33.19 ppp_SETTIMER auth_tick for 1 secs
08:03:34.39 ppp_CLEARTIMER auth_tick
08:03:34.39 ppp_SETTIMER auth_tick for 1 secs
08:03:35.59 ppp_CLEARTIMER auth_tick
08:03:35.59 ppp_SETTIMER auth_tick for 1 secs
08:03:36.79 ppp_CLEARTIMER auth_tick
08:03:36.79 ppp_SETTIMER auth_tick for 1 secs
08:03:37.99 ppp_CLEARTIMER auth_tick
08:03:37.99 ppp_SETTIMER auth_tick for 1 secs
08:03:39.19 ppp_CLEARTIMER auth_tick
08:03:39.19 ppp_SETTIMER auth_tick for 1 secs
08:03:40.39 ppp_CLEARTIMER auth_tick
08:03:40.39 ppp_SETTIMER auth_tick for 1 secs
08:03:41.59 ppp_CLEARTIMER auth_tick
08:03:41.59 ppp_SETTIMER auth_tick for 1 secs
08:03:42.79 ppp_CLEARTIMER auth_tick
08:03:42.79 ppp_SETTIMER auth_tick for 1 secs
08:03:43.99 ppp_CLEARTIMER auth_tick
08:03:43.99 ppp_SETTIMER auth_tick for 1 secs
08:03:45.19 ppp_CLEARTIMER auth_tick
08:03:45.19 ppp_SETTIMER auth_tick for 1 secs
08:03:46.39 ppp_CLEARTIMER auth_tick
08:03:46.39 ppp Sending 24 bytes, service 5d2c38
08:03:46.39 upap_sauth: Sent id 2.ppp_SETTIMER auth_tick for 1 secs
08:03:47.59 ppp_CLEARTIMER auth_tick
08:03:47.59 ppp_SETTIMER auth_tick for 1 secs
08:03:48.79 ppp_CLEARTIMER auth_tick
08:03:48.79 ppp_SETTIMER auth_tick for 1 secs
08:03:49.99 ppp_CLEARTIMER auth_tick
08:03:49.99 ppp_SETTIMER auth_tick for 1 secs
08:03:51.19 ppp_CLEARTIMER auth_tick
08:03:51.19 ppp_SETTIMER auth_tick for 1 secs
08:03:52.39 ppp_CLEARTIMER auth_tick
08:03:52.39 ppp_SETTIMER auth_tick for 1 secs
08:03:53.59 ppp_CLEARTIMER auth_tick
08:03:53.59 ppp_SETTIMER auth_tick for 1 secs
08:03:54.79 ppp_CLEARTIMER auth_tick
08:03:54.79 ppp_SETTIMER auth_tick for 1 secs
08:03:55.12 No DNS entries.
08:03:55.12 bigfreeq: head:005C239C, tail:005B5A5C, len:32, min:32, max:32
08:03:55.12 lilfreeq: head:005B46FC, tail:005B484C, len:60, min:57, max:60
08:03:55.13 rcvdq: head:00000000, tail:00000000, len:0, min:0, max:0
08:03:55.13 ppp_rcvdq: head:00000000, tail:00000000, len:0, min:0, max:1
08:03:55.14 ppp_fastq: head:00000000, tail:00000000, len:0, min:0, max:1
08:03:55.14 ppp_dataq: head:00000000, tail:00000000, len:0, min:0, max:0
08:03:55.15 mfreeq: head:005B06F0, tail:005B071C, len:187, min:186, max:187
08:03:55.15 mbufq: head:00000000, tail:00000000, len:0, min:0, max:1
08:03:55.15 soq: head:005CAC34, tail:005CAA84, len:4, min:0, max:4
08:03:55.16 inpfreeq: head:005CC03C, tail:005CACC4, len:96, min:96, max:100
08:03:55.16 soqfreeq: head:005CA9F4, tail:005C740C, len:96, min:96, max:100
08:03:55.17 tphfreeq: head:005C73DC, tail:005C614C, len:100, min:100, max:100
08:03:55.17 tcbfreeq: head:005C5E40, tail:005C23D4, len:96, min:96, max:100
08:03:55.18 Open Sockets info:
08:03:55.18 Ethernet: CrcError 0 RxMiss 0 ThrowAways 0 MaxISRTime 0 Reinit 0
08:03:55.18 Comms Mem lens mins: tiny 5 5, lil 15 14, med 25 25, big 12 11, lge 0 0
08:03:55.99 ppp_CLEARTIMER auth_tick
08:03:55.99 ppp_SETTIMER auth_tick for 1 secs
08:03:57.19 ppp_CLEARTIMER auth_tick
08:03:57.19 ppp_SETTIMER auth_tick for 1 secs
08:03:58.39 ppp_CLEARTIMER auth_tick
08:03:58.39 ppp_SETTIMER auth_tick for 1 secs
08:03:59.59 ppp_CLEARTIMER auth_tick
08:03:59.59 ppp_SETTIMER auth_tick for 1 secs
08:04:00.79 ppp_CLEARTIMER auth_tick
08:04:00.79 ppp_SETTIMER auth_tick for 1 secs
08:04:01.99 ppp_CLEARTIMER auth_tick
08:04:01.99 ppp_SETTIMER auth_tick for 1 secs
08:04:02.01 tcp_services: failed socket connect to 81.19.145.51: -30
08:04:02.02 Handle 101 TCP 0.0.0.0:1024 0.0.0.0 closing
08:04:02.03 ftp client FAILED
08:04:03.19 ppp_CLEARTIMER auth_tick
08:04:03.19 ppp_SETTIMER auth_tick for 1 secs
08:04:04.39 ppp_CLEARTIMER auth_tick
08:04:04.39 ppp Sending 24 bytes, service 5d2c38
08:04:04.39 upap_sauth: Sent id 3.ppp_SETTIMER auth_tick for 1 secs
08:04:05.59 ppp_CLEARTIMER auth_tick
08:04:05.59 ppp_SETTIMER auth_tick for 1 secs
08:04:06.79 ppp_CLEARTIMER auth_tick
08:04:06.79 ppp_SETTIMER auth_tick for 1 secs
08:04:07.99 ppp_CLEARTIMER auth_tick
08:04:07.99 ppp_SETTIMER auth_tick for 1 secs
08:04:09.19 ppp_CLEARTIMER auth_tick
08:04:09.19 ppp_SETTIMER auth_tick for 1 secs
08:04:10.39 ppp_CLEARTIMER auth_tick
08:04:10.39 ppp_SETTIMER auth_tick for 1 secs
08:04:11.59 ppp_CLEARTIMER auth_tick
08:04:11.59 ppp_SETTIMER auth_tick for 1 secs
08:04:12.79 ppp_CLEARTIMER auth_tick
08:04:12.79 ppp_SETTIMER auth_tick for 1 secs
That log shows the logger has sent a request to authenticate itself to the network server and is getting no response.
This can be due to a number of issues. One may be that the SIM card is a 3G only card, which means it cannot authenticate on a 2G connection. Others can be the network is busy and/or the connection signal strength is not good enough.
Hello.
I don´t think it´s a problem of the SIM-card, because I´ve used it successfully with other devices (mobile phones) for data transfer and have also tried SIM-cards of other providers with the same result.
Signal strength is also very good.
We have sold ~1000 of these modems all over Europe and they work on most if not all European 2G networks. Aside from the issues mentioned above other reasons this does not work for you could be:
1) in the logger stack we have a timeout of about 18 secs for receiving a reply to an authentication request. We try three times if there is no response in that time, then we redial. It could be this is timeout is a little too short for your provider - other devices may use longer timeouts which could be why they work. There is no setting to change this timeout in our logger. You could check with your provider what they would recommend though as we could consider extending this in the future.
2) although the signal strength is deemded to be good, there may be some local interference or even a fault with the aerial itself that is preventing good communications. Check the cables for obvious faults and try the aerial in a different position.
3) the logger PPP negotiation is incompatible with the authentications server (although you said it worked once). As a test you could reconfigure the modem using the MDA program to enable the modems own PPP/TCP stack and see if the modem is able to get an IP address from the network (you can do this with the modem connected to the PC - check the Diagnostics screen of the MDA for the IP address).
* Last updated by: aps on 11/14/2013 @ 11:39 AM *
Thank you for the support, it really seems to be a problem of the provider, because with a different SIM-card I´ve now managed to get the test-files pushed regularly to our ftp-Server!
What could be the reason that these files have a size of 0kB and no content?
Edit:
it works with ftpclient-putgetoption = 2 (passive mode)
* Last updated by: schiller on 11/19/2013 @ 5:32 AM *
To answer your last question I am not sure. If you are creating the files on the logger using Tablefile, are those files of zero length? If not then this points to a problem occuring during the ftp transfer which will be hard to debug unless you can get access to the ftp server logs or capture the ftpclient status response after it has finished.
In some cases you may get an empty file created if you try an active ftp connection as the initial connection will work but firewalls in between the device and the ftp server block the data ports being open and any data being transferred. The passive mode generally avoids that.
FYI we have updated our Mobile Data Assistant package which can be loaded from here:
http://www.campbellsci.co.uk/downloads
I apologise that is did not work before, but an update to the Device Configuration package that many people installed changed some of the common logger definition files.
Hello.
As a workaround for the prototype it is possible to change the Service-Provider as the modem works fine with t-mobile-Austria SIM-cards.
However this isn´t a permanent solution, because of customer demands and superior network coverage the provider A1 is preferred.
For further development it is necessary to find a solution for transferring the data via the network of this provider. Could it possibly be a problem of this very modem to cause problems with this provider and would be the solution to use modems of other manufacturers?
The COM110 is based upon a Wavecom module which is a make common in many different "modems". It is possible that the conflict may not be between the modem as such but the way the logger negotiates the PPP connection, therefore moving to a different module may not help.
Were you able to talk to the network provider to get any idea if they could see the likely cause of the issue from logs at their end.
There is a possiblity that the logger was not waiting long enough for authentication or perhaps was not disconnecting from their service properly in a previous session.
Can I make one other suggestion. Could you try ammending the modem dial string, using the device configuration program to this:
AT+CGATT=0;ATD*99***1#
The extra CGATT command forces the modem to shutdown any GPRS session before it starts to dial a new one.
The logger does not explicitly send this at the end of calls normally as it assumes that when it has shutdown the previous PPP session the modem/network will automatically close any previous GPRS sessions.
As far as we know most networks do, but it is possible this is not happening in your case. Adding the extra command makes sure the modem starts afresh.
* Last updated by: aps on 11/22/2013 @ 2:18 AM *
The modification of the modem dial string didn´t show any differences. Anyway i´ll contact the provider again to check if there are any known issues why it doesn´t work.
OK, one other customer who was having a similar problem contacted their provider (a well know Swiss telecom company) and they had tracked the problem to a recent "upgrade" of a key component of their network hardware (the GGSN) that was being done in preparation for LTE networks. They had found the change had caused numerous problems to GPRS users and have gone back to the old system until they resolve these issues. That users problem which was not dissimilar to yours has now gone away.
I am not sure what make of hardware was at fault but it is likely that other networks are using similar kit, so this could be your issue if your network is undertaking similar upgrades.
And, just one other check, which was just suggested to me indirectly by the chipset manufactuers and which may be related to network compatability (and changes in some networks).
If you are able can you please apply this setting to the modem
AT+WGPRS=8,,,0
This should stick through power cycles. You can do this either with a terminal emulator or by using the terminal screen of the MDA package (click the right hand margin of the main screen).
This disables the modem from negotiating an EGPRS connection. This will only have a small effect on its performance.
Please let us know if this helps.
I´ve applied the suggested settings but the connection attempt shows the same result as before (dialling - CONNECT 115200, after authentication attempt - NO CARRIER).