We have the module connected with one serial port, so we communicate with the module and get indications on the same port. We have configured it to send an echo of the command.
So it can happen, when sending a command, the echo might be interrupted by a +CIEV or another indication. The echo can be interrupted multiple time by several indications, and thus is split over several lines, which makes it hard to detect the echo.
Is there any way, to configure the module not to interrupt echo of commands with indications?
As a specific case, while sending an AT+CMGS command and waiting for the echo and the ‘>’ character, we got several indications. The echo for the command never came, but read the ‘>’ character. So we tried to send the SMS anyway, but didn’t get any echo for this command. After this, the module was in some kind of broken state. After lot of empty reads, we started sending new commands to the module, and could read back the echo of the individual commands, but no answer was coming. Only a restart did help.
For the time being, I have disabled most indications.
What can be done? Thank you very much.
Can you help with a relevant log please?
I added some debug prints into our kernel module, and attached it as a file.
Two problematic cases for now
An
AT+CMGR is written and is not echoed, but interrupted by several
indications, and then the answer to the command is given. But no echo.
An AT+CMGS fails, no ‘>’ is given and afterwards registration is lost.
Looks like the module did reboot at some time, hence the need of PIN and registration. Is power source strong enough?
Are you using flow control? Can you replicate these with manual commands in a terminal?
Power source should be strong enough. It’s hard to replicate this manually because problems occur usually under load.
Especially the CMGS and CMGR commands with lots of data seem prone to lose their echo. And always there are indications between writing the command and receiving the answer.
I’ve not yet seen a case where the echo is lost, without getting an indication before the answer.
Can there be other reasons for the modem to reboot besides low power?
The chain Command -> Response shall always be respected and a new command must not be issued before the module has terminated all the sending of its response result code (whatever it may be). This applies especially to applications that “sense” the OK text and therefore may send the next command before the complete code <CR><LF>OK<CR><LF> is sent by the module. It is advisable anyway to wait for at least 20ms between the end of the reception of the response and the issue of the next AT command. If the response codes are disabled and therefore the module does not report any response to the command, then at least the 20ms pause time shall be respected. During command mode, due to hardware limitations, under severe CPU load the serial port can loose some characters if placed in autobauding at high speeds. Therefore if you encounter this problem fix the baud rate with +IPR command.
We always wait for full response, and had at least 20 ms after response before sending the next command.
We now fixed the baudrate to 9600, and things really improved, thank you very much. Compared to before, it now is a rare occurence. But it still happens that the echo is lost, or only partially transmitted (see first attached example). Most time it happens when indications are involved, but not always (see second example).
We have the module connected with one serial port, so we communicate with the module and get indications on the same port. We have configured it to send an echo of the command.
So it can happen, when sending a command, the echo might be interrupted by a +CIEV or another indication. The echo can be interrupted multiple time by several indications, and thus is split over several lines, which makes it hard to detect the echo.
Is there any way, to configure the module not to interrupt echo of commands with indications?
As a specific case, while sending an AT+CMGS command and waiting for the echo and the ‘>’ character, we got several indications. The echo for the command never came, but read the ‘>’ character. So we tried to send the SMS anyway, but didn’t get any echo for this command. After this, the module was in some kind of broken state. After lot of empty reads, we started sending new commands to the module, and could read back the echo of the individual commands, but no answer was coming. Only a restart did help.
For the time being, I have disabled most indications.
What can be done? Thank you very much.
Can you help with a relevant log please?
I added some debug prints into our kernel module, and attached it as a file.
Two problematic cases for now
An
AT+CMGR is written and is not echoed, but interrupted by several
indications, and then the answer to the command is given. But no echo.
An AT+CMGS fails, no ‘>’ is given and afterwards registration is lost.
Looks like the module did reboot at some time, hence the need of PIN and registration. Is power source strong enough?
Are you using flow control? Can you replicate these with manual commands in a terminal?
Power source should be strong enough. It’s hard to replicate this manually because problems occur usually under load.
Especially the CMGS and CMGR commands with lots of data seem prone to lose their echo. And always there are indications between writing the command and receiving the answer.
I’ve not yet seen a case where the echo is lost, without getting an indication before the answer.
Can there be other reasons for the modem to reboot besides low power?
We have following settings in the modem:
FIRMWARE : 10.00.003
DTE_SPEED : AUTO
DTE_FORMAT : AUTO
GSM_DATA_MODE : Not Transparent
AUTOBAUD : +IPR0=YES
COMMAND_ECHO : E1=YES
RESULT_MESSAGES : Q0=YES
VERBOSE_MESSAGES : V1=YES
EXTENDED_MESSAGES : X1=YES
LINE_SPEED : F0=autodetect
CONSTANT_DTE_SPEED : YES
FLOW_CONTROL_OPTIONS : &K3=HW bidirect.
ERROR_CORRECTION_MODE : RLP
CTS_C106_OPTIONS : &B2=OFF while disc.
DSR_C107_OPTIONS : &S3=PHONE ready->ON
DTR_C108_OPTIONS : &D0=ignored
DCD_C109_OPTIONS : &C1=follows carrier
RI_C125_OPTIONS : R1=OFF dur. off-hk
C108/1_OPTIONS : &D4=NO
POWER_SAVING_ON_DTR : +CFUN:1=NO
DEFAULT_PROFILE : &Y0=user profile 1
Other things to check, commands issuing timing:
– wait for full response?
– 20 ms at least?
– fix the baudrate
We always wait for full response, and had at least 20 ms after response before sending the next command.
We now fixed the baudrate to 9600, and things really improved, thank you very much. Compared to before, it now is a rare occurence. But it still happens that the echo is lost, or only partially transmitted (see first attached example). Most time it happens when indications are involved, but not always (see second example).