Go Down

Topic: GSM "sleep" behaviour ? (Read 1 time) previous topic - next topic

jyaeger

I'm unclear and can find no documentation to support my supposition, but I get the impression that the GSM seems to go to sleep if not accessed over a period of time.

I do not know if this is true.  I also do not know what time parameters might be in play here.

Can anyone point me to any documentation that can clarify what the GSM module does when it is not accessed over the course of several hours or days?

FYI - I'm constructing a GSM connected animal feeder, and cannot seem to get the MKR GSM1400 to operate much past an hour or so.

Thanks in advance!

sandeepmistry

Hi @jyaeger,

Do you have a battery connected to the board?

Maybe you can share the sketch you are using too.

jyaeger

#2
Feb 15, 2018, 03:54 pm Last Edit: Feb 16, 2018, 10:04 am by jyaeger
Hi @jyaeger,

Do you have a battery connected to the board?

Maybe you can share the sketch you are using too.
Yes I have a 3.7v 3400mah connected thru a lipo rider that has 2 x 5v solar panels (in parallel).  The 1400 is connected to the lipo rider by way of the usb. Very similar to the photo at the bottom of the seeed wiki page. (wiki.seeed.cc/Lipo_Rider_V1.3/).

I've not started my sketch. I have created the outdoor physical contraption, and am only running the blink sketch, whilst monitoring the up-time throughout a day/night period - trying to make sure its going to charge and operate as intended.  Also, I have run several of the example sketches so as to start understanding the gsm capabilities.  I have not hooked up a sensor yet.

To be clearer - my concerns are two fold and not necessary related to one another.

1) Does the gsm module "sleep" automatically after a predetermined time period OR must one use gsmAccess.shutdown() method?  I would hope something like this is possible to conserve power when not messaging.

2) Am I connecting my power scheme correctly?  What are the JST connectors on the 1400 for?  should I be connecting to the header directly? Should the Lipo rider be abandoned in favour of any onboard charge controller?

I've searched for documentation of similar projects that I could reference, but there are not all too many yet using the 1400 in a manner that I intend (or at least I haven't found them).

rwilko

Hi @jyaeger,

Did you figure out about the gsm sleep mode? or is it the case to use shutdown?

Prof62

I the "sleep" might be coming from your service provider.

As I understand it GPRS connections time out and get dropped if there is no data transferred for an extended period. This is totally in the hands of the cell service provider an can vary but is typically a few hours.

One solution would be to send regular "keep-alive" requests (e.g ping a server) but this uses data which could prove expensive in the long term.

A clumsier, but effective, solution is to just perform a GPRS attach and/or GSM connect if you get an error when trying to establish an http client connection.

A better solution would be to check the connection status before attempting to send data and perfom a GPRS attach and, if necessary a GSM network reconnection as required. The AT+CIPSTATUS command could do this but I haven't found an easy way to do this yet.

Has anyone got the AT+CIPSTATUS method working?

mdunsford

"AT+CIPSTATUS?" is for a sim900 module.

The equivalent u-blox SARA-U2 command would be "AT+CGATT?".

I believe you can call it directly from your code like this:

Code: [Select]
 
String _response;

MODEM.send("AT+CGATT?");

if (MODEM.waitForResponse(180000, &_response) == 1) {

  //GPRS reports connected so do something with the link...
  client.connect(server, port);
 
  //...etc.

} else {

  //GPRS not connected so go back and attach GPRS again...
  gprs.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD);

  //...Now go back and check again.

}


The above snippet is a compilation of bits from my state based application so if if I get zero returned from CGATT? in my real code I just reset the stage to a point where I originally started GPRS. I also check for the base GSM access being alive and restart that if necessary:

Code: [Select]

#include "Modem.h"

int isGprsAttached()
{
  String _response;
  MODEM.send("AT+CGATT?");
  if (MODEM.waitForResponse(180000, &_response) == 1) {
    return _response.charAt(_response.length() - 1) - '0';
  }

  return 0;
}

Code: [Select]

case G_AWAIT_MESSAGE:
      if(messageAvailable()) {
        if(gsmAccess.isAccessAlive() ) {
          if(isGprsAttached()==1) {
            gsmState=G_CONNECT_CLIENT;
          } else {
            gsmState=G_ATTACH_GPRS;
          }
        } else  {
          gsmState=G_CONNECT_GSM;
        }
      }
      break;


(This is part of a routine that gets called once every time the main loop cycles.)

jyaeger

#6
Jun 23, 2018, 02:50 pm Last Edit: Jun 23, 2018, 03:31 pm by jyaeger
Interesting comments... I'll need to experiment a bit.

In the meantime - I have achieved a regular operation on the MKR1400 for about a month.  However, lately it seems to lock up every few days.  I suspect this might might be a mechanical sensor issue - so there is a slim chance that this is not related to sleep behaviour.

I think I have successfully solved my battery/solar load/power-supply issue. So that is not a problem.

I'm going to try implementing some additional monitoring and event flagging to see if I can narrow down my issue.

Stay tuned...

FYI: this application is a simple reed switch monitor that sends an SMS when open. Specifically when my Squirrel opens his feeding box lid.  Normally this works fine - but sometimes it just stops working altogether.  So... it could be a fault in the switch, or sleep mode, or idiot programmer.  I'm working on it...

EDIT: when I reset the MKR1400 sometimes it falls back to normal operation, and sometimes

jyaeger

ok... so this is not a sleep issue - the MKR1400 seems to work fine.  What I've discovered is a faulty electrical connector - once fixed, everything works perfectly.  Moral of the story - CHECK EVERYTHING!

Go Up