Maybe the calls fail because of an external issue? If you don’t enable #ECAM you have 100% reliability in making calls?
I think, that it happens without ECAM too. I used AT#ECAM=1 and AT#DIALMODE=0 for the previous test.
Now i used AT#ECAM=1 and AT#DIALMODE=2.
When it works: ATD 0123456780;rnrnDIALINGrn+CSSI: 1rnrnRINGINGrn
When it fails: ATD 0123456780;rrn+CSSI: 1rnrnRELEASEDrn
I notice that there is an extra carriage return contained in the answer, it seems it is sometimes contained in the echo to the ATD, when the call fails, but not always (at least when ECAM is enabled).
I would try: another SIM/network; another location/cell; probe with a phone.
What are the signal parameters?
This happens with different SIMs and different networks.
Parameters before a failed attempt, e.g.
Provider: E-Plus
Reg Status: 1
RSSI: -73 dB
BER: < 0.2%
Provider: Vodafone D2
Reg Status: 1
RSSI: -69 dBm
BER: < 0.2%
I think, that it happens without ECAM too. I used AT#ECAM=1 and AT#DIALMODE=0 for the previous test.
Now i used AT#ECAM=1 and AT#DIALMODE=2.
When it works: ATD 0123456780;rnrnDIALINGrn+CSSI: 1rnrnRINGINGrn
When it fails: ATD 0123456780;rrn+CSSI: 1rnrnRELEASEDrn
I notice that there is an extra carriage return contained in the answer, it seems it is sometimes contained in the echo to the ATD, when the call fails, but not always (at least when ECAM is enabled).
How are the AT commands terminated?
Please note that commands must be terminated by a single carriage return r.
Do not add any other characters like line feed n that can interfere with the normal operation, specially when a call has to be established.
Thanks, it seems that this might actually have been the cause of the problem.
Hi,
I have enabled ECAM with AT#ECAM=1.
From time to time I get a
#ECAM: 0,0,1,,,
line as part of an answer to an ATD or ATA request, thus terminating the call.
The signal quality is good.
E.g., ATArn is written, and ‘ATArn#ECAM: 0,0,1,,,rnOKrn’ is read.
What might be the cause of this?
Hardware: GE865-QUAD
Firmware: 10.00.003
For ATD this can happen sometimes in 1 of 10 call attempts. Sometimes it is not so easily reproducible.
Examples:
When it works, answer to ATD request looks like:
ATD 0123456780;
#ECAM: 0,1,1,,,"0123456780",129rn+CSSI: 1rn#ECAM: 0,2,1,,,rnOKrn
When it fails:
ATD 0123456780;
+CSSI: 1rn#ECAM: 0,0,1,,,rnOKrn
Thanks.
Maybe the calls fail because of an external issue? If you don’t enable #ECAM you have 100% reliability in making calls?
I think, that it happens without ECAM too. I used AT#ECAM=1 and AT#DIALMODE=0 for the previous test.
Now i used AT#ECAM=1 and AT#DIALMODE=2.
When it works:
ATD 0123456780;rnrnDIALINGrn+CSSI: 1rnrnRINGINGrn
When it fails:
ATD 0123456780;rrn+CSSI: 1rnrnRELEASEDrn
I notice that there is an extra carriage return contained in the answer, it seems it is sometimes contained in the echo to the ATD, when the call fails, but not always (at least when ECAM is enabled).
I would try: another SIM/network; another location/cell; probe with a phone.
What are the signal parameters?
This happens with different SIMs and different networks.
Parameters before a failed attempt, e.g.
Provider: E-Plus
Reg Status: 1
RSSI: -73 dB
BER: < 0.2%
Provider: Vodafone D2
Reg Status: 1
RSSI: -69 dBm
BER: < 0.2%
How are the AT commands terminated?
Please note that commands must be terminated by a single carriage return r.
Do not add any other characters like line feed n that can interfere with the normal operation, specially when a call has to be established.
Thanks, it seems that this might actually have been the cause of the problem.
First tests showed a definitive improvement.