We already try this way many times. And nothing changed.
It has been reported internally.
Please contact distributor for internal tracker QTI9X07TX-3558 and MOLRC9X07-1225.
Two weeks past and have not found the solution. Detail experiment is here: Video and AT commands log.
https://drive.google.com/drive/folders/1HSP0K10OdocqCCUeKBbja6HWHp9pdUU_?usp=sharing
Can somebody from Siera help us?
It is definitely something wrong with CMUX threads which wait for USB activities.
CONNECT and NO_CARRIER seems stucked in the buffer but sending AT will send the URC back on the line, it is possible to have some workaround waiting a fix as previously written.
The same thing happens with ATA command which not always reply OK. I use AT+CLCC to monitor the voice call state in case I didn’t received any response.
Thank PAT. But it will get your CPU busy sending AT and AT+CLCC.
Waiting 6 weeks without any updates for a very important bug.
Why don’t you contact local distributor and state your business case?
Have contacted and reported the bugs since May. If it counted then it has taken 5 months since reported.
Since July 23, after 3 months, problem has not been solved. So disappointed.
Hi @mlw Matt,
We reported the issue of AT Commands here since May. It will be very great if you can help us on this issue.
Thank you very much in advance.
Minh
Also interested in hearing from these issues.
Regards
Ran into something like this before with another module—wouldn’t give the CONNECT response half the time. I ended up digging around on https://whocalled.co.uk and found some folks sharing similar issues. Sometimes, just seeing what’s worked for others can help figure out those annoying little quirks with connection stability and getting UART commands to play nice.
how about using AT+CLCC as workaround?
at!muxmode?
!MUXMODE: 1
OK
atd93112345;
OK
at
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at+clcc
+CLCC: 1,1,0,1,0,"",128
+CLCC: 2,1,0,1,0,"",128
+CLCC: 3,0,2,0,0,"93112345",129
+CLCC: 4,1,0,1,0,"",128
OK
at
OK
ati3
Manufacturer: Sierra Wireless, Incorporated
Model: RC7620
Revision: SWI9X07H_00.09.10.00 85890e jenkins 2023/09/25 03:16:56
IMEI: 353634110312345
IMEI SV: 29
FSN: 7Q209530512435
+GCAP: +CGSM
OK
CONNECT
ath
OK
Another workaround is to use AT!MUXMODE=0
at!muxmode=0
OK
atd93112345;
OK
CONNECT
ath
OK
Lastly, you can see the workaround here: