search

arduino-libraries / MKRGSM

GNU Lesser General Public License v2.1
54 stars 51 forks source link

MKRGSM library not reliable #66

Open alanoatwork opened 5 years ago

alanoatwork commented 5 years ago

I've posted this before, but I'll try again. My code is pretty simple. I check for SMS messages and then reply back using Hologram's network. I'm using the latest MKRGSM library 1.3.1. I also have a 1400 mAhr lithium battery connected so I'm confident that I don't have a hardware issue related to modem current.

Here's my code:

#include <MKRGSM.h>
const char PINNUMBER[] = " ";
const char GPRS_APN[] = "hologram";
const char GPRS_LOGIN[] = " ";
const char GPRS_PASSWORD[] = " ";

String HOLOGRAM_DEVICE_KEY = "********";
String HOLOGRAM_TOPIC = "_SOCKETAPI_";

GSMClient client;
GPRS gprs;
GSM gsm(1);                                             // Enable debug
GSM_SMS sms;
GSMScanner scan;

char server[] = "cloudsocket.hologram.io";
int port = 9999;
boolean isSMSAvailable = false;
char sms_message[145];

void setup() {
  Serial.begin(115200);
  //while(!Serial);

  scan.begin();
  connectGSM();
}

void connectGSM() {
  boolean connected = false;

  while (!connected) {
    Serial.println("Begin GSM Access");

    if ((gsm.begin() == GSM_READY) &&
        (gprs.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD) == GPRS_READY)) {
      connected = true;
      Serial.println("GSM Access Success");
      Serial.println(scan.getCurrentCarrier());
    } 
    else {
      Serial.println("Not connected");
      delay(1000);
    }
  }
}

void loop() {
  if(Serial.available()) {
    char c = Serial.read();
    if(c == 'e')
       MODEM.debug();
    if(c == 'd')
         MODEM.noDebug();
  }

  // Get any new incoming txt messages
  int c;
  if (sms.available()) {
    int i = 0;
    while ((c = sms.read()) != -1) {
      sms_message[i++] = (char)c;
    }
    sms_message[i] = '\0';        // Terminate message
    isSMSAvailable = true;
    sms.flush();
  }

  if(gsm.isAccessAlive()) {
    if(gprs.status() != GPRS_READY) {
      if(gprs.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD) == GPRS_READY)
        Serial.println("GPRS ready!");
      else
        Serial.println("GRPS not ready!");
    }
  }
  else {
    Serial.println("Reconnect to GSM...");
    connectGSM();
  }

  // Send message back through hologram
  if(isSMSAvailable) {
    isSMSAvailable = false;

    if (client.connect(server, port)) {
      client.print("{\"k\":\"" + HOLOGRAM_DEVICE_KEY + "\",\"d\":\"");
      client.print(sms_message);
      client.println("\",\"t\":\""+HOLOGRAM_TOPIC+"\"}");
      client.stop();
    }
    else {
      MODEM.send("AT+USOER");
    }
  }

  delay(1000);
}`

It takes anywhere from a few days to a week or more to exhibit the problem. My logs typically look like this, where the incoming SMS message, "Jdjd", gets received and then repeated back to me via Hologram's network.

OK
AT+CMGL="REC UNREAD"

+CMGL: 19,"REC UNREAD","+19495472010",,"18/11/14,03:53:24+00"
Jdjd

OK
AT+CMGD=19

OK
AT+CREG?

+CREG: 0,5

OK
AT+USOCR=6

+USOCR: 0

OK
AT+USOCO=0,"cloudsocket.hologram.io",9999

OK
AT+USOWR=0,21,"7B226B223A22433E383375242B57222C2264223A22"

+USOWR: 0,21

OK
AT+USOWR=0,4,"4A646A64"

+USOWR: 0,4

OK
AT+USOWR=0,20,"222C2274223A225F534F434B45544150495F227D"

+USOWR: 0,20

OK
AT+USOWR=0,2,"0D0A"

+USOWR: 0,2

OK
AT+USOCL=0

OK
AT+CMGL="REC UNREAD"

OK
AT+CREG?

+CREG: 0,5`

However, after a week or so this happens:

