Using SYSSTART URC | Telit Cinterion IoT Developer Community
October 17, 2016 - 9:08am, 4068 views
Hello,
I want to be sure if at parser is ready after start up. Then, I will send my initial at commands.
I have 2 alternative ways to do this.
1. Setting ATCommandListener just at the beginning of code and waiting for ^SYSTART URC.
2. Waiting for some time for at parser to be ready after start up. In my tests, ^SYSSTART is being sent nearly 10 seconds later after start up to serial interface.
I don't know if there is some conditions it is sent lately (for example 20, 30 seconds or more) or even is not sent.
Which way do you recommend?
Best Regards,
Ergün.
Hi,
your Java program always will started after ^SYSTART. that's after ^SYSTART the JRC and your program will be loaded
Regards
ALopez
Somewhere over the rainbow!!! Looking for the Oz Land!!!
Hello,
Generally you should set "Oracle-MIDlet-Autostart: 2" (or more) for your MIDlet as this parameter decides about the start order. JRC has 1 so to be sure that JRC will always start before your application it should be more that 1. When 2 MIDlets have the same value the order is theoretically not determined.
The "^SYSTART" URC is thrown by JRC - if JRC does not start for some reason there will be no "^SYSTART". So if your application finally starts it will not be able to catch "^SYSTART".
I don't know why the "^SYSTART" occurs so late in your case - maybe the reason is that you have "Oracle-MIDlet-Autostart: 1" in your jad file or you have configured the delay for autostart with AT^SCFG command (this setting is global for all MIDlets including JRC).
Generally when your MIDlet starts the AT command interpreter should also be ready and there should be no need to wait for it. But if you would like to wait to let the module do all the background initiations or network registration you can configure it in the application.
Best regards,
Bartłomiej
Thanks for the answers both Alopez and Bartlomiej,
Bartlomiej, 10 seconds duration was measured when my midlet was not running in the module. I observed it from PC terminal program. I'm opening the terminal program com interface and observing start up URCs. ^SYSLOADING, ^SYSSTART, +PBREADY. SYSSTART comes nearly 10 seconds later after start up.
I'm doing this because I assumed same scenario will work when my midlet is working.
In Java User Guide, section 5.6.2 below is written:
5.6.2 Mode Indication after MIDlet Startup
After starting a module without autobauding on, the startup state is indicated over the serial interface. Similarly, after MIDlet startup the module sends its startup state (^SYSSTART, etc.) to the MIDlet. This is done via a URC to the AT Command API instance which executes the very first AT Command from within Java. To read this URC it is necessary to register a listener(see [3]) on this AT Command API instance before passing the first AT Command.
Please check the AT^SCFG? output for the line below:
^SCFG: "Userware/Autostart/Delay","0"
if there is anything greater that 0 all the MIDlets will be started with a delay (the configured value multiplied by 100 ms makes the delay in milliseconds). For 10 seconds delay there would be 100 set.
According to my experience it is not possible to catch ^SYSTART in the MIDlet.
Regards,
Bartłomiej
Hello Bartlomiej,
I checked autostart delay with at^scfg. It is 0.
In at command manual, in section 1.8.1 below sentence is written.
"Do not enter AT commands until the "^SYSSTART" URC has shown up."
Thus, I planned catching ^SYSSTART or waiting some time and then sending at commands. But according to your explanations, it is not needed. If so, I can assume at command interface is already ready when code execution is in startApp method of midlet. No need to extra check or wait.
Best Regards,
Hello,
I observed the ^SYSSTART URC and debug prints of my example midlet on 2 terminal window.
I put 2 debug trace at the beginning of Midlet constructor and startApp() method. I enabled autostart.
After power on, the order of messages is like that:
1. Constructor message(In my midlet constructor. Midlet conctructor is called by runtime system.)
2. ^SYSSTART URC.
3. startApp method message.(At the beginning of startApp() method)
This shows that, ^SYSSTART URC is sent just after Midlet instance created by runtime system.
And when startApp method starts execution, SYSSTART URC already sent by the system. So it is not possible for Midlet to catch it.
Hello,
One more addition.
I put one more system.out.print to end of my midlet constructor. The message order seen on terminal is:
1. in Constructor message (Code execution gets into constructor)
2. "^SYSSTART" URC
3.Constructor end message(code execution leaves from constructor)
4.startApp method message.(code execution gets into startApp method)
According to the scenario, SYSSTART URC is sent just after Midlet constructor is called, but before Midlet instance created. Because it is printed before constructor method ends.
If SYSSTART URC is sent to the Midlet ATCommandListener in this order, Midlet can never catch it.
In my opinion, If the SYSSTART URC cannot be catched by Midlet in any case, the explanations in the help docs should be cleared prevent confusion.
For Example, in Java Doc, in "Interface ATCommandListener" explanation below sentence is written:
Please note that system start URCs like "^SYSSTART", "^SYSSTART ALARM MODE" or "^SYSSTART CHARGE-ONLY MODE" are passed to a Java application after the first AT command has been sent by the ATCommand class after module start. They are passed only to this instance of the ATCommand class which has sent the first AT command obviously only if it has registered an ATCommandListener instance before the command is sent.
You are right - the practise shows that the SYSSTART URC's cannot be caught by Java MIDlet.