EC25E LTE connection issue

Hi,

we are using the EC25 Module for quiet some time now without any issues. However, one of our customers changed his provider and now we are not able to establish a connection anymore. It seems that the modem is bailing out very early in the connection process before actually trying to establish the data link.

At first i assumed that this would be some issue with the credentials or apn configuration. However it turned out that it works if are running the same configuration on a competitors module we used in an earlier design.

After some research and testing i could track the issue down to the network mode. For some reason the connection is established if i force the module to work either on GSM/EDGE or UTRAN mode. If it tries to connect in E-UTRAN(LTE) mode the connection attempt fails.

If the module is in its error state even a direct forced AT+COPS=1,2,“26202”,7 attempt comes back with +CME_ERROR: 30 (No Service)

To make things even more mysterious to me sometimes but very rarely the connection attempt succeeds in LTE mode and seems to be stable then.

I am able to reproduce the issue by just powering the module up and enter the pin manually via AT+CPIN=XXXX and check the AT+COPS? which always returns 1 although the +QNWINFO returns “FDD LTE”,“26202”,“LTE BAND 20”,6300.

Does someone have an idea what i could try or is there maybe a firmware issue i should address?

PPPD output:

Script /usr/sbin/chat -v -f /tmp/chat-mg finished (pid 25690), status = 0x0
Serial connection established.
using channel 21
Using interface ppp0
Connect: ppp0 <–> /dev/ttyQtel3
sent [LCP ConfReq id=0x1 <magic 0xe78ab056>]
rcvd [LCP ConfReq id=0x12 <asyncmap 0x0> <magic 0xd1322260> ]
sent [LCP ConfRej id=0x12 <asyncmap 0x0> ]
rcvd [LCP ConfAck id=0x1 <magic 0xe78ab056>]
rcvd [LCP ConfReq id=0x13 <magic 0xd1322260>]
sent [LCP ConfAck id=0x13 <magic 0xd1322260>]
sent [LCP EchoReq id=0x0 magic=0xe78ab056]
rcvd [LCP DiscReq id=0x14 magic=0xd1322260]
rcvd [CHAP Challenge id=0x1 <89229d0336b9ed67c4e5bcbd38f07958>, name = “UMTS_CHAP_SRVR”]
sent [CHAP Response id=0x1 <536368adc254581dc377eaa2408b38ef>, name = “<user>@<server>”]
rcvd [LCP EchoRep id=0x0 magic=0xd1322260 e7 8a b0 56]
rcvd [CHAP Success id=0x1 “”]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Modem hangup
Connection terminated.

chat script

TIMEOUT 45
ABORT “BUSY”
ABORT “NO CARRIER”
ABORT “NO CARIER”
ABORT “ERROR”
ABORT “NO ANSWER”
“” ‘ATZ’
OK ‘AT’
OK ATI;+CSUB;+CSQ;+CPIN?;+COPS?;+CGREG?;&D2
OK AT+CGDCONT=1,“IP”,"<apn>"
OK ATD99**1#
CONNECT \d\c

Modem revision
EC25EFAR06A04M4G-V05

Best Regards,

Thomas

Dear Tom,
Thanks for your inquiry in Quectel forum.
For your issue, just as you have said that the issue only occurs when you change another provider, so you may need to double check which bands that the provider support, and whether it have any special parameters setting such as APN, username, password. Thanks!

Dear Kyson,

tanks for the reply. However it seems like i have found a solution, maybe you are able to explain why this actually works.

During my research in your forums regarding my problem i found a similar issue which could be resolved by setting the pdp context in advance to the network registration attempt to “IPV4V6”. I gave that a try and it works for me too. If i preinitialize the modem like this…

AT+CGDCONT=1,“IPV4V6”,""
AT+CFUN=0
AT+CFUN=1

…everything is working just fine.

I get that the adressing mode is important for the actual data connection but i was unaware that this also affects the initial network registration as well. Maybe you can clarify this a bit for me or maybe there is some documentation covering this.

Best Regards,

Thomas

1 Like

Dear Tom,
Thanks for your updating.
I am glad to hear that you have find the solution to your issue. About the IP type IPV4V6 means that IPV4 or IPV6. You can check the obtained IP address with AT+CGPADDR to confirm it is IPV4 or IPV6, if you can confirm it, you also can set it IPV4 or IPV6, not IPV4V6. Thanks!