`OK
AT+CMGL="REC UNREAD"

+CMGL: 19,"REC UNREAD","+19495472010",,"18/11/20,19:51:00+00"
JDJDJ

OK
AT+CMGD=19

OK
AT+CREG?

+CREG: 0,5

OK
AT+USOCR=6

+USOCR: 0

OK
AT+USOCO=0,"cloudsocket.hologram.io",9999

ERROR

+UUSOCL: 0
AT+USOCL=0

ERROR
AT+CMGL="REC UNREAD"

OK
AT+CREG?

+CREG: 0,5

OK
AT+CMGL="REC UNREAD"

OK
AT+CREG?

+CREG: 0,5

From then on, the library is never able to recover.

Any help would be greatly appreciated. The code I submitted is a stripped down version of my application. I've been wanting to release my application using the MKRGSM board but I've been haunted by this issue. I see there's some asynchronous options that aren't well documented and I'm reluctant to use this approach - besides, shouldn't this library be rock solid as documented!

pnndra commented 5 years ago

@alanoatwork the only change is the removal of the fuse which limits battery current. It's the fix we're also recommending to who purchased the boards before we issues this notice

eiriksels commented 5 years ago

@Rocketct Thanks for your testing on the board, and confirming the instabilities seen on the 2G network.

If I am interpreting your findings correctly it is not possible to rely solely on 1 power supply? I want to have the board supplied by battery, and I would prefer to only use 1 battery (my LiPo battery).

Your answer say that capacitors should be placed close to the input pins. Is this only for Vin or also for the dedicated battery input?

pnndra commented 5 years ago

@eiriksels it is possible to rely only on battery provided the battery is capable of delivering current peaks exceeding 2.5A. capacitors are needed on vin only if you're powering the board mainly from vin. note that the peak current depends on the C factor of the battery, not just on the capacity. for example a 1000mAH battery with C=3 would be fine while a 2500mAh with C=0.5 would not be ok.

JesseAtBlue commented 5 years ago

@Rocketct

I am experiencing the same problems as the original poster. I would like to follow up on your answers:

I hope to hear from you soon!

Rocketct commented 5 years ago

Hi @JesseAtBlue ,

gsm_bottom

JesseAtBlue commented 5 years ago

@Rocketct ,

Thank you for your quick reaction! I will try out the solutions you provided!

lounchy commented 5 years ago

@Rocketct you mentioned to raise VIN supply at at least 7v if it's possible. Is it safe? The shield documentation says: “ Vin: This pin can be used to power the board with a regulated voltage source rated at 5V. If the power is fed through this pin, the USB power source is disconnected. This is the only way you can supply MAXIMUM 5V to the board not using USB. This pin is an INPUT.”

I have a project that is waiting for incoming call, if caller is me(my phone number) it hangs up the call. While it is connected to network the led blinks every 3 seconds.

I am facing with a problem that after two days the shield doesn’t work as expected. It’s still connected to the network and I can call to it from my phone, but it doesn’t hang the call and led doesn’t blink anymore.

I am powering my project with 5V 2,5A -> VIN

Does the issue is because of power supply? Is it safe to raise up to 7V? Many thanks!

Rocketct commented 5 years ago

Hi @lounchy yes you can rise, but are you try to powering only with the Vin? is mandatory use a battery pack to calling's support!

lounchy commented 5 years ago

Hi @Rocketct, thank you for your response. Yes I am powering only with Vin and looks that I managed to make it working as expected. I am powering with 4.96V 2,5A . I am using watchdog, if GSM is available I am resetting watchdog, when GSM is not available anymore or board hangs the board is getting rebooted. From the moment I turned the board on it rebooted 1x and today I am on day 4. I don’t know if it is write way to do so, what do you think?

Rocketct commented 5 years ago

@lounchy the point is that the battery work as a big capacitor that prevent from drop of current, with the calling this increase the stability, avoiding drop due to excessive consumption, i think that the idea of the watch dog could prevent you from loose the control of the board in wait from a response of the module that never came, but as i say the use is mandatory in your application kind.

terrasmart commented 5 years ago

Hi @Rocketct, what you say above on the 5th June, at numbered item 3) << we're updating the variant for GSM1400 in the core so that default value is the lowest allowed voltage >>, is this already included in core 1.8.3 ?

Then, one clarification that I need: is that correct to say that I cannot get more then 1.5A at VIN input, unless I do not intervene on the R28 resistor (which limit VIN to 1.5A by fabric) ?

(post edit)

I have a 12V solar charge controller which output a stable 2.5A 5V from a USB port (like many of them do). If I read the specs of the BQ24195/L, they say that << The bq24195/bq24195L are compliant with USB 2.0 and USB 3.0 power specifications with input current and voltage regulation >>. Then, REG00 Register at the field IINLIM[0] can be " 111 – 3 A " , with a default of 1.5 A (101). So far I understand I can fed the Arduino at 3A even.

But, at 8.3.1.3.3 Input Current Limit Detection, I read << If the portable device is attached to a charging port, it is allowed to draw up to 1.5 A >>.

I'm confused. I do not understand what is the real limit in terms of Amperes of the USB input of BQ24195/L (means of the Arduino GSM).

(end post edit)

Really thanks for the great job you and all the other guys do, supporting this community and us customers / developers.

Rocketct commented 5 years ago

Hi @terrasmart, about:

what you say above on the 5th June, at numbered item 3) << we're updating the variant for GSM1400 in the core so that default value is the lowest allowed voltage >>, is this already included in core 1.8.3 ?

yes published, here the link: https://github.com/arduino/ArduinoCore-samd/commit/45163fae62e60fc7fdd37e1181498ccddb49fc08

about:

Then, one clarification that I need: is that correct to say that I cannot get more then 1.5A at VIN input, unless I do not intervene on the R28 resistor (which limit VIN to 1.5A by fabric) ?

yes is correct, depend on how you is set the input charge limit on the bq24195, the device compare and use the lower between ILIM pin (the input pin where connected the R28 resistor) and the the input current limit (in our board is set by default to 2A)

terrasmart commented 5 years ago

Hi @Rocketct, thank you for your response. Yes I am powering only with Vin and looks that I managed to make it working as expected. I am powering with 4.96V 2,5A . I am using watchdog, if GSM is available I am resetting watchdog, when GSM is not available anymore or board hangs the board is getting rebooted. From the moment I turned the board on it rebooted 1x and today I am on day 4. I don’t know if it is write way to do so, what do you think?

@lounchy watchdog topic is really interested topic and there are not good examples around. Sounds very good you are using it successfully. If appropriate, would you mind sharing some of your watchdog reset? I'm trying to implement also in my code, but struggling. many thanks much appreciated.

terrasmart commented 5 years ago

Hi @terrasmart, about:

what you say above on the 5th June, at numbered item 3) << we're updating the variant for GSM1400 in the core so that default value is the lowest allowed voltage >>, is this already included in core 1.8.3 ?

yes published, here the link: arduino/ArduinoCore-samd@45163fa

about:

Then, one clarification that I need: is that correct to say that I cannot get more then 1.5A at VIN input, unless I do not intervene on the R28 resistor (which limit VIN to 1.5A by fabric) ?

yes is correct, depend on how you is set the input charge limit on the bq24195, the device compare and use the lower between ILIM pin (the input pin where connected the R28 resistor) and the the input current limit (in our board is set by default to 2A)

got it. thank you @Rocketct for the reply.

terrasmart commented 5 years ago

Guys, sorry to write again, but I still need one clarification about this point, if you know that.

I have a 12V solar charge controller which output a stable 2.5A 5V from a USB port (like many of them do). If I read the specs of the BQ24195/L, they say that << The bq24195/bq24195L are compliant with USB 2.0 and USB 3.0 power specifications with input current and voltage regulation >>. Then, REG00 Register at the field IINLIM[0] can be " 111 – 3 A " , with a default of 1.5 A (101).

So far I understand I can fed the Arduino at 3A even, by USB 3.0 power source.

But, at paragraph 8.3.1.3.3 Input Current Limit Detection, I read << If the portable device is attached to a charging port, it is allowed to draw up to 1.5 A >>.

So I do not understand what is the real limit in terms of Amperes of the USB input.

alanoatwork commented 5 years ago

@terrasmart, the BQ24195/L, the spec says,

The actual input current limit is the lower value between ILIM setting and register setting REG00[2:0]). For example, if the register setting is 111 for 3 A, and ILIM has a 353-Ω resistor to ground for 1.5 A, the input current limit is 1.5 A. ILIM pin can be used to set the input current limit rather than the register settings.

Given that the resistor connected to ILIM is 330 ohms, the actual input current limit can be no greater than 1.6 A according to equation 3.

terrasmart commented 5 years ago

The more I use this product, the less I understand..

In this moment I have:

CASE 1) one MKRGSM with '3G only' mode selected by the use of , powered only by a common USB cable from my Macbook Pro (500 mA only says the Mac System Monitoring..). I have upload a test sketch to connect to the phone network, connect to gprs, then disconnect everything. Doing this in cycles of 2 minutes. RESULT: It's working since yesterday without any stop or hangs. Every cycles is done perfectly.

CASE 2) two MKRGSM with '3G only' mode, powered by VIN from a solar charge controller (5V, 3A) & USB cable connected to a solar charge controller (5V, 2A). More or less same sketch, with some sensors readings, 7 minutes of cycle, the sensors are powered from the solar charge controller and not from the Arduino. RESULT: they are working since more than 30 days, without stopping.

CASE 3) one MKRGSM with '3G preferred & 2G as failover' mode, powered by USB cable connected to a solar charge controller (5V, 2A) & LiPo battery 3,7V - 3000 mAh & VIN power (5V, 3A). More or less same sketch, with some sensors readings, 7 minutes of cycle, the sensors are powered from the solar charge controller and not from the Arduino. RESULT: it worked for 7-8 days, then it drained completely the LiPo battery and hanged while connecting to phone network.

CASE 4) one MKRGSM with '3G preferred & 2G as failover' mode, powered by USB cable connected to a solar charge controller (5V, 2A) & LiPo battery 3,7V - 3000 mAh. More or less same sketch, 5 minutes of cycle, with some sensors readings, the sensors are powered from the solar charge controller and not from the Arduino. RESULT: It worked for less than 48 hours, then stopped. I still have to check it, but I suspect it may have drained again the battery like CASE 3.

Many questions come to my mind..

for example..

For CASE 4) if the problem is the battery been drained, why it does not connect just using the USB cable like the CASE 1 ??

For CASE 3) why the battery has been drained if the core version is the latest one ??

etc etc

eiriksels commented 5 years ago

@terrasmart Your observations are exactly the same as mine. I have not been able to run it stable on 2G.

For your CASE 2 and 4 it probably failed when trying to fall over to 2G. I thought that if you power the board in the microUSB connector you will not be able to supply the board with more than 500 mA, even if your supply power is more than that:

"During cellular transmissions the peak current required by the board will exceed 500mA. This is in excess of what can sourced by a standard USB port, so it's mandatory to have a 1500mAh or higher LiPo battery plugged all the time." from mouser.com/new/arduino/arduino-mkr-gsm-1400/

My experience when trying to run the board on 2G is that the serial communication to the modem freezes, and the board becomes unresponsive because the serial hangs.

Because 3G has now almost completely shut down in my country, I have given up the use of this module for my project. I have not yet heard of anyone been able to run this module when locked to 2G network.

terrasmart commented 5 years ago

@eiriksels yes.. I struggling myself also in using this product and I'm thinking about giving up with MKR GSM for my project..

I thought that if you power the board in the microUSB connector you will not be able to supply the board with more than 500 mA, even if your supply power is more than that:

Yes, this is not clear to me also. I do not understand what is the maximum current mA I can supply through USB input. I asked this previously but no answer. I do not understand what is the real limit in terms of Amperes of the USB input with this board.

@alanoatwork the ILIM 1,6A you say, it is valid also for the USB input ?

@eiriksels you very likely are right. The real limit from USB input is less than 1.5A.. For the CASE 4, I think the battery has been drained again (so the problem of LiPo recharging is not solved even with the latest core 1.8.3) and the U-201 has fallen back to 2G (for some reasons, do not why and how..) and the MKR has stopped because hanged while trying to connect with only the USB cable input.

I think there are some serious issues (you Arduino team guys will have to forgive me, you are doing a great job supporting us, but I think this product has serious limits..):

a) power management by BQ24195L: the LiPo battery completely drained, even with 2 alternate power sources connected, is a serious issue. It has been said this should be corrected with the latest core 1.8.3 version. I wonder if the same issue happens with the MKR 1000 where the power is managed by MCP78730 (I do not have MKR 1000 projects with LiPo, since the USB power source is enough to do everything).

b) "3G preferred & 2G as failover" mode: It's not clear to me how this mode works. I'm using MKR in a place where 4G is always present. So, it should run always with 3G.. Is there really a 2G fallback in an area where 4G is always present ? If yes, why ? What's the philosophy behind? Is it a problem of SARA U-201 ? Is it a problem also of SARA U-270 ? Do I need to absolutely restrict the use to 3G only ?

There some boards based on 2G SimCom SIM800E module which consumes around 500 mA as peak and can work even with only the USB cable.

It seems the SARA U family has a higher power consumption. May be yes, may be not.

terrasmart commented 5 years ago

Sorry I forgot to say

I had also another case experimented of MKR hanged:

CASE 5) one MKRGSM with '3G only' mode, powered by VIN from a solar charge controller (5V, 3A) & USB cable connected to a solar charge controller (5V, 2A). Same power supply as CASE 2. More or less same sketch, with some sensors readings, 5 minutes of cycle, the sensors are powered from the solar charge controller and not from the Arduino. RESULT: it worked for around 20-25 days, then stopped.

I have experimented almost all the possible configuration, I think..

Rocketct commented 5 years ago

@terrasmart i'll investigate over the cases you list, about the current limit, as @alanoatwork wrote, the current is limited by the pmic in terms of upper limits, if you supply only from USB (depends which version, for a usb 2.0- 500 mA) not make nothing. the point change when you supply with current or/and battery higher then 1.5 A, for how is build the board, he limit the current to 1.5 A, and doesn't mater the source(vin usb battery) what change are the pmic operations in terms of powering. Now when in 2g we suggest to remove this current limit by a h/w patch, the famous R28 showed before, this because is it that limit the current to 1.5 A(is the input of the ILIM pin on pmic) depends with one you replace the limit could be defined or by the register 0x00 the input_source register of the pimc or the, exactly, ilim pin that i talk before.

Rocketct commented 5 years ago

@terrasmart i'm looking also over another issue and i have a question for you, when the board freeze (in 3g mode only) have you notice if the led of charging start to blinking constant with a period of 1 sec more or less or however slowly?

terrasmart commented 5 years ago

@Rocketct many thanks for your kind reply and support.

So if I have a USB power source rated 1.2A max (as my solar charge controller has) and I connect a suitable USB cable to the MKR (as the cable I'm using which is 2.4A rated) I should be able to supply the MKR with all the Amperes I can get from the USB power source (here, 1.2A), up the upper limit of MKR which is always 1.5A. Correct ?

My firm points of analysis in this moment are:

a) in "3G only" the MKR works much much better and can do a basic connect/disconnect cycle even when powered only by USB 2.0 power source (500 mA !) such as my laptop port. I have tested this only with MKR powered and no other devices powered, but if I can get all the Amperes I can from the USB input (up to 1.5A) I should have more room even for other devices sub-powered by MKR by VCC output (example), such as some small sensors I have (3 - 30V) which draw around 50 mA each. I want to do more tests and try connecting also the sensors.

b) in "2G only" & power by USB only, the MKR hangs at the first cycle.

c.1) in "2G only" & power by USB only & WatchDog (16 sec, activated around GSM.begin and GPRS.attach calls), it hangs and the Watchdog resets and sometimes the cycle after the reset the MKR is able to complete the GSM.begin (but not the GPRS.attach).

c.2) in "3G preferred & 2G fallback" & power by USB only, there is no problem. The MKR does all the cycles, even if it is slower than "3G only". The connection take some seconds more (which is another problem because I cannot use the 16 sec WatchDog because it would reset). But the connection is ok.

d) in "3G only" & powered by VIN & USB cable, it may hangs.

e) in "3G preferred & 2G fallback" & power by VIN & USB cable, it may hangs.

f) with USB + LiPo, there are no issues until the battery is up, in all the modes. Then, the battery may be drained. It happened to me twice.

@Rocketct in the case "3g only", yes, when I have opened the box I found the charge LED was blinking someway. This happened to me also in the other case of hanging ("3G preferred & 2G fallback" + VIN & USB cable): when I have opened the box the charge LED was blinking someway.

One question: are the VIN and the USB mutual exclusive such as with the MKR 1000 with the MCP73830 charging module? It may be the problem the fact that VIN and USB are used together ?

Rocketct commented 5 years ago

are the VIN and the USB mutual exclusive such as with the MKR 1000 with the MCP73830 charging module? It may be the problem the fact that VIN and USB are used together ?

this should be the normal behaviour i mean the pmic should work as dinamic mode section 8.3.2.2 of the bq24195 datasheet and no should manage autonomously the charge, discharge and the power source in accord with the value set on the properly register.

So if I have a USB power source rated 1.2A max (as my solar charge controller has) and I connect a suitable USB cable to the MKR (as the cable I'm using which is 2.4A rated) I should be able to supply the MKR with all the Amperes I can get from the USB power source (here, 1.2A), up the upper limit of MKR which is always 1.5A. Correct ?

yes should be correct

terrasmart commented 5 years ago

this should be the normal behaviour i mean the pmic should work as dinamic mode section 8.3.2.2 of the bq24195 datasheet and no should manage autonomously the charge, discharge and the power source in accord with the value set on the properly register.

Ok..

Let me make some more considerations:

a) The BQ24195 uses power sources that are connected to VBUS pin. If I look at the MKR GSM diagram (MKRGSM_V2.2_sch.pdf), in the first page there is a VBUS power line from the USB port, but in the second page I do not see anymore this line, and the only input connection to VBUS pin of the BQ24195 appears to be only the VIN line. Is it a misprint ? Or it's me I do not see that..

b) Looking at the datasheet of another 3G/2G board in the market which uses the same BQ24195, they say USB and VIN are mutual exclusive: "When the XXXXX is powered via the USB port, this pin will output a voltage of approximately 4.8VDC due to a reverse polarity protection series Schottky diode between VUSB and VIN".

So, at this point, I believe the usual configuration of BQ24195 should be or USB or VIN.

This means my tests with USB & VIN together are useless (MKR is using only one) or - even worse - this is creating issues.

So my doubt is: there may be a problem in the VIN/USB management in the MKR GSM ?

Trying to find a reason why in my field tests, MKR GSM hanged in "3G only" when powered by VIN (5V, 3A) & USB (5V, 2A). There had to be no specific reason for hanging. But when powered only by USB it works, so.. the double connection created the problem ?

Trying also to find a reason why in my field tests with LiPo & USB, the battery drained and not been charged.

terrasmart commented 5 years ago

Hello.

Some update.

Since yesterday my MKR GSM is in a bad mood.. It's not connecting anymore, even in 3G only, in any available mode, both USB only and with USB + LiPo (3000 mAh).

Same sketch like other days.

It does not hang but it keeps doing AT+CREG without connecting to network.

When Lipo is connected, the CHARGE led is fixed on (not blinking).

I give up.

Rocketct commented 5 years ago

@terrasmart the charge led behaviour its ok:

It does not hang but it keeps doing AT+CREG without connecting to network.

the behaviour follow also after a hard reset of the board?

There had to be no specific reason for hanging. But when powered only by USB it works, so.. the double connection created the problem ?

i'm trying to find some explanation on the PMIC datasheet, in some test that i make, what i had experienced is that like you the board discharge the battery and when the battery is discharged, what also i found that is respected is the batfeet management (when led is turned off), would you like to check if some pmic fault rise? fault register (REG09) on the BQ21195

i'll follow to check to response to your doubt.

terrasmart commented 5 years ago

the behaviour follow also after a hard reset of the board? Yes it does, I have tried multiple hard resets. It was working since two days ago.

pnndra commented 5 years ago

Hi, let me summarize a few points to get everyone in sync on what has been stated so far: 1) when working in 2G mode the modem will require very strong current peaks. these peaks can be as high as 2A and can have as much as a duty cycle of 50%. this basically means that current to the modem is highly dependent on network status, including GPRS Class being used. if you're curious about this check paragraph 1.5.1.2 of https://www.u-blox.com/sites/default/files/SARA-G3-U2_SysIntegrManual_%28UBX-13000995%29.pdf 2) power input to the board is fed to VBUS pin of BQ24195L via a diode or of the VBUS from USB connector and VIN from headers. 5V from USB are basically straight whereas VIN is passing through a diode so it will be subtracted by Diode forward voltage 3) the max current that can be input on VBUS pin of BQ24195L is limited by the resistor on ILIM. this is set to 330hm which give more or less 1.6A at the input voltage. considering 80% efficiency, and considering that we're powering modem at 3.8V, input current limit is basically the same as output current so this current is clearly not enough for 2G networks, especially if going for higher duty cycles. regardless of this, if you connect the board to a PC with USB 2.0 likely you're being limited by the current the port can provide (500mA) so this would be a no go. 4) the additional battery we recommend will be limited by the fuse F2 which has a low current rating and since this is basically a PTC, it will behave differently at different ambient temperatures. we recommend to short this for 2G operation 5) due to the fact that steep current rise is slowed down by cable inductance and voltage is limited by cable resistance it's very important to have thick and short cables to bring power to the board. a "normal" usb cable may just not be the right choice to power the board also because for example max current handled by micro usb connector is 1.8A. max current handled by battery connector is 2A and max current handled by headers is more than 4A. this basically means that not only cable but also connector is a bottleneck and it's important to understand that even if you have a supply capable of a lot of current it may not be able to regulate quickly enough to sustain the huge change in current as it's going to pass from almost 0 to 2A and then back to 0 in just 576.9 µs, so with a rise time of very few µs. if the power supply or the cabling is not able to support such rise times the voltage on the board side will have a drop and that may trigger the brownout reset of the charger or cause modem lockup. this basically means that you should carefully check with a scope the power line at the board and verify there is no significant drop during transmission slots. the only way to fix this is either providing a power supply with fast regulation or add significant capacitance as close as possible to pins. @Rocketct recently released a new version of the bootloader that changes brownout reset threshold to a lower level that is still safe for operation that provides some extra margin to prevent resets but keep in mind this is NOT the solution to poor power supply. 6) if the battery drains it means that the current it's providing to the modem is more than it is being recharged so it must mean that, if charger is set up properly, your average current consumption is higher than the current you're supplying the board... good reason to explain why the board is not working without the battery. 7) if the battery is drained part of the current being handled by the charger will go to the battery. this means that if the current limit from VUSB is 1.6A and for example you set 2A charge current (see register REG02, which defaults to 0x60, 2A), then basically all input current will be sent to the battery and there will be nothing left for the modem, if the input voltage is around 5V. using a VIN higher than 5V helps because charger supports up to 17V and since the charger works in buck mode when charging,an input current of 1.6A at 10V means 16W which also mean that at 3.8V it can source more than 4A.

NOTE: edited adding more points and considering conversion efficiency on point 3.

terrasmart commented 5 years ago

@pnndra thanks a lot for your clarification. For what concerns my project, I will give up the 2G connectivity and I will work only in '3G only' mode. 2G too much difficult for me, to power manage.

Please forgive me, I don't want to be brutal, but I'm running a commercial start-up and it's a matter of profit or not, the WiFi connectivity is successfully based on the MKR 1000 but the GSM monitoring is based on this board, and I'm having hard times with my clients, trying to let the systems work consistently. I need a device which is ready to use, I cannot modify removing parts, soldering, etc.

So, I need now to understand what's the most stable powering configuration for working in 3G. The real operative requirements in terms of power supply in 3G mode.

Please consider my systems are '12V rated', solar powered (12V panel, 20 or 30W) with 10A or 20A solar charge regulator and a 12V battery (12 - 15Ah for the smaller monitoring box and 30Ah for the weather stations). The battery is the main power supply. The solar charge controller has a USB output (rated 5V - 1.2A) and one LOAD output rated same like the power circulating (12V 10A or 12V 20A depending on the rating of the controller). I believe with this devices, with 12V and 12 - 15 Ah (even more with the 30Ah..) to have all the Volts & Amperes I should need to power the MKR and all the other devices of monitoring station (moisture sensors, temperature sensors, etc). So I just to need to understand the most suitable powering scheme.

POST EDIT: the average load of our monitoring systems is usually around 200 - 250 mA. Talking about moisture sensors, temperature sensors, stuff like that. Such sensors can be powered at 5V, so we use a 12V/5V converter to power them by the LOAD output of the solar charge controller. I do readings of sensors every 5 or 7 minutes, in the between I shut down the WiFi or 3G connection to save power.

terrasmart commented 5 years ago

if the battery is drained part of the current being handled by the charger will go to the battery. this means that if the current limit from VUSB is 1.6A and for example you set 2A charge current (see register REG02, which defaults to 0x60, 2A), then basically all input current will be sent to the battery and there will be nothing left for the modem, if the input voltage is around 5V. using a VIN higher than 5V helps because charger supports up to 17V and since the charger works in buck mode when charging,an input current of 1.6A at 10V means 16W which also mean that at 3.8V it can source more than 4A

Would a 7,5V 3A to VIN + LiPo 3000 mAh be enough to do the job ? Or I risk to drain the battery ?

I have a 12V -> 7,5V 3A regulator I can use (Dynamic response speed: 5% 200uS, according to the producer)

salvq commented 4 years ago

This is my settings and I am getting very stable GSM connection, running several days without any reconnect or drop off on UMTS (3G). Connected to MS azure via MQTT protocol, msg send every 20 secs.

This is my settings for Modem.cpp

I am using baudrate 460800 ModemClass MODEM(SerialGSM, 460800, GSM_RESETN, GSM_DTR);

and delay increse to 200ms

if (_baud > 115200) {
    sendf("AT+IPR=%ld", _baud);
    if (waitForResponse() != 1) {
      return 0;
    }

    _uart->end();
    delay(200);
    _uart->begin(_baud);

Using Lion battery(1500mAh) and 24V/36W power supply with 5V output / 2A of continuous current with peak loads of 3A (<1sec), step down regulator LT8609S from 24V DC.

terrasmart commented 4 years ago

@salvq thanks for sharing ! Are you experiencing any issues with battery recharging ?

By the way, what happens to MKR 1400 ? Is not available any more in the Arduino store. New version incoming ? Or a new different product .. ?

salvq commented 4 years ago

@terrasmart, to be honest not sure if any issue with battery recharging, how do you check the status of battery, voltage or any other way ? I may add routine and let you know afterwards.

I am using mouser and they do have a stock and also mention 3 weeks stock in time so seems to be still available.

terrasmart commented 4 years ago

@salvq, thanks for the kind reply, very good to know Mouser still has stock.

Meanwhile I was analyzing your set-up of your previous post. In SARA U2 series Autobauding is enabled by default as I see in the Datasheet. While debugging GSM connection of MKR with the 'true' option, I see my MKR is autobauding at max rate 921600 bit/s by AT+IPR command.

However, AT commands Manual says that baud rate 460800 and 921600 b/s cannot be automatically detected by DCE and must only be set as a fixed rate (via +IPR AT command). This means that AT+IPR=921600 command is given by the MKRGSM library ?

You are (manually?) selecting a baud rate of 460800 ? If yes, what's exactly the philosophy behind this choice ? Do you think or tested the UART data rate can be an issue ? UART Interface is mainly responsible for Data lines (RXD as output, TXD as input), hardware flow control lines (CTS as output, RTS as input), modem status and control lines (DTR as input, DSR as output, DCD as output, RI as output).

About the delay(200): I understand this gives more time between UART ending and starting again. Do you think or tested this operation can be an issue ?

salvq commented 4 years ago

@terrasmart as far as I can see I have not checked MKRGSM library so closely but there is a setup in Modem.cpp file ModemClass MODEM(SerialGSM, 460800, GSM_RESETN, GSM_DTR); where you can set your default baud rate. Yes +IPR command is given by MKRGSM library when baud rate is higher then 115200 (it is visible on above code).

Well to be honest I was trying whatever to make the unit stable therefore tried to slow down baud rate. Unit is now stable but not sure if this is related to lower baud rate.

With regards to delay, yes I had several problems with changing baud rate on unit start up from default 115200, this is when the IPR command is not triggered.

From time to time when I have default baud rate (921600) or current (460800) unit at the beginning tried to set baud from 115200 to 921600 / 460800 unit got stucked. Now no hangsup when making restart and script making change of baudrate. Also could be linked to ArduinoHandler library issue which I was also using in paralel with MKRGSM library.

What about the battery, how to check the status such as being charged, or charged or loe power etc. ?

terrasmart commented 4 years ago

@salvq Ok, noted. Baud rate has also been previously mentioned in another topic by @FrancMunoz if I remember well. Wondering if he has some updates or other information.

About the battery, I'm currently reading LIPO voltage successfully (so far..) with this portion of code:

/*
  Read and print LiPo battery voltage
*/
float ReadVoltage()  {
  int pinValue = analogRead(ADC_BATTERY);        // read the input on analog pin 0
  float voltage = pinValue * (4.3 / 1023.0);     // Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 4.3V)
  Serial.print("LiPo battery voltage is: ");
  Serial.println(voltage);                       // print out the value you read
  return voltage;
}

then I do a check at the very beginning of the program to check LIPO, if voltage is not enough then I send device to sleep using Adafruit_SleepyDog library: 

/*
  Battery saving function
*/
void FuelCheck()
{
  if (ReadVoltage() < 3.7)                                                       // If the battery level is below 3.7V
  {
    Serial.println("Not enough LiPo battery, I will go to sleep for 1 hour");
    mySleep(225);                                                               // go to sleep for 1 hour
  } else Serial.println("Lipo ok.");
}
terrasmart commented 4 years ago

My sleep function is very simple:

#include <Adafruit_SleepyDog.h>

/*
   Sleep function
*/
void mySleep (int SleepCycles) {

  /*
    SleepCycles: 8->2min, 19->5min, 30->8min, 45->12min, 56->15min, 75->20min, 225->60min
  */

  int i;

  for (i = 1; i <= SleepCycles; i++)
  {
    SysTick->CTRL &= ~SysTick_CTRL_TICKINT_Msk;         // Disable systick interrupt
    Watchdog.sleep(16000);                              // Sleep for up to 16 second.
    SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk;          // Enable systick interrupt
    timeLoop(millis(), 100);                            // Little delay after wake-up, before the next sleep
  }
}

I do not use delay() to delay, but this function which does not halt the program:

/*
  Time delay using CPU and not delay
*/
void timeLoop (long int startMillis, long int interval) {
  while (millis() - startMillis < interval) {}
}
terrasmart commented 4 years ago

@salvq I disable systick interrupt since this is known to prevent sometimes the SAMD21 to wake up from deep sleep. I have personally experienced this issue. Solution has been mentioned here: https://forum.arduino.cc/index.php?topic=620634.0

salvq commented 4 years ago

@terrasmart thanks for the code.

Now I am making test without even battery (connected to 3G only). I would like to not use battery at all in production setup (extra cost, assembly, risk of fire etc.).

  1. Have you ever made any test with vs. without battery for 3G ?
  2. Also do you use asynchronous mode for attaching to the GSM network and attachGPRS ?

I am thinking about moving out from sync mode and switch to asyn mode to have better control of script, run some routine in the meantime and avoid possible issues with sketch hangs up (I do think that most my hangs up are related to sketch hangs due to never ending loops) and using watch dog is just not the best way (loosing window of data capture until unit gets restarted and settled back to network).

pnndra commented 4 years ago

Hi, depending on how strong is your signal and if you're on 2G or 3G you may want to check R28, connected to ILIM pin of the BQ24195. the current resistor is 330 ohm and limits current from USB to 1.6A. since there's a DC-DC converter that steps down from 5v to 3.8V, the max current to the modem would be around 2A to which you would have to subtract the current going to the rest of the board. if your application requires more current (if you use 2G it's likely to be more) you should change that resistor to prevent current limit and this will also allow you to get rid of the battery. from BQ24195 data sheet current limit is set to ILIM=530/R28.

salvq commented 4 years ago

@pnndra got it, thanks.

Change means lower the resistor value or even make the shortcut ?

Also today, unit was running for ~ 24 hours (PSU with 5V/2A up to 3A ~1s peaks, without battery) and then just hangs up...not even possible to debug such a fail, sometimes unit is running 3 days..this is very random, could it be related to this resistor ?

19:56:30.462 -> +USORD: 0,0,""
19:56:30.462 -> 
19:56:30.462 -> OK
19:56:30.496 -> AT+USORD=0,512

19:56:30.496 -> +USORD: 0,0,""
19:56:30.496 -> 
19:56:30.496 -> OK
19:56:30.530 -> AT+USORD=0,512

19:56:30.530 -> +USORD: 0,0,""
19:56:30.530 -> 
19:56:30.530 -> OK
19:56:30.530 -> AT+USORD=0,512

19:56:30.530 -> +USORD: 0,0,""
19:56:30.530 -> 
19:56:30.530 -> OK
19:56:30.565 -> AT+USORD=0,512

19:56:30.565 -> +USORD: 0,0,""
19:56:30.565 -> 
19:56:30.565 -> OK
19:56:30.599 -> AT+USORD=0,512

19:56:30.599 -> +USORD: 0,0,""
19:56:30.599 -> 
19:56:30.599 -> OK
19:56:30.632 -> AT+USORD=0,512

19:56:30.632 -> +USORD: 0,0,""
19:56:30.632 -> 
19:56:30.632 -> OK
19:56:30.632 -> AT+USORD=0,512

19:56:30.632 -> +USORD: 0,0,""
19:56:30.632 -> 
19:56:30.632 -> OK
19:56:30.666 -> AT+USORD=0,512

19:56:30.666 -> +USORD: 0,0,""
19:56:30.666 -> 
19:56:30.666 -> OK
19:56:30.701 -> AT+USORD=0,512

19:56:30.701 -> +USORD: 0,0,""
19:56:30.701 -> 
19:56:30.701 -> OK
19:56:30.701 -> AT+USORD=0,512

19:56:30.701 -> +USORD: 0,0,""
19:56:30.701 -> 
19:56:30.701 -> OK
19:56:30.736 -> AT+USORD=0,512

19:56:30.736 -> +USORD: 0,0,""
19:56:30.736 -> 
19:56:30.736 -> OK
19:56:30.770 -> AT+USORD=0,512

19:56:30.770 -> +USORD: 0,0,""
19:56:30.770 -> 
19:56:30.770 -> OK
19:56:30.804 -> AT+USORD=0,512

19:56:30.804 -> +USORD: 0,0,""
19:56:30.804 -> 
19:56:30.804 -> OK
19:56:30.804 -> AT+USORD=0,512

19:56:30.804 -> +USORD: 0,0,""
19:56:30.804 -> 
19:56:30.804 -> OK
19:56:30.837 -> AT+USORD=0,512

19:56:30.837 -> +USORD: 0,0,""
19:56:30.837 -> 
19:56:30.837 -> OK
19:56:30.872 -> AT+USORD=0,512

19:56:30.872 -> +USORD: 0,0,""
19:56:30.872 -> 
19:56:30.872 -> OK
19:56:30.872 -> AT+USORD=0,512

19:56:30.872 -> +USORD: 0,0,""
19:56:30.872 -> 
19:56:30.872 -> OK
19:56:30.906 -> AT+USORD=0,512

19:56:30.906 -> +USORD: 0,0,""
19:56:30.906 -> 
19:56:30.906 -> OK
19:56:30.941 -> AT+USORD=0,512

19:56:30.941 -> +USORD: 0,0,""
19:56:30.941 -> 
19:56:30.941 -> OK
19:56:30.976 -> AT+USORD=0,512

19:56:30.976 -> +USORD: 0,0,""
19:56:30.976 -> 
19:56:30.976 -> OK
19:56:30.976 -> AT+USORD=0,512

19:56:30.976 -> +USORD: 0,0,""
19:56:30.976 -> 
19:56:30.976 -> OK
19:56:31.009 -> AT+USORD=0,512

19:56:31.009 -> +USORD: 0,0,""
19:56:31.009 -> 
19:56:31.009 -> OK
19:56:31.042 -> AT+USORD=0,512

19:56:31.042 -> +USORD: 0,0,""
19:56:31.042 -> 
19:56:31.042 -> OK
19:56:31.076 -> AT+USORD=0,512

19:56:31.076 -> +USORD: 0,0,""
19:56:31.076 -> 
19:56:31.076 -> OK
19:56:31.076 -> AT+USORD=0,512

19:56:31.076 -> +USORD: 0,0,""
19:56:31.076 -> 
19:56:31.076 -> OK
19:56:31.109 -> AT+USORD=0,512

19:56:31.109 -> +USORD: 0,0,""
19:56:31.109 -> 
19:56:31.109 -> OK
19:56:31.143 -> AT+USORD=0,512

19:56:31.143 -> +USORD: 0,0,""
19:56:31.143 -> 
19:56:31.143 -> OK
19:56:31.143 -> AT+USORD=0,512

19:56:31.143 -> +USORD: 0,0,""
19:56:31.143 -> 
19:56:31.143 -> OK
19:56:31.177 -> AT+USORD=0,512

19:56:31.177 -> +USORD: 0,0,""
19:56:31.177 -> 
19:56:31.177 -> OK
19:56:31.211 -> AT+USORD=0,512

19:56:31.211 -> +USORD: 0,0,""
19:56:31.211 -> 
19:56:31.211 -> OK
19:56:31.245 -> AT+USORD=0,512

19:56:31.245 -> +USORD: 0,0,""
19:56:31.245 -> 
19:56:31.245 -> OK
19:56:31.245 -> AT+USORD=0,512

19:56:31.245 -> +USORD: 0,0,""
19:56:31.245 -> 
19:56:31.245 -> OK
19:56:31.279 -> AT+USORD=0,512

19:56:31.279 -> +USORD: 0,0,""
19:56:31.279 -> 
19:56:31.279 -> OK
19:56:31.313 -> AT+USORD=0,512

19:56:31.313 -> +USORD: 0,0,""
19:56:31.313 -> 
19:56:31.313 -> OK
19:56:31.313 -> AT+USORD=0,512

19:56:31.313 -> +USORD: 0,0,""
19:56:31.313 -> 
19:56:31.313 -> OK
19:56:31.348 -> AT+USORD=0,512

19:56:31.348 -> +USORD: 0,0,""
19:56:31.348 -> 
19:56:31.348 -> OK
19:56:31.383 -> AT+USORD=0,512

19:56:31.383 -> +USORD: 0,0,""
19:56:31.383 -> 
19:56:31.383 -> OK
19:56:31.416 -> AT+USORD=0,512

19:56:31.416 -> +USORD: 0,0,""
19:56:31.416 -> 
19:56:31.416 -> OK
19:56:31.416 -> AT+USORD=0,512

19:56:31.416 -> +USORD: 0,0,""
19:56:31.416 -> 
19:56:31.416 -> OK
19:56:31.450 -> AT+USORD=0,512

19:56:31.450 -> +USORD: 0,0,""
19:56:31.450 -> 
19:56:31.450 -> OK
19:56:31.483 -> AT+USORD=0,512

19:56:31.483 -> +USORD: 0,0,""
19:56:31.483 -> 
19:56:31.483 -> OK
19:56:31.517 -> AT+USORD=0,512

19:56:31.517 -> +USORD: 0,0,""
19:56:31.517 -> 
19:56:31.517 -> OK
19:56:31.517 -> AT+USORD=0,512

19:56:31.517 -> +USORD: 0,0,""
19:56:31.517 -> 
19:56:31.517 -> OK
19:56:31.550 -> AT+USORD=0,512

19:56:31.550 -> +USORD: 0,0,""
19:56:31.550 -> 
19:56:31.550 -> OK
19:56:31.584 -> AT+USORD=0,512

19:56:31.584 -> +USORD: 0,0,""
19:56:31.584 -> 
19:56:31.584 -> OK
19:56:31.584 -> AT+USORD=0,512

19:56:31.584 -> +USORD: 0,0,""
19:56:31.584 -> 
19:56:31.584 -> OK
19:56:31.617 -> AT+USORD=0,512

19:56:31.617 -> +USORD: 0,0,""
19:56:31.617 -> 
19:56:31.617 -> OK
19:56:31.650 -> AT+USORD=0,512

19:56:31.650 -> +USORD: 0,0,""
19:56:31.650 -> 
19:56:31.650 -> OK
19:56:31.684 -> AT+USORD=0,512

19:56:31.684 -> +USORD: 0,0,""
19:56:31.684 -> 
19:56:31.684 -> OK
19:56:31.684 -> AT+USORD=0,512

19:56:31.684 -> +USORD: 0,0,""
19:56:31.684 -> 
19:56:31.684 -> OK
19:56:31.719 -> AT+USORD=0,512

19:56:31.719 -> +USORD: 0,0,""
19:56:31.719 -> 
19:56:31.719 -> OK
19:56:31.753 -> AT+USORD=0,512

19:56:31.753 -> +USORD: 0,0,""
19:56:31.753 -> 
19:56:31.753 -> OK
19:56:31.753 -> AT+USORD=0,512

19:56:31.787 -> +USORD: 0,0,""
19:56:31.787 -> 
19:56:31.787 -> OK
19:56:31.787 -> AT+USORD=0,512

19:56:31.787 -> +USORD: 0,0,""
19:56:31.787 -> 
19:56:31.787 -> OK
19:56:31.822 -> AT+USORD=0,512

19:56:31.822 -> +USORD: 0,0,""
19:56:31.822 -> 
19:56:31.822 -> OK
19:56:31.856 -> AT+USORD=0,512

19:56:31.856 -> +USORD: 0,0,""
19:56:31.856 -> 
19:56:31.856 -> OK
19:56:31.856 -> AT+USORD=0,512

19:56:31.856 -> +USORD: 0,0,""
19:56:31.856 -> 
19:56:31.856 -> OK
terrasmart commented 4 years ago

@salvq There are many posts above, on this topic discussion, also mine, because it has been analyzed a lot. I personally believe to have done all the possible test in every possible configuration.

After more than 8 months of field work (real test, not laboratory) I came to the conclusion the board strictly needs a LiPo battery always connected, to have stable and consistent connections. This because the peak of current needed by SARA U201 during network registration (and also APN connection) is really high, more than 1A at 3G (and even more than 2A in 2G fallback).

LiPo 3,7V always connected, at least 1800 mAh. I'm using 3000 mAh 1C battery, to be sure. And USB cable connected, 5V 500 mAh, to recharge the LiPo.

I will do soon (next week) some new test with an external LiPo charging module (Adafruit USB LiIon/LiPoly charger - v1.2, id 259) which uses the MCP73833 chip and it seems to be the only one in the market where the BATT and LOAD are connected in parallel, so the current capacity of the LOAD outputs is the same as your battery's max discharge current rating.

I will keep you informed about the results.

pnndra commented 4 years ago

@salvq if you see 3A peaks for sure the resistor is the problem. unfortunately current consumption varies greatly depending on the signal quality. when the modem requests high currents the result is that the PMIC will limit current and hence will drop voltage. if the voltage drop exceeds the threshold it will either lock up the modem or reset the processor. i would not recommend shorting the resistor, maybe better change it with a smaller value such as 180 ohm which will give you 3A

salvq commented 4 years ago

@pnndra my PSU can supply 3A peaks for short time, I never measure the current but will try to change if this helps.

Please share which resistor it is, there are no description on the board.

Thanks

FrancMunoz commented 4 years ago

@terrasmart , I stopped developing with MKRGSM board. I ported all the code to another SAMD board and ALL the problems gone. The same code didn't hang the new board anymore. So, it's clear to me that MRKGSM has a serious design problem, maybe its design to last battery and low-power mode... won't waste more time to investigate why.

In my case, final client wasted almost 800 euros in MKRGSM's for prototypes that finally went to trash with their PCBs design... As far as i know... Arduino silently removed from their store... after that I fell lucky... our prototype is in final release and ready for production and has over-the-air updates so we can update it remotely with no cost.

I suggest to all that are developing something to go to production to stop using MKRGSM and try another boards I wasted 8 months with it.

Now, I think I won't build with Arduino anymore. For more details ask me private messages, I think it's not fair to put brand names here.

Hope it helps.

eiriksels commented 4 years ago

@FrancMunoz @terrasmart I add to FrancMunoz conclusions.The only use I have of the MKR1400 is basically as a MKR Zero by connecting it to a 4$ SIM800 module (only 2G modem). Works perfect without any issues.

terrasmart commented 4 years ago

I would like to buy an Arduino MKR NB 1500 to test how it works. The on board SARA-R410M-02B module operates in 4G, both using LTE Cat M1 or NB1. The library is MKRNB. I would like to study deeper the architecture of this board and the library.

In LTE Cat M1 Connected Mode, according to UBLOX datasheet, Peak current value during Tx is 0.5A. It is known 4G consumes much less than 3G and of course 2G.

Anybody experience with this board ?

salvq commented 4 years ago

@terrasmart as far as the datasheet states it only supports LTE IOT types networks. If you are talking about standard LTE 4G network where mobile phone operates this is not supported by NB 1500.

SARA-R410M-02B supports only LTE-M and NB-IOT. SARA-R412M adding supports for GPRS / EGPRS (2G type network).

As far as I can see there is not alternative within Arduino MKR family to MKR GSM 1400.

compunited commented 4 years ago

Bad idea to buy a mkr gsm. I've wasted a lot of money with it. There is a design error in the power supply circuit which leads to sudden hangs and crashes especially if you are using GSM900 which is quite common in Europe.