GSM-Shield ON/OFF

Hi,

I try to solve a strange problem, where I do not have an explanation.
With the following sketch I want to switch a GSM-shield ON (by triggering the according pin), and as it can be ON already and as I want to have it in a defined state, I should switch it off first.To accomplish this, I use the command “AT+CPOWD=0”.
My problem is now, that this works perfectly every other time, every second time the sketch pretends to have the shield switched on, but in reality it is still off.When I start the sketch again, the shield is really switched on.
I need to use the AT-Command, as the shield can be on already and triggering the power-pin once will switch it off.
Of course I can send an “AT” and depending on the response I can send one(i.e. there was no response, which means the shield is off) or two (i.e. there was a response and I have to switch the shield off and on again) trigger-commands, but I would like to know why my sketch in the present form does not work.
Just a remark: it’s an experimental sketch, so don’t worry about the naming.

Sketch:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3);
#define GSMONOffPIN 8                      // On/Off-pin of the GSM shield
 
void setup()
{
  mySerial.begin(9600);  
  Serial.begin(9600);               
  if (mySerial.available())     Serial.write(mySerial.read());
  if (Serial.available())       mySerial.write(Serial.read());
  mySerial.println("ATE0");
  mySerial.println("AT+CPOWD=0");
//  if (!mySerial.available())
//  {   
      GSM900PowerOn();                 // Power on GSM shield
      mySerial.begin(9600); 
//  }
}

void loop()
{
  if (mySerial.available())
    Serial.write(mySerial.read());
  if (Serial.available())
    mySerial.write(Serial.read());

}


void GSM900PowerOn()
{
    byte i=0;
    while (!mySerial.available())
    {
      pinMode(GSMONOffPIN, OUTPUT);
      digitalWrite(GSMONOffPIN, HIGH);
      delay(2000);
      digitalWrite(GSMONOffPIN, LOW);
      delay(3000);
    }
   Serial.println("Port " + String(GSMONOffPIN)+" switched on");
}

Output 1 (Shield is really switched on):

Port 8 switched on
ÿÿÿÿÿ
RDY
+CFUN: 1
+CPIN: SIM PIN
+CSQN: 28,0
+CSQN: 30,0

Output 2 (Shield stays switched off)

Port 8 switched on
ATE0
AT+CPOWD=0
OK
+CSQN: 0,0
NORMAL POWER DOWN

and again output 1 and again output 2 (I trigger the sketch by setting the Serial Monitor every time to 9600 Baud, so the sketch restarts)

I am also a bit astonished, that despite the “AT+CPOWD=0” the message “NORMAL POWER DOWN” appears - the parameter “0” should suppress this.

Any idea? Maybe I do not see the forest because of the trees (as there is a saying in Germany…)

Have a nice day

Piqueremy

  mySerial.println("ATE0");
  mySerial.println("AT+CPOWD=0");

It does so matter what the device responds with.

Turning the power on or off should NOT depend on the response to this command. You turned the power on. Remember that. You turned the power off. Remember that. NOTHING else can turn the power on or off, so there is no reason to have to ask the device if it is off or on.

Finally, it does NOT make sense to activate the SoftwareSerial instance AFTER you have used it to send commands.

You can also turn the modem off with the power control pin, but it is fiddly... ( i'm talking about a SIM5320 here)

Check the modem manual, otherwise, i do exactly what you do - testing for an OK response to AT\r to determine if the modem is already on.

The timing of the on/off pin and intervals is quite fussy.

OK,

but do you have an idea why the "AT+CPOWD=0" one time issues the "NORMAL POWER DOWN" and the other time not?

Are you ‘peeking’ in to monitor the modem commands and responses?

Perhaps there is an incomplete command that hasn’t been sent…?
e.g. ATD012345AT**+CPOWD=0\r**
i.e. between the 5 and the +

So the modem doesn’t see it…
I can think of any other reason.

Well,

I do not think that this might be the reason (btw - it's a SIM800). I restart the sketch everytime anew (by resetting the baudrate in Serial Monitor) - i.e. the sequence of commands is initialized and everytime the same - only the behaviour changes. Strange....