URCs and responses | Telit Cinterion IoT Developer Community
September 17, 2018 - 4:02pm, 5735 views
Can URCs have OK and/or ERROR responses ? I noticed I was also getting an ERROR response after the ^SYSSTART URC occurred, which did not seem to be right according to the Gemalto_ELS31_AT_Commands_GELS3-C.pdf doc,
Hello,
URC is an unsolicited result code which is not a reply to AT command but some information that can be thrown by the module any time. Only AT command has OK or ERROR reply which terminates each command response. Maybe this ERROR was a reply to some command sent by your application.
Regards,
Bartłomiej
Thanks for your reply. I will look into why there was an ERROR repsonse just after picking up the ^SYSSTART URC.
I am definitely picking up a ^SYSSTART URC followed by an ERROR response the first time I poll the modem after the OS ( Debian arm-64 ) is booted and I access the modem programatically for the first time. This is happening before the first command I send through the modem in order to configure the modem. I do delay programatically a full second before I send the first command and after I setup the modem port programatically. After the first time I access the modem port in my program I never receive the ^SYSSTART URC, which makes perfect sense, but why I receive an ERROR message after the initial ^SYSSTART URC I do not understand. I do ignore that initial ERROR return after the ^SYSSTART URC, so that is not a problem in my code. I do not understand why I would receive the initial ERROR return as it does not seem possible that the modem should still have a previous ERROR return in an internal queue when the modem is first being accessed after an OS boot.
I am just worried I might receive an OK or ERROR after some other URC during processing, which would definitely foul up my programming logic when sending commands throught the modem and waiting for the usual responses. I do wait at least the proverbial 1/10 second between commands. so URCs should not get mixed up with AT command processing and response, but this initial ERROR after the ^SYSSTART URC does have me worried. Perhaps it is a minor hardware glitch with the Gemalto.
Hello,
SYSSTART is thrown when the module is powered up, so it should happen only once. My suspicion is that this ERROR might be caused by some interaction with your OS before you access the module. You could try to trace the communication between modem and system to check it. The easy test would be to just try to connect it to some other OS like Windows for example and check if this ERROR will also appear.
Could you also check the firmware version with ATI1 command?
Best regards,
Bartłomiej
Hello,
How about setting the error message output to text mode?
AT+CMEE=2 and AT&W.
If the error message comes from OS handshaking etc, you may see a message like
+CME ERROR: 25 invalid characters in text string
^SYSSTART itself can give only the following URC's on the ELS31:
^SBC: Undervoltage Warning
^SBC: Undervoltage Shutdown
^SBC: Overvoltage Warning
^SBC: Overvoltage Shutdown
Are you using the ASC0, ASC1 or USB?
If you are using either ASC0 or ASC1, please check AT^SPOW?
Try setting it to AT^SPOW=1,0,0 to avoid delays in default sleep mode communication.
Best regards,
Antero
Antero Markkula
Communication and Mechatronics
Enkom Active Oy – www.enkom-active.fi
Upseerinkatu 3 A, 02600 Espoo, Finland
Mobile: +358 400 411368
Office: +358 10 204 0000
Fax: +358 10 204 0010
E-mail: antero.markkula@enkom-active.fi
Settting anything after the fact is not going to work since the ^SYSSTART / ERROR sequence occurs the first time the modem is polled after the com port has been initialized. I am aware of the URCs which could occur, as you list them, and I am aware that the ^SYSSTART URC should not be generated a further ERROR response, so why it is happening is a mystery.
Unfortunately the application is running on a SOM board which only boots up Debian Linux. So it is impossible to check on Windows. The modem information from the ATI command is:
Cinterion
ELS31-V
REVISION 4.3.2.0
Hello,
AT&W stores the current AT command settings in the non-volatile memory. So it will automatically be restored during power-up. This might help to get some more information. You could also try to connect some hardware tracer to the interface used by the board or try some tracing in Linux.
Please use ATI1 for detailed firmware information.
Regards,
Bartłomiej