MKR GSM 1400 - Losing Connection to Thinger.io

Dear ALL
If I run the simple demo script from the thinger Homepage for GSM1400, Im able to connect the platform, but after a while or after 1-2 min I loose the connection again (see debuging serial monitor below).

It seems that system wanted to built up a connection again, than the serial monitoring is hanging

Using secure TLS/SSL connection: yes . It seems something is quite instable

Markus

[SIMCARD] GSM Network: 1
12:04:10.965 -> [___GPRS] Connecting to APN: telekom
12:04:10.965 -> [___GPRS] APN username: your_gprs_login
12:04:10.965 -> [___GPRS] APN password: your_gprs_password
12:04:13.113 -> [___GPRS] APN Connection suceed!
12:04:13.113 -> [NETWORK] Got IP Address: 10.51.186.132
12:04:13.113 -> [NETWORK] Connected!
12:04:13.113 -> [_SOCKET] Connecting to iot.thinger.io:25202
12:04:13.113 -> [_SOCKET] Using secure TLS/SSL connection: yes
12:04:19.949 -> [_SOCKET] Connected!
12:04:19.949 -> [THINGER] Authenticating. User: Markus1 Device: MKR1400
12:04:19.949 -> [THINGER] Writing bytes: 40 [OK]
12:04:20.333 -> [THINGER] Authenticated
12:04:20.612 -> [THINGER] Available bytes: 29
12:04:20.649 -> [THINGER] Writing bytes: 7 [OK]
12:04:20.686 -> [THINGER] Available bytes: 20
12:04:20.720 -> [THINGER] Writing bytes: 8 [OK]
12:04:20.753 -> [THINGER] Available bytes: 18
12:04:20.791 -> [THINGER] Writing bytes: 8 [OK]
12:05:06.121 -> [THINGER] Writing bytes: 2 [OK]
12:05:06.121 -> [THINGER] Available bytes: 2
12:05:29.942 -> [THINGER] Available bytes: 14
12:05:29.976 -> [THINGER] Writing bytes: 61 [OK]
12:05:31.131 -> [THINGER] Available bytes: 18
12:05:31.131 -> [THINGER] Writing bytes: 14 [OK]
12:05:31.589 -> [THINGER] Available bytes: 21
12:05:31.622 -> [THINGER] Writing bytes: 38 [OK]
12:05:31.656 -> [THINGER] Available bytes: 21
12:05:31.691 -> [THINGER] Writing bytes: 18 [OK]
12:05:35.460 -> [THINGER] Available bytes: 15
12:05:35.495 -> [THINGER] Writing bytes: 7 [OK]
12:05:37.993 -> [THINGER] Available bytes: 15
12:05:37.993 -> [THINGER] Writing bytes: 7 [OK]
12:05:39.110 -> [THINGER] Available bytes: 16
12:05:39.110 -> [THINGER] Writing bytes: 8 [OK]
12:05:40.442 -> [THINGER] Available bytes: 16
12:05:40.475 -> [THINGER] Writing bytes: 8 [OK]
12:06:00.995 -> [_SOCKET] Connecting to iot.thinger.io:25202
12:06:00.995 -> [_SOCKET] Using secure TLS/SSL connection: yes

Hello @Markus_Schmeckenbech,

This is a problem appears when the MKR tries to make a reconnection and it fails. I understand that Arduino’s developers have been working on it, so we’ll see if we can come up with a better solution.

Does the problem appear after upload a new sketch? or was exactly the same compilation and library versions? have you tried updating mkr libraries? or using an old one?

By the moment, the only way to solve it is detecting the disconnection and making a reset but I don’t know if this works well for your case, if you need to hold real time variables or similar. If you are interested on this, answer me and I will send you the source code to make this.

Hi @JorgeTrincado,
I’m interesting in the code that you says in te previous message, that it allows reset the arduino board when this problem appears

Hi @PeRSaMo,

Unfortunately, after looking for the code for a while I wasn’t able to find it. However, it is not difficult to implement using the client listener structure explained by @alvarolb on this post

something like this:

#include <ThingerMKRGSM.h>

#define USERNAME "your_user_name"
#define DEVICE_ID "your_device_id"
#define DEVICE_CREDENTIAL "your_device_credential"

#define PIN_NUMBER "your_pin"

#define GPRS_APN "your_apn_name"
#define GPRS_LOGIN "your_gprs_login"
#define GPRS_PASSWORD "your_gprs_password"

class ClientListener : public ThingerMKRGSM{
public:
    ClientListener(const char* user, const char* device, const char* device_credential) : 
      ThingerMKRGSM(user, device, device_credential){}
protected:
  virtual void thinger_state_listener(THINGER_STATE state){
    // call current implementation (debug)
    ThingerMKRGSM::thinger_state_listener(state);
    switch(state){
        case NETWORK_CONNECTING:
            break;
        case NETWORK_CONNECTED:
            break;
        case NETWORK_CONNECT_ERROR:
        //RESET THE PROCESSOR HERE
            break;
        case SOCKET_CONNECTING:
            break;
        case SOCKET_CONNECTED:
            break;
        case SOCKET_CONNECTION_ERROR:
            break;
        case SOCKET_DISCONNECTED:
            break;
        case SOCKET_TIMEOUT:
            break;
        case THINGER_AUTHENTICATING:
            break;
        case THINGER_AUTHENTICATED:
            break;
        case THINGER_AUTH_FAILED:
            break;
        case THINGER_STOP_REQUEST:
            break;
    }
  }
};

ClientListener thing(USERNAME, DEVICE_ID, DEVICE_CREDENTIAL);

void setup() {
  Serial.begin(115200);

  // optional set pin number
  thing.set_pin(PIN_NUMBER);

  // set APN
  thing.set_apn(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD);

  // set builtin led to output
  pinMode(LED_BUILTIN, OUTPUT);

  // pin control example over internet (i.e. turning on/off a light, a relay, etc)
  thing["led"] << digitalPin(LED_BUILTIN);

  // resource output example (i.e. reading a sensor value, a variable, etc)
  thing["millis"] >> outputValue(millis());

  // more details at http://docs.thinger.io/arduino/
}

void loop() {
  thing.handle();
}

I’m sure that if you execute a reset command (or wire up a gpio to RST pin to make reset when digitalWrite(pin,1); ) It should reset the PCB just when the connection is closed, but maybe this will produce a lot of resets if the PCB is moving between different antennas.

Hope it helps

Thanks @JorgeTrincado for your fast reply. I think that this structure go to work fine, but i have two questions:

  1. The ClientListener structure replace the ThingerMKRGSM structure?
    ThingerMKRGSM thing(USERNAME, DEVICE_ID, DEVICE_CREDENTIAL);

  2. The structure definition can be included in the sketch or it is mandatory included in the <MKRGSM.h> or <ThingerMKRGSM.h> libraries?

Thanks a lot and i will reply if it works this weekend whe i probe it
Luis

Hi @PeRSaMo,

1-yes the listener must replace the common object.
2-That code is the complete sketch, it is not necessary to modify the library

best!