Can middlet change AT^SPOW by it self? [BGS5T] | Telit Cinterion IoT Developer Community
January 20, 2016 - 1:00pm, 6319 views
Hi,
on BGS5T I set trough the RS232 terminal AT^SPOW to 1,0,0. After that I issue AT^SPOW?, and value is correct. After that I reset the module and when I check the value is still correct. But after the MIDlet starts value change to ^SPOW: 2,1000,3.
I checked whole project and I don't change value of AT^SPOW anywhere in the code, but I use ASC0. Is it posible that when I use ASC0, value of AT^SPOW changes by it self?
Best regards,
Jure
Hello Jure,
The SPOW setting is not volatile and should not change by itself. If your application does not change the setting it should not be changed.
Regards,
Bartłomiej
Hello Bartłomiej,
I used search of IDE for whole project and I only read SPOW value. I also discovered, that if I stop MIDlet, value is still ^SPOW: 2,1000,3, but if I restart module if AT^CFUN=1,1, then value is ^SPOW: 1,0,0 again.
Could somebody else test this to confirm? To open RS232 I use:
EDIT: I tryed it in similar middlet and there SPOW stays unchanged. But I can't find the diffrence, because in both cases I use same AT commands before I check SPOW.
This are all AT commands that I use in MIDlet, does anyone see any that could be causing problems?
EDIT 2: I output spow for almost every line at start of MIDlet, and SPOW changes after this line:
But what makes it interesting is that in other MIDlet, where SPOW doesn't chage. I have same code to open RS232, only diffrence is baud rate:
If I copy this code in to the midlet where I am facing problems with SPOW, problem still occurs. So it must be some other settings, that causes change of SPOW on openeing RS232 connection.
Regards,
Jure
I am - coincidentally also today - struggling with the fact that I have a running midlet which is able to receive data packets from the RS232 cable, but in a separate terminal window I get:
at^spow?
^SPOW: 0,0,0
OK
According to the manual this should not be possible, but it works at the very moment. The actual problem that I am chasing is, that after a longer idle period (don't know time yet, but like 5-10 minutes) seems that some ***** the next incoming serial packet may be lost completely, while systems having a steay incoming data flow work well.
I have solved my problem. I have tested on two types of MIDlets. One type has RS232 connection opened all the time, other type only when needed. So when I have retrieved RS232 value, on MIDlet would already open RS232 connection, and other would be waiting for command to open it.
So I discovered that in both cases that once that RS232 connection was opened and even if it was closed afterwards, SPOW would change to 2,1000,3. After module reset it would come back to set value again. I don't know what happens inside CommConnectionControlLines and if this is a bug, since Bartłomiej says that value shouldn’t change. But at least now I know when it happens.
@JTIUSANE, have you set SPOW with AT commands, before runing midlet?
Regards,
Jure
Hello Jure,
This seems very strange. How about the real power saving behaviour - is it only the matter of response or does the interface behave like the power saving is active? Can you provide the ATI1 response?
Regards,
Bartłomiej
Hello Bartłomiej,
how could I test if power savig is active? Currently I am working in the office so nothing is attached to RS232 port.
My midlets are designed so that they are checking all the time if there is anything to read, or they try to read every half minute.
ATI:
Cinterion
BGS5
REVISION 01.100
OK
Regads,
Jure
Hello Jure,
You would have to send data to the module and check if there are any delays or problems with communication.
In sleep mode you need to use RTS/CTS flow control. So if you disable flow control while the sleep mode is active you should have problem with communication or maybe use some tracer or oscilloscope to monitor the lines.
Please issue ATI1 command instead of ATI so we have the complete information about the firmware version to check if it's the latest.
Regards,
Bartłomiej
@ JTIUSANE: With 0 setting the interfaces should not be working according to the documentation. Do you also experience such a problems when the interface is properly activated?
Hello ,
sorry I missread which command do you want me to issue. Here is ATI1:
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.10
OK
I tryed sending data without RTS/CTS flow control and I didn't notice any problems.
Regards,
Jure
Our java code is an evolution version of a EGS5 code, and we have not discovered the possible sleep mode problem until now. So to answer you: no, our code doesn't issue any AT^SPOW commands.
My collegue has been debugging all yesterday, and now we know, that in the SystemOut com-port (30) and an active terminal com-port (31) we get:
AT^SPOW?
^SPOW: 0,0,0
OK
We get this reply even though we are putting serial data in all the time. Our TE is not capable of hardware flow control, so we have hard-wired the modem's RS232 pin7 to pin8.
While the midlet is running, if I issue the AT^SPOW=1,0,0 command on the fly, then the midlet will also reply that it's 1,0,0 and serial port keeps working. If I issue AT^SPOW=0,0,0 then the Midlet will aggree that it's 0,0,0 but serial port goes dead.
I suspect, that initially SPOW is perhaps the default value (2,1000,3 ???) but I have no way to find out whether this is true or not. When I give AT^SPOW commands, then it becomes whatever is given.
One more observation: If I manually in terminal set SPOW=2,500,5 then this value is preseved over a hard power down boot. When I start the midlet (AT^SJAM=1 etc) the AT^SPOW reply drops to 0,0,0. Stopping the midlet, doing another hard boot, then the value is again 2,500,5. Seems to me that starting a midlet resets the SPOW reply to 0,0,0 but leaves the actual values at what ever they are.
Cinterion
EHS6
REVISION 02.000
A-REVISION 00.000.15
Hello Jure,
It seems that you have currently the latest firmware for BGS5.
If you have no problems with sending data without RTS/CTS flow control the power saving mode is not active as you have configured it to be not active. Just for some reason the answer is wrong when the MIDlet is working.
Hello JTIUSANE,
Generally the SPOW setting is non-volatile so whatever you set it should not change after reboot.
2,1000,3 is the default setting ad it should be set in a factory new module.
If you set 0,0,0 the communication should not work. If the power saving is active (for example 2,500,5 is set) the communication should still be possible if the HW flow control is used (or some pins have been hard-wired) but it may be slower.
It looks like the SPOW reply changes under Java but the real setting is preserved.
For EHS6 module there is the newer firmware version for release 2 and there is also release 3.
Regards,
Bartłomiej